Transcript
Metodología UML
Miguel Almeyda MVP Client App Dev CEO Integration and Development Solutions
Agenda Introducción al UML Loss Cas Lo Casos os de Us Usoo Los Diag Diagramas ramas de Inter Interacci acción ón Fundam Fun dament entos os en la Tecn ecnolo ología gía Ori Orient entada ada a Obje Objetos tos Principios del Soft Principios Software ware Orien Orientado tado a Objet Objetos: os: Diagr Diagramas amas de Clases
Agenda Introducción al UML Loss Cas Lo Casos os de Us Usoo Los Diag Diagramas ramas de Inter Interacci acción ón Fundam Fun dament entos os en la Tecn ecnolo ología gía Ori Orient entada ada a Obje Objetos tos Principios del Soft Principios Software ware Orien Orientado tado a Objet Objetos: os: Diagr Diagramas amas de Clases
Introducción al UML
¿Qué es UML?
UML = Unified Modeling Language Un lenguaje de propósito general para el modelado orientado a objetos. UML combina notaciones provenientes desde: – – – –
Modelado Orientado a Objetos Modelado de Datos Modelado de Componentes Modelado de Flujos de Trabajo (Workflows)
Historia de UML
Comenzó como el “Método Unificado”, con la partitici par cipac pación ión de Grad Gradyy Booch Booch y Jim Jim Rum Rumbau baugh. gh. Se presentó en el OOPSLA’95 El mism mismoo año se unió unió Ivar Ivar Jaco Jacobson bson.. Los “Tres Amigos” son socios en la compañía Rationa Rat ionall Sof Softwar tware: e: Herramien Herramienta ta CASE Rational Rational Rose.
Historia de UML UML 2.0
2001
UML 1.4
2000
UML 1.3
1999
Revisiones menores
1998 Nov ‘97
UML 1.2 UML aprobado por el OMG
Participantes en UML 1.0
Rationa Ratio nall So Softftwa ware re (Grady Booch, Jim Rumb Ru mbau augh gh y Iva Ivarr Jacobson) Digital Equipment Hewlett-Packard i-Logi i-L ogixx (Da (David vid Har Harel) el) IBM ICON Computing (Desmond D’Souza) Intell Int ellico icorp rp and Jam James es Martin & co. (James Odell)
MCI Systemhouse Microsoft ObjecTime Oracle Platin Pla tinium ium Tec Techno hnolog logyy Ster St erliling ng So Softftwa ware re Taskon Texas Instruments Unisys
Perspectivas para el UML UML es el lenguaje de modelización de objetos estándar, predominante para los próximos años • Razones: •
Participación de metodólogos influyentes Participación de importantes empresas Aceptación del OMG como notación estándar Herramientas que provee la notación UML
Perspectivas para el UML El objetivo de UML es describir cualquier tipo de sistema en términos de diagramas orientados a objetos. • Algunas categorías de Sistemas que puede diagramar el UML: •
• • • • • •
Sistemas de Información Sistemas de Tiempo Real Sistemas Embebidos Sistemas Distribuidos Software de Sistemas Sistemas de Negocios
Diagramas del UML La finalidad de los diagramas es presentar diversas perspectivas de un sistema a las cuales se les conoce como modelo. • Muestran diferentes aspectos de los sistemas que son modelados. • Definiendo una serie de vistas, cada una mostrando un aspecto particular del sistema, puede ser construida como una imagen completa del sistema. • Las vistas también enlazan el lenguaje de modelaje al método o proceso escogido para el desarrollo. •
Tipos de Diagramas en UML Diagrama de Casos de Uso Diagrama de Clase (incluyendo Diagrama de Objetos) • Diagramas de Comportamiento • •
– – –
Diagrama de Estados Diagrama de Actividad Diagramas de Interacción
Diagrama de Secuencia Diagrama de Colaboración • Diagramas de implementación • •
– –
Diagrama de Componentes Diagrama de Despliegue
Modelado con UML “Un modelo
es una descripción completa de un sistema, desde una perspectiva concreta”
Use Case Use Case Diagramas de Diagrams Diagrams Secuencia
Use Case Use Case Diagramas de Diagrams Diagrams Casos de Uso
Scenario Scenario Diagrams Diagramas de Diagrams Colaboración Scenario Scenario Diagrams Diagramas de Diagrams Estados
State State Diagrams Diagramas de Diagrams Clases
Modelo
State State Diagrams Diagramas de Diagrams Objetos
State State Diagramas de Diagrams Diagrams Componentes Component Component Diagrams Diagramas de Diagrams
Diagramas de Actividad
Distribución
Relación entre diagramas Diagramas de Distribución
Casos de Uso
Diagramas de Secuencia
Diagramas de Colaboración
Diagramas de Clases Diagramas de Componentes
Diagramas de Estados
Diagramas de Actividad
C Ó D I G O
¿Por qué es necesario el UML? Conforme aumenta la complejidad en los sistemas informaticos será mas necesario organizar el proceso de diseño • De tal forma que los analistas, clientes y desarrolladores y otras personas lo comprendan, y el UML proporciona tal organización. • Hay otro aspecto de la vida moderna que demanda un diseño sólido, las adquisiciones corporativas, cuando una empresa adquiere a otra, los proyectos ya desarrollados o en desarrollo que han sido bien diseñado, facilitará la conversión, si el diseño es sólido los cambios se implementarán sin problemas. •
Los Casos de Uso
Definir el Comportamiento del Sistema El comportamiento de un sistema es cómo un sistema actúa y reacciona • La actividad exterior visible y “ testeable” de un sistema. • El comportamiento del sistema es capturado en los casos de uso mediante un proceso de recopilación de requerimientos del sistema. •
Caso de Uso y los Usuarios Este tipo de análisis es particularmente crucial para la fase de análisis del desarrollo de un sistema. • La forma en que los usuarios utilicen un sistema le da la pauta para lo que diseñará y creará. • El caso de usos es una estructura que ayuda a los analistas a trabajar con los usuarios para determinar la forma en que se usará un sistema. • Con una colección de casos de uso se puede hacer el bosquejo de un sistema en términos de lo que los usuarios intenten hacer con él. •
Abstraerse • • • • •
Imagínese al caso de uso como una colección de situaciones respecto al uso de un sistema. Cada escenario describe una secuencia de eventos. Cada secuencia se inicia por una persona, otro sistema, una parte del hardware o por el paso del tiempo. A las entidades que inician secuencias se les conoce como actores. El resultado de la secuencia debe ser algo utilizable ya sea por el actor que la inició o por otro actor.
Representación Los casos de uso fueron inventadas por Ivar Jacobson. • Ellos describen la conducta de un sistema desde el punto de vista del usuario por que generan acciones y reacciones. • Un Caso de Uso es representado por una elipse y describe una situación de uso del sistema interactuando con actores. •
El Propósito de los Casos de Uso El propósito primario del modelo caso de uso es comunicar las funciones y el comportamiento del sistema al cliente o al usuario final
Beneficios del Modelado con Casos de Uso El caso de uso es una excelente herramienta para estimular a que los usuarios potenciales hablen, de un sistema, desde sus propios puntos de vista. • No siempre es fácil para los usuarios explicar como pretenden utilizar un sistema. • Puesto que el desarrollo tradicional de los sistemas era, con frecuencia, algo así como una ciencia oculta, con muy poca información para los usuarios, a aquellos que osaban preguntar se les daba información muy poco explícita o ciertamente confusa respecto a lo que utilizarían. •
Los Casos de Uso son: Usados para comunicarse con el usuario final y el experto del dominio. • Proporciona credibilidad en una etapa inicial del desarrollo del sistema. • Asegura una comprensión mutua de los requisitos. • Es usado para identificar: •
– –
•
Quién interactuará con el sistema y qué deberá hacer el sistema Qué interfaz deberá tener el sistema
Es usado para verificar que: – –
Se capturan todos los requisitos Que los desarrolladores hayan entendido los requisitos
Los Actores •
Un actor es un agente, alguien o algo que solicita un servicio al sistema o actúa como catalizador para que ocurra algo.
Actor 23
Los Actores Los actores no son parte del sistema, ellos representan roles que un usuario del sistema puede desempeñar. • Un actor puede intercambiar activamente la información con el sistema . • Un actor puede ser un recipiente pasivo de la información . • Un actor puede representar a un humano, una máquina u otro sistema. •
Los Actores y los Casos de Uso El modelo de los Casos de Uso comprende los actores, el sistema y los propios casos de uso. • El conjunto de funcionalidades de un sistema se determina examinando las necesidades funcionales de cada actor, expresadas en forma de interacciones. •
Identificando Actores •
Los actores se determinan observando: – Usuarios
directos del sistema – Responsables del uso o mantenimiento del sistema – Otros sistemas que interactúan con el sistema en cuestión
Preguntas usadas para ayudar a identificar actores • • • • • • • •
¿Quién usará la funcionalidad principal del sistema? ¿Quién esta interesado en cierto requerimiento? ¿Donde en la organización será usado el sistema? ¿Quién se beneficiará con el uso del sistema? ¿Quién administrará, soportará y mantendrá el sistema? ¿El sistema usa un recurso externo? ¿Alguna persona juega varios roles diferentes? ¿El sistema interactúa con otro sistema?
