UML 2.3 con Enterprise Architect

20
1 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 División de Alta Tecnología - DAT ANALISIS Y DISEÑO DE SOFTWARE

description

ANALISIS Y DISEÑO DE SOFTWARE

Transcript of UML 2.3 con Enterprise Architect

Page 1: UML 2.3 con Enterprise Architect

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

1

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

División de Alta Tecnología - DAT

ANALISIS Y DISEÑO DE SOFTWARE

Page 2: UML 2.3 con Enterprise Architect

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

2

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)

División de Alta Tecnología - DAT

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

UML 2.3 con Enterprise Architect

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

División de Alta Tecnología - DAT

Page 3: UML 2.3 con Enterprise Architect

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

3

UML 2.3 con Enterprise Architect

Capítulo 1:

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

1. Crisis del software

División de Alta Tecnología - DAT

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

División de Alta Tecnología - DAT

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.

1. Crisis del Software

Page 4: UML 2.3 con Enterprise Architect

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

4

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. Crisis del Software

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.

1. Crisis del Software

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

1. Crisis del Software

Page 5: UML 2.3 con Enterprise Architect

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

5

1.4. SOLUCIONES

Se recomienda:

Buen Análisis y Diseño

Construir un modelo sencillo

Usar un lenguaje de modelado

Compatible con diversas herramientas

1. Crisis del Software

UML 2.3 con Enterprise Architect

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

División de Alta Tecnología - DAT

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

2. El modelado

2.1 Introducción

2.2 La importancia de modelar

2.3 Modelamiento

2.4 Métodos para el modelado

División de Alta Tecnología - DAT

Page 6: UML 2.3 con Enterprise Architect

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

6

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.

2. El modelado

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

2.3. MODELAMIENTO

2. El modelado

Napoleón

Cervantes Concepto sin objeto

Objeto sin Concepto

2.4. MÉTODOS PARA EL MODELAMIENTO

2. El modelado

No-formales

Semi-formales

Formales

1

2

3

Page 7: UML 2.3 con Enterprise Architect

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

7

UML 2.3 con Enterprise Architect

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

División de Alta Tecnología - DAT

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

3. Conceptos Iniciales

3.1 Objeto

3.2 Orientación a objetos

3.3 Principio del software OO

3.4 Clases

División de Alta Tecnología - DAT

3.1 OBJETO

3. Conceptos Iniciales

Andrea Lamas Computador

Serie 26588-A

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

e inconfundibles”

Page 8: UML 2.3 con Enterprise Architect

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

8

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

3.1.2. CARACTERÍSTICAS

Atributos y Operaciones:

3.1. Objeto

Atributos:

Nombre

Estatura

Edad

Comportamiento (operación):

Caminar

Hablar

Saltar

3.1.2. CARACTERÍSTICAS

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

Page 9: UML 2.3 con Enterprise Architect

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

9

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. OBJETOS. Identificación de elementos

3. Conceptos iniciales

Objeto 1

Objeto 2

Objeto 3 Objeto 4

: Mensaje A

: Mensaje C

: Mensaje D

: Mensaje E

3.1.3. COMUNICACIÓN ENTRE OBJETOS

3.1. Objeto

LABORATORIO N° 1

En este laboratorio, usted:

Identificará los objetos del enunciado

Establecerá la diferencia con otros elementos

División de Alta Tecnología - DAT

Page 10: UML 2.3 con Enterprise Architect

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

10

3.2. ORIENTACIÓN A OBJETOS

3. Conceptos Iniciales

“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. Conceptos Iniciales

3.4. CLASES

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

3. Conceptos Iniciales

CLASE: Persona

Juan Arias

DNI 07715221

Ate

José López

DNI 08816721

Lince

Mary Falcón

DNI 05814423

San Borja

Page 11: UML 2.3 con Enterprise Architect

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

11

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)

3.4. Clases

Representación UML

+consulta_grado()+graba_sueldo()

-Apellidos-Nombres-Grado Academico

Profesor

LABORATORIO N° 2

En este laboratorio, usted:

Identificará las clases del enunciado.

Establecerá la diferencia con los objetos.

Identificará los elementos que servirán de atributos a las clases.

División de Alta Tecnología - DAT

Page 12: UML 2.3 con Enterprise Architect

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

12

UML 2.3 con Enterprise Architect

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

División de Alta Tecnología - DAT

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

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

División de Alta Tecnología - DAT

CONTROLAR CAMBIOS

ADMINISTRAR REQUERIMIENTOS

Arquitecturas Basadas en

Componentes

Desarrollar Iterativamente

Verificar Calidad

Modelizar Visualmente

4.1. LAS 6 MEJORES PRÁCTICAS

4. Buenas Prácticas

Page 13: UML 2.3 con Enterprise Architect

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

13

Planeamiento Inicial

Planeamiento

Requerimientos Análisis y Diseño

Implementación

Prueba

Distribución

Evaluación

Ambiente de Administración

4.1.1. DESARROLLAR SOFTWARE ITERATIVAMENTE

Cada iteración resulta en un release ejecutable

4.1. Las 6 mejores prácticas

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. Las 6 mejores prácticas

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

verifica Realización influenciados por

Los Casos de Uso direccionan

el trabajo desde el análisis

hasta el test

Modelo de Casos de Uso

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.

4.1. Las 6 mejores prácticas

Page 14: UML 2.3 con Enterprise Architect

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

14

4.1.2. ADMINISTRAR LOS REQUERIMIENTOS

4.1. Las 6 mejores prácticas

Necesito

algo para

balancearme

bajo un árbol

¿Cómo lo explicó el cliente?

¿Cómo son interpretados los requerimientos?

¿Cómo son interpretados los requerimientos?

4.1. Las 6 mejores prácticas

¿Cómo lo entendió el líder del proyecto?

¿Cómo fue descrito por el consultor?

¿Cómo fue analizado

y diseñado?

¿Cómo son interpretados los requerimientos?

4.1. Las 6 mejores prácticas

¿Cómo fue programado?

¿Cómo fue documentado?

¿Cómo fue instalado?

Page 15: UML 2.3 con Enterprise Architect

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

15

¿Cómo son interpretados los requerimientos?

4.1. Las 6 mejores prácticas

¿Cómo fue cobrado?

¿Qué soporte se brindó?

¿Qué necesitaba realmente el cliente?

System- software

Middleware

Negocio

Aplicación

Arquitectura basada en componentes

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.

4.1. Las 6 mejores prácticas

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.

4.1. Las 6 mejores prácticas

Page 16: UML 2.3 con Enterprise Architect

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

16

Código

Clases

Subsistemas

La Modelización

Visual eleva el nivel

de abstracción

4.1.4. MODELAR SOFTWARE VISUALMENTE

4.1. Las 6 mejores prácticas

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. Las 6 mejores prácticas

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.

4.1. Las 6 mejores prácticas

Desarrollo Implementación

Costo Encontrar y reparar un

problema de software después

de la implementación puede

resultar de 100 a 1000 veces

más costoso

Page 17: UML 2.3 con Enterprise Architect

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

17

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. Las 6 mejores prácticas

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

4.1. Las 6 mejores prácticas

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.

4.1. Las 6 mejores prácticas

Page 18: UML 2.3 con Enterprise Architect

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

18

4.2. CONSECUENCIAS DE NO APLICAR LAS

BUENAS PRÁCTICAS

4. 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. Consecuencias de no aplicar las buenas prácticas

4.2.3. LAS MEJORES PRÁCTICAS ENFRENTAN LAS CAUSAS

4.2. Consecuencias de no aplicar las buenas prácticas

Page 19: UML 2.3 con Enterprise Architect

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

19

SOLUCIÓN A LOS PROBLEMAS DE SW

Mejorar el proceso de desarrollo de Software

División de Alta Tecnología - DAT

Seleccionar el

mejor método de

desarrollo

Seleccionar el

mejor estándar

de modelado

LABORATORIO N° 3

En este laboratorio, usted:

Reconocerá las 6 mejores prácticas.

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

División de Alta Tecnología - DAT

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

División de Alta Tecnología - DAT

Page 20: UML 2.3 con Enterprise Architect

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

20

BIBLIOGRAFÍA RECOMENDADA

El Proceso Unificado de Desarrollo de Software.

Jacobson I., Rumbaugh J., BOOCH G.

2000. Addison Wesley.

El Lenguaje Unificado de Modelado.

Jacobson I., Rumbaugh J., BOOCH G.

2000. Addison Wesley.

El Lenguaje Unificado de Modelado. Manual de Referencia.

Jacobson I., Rumbaugh J., BOOCH G.

2000. Addison Wesley.

División de Alta Tecnología - DAT