Professional Documents
Culture Documents
Metodologías, UML y
patrones de diseño
¢ <onceptos
¢ Lenguajes de modelado: UML
¢ Metologías:
± Metologías clásicas: RUP, Métrica, MSF
± Metologías ágiles: eXtreme Programming
¢ Patrones de diseño de sofware
¢ Arquitecturas dirigidas por modelos (MDA)
¢ Herramientas de modelado
|
<
Odell
Meyer
Pre- and Post-conditions
Shlaer-Mellor 2
Object life cycles
Harel
State <harts
Gamma et. al.
Frameworks, patterns,
notes
ñmbly Wirfs-Brock
Singleton classes Responsabilities
Fusion
Operation descriptions,
message numbering
~
2
M
M
M
M
M
M
] i
"
2
¢ 2
" captura una vista de un sistema del mundo real. ñs una
abstracción de dicho sistema, considerando un cierto propósito.
¢ !
" representación gráfica de una colección de elementos
de modelado, a menudo dibujada como un grafo con vértices
conectados por arcos.
2
J
J
÷
J
J J
!
2
!
"
2
2
± <
(
) ñntre un actor y un
caso de uso, denota la participación del actor en
el caso de uso determinado.
<
¢
(Relación entre dos casos de
uso, denota la inclusión del comportamiento
de un escenario en otro. Se utiliza cuando se
repite un caso de uso en dos o más casos
de uso separados. Frecuentemente no hay
actor asociado con el caso de uso común.
<
¢ <lase
¢ Objeto
¢ Herencia
¢ Interfaz
¢ Polimorfismo de clases
¢ <lases y atributos estáticos
¢ <lases y atributos finales
¢ <lases y métodos abstractos
!
¢ <
" representa un conjunto de entidades que
tienen en común propiedades, operaciones,
relaciones y semántica.
¢ Una clase es un constructor que define la estructura
y comportamiento de una colección de objeto
denominados instancia de la clase.
¢ ñn UML la clase está representada por un
rectángulo con tres divisiones internas, son los
elementos fundamentales del diagrama.
!
¢
" ñl conjunto de operaciones que
describen el comportamiento de los objetos de una
clase. La sintaxis de una operación en UML es:
¢ J
"
#
!
!
'
"
2
!
¢ (
" <ontrato u obligación de una
clase, asignada en el momento del diseño.
¢ <lase Producto:
± Registrar el código de la publicación.
± Mantener estructura del producto plantilla.
!
¢ )
"
± Modelado del vocabulario de un sistema a partir de
las descripciones funcionales.
± Modelado de la distribución de responsabilidades en
un sistema.
± Modelado de cosas que no son software (hardware,
personas, etc).
± Modelado de tipos primitivos.
!
¢ "
(rol, multiplicidad, calificador):
representan las relaciones entre instancias de clase.
Una asociación es una línea que une dos o más
clases.
!
¢ 2
" Describe la cardinalidad de la
relación, es decir, cuanto objetos de esa clase
pueden participar en la relación dada. Tipos:
!
¢ !
" ñs una relación donde existen entidades
independientes y otras dependientes, lo que implica que
cambiar el elemento independiente puede requerir
cambios en los dependientes. Se representa con una
línea punteada direccional, indicando el sentido de la
dependencia.
!
!
¢ "
*
" Representa una relación
sencilla entre dos clases, no muy fuerte (es decir,
no se exige dependencia existencial ni
encapsulamiento). Se indica como una línea sólida
que une dos clases.
¢ "
+
" ñs una asociación entre tres o
más clases. Se representa como un diamante del
cual salen líneas de asociación a las clases.
!
!
¢ "
" Relaciona una clase ya
ensamblada con una clase componente. ñs
también una relación de composición menos
fuerte (no se exige dependencia existencial)
y se denota por un rombo sin rellenar en un
o de los extremos.
!
!
¢ ,
" es un proceso de abstracción en el
cual un conjunto de clases existentes, que tienen
atributos y métodos comunes, es referido por una
clase genérica a un nivel mayor de abstracción. La
relación de generalización denota una relación de
herencia entre clases. Se representa dibujando un
triángulo sin rellenar en el lado de la superclase. La
subclase hereda todos los atributos y mensajes
descritos en la superclase.
!
!
¢ (
" ñs una relación que
representa la especificación completa de
algo que ya ha sido especificado con cierto
nivel de detalle. Por ejemplo, una clase del
diseño es un refinamiento de una clase de
análisis.
!
!
¢ )
"
± Modelado de dependencias simples.
± Modelado de herencia simple.
± Modelado de relaciones estructurales
(composiciones y agregaciones).
± Modelado de comentarios.
!
!
|
!
¢ !
<
"
± ñs una forma de representar interacción entre los objetos,
es decir, las relaciones entre ellos y la secuencia de los
mensajes de las iteraciones que están indicadas por un
número A diferencia de los diagramas de secuencia,
pueden mostrar el contexto de la operación (cuáles objetos
son atributos, cuáles temporales, etc) y ciclos en la
ejecución. Muestra como varios objetos colaboran en un
solo caso de uso.
!
!
¢ )
"
± Modelado dinámico del sistema.
± Implementación de un caso de uso en concreto para
cada diagrama.
± Modelado del flujo de control por ordenación temporal
(secuencia).
± Modelado del flujo de control por organización
(colaboración).
!
#
!
¢ !
#
"
± Muestra el conjunto de estado por los cuales
pasa un objeto durante su vida en una aplicación
junto con los cambios que permiten pasar de un
estado a otro. ñsta representado principalmente
por los siguientes elementos:
¢ ñstado.
¢ ñlemento.
¢ Transición.
!
¢ #
" Identifica un período de tiempo del objeto
(no instantáneo) en el cual el objeto esta esperando
alguna operación, tiene cierto estado característico o
puede recibir cierto tipo de estímulos.
!
¢ )
" ñs una relación entre estados de un
fuente a un destino.
¢ Partes que componen una transición:
± ñstado de origen.
± ñvento de disparo.
± <ondición de guarda.
± Acción.
± ñstado de destino.
!
¢
"
± Subestados. Secuenciales o no, resultan en una nueva
máquina de estados.
± ñstados de historia.
± ñstados de historia. Permiten a un conjunto de estados o
subestados de un objeto, recordar el estado que estaba
activo en su última ejecución. Si no existe historia, se
comenzaría por el estado inicial.
± Subestados concurrentes.
!
!
¢ )
"
± Modelado de la vida de un objeto. ñste tipo de
diagramas se asocian directamente a una clase.
!
"
!
"
¢ #
" " representa un estado
con acción interna, con lo menos una
transición que indica la culminación de la
acción (por medio de un evento implícito).
± Permite modular un paso dentro del algoritmo. Se
representan por un rectángulo con bordes
redondeados.
!
"
¢ #
"
" ñstado más general
que permite su descomposición en otro
diagrama de actividades interno, de nivel
más bajo.
± Su representación, en cuanto a la notación, es la
misma que el de Acción.
!
"
¢ <
"
± ñstado inicial. Representa el punto de entrada del
diagrama de actividades.
± ñstado final. Su existencia depende de si el
diagrama es cíclico.
± Ítem de decisión. Representado con un rombo,
permite tomar bifurcaciones condicionales.
!
"
¢ <
"
± <arriles o ³Swim Lanes´. Permiten acotar el área a
las cuales las actividades están asociadas
(departamentos, módulos del sistema, etc).
± Flujos con objetos. Hacer explícita la relación con una
entidad en concreto.
!
"
¢ )
" ñs la relación entre dos estados
y se encuentran unidos por flechas;
indicando que un objeto que está en el
primer estado realizará una acción
especificada y entrará en el segundo estado
cuando un evento implícito ocurra y unas
condiciones especificas sean satisfechas.
!
"
¢ )
"
± Bifurcaciones condicionales. Permiten tomar
distintos caminos dentro del diagrama en función
de una condición o ³guarda´.
± División y unión. Permiten representar el
paralelismo en la ejecución de actividades.
!
"
!
¢ )
"
± Modelado de un flujo de trabajo o Workflow. Uso intensivo de
estados de actividad, swim lanes y bifurcaciones
condicionales.
± Modelado de una operación concreta que resulta muy
complicada. Uso intensivo de transiciones (simples o
paralelas) y de estados de acción.
!
<
!
¢ )
"
± Modelado de ejecutables y bibliotecas.
± Modelado de tablas, archivos y documentos.
± Modelado y diseño de un API.
± Modelado del código fuente.
± Planificación de versiones ejecutables para su implementación
con Nant.
!
!
!
¢ )
"
± Modelado de procesadores y dispositivos.
± Modelado de distribución de componentes.
(-" # -
(
-
(
¢ Orígenes
± Modelo original Objectory definido por Ivan
Jacobson (1987)
± Rational Software compra la empresa de
Objectory (1995)
± Surge la primera versión de UML (1997)
± Se publica la primera versión del Proceso
Unificado de Rational - RUP (junio 1998)
<
¢ <entrado en la arquitectura
± <oncepto similar a la arquitectura de un edificio
¢ Varios planos con diferentes aspectos del edificio
¢ Tener una imagen completa del edificio antes que comience la construcción
± Arquitectura en software
¢ Diferentes vistas del sistema: estructural, funcional, dinámico, etc.
¢ Plataforma en la que va a operar
¢ Determina la forma del sistema
± Arquitectura: determina la forma del sistema
± <asos de uso: determinan la función del sistema
2
¢ Iterativo e incremental
± Descomposición de un proyecto grande en mini-proyectos
± <ada mini-proyecto es una iteración
± Las iteraciones deben estar controladas
± <ada iteración trata un conjunto de casos de uso
¢ Ventajas del enfoque iterativo
± Detección temprana de riesgos
± Administración adecuada del cambio
± Mayor grado de reutilización
± Mayor experiencia para el grupo de desarrollo
#
Dinámica
¢ <iclo: cada ciclo una nueva versión del producto
¢ Fase: ñtapas de un ciclo que finalizan en un HITO
¢ Iteración: Proceso de ingeniería sobre una funcionalidad
limitada del sistema
ñstática - Flujos de trabajo
¢ Artefactos
¢ Actividades
¢ Roles
#
¢ Roles Ã
¢ Actividades <2%
¢ Artefactos Ã
¢ Flujo de Trabajo < %
(
"
<
! &
! <
! '
!
~
!
<
<
<
<
<
!
Æ
¢ <omunicaci÷n
¢ Simplicidad
¢ Retroalimentaci÷n
¢ <oraje
(
¢ Programador "
¢ Jefe de Proyecto
± Responsable de decisiones "2
tcnicas ± Organiza y gu@a las
reuniones
± Responsable de construir el
± Asegura condiciones
sistema
adecuadas para el proyecto
± Sin distinci÷n entre analistas,
diseadores o codificadores
¢ <liente "<
± ñn XP, los programadores
disean, programan y realizan las ± ñs parte del equipo
¢ ~
%i g
± ñstablecen los requisitos del cliente
± Trozos de funcionalidad que aportan valor
± Se les asignan tareas de programaci÷n con un n de
horas de desarrollo
± Las establece el cliente
± Son la base para las pruebas funcionales
-
÷
£ £
÷
÷
£
£
£ £ ÷ @
£
£
£
£
£ £
÷
# &
÷
¢ Nombre
¢ Resumen o esencia de la solución
¢ <ontexto al que se aplica
¢ Razones para utlizar o no el patrón
¢ <onsideraciones de implementación
¢ <onsecuencias e implicaciones de su uso
¢ ñjemplo de uso (Test <ase)
¢ Patrones relacionados
-
÷
¢ Fundamentales
¢ De creación
¢ De partición
¢ ñstructurales
¢ De comportamiento
¢ De concurrencia
Æ
¢ Delegate
¢ Interface
¢ Abstract superclass
¢ Interface + abstract class
¢ Immutable
¢ Proxy
!
¢ Factory
¢ Builder
¢ Prototype
¢ Singleton
¢ Object pool
!
¢ Filter
¢ <omposite
¢ Read-only interface
#
¢ Adapter
¢ Iterator
¢ Bridge
¢ Façade
¢ Flyweight
¢ Dynamic linkage
¢ Virtual proxy
¢ Decorator
¢ <ache management
!
¢ <hain of responsibility
¢ <ommand
¢ Little language
¢ Mediator
¢ Snapshot
¢ Observer
¢ State
¢ Null object
¢ Strategy
¢ Template method
¢ Visitor
!
÷
#&
2Æ Ý2|
%1%
2(%3 5%(
2"%3
D4
" t
C l r : tri
D<
4D <
4
r: I t r
5%( D4-D 4
E i : I t r
D&4+D &4
D 4
(1$
:2"%3 5%('"
0 2"%3
7<
D&
89 7
"
9 2<
6
9 6
&9
8 &634
~
~
¢ Formato XMI
¢ Importación y exportación a este formato por parte
de las herramientas
¢ Base para las transformaciones en MDA