PowerPoint Capitulo 1 (Modo de Compatibilidad)

Divisin de Alta Tecnologa DAT
UML 2.3 con Enterprise Architect

1
UML 2.3 con Enterprise
Architect
OBJETIVOS DEL CURSO
Usar UML para el anlisis y diseo orientado a
objetos.
Aplicar el anlisis y diseo 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 cdigo y actualizar el modelo.
Divisin de Alta Tecnologa - DAT
METODOLOGA DEL CURSO
45 horas de Teora y prctica.
Material audiovisual
Libro del curso, presentaciones
Participacin individual y grupal
Laboratorios en clase

2
EVALUACIN DEL CURSO
PPC = Promedio de prcticas calificadas
2 Prcticas calificadas (sesiones por definir)
Tareas
TF = Trabajo Final (ltima sesin)
EF = Examen Final (Penltima sesin)

Promedio = 30% (PPC) + 30% TF + 40% EF
UML 2.3 con Enterprise
Architect
Capitulo 1. Introduccin al
Anlisis y Diseo
orientado a Objetos
Captulo 1:
Introduccin al Anlisis y Diseo orientado
a Objetos

Temas:
1. Crisis del software
2. El modelado
3. Conceptos iniciales
4. Buenas prcticas
3
Captulo 1:
a Objetos

Introduccin al Anlisis y Diseo orientado a Objetos
1. Crisis del Software

1.1 Introduccin
1.2 Sntomas
1.3 Razones
1.4 Soluciones
1.1. INTRODUCCIN
La crisis del software:
No satisface los requerimientos.
No satisface las necesidades del cliente.
Excede los presupuestos.
Excede el cronograma inicial.
4
1.1. INTRODUCCIN
Casos:
El departamento de vehculos motorizados de
California gast sobre $43 millones de dlares
en un sistema para fundir los sistemas de
conductores y registro de vehculos
El sistema fue abandonado sin ni siquiera
haber sido usado.
Un fallido esfuerzo de $165 millones de
dlares de American Airlines de vincular su
software de reserva de pasajes con el sistema
de reservaciones de Marriott, Hilton y Budget.
1.2. SNTOMAS
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

5
1.4. SOLUCIONES
Se recomienda:
Buen Anlisis y Diseo
Construir un modelo sencillo
Usar un lenguaje de modelado
Compatible con diversas herramientas

Captulo 1:
a Objetos

Temas:
2. El modelado
4. Buenas prcticas
2. El modelado

2.1 Introduccin
2.2 La importancia de modelar
2.3 Modelamiento
2.4 Mtodos para el modelado
6
2.2. LA IMPORTANCIA DE MODELAR
La elaboracin de un modelo para el desarrollo
de un sistema antes de su programacin es tan
importante como tener un modelo (planos) y los
cimientos antes de construir una casa.

2. El modelado
Un modelo es la simplificacin de la realidad
2.3. MODELAMIENTO
2. El modelado
Napolen
Cervantes
Concepto
sin objeto
Objeto sin
Concepto
2.4. MTODOS PARA EL MODELAMIENTO
2. El modelado
No-formales
Semi-formales
Formales
1
2
3
7
Captulo 1:
a Objetos

Temas:
2. El modelado
4. Buenas prcticas
3. Conceptos Iniciales
3.1 Objeto
3.2 Orientacin a objetos
3.3 Principio del software OO
3.4 Clases
3.1 OBJETO
Andrea Lamas
Computador
Serie 26588-A
Es un ente real o conceptual que posee
caractersticas y comportamiento propios, nicos
e inconfundibles
8
3.1.2. CARACTERSTICAS
Identidad:
Cada objeto tiene una identidad nica, incluso
si su estado es idntico al de otro objeto.
3.1. Objeto
Atributos y Operaciones:
3.1. Objeto
Atributos:
Nombre
Estatura
Edad

Comportamiento
(operacin):
Caminar
Hablar
Saltar

Comportamiento
Agrupa las competencias de un objeto
Conocido como OPERACIN
Es consecuencia de un estmulo externo
(mensaje)
Ejemplo: Prender CPU

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

3.1. Objeto
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 Mxima = 250 km/h
Cuando a las caractersticas del objeto se le asignan valores, se dice
que el objeto tiene estados.
3.1. OBJETOS. Identificacin de elementos
Objeto 1
Objeto 2
Objeto 3 Objeto 4
: Mensaje A
: Mensaje C
: Mensaje D
: Mensaje E
3.1.3. COMUNICACIN ENTRE OBJETOS
3.1. Objeto
LABORATORIO N 1
En este laboratorio, usted:
Identificar los objetos del enunciado
Establecer la diferencia con otros elementos

10
3.2. ORIENTACIN A OBJETOS
Conjunto de disciplinas que desarrollan y
modelizan software que facilitan la construccin
de sistemas a partir de componentes.

3.3 PRINCIPIOS DEL SW OO
Abstraccin
Encapsulamiento
Principio cliente-servidor
Jerarquas
Polimorfismo
Modularidad
Persistencia

3.4. CLASES
Conjunto de objetos con caractersticas
(atributos) y comportamientos (operaciones)
similares.

CLASE:
Persona
Juan Arias
DNI 07715221
Ate
Jos Lpez
DNI 08816721
Lince
Mary Falcn
DNI 05814423
San Borja
11
3.4.2. NOMBRAMIENTO DE CLASES
Gua de estilo:
Usar un sustantivo singular.
Los nombres de la clase deben empezar con
maysculas.
No debe usarse el subrayado.
Los nombres compuestos se ponen juntos y la
primera palabra se escribir con mayscula.

Ejemplo:
Alumno, SistemaDePago

3.4. Clases
3.4.3. NOTACIN DE CLASES EN UML
Representacin grfica
Nombre
Estructura (atributos)
Comportamiento (operaciones)

3.4. Clases
Representacin UML
+consulta_grado()
+graba_sueldo()
-Apellidos
-Nombres
-Grado Academico
Profesor
LABORATORIO N 2
Identificar las clases del enunciado.
Establecer la diferencia con los objetos.
Identificar los elementos que servirn de
atributos a las clases.

12
Captulo 1:
a Objetos

Temas:
2. El modelado
4. Buenas prcticas
4. Buenas Prcticas
4.1. Las 6 mejores prcticas
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 prcticas
CONTROLAR CAMBIOS
ADMINISTRAR REQUERIMIENTOS
Arquitecturas
Basadas en
Componentes
Desarrollar
Iterativamente
Verificar
Calidad
Modelizar
Visualmente
4.1. LAS 6 MEJORES PRCTICAS
4. Buenas Prcticas
13
Planeamiento
Inicial
Planeamiento
Requerimientos
Anlisis y Diseo
Implementacin
Prueba
Distribucin
Evaluacin
Ambiente de
Administracin
4.1.1. DESARROLLAR SOFTWARE ITERATIVAMENTE
Cada iteracin resulta en un release ejecutable

4.1.1. DESARROLLAR SOFTWARE ITERATIVAMENTE
Caractersticas:
Los desentendimientos importantes se
evidencian tempranamente.
Se alienta el feedback del usuario.
Focalizacin en los temas ms crticos, sin
distracciones.
Testing continuo e iterativo: evaluacin
objetiva.
Deteccin temprana de inconsistencias entre
requerimientos, diseos e implementaciones.


Modelo de Diseo
Modelo de Implementacin Modelo de Test
verifica Realizacin influenciados por
Los Casos de Uso direccionan
el trabajo desde el anlisis
hasta el test
Modelo de Casos de Uso
4.1.2. ADMINISTRAR LOS REQUERIMIENTOS
Los requerimientos pueden ser adecuadamente
capturados y comunicados, a travs de Casos de
Uso.
Los Casos de Uso son importantes instrumentos
de planificacin.

14
4.1.2. ADMINISTRAR LOS REQUERIMIENTOS
Necesito
algo para
balancearme
bajo un rbol
Cmo lo explic el
cliente?
Cmo son interpretados los
requerimientos?
Cmo son interpretados los requerimientos?
Cmo lo entendi el
lder del proyecto?
Cmo fue descrito
por el consultor?
Cmo fue analizado
y diseado?
Cmo fue
programado?
Cmo fue
documentado?
Cmo fue
instalado?
15
Cmo fue
cobrado?
Qu soporte se
brind?
Qu necesitaba
realmente el cliente?
System-
software
Middleware
Negocio
Aplicacin
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 mdulo o un
subsistema que completa una funcin clara, tiene
lmites claros y puede ser integrado en una
arquitectura bien definida.

4.1.3. UTILIZAR ARQUITECTURAS BASADAS EN
COMPONENTES
La Arquitectura de Software representa el
conjunto de decisiones significativas sobre la
organizacin de un sistema de software:
Seleccin de los elementos estructurales y sus
interfaces, por los cuales el sistema est compuesto.
Comportamiento, especificado como colaboraciones
entre los elementos.
Composicin en subsistemas de los elementos
estructurales y de comportamiento.
Estilo de arquitectura que gua a la organizacin.

16
Cdigo
Clases
Subsistemas
La Modelizacin
Visual eleva el nivel
de abstraccin
4.1.4. MODELAR SOFTWARE VISUALMENTE
4.1.4. MODELAR SOFTWARE VISUALMENTE
Beneficios:
Los casos de uso permiten especificar
comportamiento sin ambigedades.
Quedan expuestas las arquitecturas
inflexibles o no modulares.
El diseo refleja sus inconsistencias ms
rpidamente.
Existen herramientas que proveen soporte
para la modelizacin visual.

4.1.5. VERIFICAR LA CALIDAD DEL SOFTWARE
La actividad fundamental de esta prctica es el
testing.
Evaluar continuamente la calidad de un sistema
con respecto a funcionalidad, confiabilidad y
performance.

Desarrollo Implementacin
Costo
Encontrar y reparar un
problema de software despus
de la implementacin puede
resultar de 100 a 1000 veces
ms costoso
17
4.1.5. VERIFICAR LA CALIDAD DEL SOFTWARE
Beneficios:
La evaluacin del estado del proyecto es
objetiva, pues se evalan resultados de test.
Se exponen las inconsistencias en los
requerimientos, diseos e implementaciones.
Se focaliza en las reas de riesgo ms alto.
Los defectos se identifican en forma
temprana.
Existen herramientas automatizadas para el
testing de funcionalidad, confiabilidad y
performance.

El manejo del cambio es ms que apenas comprobar dentro y fuera de
archivos. Incluye el manejo de espacios de trabajo, del desarrollo
paralelo, de la integracin y de construcciones.
4.1.6. CONTROLAR LOS CAMBIOS AL SOFTWARE
4.1.6. CONTROLAR LOS CAMBIOS AL SOFTWARE
Beneficios:
Las solicitudes de cambios formales facilitan
la claridad de comunicacin.
Los espacios de trabajo aislados reducen la
interferencia entre los miembros del equipo
que trabajan en paralelo.
Las estadsticas de cantidad de cambios
proveen buenas mtricas para evaluar
objetivamente el estado del proyecto.
La propagacin del cambio es evaluable y
controlable.
Los cambios pueden ser mantenidos en
sistemas automticos.
18
4.2. CONSECUENCIAS DE NO APLICAR LAS
BUENAS PRCTICAS
4. Buenas Prcticas
Baja
Calidad del
software
4.2.1. Deteccin 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 mdulos que no se pueden integrar.
Interferencias entre los miembros del equipo.

4.2.3. LAS MEJORES PRCTICAS ENFRENTAN LAS CAUSAS
19
SOLUCIN A LOS PROBLEMAS DE SW
Mejorar el proceso de desarrollo de Software

Seleccionar el
mejor mtodo de
desarrollo
Seleccionar el
mejor estndar
de modelado
LABORATORIO N 3
Reconocer las 6 mejores prcticas.
Identificar como se aplican las 6 mejores
prcticas en el desarrollo de un proyecto.
BIBLIOGRAFA 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
20
BIBLIOGRAFA 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.

PowerPoint Capitulo 1 (Modo de Compatibilidad)

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PowerPoint Capitulo 1 (Modo de Compatibilidad)

Transféré par

Droits d'auteur :

Formats disponibles

Divisin de Alta Tecnologa DAT

UML 2.3 con Enterprise Architect

Vous aimerez peut-être aussi