View
225
Download
0
Category
Preview:
Citation preview
Introducción al modeladoIntroducción al modelado
Metodologías, UML y patrones de diseñoMetodologías, UML y patrones de diseño
Mentor: MsC(c) Esp Alexis Olvany Torres Ch
Índice
Conceptos
Lenguajes de modelado: UML
Metologías:
� Metologías clásicas: RUP, Métrica, MSF� 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
Introducción a las metodologíasIntroducción a las metodologías
Componentes básicos
RUP. Técnicas y su aplicación a la gestión de
proyectos software orientados a objeto.
XP. Gestión ágil de proyectos y grupos de
desarrollo.desarrollo.
UML. Diagramas, elementos notacionales y
semántica de los modelos generados.
Modelado con UMLModelado con UML
Método y metodologías
• Un método es un proceso disciplinado para generar un
conjunto de modelos que describen varios aspectos de un
sistema de software en desarrollo, utilizando alguna
notación bien definida
• Una metodología es una colección de métodos aplicados• Una metodología es una colección de métodos aplicados
a lo largo del ciclo de vida del desarrollo de software y
unificados por alguna aproximación general o filosófica
NOTACIÓN
Una notación es un conjunto de diagramas normalizados que posibilita al analista o desarrollador el describir el comportamiento del sistema (análisis) y los detalles de una arquitectura (diseño) de forma no ambigua
– La acción de dibujar un diagrama no constituye ni análisis ni diseño
– Una notación no es un fin por si misma
– El hecho de que una notación sea detallada no significa que todos sus aspectos deban ser utilizados en todas las ocasionesaspectos deban ser utilizados en todas las ocasiones
– La notación son como los planos para un arquitecto o un ingeniero
– Una notación no es más que un vehículo para capturar los razonamientos acerca del comportamiento y la arquitectura de un sistema
– Las notaciones deben ser lo más independientes posibles de los lenguajes de programación, sin embargo facilita el proceso de desarrollo que exista una equivalencia entre la notación y los lenguajes de programación
– El propósito de este tema es describir la sintaxis y semántica de la notación que se utiliza para el análisis y diseño orientado a objetos
Qué es UML?
UML es un Lenguaje de Modelado Unificado basado en una
notación gráfica la cual permite: especificar, construir, visualizar
y documentar los objetos de un sistema programado.y documentar los objetos de un sistema programado.
Este lenguaje es el resultado de la unificación de los métodos de
modelado orientados a objetos de Booch, Rumbaugh (OMT:
Object Modeling Technique) y Jacobson (OOSE: Object-Oriented
Sotfware Engineering).
UML
UML es un lenguaje de modelado que sirve para visualizar,
especificar , construir y documentar un sistema software.
Lenguaje de modelado:
“Lenguaje cuyo vocabulario y reglas se centran en la representación
conceptual y física de un sistema” (Booch, Jacobson y Rumbaugh).conceptual y física de un sistema” (Booch, Jacobson y Rumbaugh).
UML para visualizar
� Símbolos con semántica bien definida.
� UML transciende al lenguaje de programación.
� Modelo explícito, que facilita la comunicación.� Modelo explícito, que facilita la comunicación.
UML para especificar
Especificar es equivalente a construir modelos que cumplan las
condiciones de no ambigüedad y completitud.
UML cubre la especificación del análisis, diseño e implementación
de un sistema software.
UML para construir
Es posible hacer
corresponder con los Ingeniería Directa
corresponder con los
lenguajes de
programación (Java,
C#, B.Datos, etc.).
Modelo
UML
Ingeniería Inversa
CÓDIGO
UML para documentar
UML cubre la documentación de un sistema:
– Requisitos
– Arquitectura
– Diseño
– Código fuente– Código fuente
– Planificación
– Pruebas
– Prototipos
– Versiones
UML “aglutina” enfoques OO
Rumbaugh
Jacobson
Meyer
Shlaer-Mellor
Odell
Booch
Pre- and Post-conditions
UMLHarel
Wirfs-BrockFusion
Embly
Gamma et. al.
Shlaer-Mellor
State Charts
Responsabilities
Operation descriptions,
message numbering
Singleton classes
Frameworks, patterns, notes
Object life cycles
Historia de UML
Nov ‘97 UML aprobado por el OMG
1998
1999
2000
UML 1.2
UML 1.3
UML 1.4
2001 UML 2.0
Revisiones menores
Actualizaciones de UML
UML 1.3 es una versión madura de UML a la que se le han añadido una serie de pequeñas revisiones, las cuales corrigen o mejoran la especificación base (UML 1.2).
UML 1.4 incorpora ciertas modificaciones sobre el estándar en base a los comentarios recogidos de los usuarios finales y de los fabricantes de software compatible con UML.software compatible con UML.
UML 2.0 promete la puesta a punto del estándar para poder integrarse con el desarrollo basado en componentes que demanda el mercado.
UML 2.0
Arquitectura: refinamiento del núcleo del estándar para que esté en consonancia con el resto de estándares del mercado.
Personalización: mejora de los mecanismos de extensibilidad y personalización.
Componentes: mejor soporte para el desarrollo basado en componentes (CORBA, EJB, COM+).
Mecanismos generales: nuevos mecanimos para el control de las versiones Mecanismos generales: nuevos mecanimos para el control de las versiones dentro del modelo, así como el intercambio de los metadatos del mismo con XMI (XML Metadad Interchange).
Modelos y Diagramas
� Un proceso de desarrollo de software debe ofrecer un conjunto de
modelos que permitan expresar el producto desde cada una de las
perspectivas de interés
� El código fuente del sistema es el modelo más detallado del sistema (y
además es ejecutable). Sin embargo, se requieren otros modelos ...además es ejecutable). Sin embargo, se requieren otros modelos ...
� Cada modelo es completo desde su punto de vista del sistema, sin
embargo, existen relaciones de trazabilidad entre los diferentes modelos
Modelos y Diagramas
Modelo: captura una vista de un sistema del mundo real. Es una abstracción
de dicho sistema, considerando un cierto propósito.
Diagrama: representación gráfica de una colección de elementos de Diagrama: representación gráfica de una colección de elementos de
modelado, a menudo dibujada como un grafo con vértices conectados
por arcos.
Vista de DiseñoVista de
Organización de Modelos
Vista de Diseño
Vista de Procesos
Vista de Despliegue
Vista deImplementación
Vista de los Casos de Uso
Diagramas de UML
Use CaseDiagramsUse CaseDiagramsDiagramas de Casos de Uso
Scenario State
StateDiagrams
StateDiagramsDiagramas de Objetos
Use CaseDiagramsUse CaseDiagramsDiagramas deSecuencia
StateDiagrams
StateDiagramsDiagramas de
Clases
ScenarioDiagramsScenarioDiagramsDiagramas deColaboración
StateDiagrams
StateDiagramsDiagramas deComponentes
ComponentDiagramsComponentDiagramsDiagramas deDistribución
ScenarioDiagramsScenarioDiagramsDiagramas deEstados Diagramas de
Actividad
Modelo
Mecanismos comunes en UML
� Especificaciones. Es más que un lenguaje gráfico (semántica detrás de la notación).
� Adornos. Detalles sobre un clase, nivel de acceso de sus métodos, notas.de sus métodos, notas.
� Divisiones Comunes: Clase/Objecto o Interfaz/Implementación.
� Extensibilidad. Estereotipos, valores etiquetados o restricciones.
Mecanismos comunes en UML
DIAGRAMAS DE CASOS DE USODIAGRAMAS DE CASOS DE USO
MsC (c) Esp. Alexis Ovany Torres Ch.damian7914@hotmail.com
Orientador Análisis y Diseño de Sistemas de Informacion
DIAGRAMAS DE CASOS DE USO
Los diagramas de casos de usodocumentan el comportamiento deun sistema desde el punto de vistadel usuario. El diagrama de casosde uso representa la forma encomo un Cliente (Actor) opera conel sistema en desarrollo, ademásde la forma, tipo y orden en comolos elemento interactúan.
� Actor
� Casos de Uso
� Relaciones de Uso, Herencia y Comunicación
ELEMENTOS
y Comunicación
Es un rol que un usuario juega conrespecto al sistema. Es importante destacarel uso de la palabra rol, pues con esto seespecifica que un Actor no necesariamenterepresenta a una persona en particular,
ACTOR
representa a una persona en particular,sino más bien la labor que realiza frente alsistema.
Es una operación/tarea específica que serealiza tras una orden de algún agenteexterno, sea desde una petición de un actoro bien desde la invocación desde otro caso
CASO DE USO
o bien desde la invocación desde otro casode uso.
Asociación
Es el tipo de relación más básica que indica la invocacióndesde un actor o caso de uso a otra operación (caso deuso). Dicha relación se denota con una flecha simple.
Dependencia o Instanciación
RELACIONES
Dependencia o Instanciación
Es una forma muy particular de relación entre clases, en lacual una clase depende de otra, es decir, se instancia (secrea). Dicha relación se denota con una flecha punteada.
Generalización
Este tipo de relación es uno de los más utilizados, cumpleuna doble función dependiendo de su estereotipo, quepuede ser de Uso (<<uses>>) o de Herencia (<<extends>>).
Su ventaja principal es la facilidad parainterpretarlos, lo que hace que seanespecialmente útiles en la comunicacióncon el cliente.
VENTAJAS
con el cliente.
Como ejemplo esta el caso de una MáquinaRecicladora:
Sistema que controla una máquina de reciclamientode botellas, tarros y jabas. El sistema debe controlar
Ejemplo:
de botellas, tarros y jabas. El sistema debe controlary/o aceptar:Registrar el número de ítemes ingresados.Imprimir un recibo cuando el usuario lo solicita:
� Describe lo depositado� El valor de cada ítem� Total
El usuario/cliente presiona el botón de comienzo
Existe un operador que desea saber lo siguiente:� Cuantos ítemes han sido retornados en el día.� Al final de cada día el operador solicita un
resumen de todo lo depositado en el día.resumen de todo lo depositado en el día.
El operador debe además poder cambiar:� Información asociada a ítemes.� Dar una alarma en el caso de que:
� Ítem se atora.� No hay más papel.
Como una primera aproximación identificamos a los actores que interactúan con el sistema:
Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Ítem o bien puede Imprimir un informe:
Además podemos notar que un ítem puede ser una Botella, un Tarro o una Jaba.
Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.
Entonces, el diseño completo del diagrama caso de uso es:
Recommended