Post on 03-Jul-2015
description
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
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
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
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
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
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
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”
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
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
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
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
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
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
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?
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
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
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
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
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
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