UML 2.3 con Enterprise Architect

División de Alta Tecnología – DAT
UML 2.3 con Enterprise Architect

ANALISIS Y DISEÑO DE SOFTWARE

UML 2.3 con Enterprise
Architect

OBJETIVOS DEL CURSO

 Usar UML para el análisis y diseño orientado a
objetos.
 Aplicar el análisis y diseño iterativo, basado en casos
de uso para desarrollar modelos eficientes y
robustos.
 Modelar clases, objetos, componentes, atributos,
operaciones, relaciones, multiplicidad.
 Analizar un problema concreto para representar una
realidad en objetos y transformarla en un modelo
UML por medio de una herramienta
 Manipular los diagramas en UML 2.3
 Generar código y actualizar el modelo.

División de Alta Tecnología - DAT

METODOLOGÍA DEL CURSO

 45 horas de Teoría y práctica.
 Material audiovisual
 Libro del curso, presentaciones
 Participación individual y grupal
 Laboratorios en clase


1


EVALUACIÓN DEL CURSO

 PPC = Promedio de prácticas calificadas
 2 Prácticas calificadas (sesiones por definir)
 Tareas
 TF = Trabajo Final (Última sesión)
 EF = Examen Final (Penúltima sesión)

Promedio = 30% (PPC) + 30% TF + 40% EF


UML 2.3 con Enterprise
Architect

Capitulo 1. Introducción al
Análisis y Diseño
orientado a Objetos


Capítulo 1:
Introducción al Análisis y Diseño orientado
a Objetos

Temas:
1. Crisis del software
2. El modelado
3. Conceptos iniciales
4. Buenas prácticas


2



Capítulo 1:
a Objetos



Introducción al Análisis y Diseño orientado a Objetos

1. Crisis del Software

1.1 Introducción
1.2 Síntomas
1.3 Razones
1.4 Soluciones


1.1. INTRODUCCIÓN

 La crisis del software:
 No satisface los requerimientos.
 No satisface las necesidades del cliente.
 Excede los presupuestos.
 Excede el cronograma inicial.


3


1.1. INTRODUCCIÓN

 Casos:
 El departamento de vehículos motorizados de
California gastó sobre $43 millones de dólares
en un sistema para fundir los sistemas de
conductores y registro de vehículos
 El sistema fue abandonado sin ni siquiera
haber sido usado.
 Un fallido esfuerzo de $165 millones de
dólares de American Airlines de vincular su
software de reserva de pasajes con el sistema
de reservaciones de Marriott, Hilton y Budget.


1.2. SÍNTOMAS

 Baja calidad del producto de software.
 Tiempo y presupuesto inicial excedido.
 Confiabilidad cuestionable.
 Altos requerimientos de personal para desarrollo
y mantenimiento.

Figura: http://thumbs.dreamstime.com/thumb_0/1083885788In01Lh.jpg


1.3. RAZONES

 Algunas razones:
 Base Inestable
 Fallas en el manejo del riesgo
 La complejidad del software


4


1.4. SOLUCIONES

 Se recomienda:
 Buen Análisis y Diseño
 Construir un modelo sencillo
 Usar un lenguaje de modelado
 Compatible con diversas herramientas



Capítulo 1:
a Objetos

Temas:
2. El modelado



2. El modelado

2.1 Introducción
2.2 La importancia de modelar
2.3 Modelamiento
2.4 Métodos para el modelado


5


2.2. LA IMPORTANCIA DE MODELAR

 La elaboración de un modelo para el desarrollo
de un sistema antes de su programación es tan
importante como tener un modelo (planos) y los
cimientos antes de construir una casa.

“Un modelo es la simplificación de la realidad”

2. El modelado

2.3. MODELAMIENTO

Cervantes
Concepto
sin objeto

Objeto sin
Concepto

Napoleón

2. El modelado

2.4. MÉTODOS PARA EL MODELAMIENTO

1 No-formales

2 Semi-formales

3 Formales

2. El modelado

6



Capítulo 1:
a Objetos

Temas:
2. El modelado



3. Conceptos Iniciales
3.1 Objeto
3.2 Orientación a objetos
3.3 Principio del software OO
3.4 Clases


3.1 OBJETO

“Es un ente real o conceptual que posee
características y comportamiento propios, únicos
e inconfundibles”

Computador
Andrea Lamas
Serie 26588-A


7


3.1.2. CARACTERÍSTICAS

 Identidad:
 Cada objeto tiene una identidad única, incluso
si su estado es idéntico al de otro objeto.

3.1. Objeto


 Atributos y Operaciones:
 Atributos:
 Nombre
 Estatura
 Edad

 Comportamiento
(operación):
 Caminar
 Hablar
 Saltar

3.1. Objeto


 Comportamiento
 Agrupa las competencias de un objeto
 Conocido como OPERACIÓN
 Es consecuencia de un estímulo externo
(mensaje)
Ejemplo: Prender CPU

 Estado
 Representado por los valores de los
atributos
Ejemplo: Prendido, apagado

3.1. Objeto

8


3.1. OBJETOS. Identificación de elementos

Imaginemos que tenemos estacionado
en nuestra cochera un Audi - A8 6.0
450CV quattro, color azul que corre
hasta 250 km/h.

Marca = Audi
Modelo = A8 6.0 450CV quattro
Color = Azul
Velocidad Máxima = 250 km/h

Cuando a las características del objeto se le asignan valores, se dice
que el objeto tiene estados.


3.1.3. COMUNICACIÓN ENTRE OBJETOS

Objeto 1

: Mensaje A

Objeto 2

: Mensaje E
: Mensaje C

Objeto 3 Objeto 4

: Mensaje D

3.1. Objeto

LABORATORIO N° 1

 En este laboratorio, usted:
 Identificará los objetos del enunciado
 Establecerá la diferencia con otros elementos


9


3.2. ORIENTACIÓN A OBJETOS

“Conjunto de disciplinas que desarrollan y
modelizan software que facilitan la construcción
de sistemas a partir de componentes.”


3.3 PRINCIPIOS DEL SW OO

 Abstracción
 Encapsulamiento
 Principio cliente-servidor
 Jerarquías
 Polimorfismo
 Modularidad
 Persistencia


3.4. CLASES

 Conjunto de objetos con características
(atributos) y comportamientos (operaciones)
similares.

Juan Arias José López Mary Falcón
DNI 07715221 DNI 08816721 DNI 05814423
CLASE:
Ate Lince San Borja
Persona


10


3.4.2. NOMBRAMIENTO DE CLASES

 Guía de estilo:
 Usar un sustantivo singular.
 Los nombres de la clase deben empezar con
mayúsculas.
 No debe usarse el subrayado.
 Los nombres compuestos se ponen juntos y la
primera palabra se escribirá con mayúscula.

 Ejemplo:
 Alumno, SistemaDePago

3.4. Clases

3.4.3. NOTACIÓN DE CLASES EN UML

 Representación gráfica
 Nombre
 Estructura (atributos)
 Comportamiento (operaciones)

Profesor
-Apellidos
-Nombres
-Grado Academico
+consulta_grado()
+graba_sueldo()

Representación UML

3.4. Clases

LABORATORIO N° 2

 Identificará las clases del enunciado.
 Establecerá la diferencia con los objetos.
 Identificará los elementos que servirán de
atributos a las clases.


11



Capítulo 1:
a Objetos

Temas:
2. El modelado



4. Buenas Prácticas
4.1. Las 6 mejores prácticas
a) Desarrollar software iterativamente
b) Administrar los requerimientos
c) Utilizar arquitecturas basadas en componentes
d) Modelar software visualmente
e) Verificar la calidad del software
f) Controlar los cambios al software
4.2. Consecuencias de no aplicar las buenas prácticas


4.1. LAS 6 MEJORES PRÁCTICAS

ADMINISTRAR REQUERIMIENTOS

Arquitecturas
Desarrollar Verificar Modelizar
Basadas en
Iterativamente Calidad Visualmente
Componentes

CONTROLAR CAMBIOS


12


4.1.1. DESARROLLAR SOFTWARE ITERATIVAMENTE

 Cada iteración resulta en un release ejecutable

Requerimientos
Análisis y Diseño
Planeamiento
Implementación
Planeamiento
Inicial Ambiente de
Administración

Distribución

Evaluación
Prueba


4.1.1. DESARROLLAR SOFTWARE ITERATIVAMENTE

 Características:
 Los desentendimientos importantes se
evidencian tempranamente.
 Se alienta el feedback del usuario.
 Focalización en los temas más críticos, sin
distracciones.
 Testing continuo e iterativo: evaluación
objetiva.
 Detección temprana de inconsistencias entre
requerimientos, diseños e implementaciones.


4.1.2. ADMINISTRAR LOS REQUERIMIENTOS

 Los requerimientos pueden ser adecuadamente
capturados y comunicados, a través de Casos de
Uso.
 Los Casos de Uso son importantes instrumentos
de planificación.

Modelo de Casos de Uso

Los Casos de Uso direccionan
el trabajo desde el análisis Realización influenciados por verifica
hasta el test

Modelo de Diseño
Modelo de Implementación Modelo de Test


13


4.1.2. ADMINISTRAR LOS REQUERIMIENTOS

¿Cómo son interpretados los
requerimientos?

Necesito
algo para
balancearme
bajo un árbol
¿Cómo lo explicó el
cliente?


¿Cómo son interpretados los requerimientos?

¿Cómo lo entendió el ¿Cómo fue descrito ¿Cómo fue analizado
líder del proyecto? por el consultor? y diseñado?



¿Cómo fue ¿Cómo fue ¿Cómo fue
programado? documentado? instalado?


14



¿Cómo fue ¿Qué soporte se ¿Qué necesitaba
cobrado? brindó? realmente el cliente?


4.1.3. UTILIZAR ARQUITECTURAS BASADAS EN
COMPONENTES

 Un componente de software puede definirse como
una pieza no trivial de software, un módulo o un
subsistema que completa una función clara, tiene
límites claros y puede ser integrado en una
arquitectura bien definida.

Aplicación

Negocio

Arquitectura basada Middleware
en componentes
System-
software


4.1.3. UTILIZAR ARQUITECTURAS BASADAS EN
COMPONENTES

 La Arquitectura de Software representa el
conjunto de decisiones significativas sobre la
organización de un sistema de software:
 Selección de los elementos estructurales y sus
interfaces, por los cuales el sistema está compuesto.
 Comportamiento, especificado como colaboraciones
entre los elementos.
 Composición en subsistemas de los elementos
estructurales y de comportamiento.
 Estilo de arquitectura que guía a la organización.


15


4.1.4. MODELAR SOFTWARE VISUALMENTE

Subsistemas

La Modelización
Clases
Visual eleva el nivel
de abstracción
Código


4.1.4. MODELAR SOFTWARE VISUALMENTE

 Beneficios:
 Los casos de uso permiten especificar
comportamiento sin ambigüedades.
 Quedan expuestas las arquitecturas
inflexibles o no modulares.
 El diseño refleja sus inconsistencias más
rápidamente.
 Existen herramientas que proveen soporte
para la modelización visual.


4.1.5. VERIFICAR LA CALIDAD DEL SOFTWARE

 La actividad fundamental de esta práctica es el
testing.
 Evaluar continuamente la calidad de un sistema
con respecto a funcionalidad, confiabilidad y
performance.

Encontrar y reparar un Costo
problema de software después
de la implementación puede
resultar de 100 a 1000 veces
más costoso
Desarrollo Implementación


16


4.1.5. VERIFICAR LA CALIDAD DEL SOFTWARE

 Beneficios:
 La evaluación del estado del proyecto es
objetiva, pues se evalúan resultados de test.
 Se exponen las inconsistencias en los
requerimientos, diseños e implementaciones.
 Se focaliza en las áreas de riesgo más alto.
 Los defectos se identifican en forma
temprana.
 Existen herramientas automatizadas para el
testing de funcionalidad, confiabilidad y
performance.


4.1.6. CONTROLAR LOS CAMBIOS AL SOFTWARE

El manejo del cambio es más que apenas comprobar dentro y fuera de
archivos. Incluye el manejo de espacios de trabajo, del desarrollo
paralelo, de la integración y de construcciones.


4.1.6. CONTROLAR LOS CAMBIOS AL SOFTWARE

 Beneficios:
 Las solicitudes de cambios formales facilitan
la claridad de comunicación.
 Los espacios de trabajo aislados reducen la
interferencia entre los miembros del equipo
que trabajan en paralelo.
 Las estadísticas de cantidad de cambios
proveen buenas métricas para evaluar
objetivamente el estado del proyecto.
 La propagación del cambio es evaluable y
controlable.
 Los cambios pueden ser mantenidos en
sistemas automáticos.


17


4.2. CONSECUENCIAS DE NO APLICAR LAS
BUENAS PRÁCTICAS

Baja
Calidad del
software


4.2.1. Detección del fracaso en un proyecto

 No cumplen sus objetivos.
 Se exceden considerablemente en el tiempo.
 Se exceden de su presupuesto.
 No se comprendieron las necesidades del
usuario.
 No se previó el impacto de los requerimientos
de cambios.
 Se descubrieron muy tarde falencias graves
en el Proyecto.
 Hay módulos que no se pueden integrar.
 Interferencias entre los miembros del equipo.


4.2.3. LAS MEJORES PRÁCTICAS ENFRENTAN LAS CAUSAS


18


SOLUCIÓN A LOS PROBLEMAS DE SW

 Mejorar el proceso de desarrollo de Software

Seleccionar el Seleccionar el
mejor método de mejor estándar
desarrollo de modelado


LABORATORIO N° 3

 Reconocerá las 6 mejores prácticas.
 Identificará como se aplican las 6 mejores
prácticas en el desarrollo de un proyecto.


BIBLIOGRAFÍA RECOMENDADA

 UML 2 Toolkit.
 OMG Press
 Autores: Hans-Erik Eriksson, Magnus Perker,
Brian Lyons, David Fado.

 UML 2.0,
 Anaya Multimedia
 Autores: Jim Arlow, Ila Neustadt


19


BIBLIOGRAFÍA RECOMENDADA

 El Proceso Unificado de Desarrollo de Software.
 Jacobson I., Rumbaugh J., BOOCH G.
 2000. Addison Wesley.
 El Lenguaje Unificado de Modelado.
 El Lenguaje Unificado de Modelado. Manual de
Referencia.


20

UML 2.3 con Enterprise Architect

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (16)

Destacado

Destacado (15)

Similar a UML 2.3 con Enterprise Architect

Similar a UML 2.3 con Enterprise Architect (20)

UML 2.3 con Enterprise Architect