diseño de sistemas - uml - compendio

UMLDiseño de sistemas

Compendio

UML (Unified Modeling Language)

El mundo esta compuesto por sistemas complejos, losingenieros deben entender estos sistemas yrepresentarlos de alguna forma.

UML emplea símbolos y diagramas para comunicar laidea de un diseño.

Es usado entender, diseñar, navegar , configurar,mantener y controlar información acerca de un sistema.

UML

UML no es una metodología

No define estándares de procesos.

La estructura Estática y Dinámica de un sistema es

capturada.

Estática: Objetos importantes del sistema y sus relaciones.

Dinámica: Relación de los objetos en el tiempo (Histórico).

UML

No es un lenguaje de programación.

Herramientas permiten crear código aplicando

“ingeniería inversa”.

Propósito general.

Se modela la lógica del Negocio.

Porque Modelar?

Para asegurarse que las aplicaciones trabajaran.

Para reducir el numero de errores que se presentan.

Para permitirle al usuario final ver las funcionalidades

del su aplicativo antes de que este terminado.

Para definir un puente de comunicación.

Porque es necesario UML

Planificación

Los sistemas son muy complejos y difíciles de

administrar.

Los nuevos desarrollos se hacen en equipos.

Reducir el tiempo de desarrollo.

Diseños sólidos.

Historia y Concepción

UML nació por un esfuerzo de simplificar y consolidar el

gran numero de desarrollos orientados a objetos que

estaban apareciendo.

Grady Booch, James Rumbaugh e Ivan Jacobson “Los

tres amigos”.

OMG (Object Management Group) lo popularizo.

Naturaleza de los Modelos

UML

Modelo:

Representación de algo por medio del mismo u otro medio.

Se expresa de forma que se facilite el trabajo.

Puede tomar varias formas.

Se emplean para capturar requerimientos y los dominios de conocimiento que poseen los interesados y que pueden entender.

Arquitectos – Analistas – Programadores – Directores de Proyectos – Clientes – Usuario final – Patrocinadores y operadores.

Modelos

Pensar en el diseño de un sistema:

Así como los arquitectos emplean bocetos,

en la Ing. Software se emplean los modelos para

explorar con diversas arquitecturas y soluciones a un

problema.

Decisiones de Diseño de forma independiente.

Los modelos permiten acceder a vistas diferentes

del mismo sistema.

Planos eléctricos – Planos de tuberías – Planos de redes

Modelos

Generar Productos

Clases – bases de datos – procedimientos – guías –

Configuraciones.

Organizar, Filtrar la información de grandes Sistemas.

Encontrar la información útil para los sistemas no es fácil.

Los modelos presentan la información de diferentes formas

y formatos.

Modelos

Explorar múltiples soluciones económicamente.

Se pueden explorar diferentes diseños y realizar los

cálculos de costo y riesgos antes de iniciar la construcción.

Control completo

Algunos sistemas presentan tan complejidad que solo es

posible controlarlos cuando se realiza la modelación.

Modelos

Completar sistemas parciales:

Durante el desarrollo de un modelado se pueden

completar aspectos olvidados de un sistema.

Los modelos son evolutivos.

Los modelos se trabajan en procesos iterativos y entre más

niveles avance un modelo más detallado y completo se

vuelve.

Diagramas UML - I

Diagramas más comunes:

Estructural:

Vista Estática

Diagrama de Clases:

Representación Grafica de elementos que conformaran el diseño, junto con sus

relaciones, dependencias e interfaces.

Automóvilmarca

modelo

serie

colorencender()

apagar()

acelerar()

Diagramas UML - II

Estructural:

Vista Caso de Uso

Diagrama de Casos de Uso:

Modelo que presenta las relaciones existentes entre actores

y casos de uso.

Actor: Abstracción de una entidad que interactúa

directamente con el sistema. Puede ser una persona, otro

sistema, un subsistema o una clase.

Caso de Uso: Especificación de una secuencia de acciones,

variantes ..etc. Que el sistema puede realizar al

interactuar con un actor.

Diagramas UML- III

Estructural:

Vista de Implementación – Vista de Despliegue

Diagrama de Componentes: Diagrama que presenta las relaciones y dependencias entre

componentes.

Componente: Parte reemplazable de un sistema . Representa una parte física del sistema

(Código, binario, ejecutable). Un componente puede ser accedido a través de las interfaces

que implementa.

MotorChequeo_motor

inicio_motor

Diagramas UML - IV

Estructural:

Vista de Implementación – Vista de Despliegue

Diagrama de Despliegue: Presenta la configuración en tiempo de

ejecución , los nodos, los componentes y los objetos.

Nodo: Representación de un objeto computacional físico.

Diagramas UML - V

Dinámico:

Vista de Estado de la maquina

Diagrama de estados: Presenta los estados de la maquina, y el

comportamiento de los elementos a través del tiempo

Diagramas UML - VI

Dinámico:

Vista de Actividades

Diagrama de Actividades: Presenta un flujo de actividades o

workflow que se disparan tras la ejecución de otra actividad. Se

enfatiza la secuencia.

Branch: rama

Fork of Control: Bifurcación

Conditional Thread : Hilo Condicional

Join of Control: Union

Merge: Combinación

Diagramas UML

Diagramas UML - VII

Dinámico:

Vista de Interacción

Diagrama de Secuencia: Presenta las interacciones de los objetos

colocadas en una línea de secuencia.

Los objetos interactúan intercambiando mensajes.

Se trabajan dos dimensiones:

Vertical: Representa el tiempo.

Horizontal: Representa las interacciones.

Los objetos se representan en columnas independientes.

Cada mensaje es representado por una flecha horizontal.

Diagramas UML

Diagramas UML - VIII

Dinámico:

Vista de Interacción

Diagrama de Colaboración: Presenta las interacciones

organizadas alrededor de roles y sus colaboraciones.

Representa relaciones

No maneja el tiempo como una dimensión separada.

Presenta información similar al diagrama de secuencia pero de

forma diferente.

Los mensajes están acompañados por una etiqueta numérica que

indica el orden en que se presentan.

Si existen parámetros en los mensajes, estos se ubicaran dentro

de parentesis.

Diagramas UML

Modelos

Casos de uso

1

Casos de Uso

Representa funcionalidad.

Grafo de actores y un conjunto de casos de uso.

Las relaciones son asociaciones entre actores y casos de

uso.

Se puede emplear rectángulos para limitar las fronteras

del sistema.

Casos de Uso

Actor:

Rol de un usuario dentro de un sistema.

No necesariamente representa una persona.

Otros sistemas

Material externo

La misma persona puede ser varios actores

El nombre del actor lo describe

Casos de Uso

Caso de uso:

Representación de una unidad funcional del sistema.

Se caracteriza por la secuencias.

Se representan por un elipse que contiene el nombre del caso de uso.

Se ejecutan tras una orden de un agente externo.

Se pueden emplear notas para aclarar información incompleta o

ambigua.

Casos de Uso

Relaciones:

Comunicación:

La mas empleada, representa una comunicación directa entre

actor y caso de uso.

Casos de uso

Relaciones:

Inclusión:

Un caso de uso implementa el mismo comportamiento de

otro.

Casos de Uso

Relaciones:

Extensión:

Extiende el comportamiento de otro caso de uso.

Casos de Uso

Include & Extend:

Casos de Uso

Relaciones:

Herencia:

Un caso de uso hereda las especificaciones de otro caso de uso

y las modifica.

Casos de Uso

Consideraciones:

Identificar las tareas que realiza un actor.

Los cambios se informan a los actores?

La información es alterada:

Inserta – Borra – Actualiza

Que mensajes se intercambian

Objetivo del caso de uso.

Interacciones del sistema.

Casos de Uso

Consideraciones:

Que se repite mas?

Cronología (Tiempo)

Variantes en los flujos normales.

Donde inician – Donde Terminan.

Cuantos actores interactúan en el sistema?.

Casos de Uso

Plantillas:

Identificador: Identifica de forma única un caso de uso.

Nombre: Describe las funcionalidades ofrecidas por el caso de uso.

Precondición: Condiciones especiales que se deben presentar antes

de la ejecución del caso de uso.

Casos de Uso

Plantillas

Secuencia Normal o flujo principal: Descripción de las

acciones realizadas por el actor y su interacción con los

casos de uso.

Se emplea lenguaje natural.

Postcodicion: Estado del sistema después de ser ejecutado

el caso de uso.

Casos de Uso

Plantilla:

Excepciones o flujos alternos: Descripción detallada de las acciones que no se contemplan en la ejecución común de un caso de uso.

Tiempo: EL tiempo que se espera se invierta ejecutando las acciones.

Frecuencia: Numero de veces que se espera se repita las acciones del caso de uso.

Casos de Uso

Plantilla:

Importancia: Se especifica el grado de importancia que tiene el caso

de uso dentro del aplicativo.

Es necesario definir escalas.

Prioridad: Se especifica la prioridad que tiene el desarrollo del caso

de uso para el aplicativo.

Es necesario definir escalas.

Comentarios: Aclaraciones, notas adicionales.

Diagrama de

Clases

2

Diagrama de Clases

Notación Gráfica para representar un conjunto de objetos.

Atributos.

Acciones comunes.

Rectángulo con secciones para:

Nombre de la Clase

Atributos

Operaciones.

Diagrama de Clases

La misma Filosofía que la programación orientada a

Objetos.

Da una visión estática del sistema y las relaciones

incluidas en él (fotografía).

También se pueden modelar los paquetes del sistema.

Paquete

Diagrama de Clases

Pueden existir varios DC.

Especificando aspectos diferentes del mismo sistema.

Detallando subsistemas.

Incluyendo mayor numero de propiedades.

Diagramando solo las relaciones entre paquetes.

Diagrama de Clases

Diagrama de Clases

Clase:

Es algo que encapsula información y comportamiento.

Enfoque tradicional:

Información = Base de datos.

Comportamiento= Aplicativo.

Enfoque O.O:

A little bit of information and a little bit of behavior, and encapsulate them into something called a class.

Diagrama de Clases

Una clase puede ser:

Una cosa: Un ítem tangible que existe dentro del mundo

real.

Un evento: llamada telefónica, activación de un elemento,

etc.

Un proceso: Colocar una orden, interacción con una base

de datos.

Diagrama de Clases

Una clase y sus objetos:

Simple / Complejo

Real / Imaginario

Atributos / Operaciones

Las operaciones se realizan sobre el objeto mismo.

Otro objeto invoca un evento externo a través de

mensajes.

Identificando los Objetos

Examinando el flujo de eventos de los casos de uso.

Identificar los sustantivos

Los sustantivos se pueden convertir en 4 tipos de cosas:

Actor : Maria

Clase (Candidato a Objeto): Ingles

Un atributo de una clase: 30 personas

Una expresión no modelable: Sistema

Agrupando en clases

John Doe and Jane Doe:

Attributes:

Employee’s name.

Adress.

Telephone number.

Similar Operations.

Se agrupan objetos comunes para crear la clase

Employee.

Tomado del libro: UML with Rational Rose

Consideraciones

En ocasiones se prefiere crear primero el diagrama de

secuencia, actividades o colaboración.

El diagrama de clases funciona como diccionario de

datos y relaciones.

Agrupar las clases en paquetes y en capas de

arquitectura facilitan el trabajo y la expresividad del

modelo.

¿Cuando Diseñar?

Antes que otros diagramas:

Permite diseñar las capas de arquitectura.

Patrones de comunicación.

Al llegar al diagrama de secuencia se

identifican los mensajes que violen la

arquitectura del diseño.

Es posible rediseñar varias veces el

diagrama antes de realizar grandes

cambios.

¿Cuando Diseñar?

Después de otros diagramas:

Se puede examinar que objetos son los necesarios.

No se modelan objetos que no se emplearan.

Se examina mejor las interacciones.

No se limita los nuevos diseños al diccionario dado por el diagrama de clases.

Relaciones

Los diagramas de clases también son empleados para

representar las relaciones del sistema.

Asociación

Agregación

Composición

Generalización.

Asociación

Utiliza un:

Denota comunicación entre objetos.

Se representa por una línea entre dos clases.

Departamento Profesor

Asociación - Multiplicidad

Especifica el número de instancias de las clases involucradas en la relación.

Facultad Profesor1 1..*

Asignatura

Pre-requisito0..*

0..*

Agregación

Se emplea para mostrar que una clase es parte de otra.

Se emplea un diamante como símbolo.

Una línea une las clases.

Currículo Diplomado1..*

“Es parte de”

Composición

With composition, when the Whole is destroyed, so are all its

parts.

La relación es mas fuerte.

Se representa por un Diamante relleno.

Pensum Asignatura1..*

“Es parte de”

Tomado del Libro: UML for Mere Mortals

Ejemplo

CámaraSwitch

Bateria

No se permite

Clase I

Clase I Clase II

Clase I

Clase III Clase II

Tomado del Libro: UML for Java Programmers

Herencia

Compartir Atributos y funcionalidades.

Relación de “Es un”

Las clases heredantes se denominan subclases.

Las subclases pueden adicionar nuevos atributos y operaciones.

Generalización / Especialización

Herencia Múltiple vs Interfaces.

Ejemplo

Weapon

-weight

-length

-range

+load()

+fire()

+setSafety()

+releaseSafety()

Rifle Blowgun

+load(cartridge,numberOfRounds) +load(dart,singleRound)

Diagrama de

Objetos

3

Diagrama de Objetos

Instancia de un Diagrama de Clases.

Presenta los detalles del sistema en un punto

determinado.

Se presentan los objetos y sus relaciones durante el

tiempo de ejecución.

Se emplea para validar el modelo de clases.

Ejemplo

Estudiante

-código=2003039

-nombre=Juan

Ingles: Asignatura

Software: Asignatura

QuimicaO: Asignatura

IdentidadU: Asignatura

Diagrama de

Estados

4

Introducción

Todo cambia en el tiempo y los sistemas no son la

excepción.

Los objetos pasan por varios estados.

Se requiere de un modelo que permita ilustrar estos

estados y sus cambios en el tiempo.

Sucesos + Tiempo.

Introducción

Diagrama de estados o maquina de estados.

Cada entidad es modelada como un objeto solitario que

percibe eventos y responde a ellos.

Un evento son los cambios que un objeto puede

detectar.

Diagrama de Estados

Cualquier cosa que afecte un objeto puede ser

considerado como un evento.

Estado: Conjunto de valores de una clase en un

momento dado.

En un estado especifico se ejecuta la misma función

cuando recibe el mismo evento.

Diagrama de estados

En diferentes estados un mismo evento genera

comportamientos diferentes.

Los diagramas de estados describen los

comportamientos dinámicos de los casos de uso.

“Dan mayor expresividad”

Diagrama de estados

Maquina de estados:

Grafo de estados y transiciones.

Generalmente se construye sobre el diagrama de clases.

Se ilustra la respuesta que las clases dan a los eventos.

Los casos de uso pueden ser la base del modelado.

Maquina de estados

Modelado de todo el ciclo de vida de un sistema dado,

desde una perspectiva de maquina.

Las respuestas a los eventos pueden originar el cambio a

un nuevo estado.

Vista separada, que permite observar el sistema como

una entidad solitaria

Eventos

Se realizan en un tiempo y espacio.

Cuando un evento ocurre se llama “instancia de

evento”.

Los eventos pueden llevar parámetros.

Se dividen en:

Call events – change events

Signal events – time events

Eventos

Call event:

Llamada a la ejecución de un evento.

El emisor recupera el control cuando se ejecuta la acción.

Change event:

Satisface condición Booleana.

Wait until.

Eventos

Signal Event:

Vehiculo de comunicación.

Asíncrona.

Time Event:

Representa el paso del tiempo.

Paso de señales-

Estado (state)

Describe un periodo de tiempo de la vida de un objeto.

Valores: Cualitativos

Periodo de tiempo esperando evento.

Periodo de tiempo efectuando acción.

Generalmente llevan un nombre

Los estados son conectados por transiciones.

Ejemplo - Estados

Confirmar Crédito

Inactivo Cancelar Orden

Transiciones

Define la respuesta de un objeto en un estado a la

ocurrencia de un evento.

Disparador

Guard Condition.

Acción.

Estado objetivo.

Transiciones

Tipos:

Transición externa:

Cambia el estado actual

Se gráfica con una flecha desde el invocadora al destino.

Es la más común.

Lleva texto complementario.

Transiciones

Transición Interna:

Respuesta a un evento que causa una ejecución pero no

provoca un cambio de estado.

No genera acciones de entrada ni salida.

Acción de entrada (Entry action):

Se ejecuta cuando se ingresa a un estado.

Acción de Salida (Exit action):

Se ejecuta cuando se abandona un estado.

Ejemplo – Transición

Representación

Nombre

Variables de Estado

Actividades

Nombre

Actividades

Nombre

Transiciones

Evento disparador:

Encargado de habilitar la transición.

Puede llevar parámetros.

MouseButton

El evento Disparador = MouseButtonDown

Se ejecuta en un tiempo dado.

No es recordado.

Transiciones

Guard Condition:

Expresión Booleana.

Puede hacer referencia a parámetros específicos del

trigger.

Se evalúa cuando el evento disparador ocurre.

Ejemplo

Transiciones

Acciones:

Operación computacional asociado a un evento disparador.

Assignment: asignación

Call: Llamada a un evento

Create: Crear un objeto

Destroy: Destruir un objeto

Return: Especifica el valor a retornar.

Send: Crea una instancia de señal.

Terminate: Auto destrucción.

Estados Compuestos

Estado simple

Concurrente

Se activa un sub estado a

la vez.

Secuenciales

Sub estados que se activan

cuando el principal se

activa.

Inicio

Estados Compuestos

Estado Final

Agrupa diferentes

transiciones en una.

Estado de Unión

Estado de historiaRestaura el comportamiento

previo de un estado.

Estado de Sub maquinaHace referencia a una

maquina externa.

Ejemplo

Ejemplo - Concurrente

Ejemplo- Secuenciales

Ejemplo Sub máquinas

Diagrama de

Secuencia

5

Introducción

Los diagramas de estados llegan hasta un punto determinado, los diagramas de secuencia dan el siguiente paso.

Presenta la interacción de los objetos en el tiempo.

Los mensajes y quienes los envían y reciben son capturados en este diagrama.

Diagrama de Secuencia

La interacción entre objetos siempre se realiza en una secuencia especifica.

Un sistema debe ser analizado en base a esta secuencia.

“Interacciones” son el centro del diagrama:

Conjunto de comunicaciones entre objetos en un tiempo dado.

Diagrama de Secuencia

No se incluye las relaciones entre los objetos (Diagrama

de colaboración si lo hace).

DC y DS presenta información similar pero desde puntos

de vista diferentes.

Se generan diferentes diagramas para diferentes

escenarios.

Vista Dinámica

El Diagrama de secuencia hace parte de

la denominada vista dinámica del

sistema.

Diagrama de estados: statechart diagram.

Diagrama de actividades: activity diagram.

Diagrama de secuencia: sequence diagram.

Diagrama de Colaboración: collaboration diagram.

Dimensiones

Los DS posee dos dimensiones:

Vertical:

Representa la línea de tiempo en la cual se efectúan las

interacciones. El tiempo que tarda en realizarse una acción se

representa sobre ella.

Horizontal:

Representa los objetos que participan en las interacciones.

Cada objeto es mostrado en una columna independiente.

Notación

Una línea punteada indica el tiempo de vida del objeto.

Una X se sitúa en el punto donde el objeto deja de existir.

Cada mensaje es representado por una flecha horizontal, que va desde el emisor al receptor, se acompaña de una etiqueta indicando el evento a invocar.

Notación

Los mensajes llevan una secuencia numérica indicando

el orden de ejecución.

El actor que interviene debe ser representado en el

modelo.

Normalmente no se representan mensajes de retorno,

pero es permitido hacerlo.

Como elaborarlo?

Seleccione un caso de uso

Situé el actor en el diagrama.

Identifique las clases de interfaz.

Identifique las clases de control.

Identifique las clases de entidad.

Clase Interfaz- Control -

Entidad

Interfaz: Son las clases que interactúan

directamente con el actor.

Control: Son aquellas clases que manejan la

lógica del negocio.

Entidad: Clases que representan las tablas de

la base de datos.

Ejemplo

Ejemplo

Ejemplo

Diagrama de

Colaboración

6

Diagrama de Colaboración

Presenta la colaboración entre los objetos.

Relaciones entre objetos.

Mensajes que se envían entre objetos.

Cualquier diagrama de colaboración puede ser

convertido en un diagrama de secuencia.

Diagrama de Colaboración

Notación:

Objetos del sistemas:

Mensaje y Relaciones:

Diagrama de Colaboración -

Ejemplo

Diagrama de Colaboración -

Ejemplo

Diagrama de

Actividades

7

Diagrama de Actividades

Grafo de actividades:

Actividad:

Expresión de una acción computacional no atómica.

Algoritmo expresado en un lenguaje de programación.

Es ocasiones se expresa en lenguaje humano.

Representa una operación del mundo real.

Diagrama de Actividades

Similar al diagrama de estados:

Estados ----- Actividades

Representa un procedimiento o flujo de trabajo.

Se enfatiza la secuencia.

Se reflejan las concurrencias.

Las decisiones son igualmente representadas.

Diagrama de Actividades

Se modelan pasos en la ejecución de un procedimiento.

Al finalizar la ejecución de una actividad se referencia a

la siguiente.

Es útil para definir responsabilidades de los procesos.

Diagrama de Actividades

Notación:

Así como el diagrama de estados se inicia con una circulo

negro y se finaliza con el circulo negro rodeado por aro.

Se emplea una flecha para representar el paso de una

acción a otra.

Diagrama de Actividades

Una Actividad se representa por un rectángulo con las

esquinas redondeadas.

caminar

Diagramas de Actividades

Notación: Decisiones

Diagrama de Actividades

Notación: Concurrencia

Diagrama

de

Actividades

Diagrama de

Componentes

8

Introducción

Los diagramas de componentes representan la

estructura física del código.

Los componentes se pueden agrupar en paquetes y

entre estos podrían llegar a existir dependencias del

tipo:

Generalización.

Agregación.

Asociación.

Realización.

Los componentes poseen interfaces que les permite

interactuar con el exterior.

Generación

Los diagramas de componentes nacen a partir de los

diagramas de clases, que son empleados para

determinar aquellos elementos que prestaran una

funcionalidad al sistema.

Es posible iniciar la implementación del sistema al

realizar el diagrama de componentes.

Pasos para generación

Debe existir el diagrama de clases.

Se debe identificar las clases y los métodos que serán

empleados para el diagrama.

Las clases se agrupan en módulos y se transformaran en

componentes.

Se identifican las interfaces que se emplearan por los

componentes para comunicarse entre ellos.

Ejemplo diagrama

Diagrama de

Distribución

9

Introducción

Los diagramas de distribución permiten establecer como

estarán conectados las unidades entre si y como serán

ejecutados los programas.

Los Nodos son la representación gráfica que caracteriza

los diagramas de distribución. Un Nodo es un elemento

físico que existe y representa un recurso

computacional.

Normalmente la reunión de los Nodos terminan

representando la Topología asociada al Hardware que

será la solución del sistema.

Ejemplo

Consideraciones

Consideración

No todos los diagramas son necesarios, pero se

recomienda la realización de los mismos para una mayor

comprensión del sistema que se esta desarrollando.

Aunque hay críticas sobre la redundancia de la

información presentada en los diagramas , cada uno de

ellos permiten representar la información desde una

perspectiva única.

Los diagramas representan aspectos estáticos y

dinámicos de un sistema y debe tener presente esto

para no quedarse con una vista parcial de la solución.

@josefabiandiaz

josefabiandiazs@Gmail.com

https://www.youtube.com/user/fabiandiazs

Msc.Ing.Jose Fabián Diaz Silva

Consultas