LENGUAJE DEL MODELADO
UNIFICADO - UML
¿Por qué modelamos?
• El modelado es una parte central de todas las actividades que
conducen a la producción de un software de calidad. Como tal la
ingeniería software debe basarse en el modelado como una parte
central de toda la actividades que conducen a la producción de
software de calidad.
• ¿Qué es, entonces un modelo?
“Es un simplificación de la realidad”. Proporciona los planos de un
sistema, incluyendo aquellos elementos que tienen gran influencia y
omite aquellos que no son relevantes para el nivel de abstracción dado.
• Tipos de modelo:
• Modelo Estructural: Destaca la organización del sistema
software.
• Modelo de Comportamiento: Resalta la dinámica del software.
¿Por qué modelamos?
A través del modelado se
consigue:
•Visualizar cómo es o queremos
que sea un sistema software.
•Especificar la estructura o el
comportamiento de un sistema.
•Proporcionan plantillas que guían
en la construcción de un sistema.
•Documentar las decisiones
adoptadas.
“Se construyen modelos para :
Comprender mejor el sistema que se está desarrollando”
Formas de Enfocar un Modelo:
◼ En el diseño de un sistema software hay dos formas de enfocar un modelo:
◼ Perspectiva algorítmica: El bloque principal de construcción es el
procedimiento o función. Los desarrolladores se centran en cuestiones
de control y descomposición de algoritmos grandes en otros más
pequeños.
◼ Perspectiva Orientada a Objetos: El bloque principal de
construcción es la Clase o el Objeto. El diseño orientado a objetos
propone una estrategia de diseño basada en la ocultación de
información, que ve el sistema software como un conjunto de objetos
que interaccionan entre sí con su propio estado privado, en vez de un
conjunto de funciones que comparten un estado global.
Modelado Orientado a Objetos con UML
◼ ¿Qué es UML(Unified Modeling Language)?: Lenguaje de Modelado Unificado.
◼ Es un lenguaje estándar para escribir planos (modelos) de software.
◼ Utilizado para expresar gráficamente el proceso de generación de software.
◼ UML es independiente del lenguaje de implementación del software.
Para comprender qué es el UML, basta con analizar cada una de las palabras
que lo componen, por separado.
◼ Lenguaje: Proporciona la sintaxis, vocabulario y las reglas necesarias para la
representación conceptual y física de un sistema software.
◼ Modelado: El UML es visual. Mediante su sintaxis se modelan distintos
aspectos del mundo real, que permiten una mejor interpretación y
entendimiento de éste.
◼ Unificado: Unifica varias técnicas (orientada a objetos, enfocada al usuario…)
de modelado en una única.
Modelado Orientado a Objetos con UML
◼ UML es un Lenguaje “Unificado” de Modelado para:
◼ Visualizar: Representar y Comunicar Ideas. Detrás de cada símbolo de
UML hay una semántica bien definida.
◼ Especificar: Modelos precisos, no ambiguos, completos.
◼ Construir: Trasladar en forma directa a un lenguaje de programación.
◼ Documentar: Los artefactos construidos durante un proyecto.
Los objetos de un sistema de software.
Modelo Conceptual de UML
Para comprender UML, se
necesita adquirir un modelo
conceptual del lenguaje. Esto
requiere aprender a utilizar tres
elementos principales:
1. Bloques básicos de
construcción de UML: Elementos
Relaciones
2. Reglas que dictan cómo se
pueden combinar esos Diagramas
bloques.
3. Y algunos mecanismos
comunes que se aplican a
través de UML.
Bloques de Construcción de UML:
“Elementos”
Son los nombres de los modelos Son los verbos del modelo.
UML. Representan las partes Representan comportamientos
estáticas en el tiempo y el espacio.
Representan las partes
dinámicas
Son las partes
Son las partes organizativas. explicativas de UML.
Establecen las divisiones en
que se puede fraccionar un
modelo.
Elementos Estructurales de UML
Elementos Estructurales de UML
Elementos de Comportamiento de UML
Elementos de Agrupación de UML
◼ Son las partes organizativas de los modelos
UML.
◼ Hay un elemento de agrupación principal,
los paquetes. Un paquete es un
mecanismo de propósito general para
organizar elementos (estructurales, de
comportamiento, e incluso otros elementos
de agrupación ) en grupos.
◼ Al contrario de los componentes (que
existen en tiempo de ejecución), un paquete
es puramente conceptual (sólo existe en
tiempo de desarrollo).
Elementos de Anotación de UML
◼ Son las partes explicativas de los modelos UML.
◼ Hay un tipo principal llamado Nota.
◼ Son comentarios que se pueden aplicar para describir,
clarificar y hacer observaciones sobre cualquier elemento de
un modelo.
Modelo Conceptual de UML:
“Relaciones”
Una relación es una conexión entre elementos. Para diferenciar las distintas
relaciones se utilizan diferentes tipos de líneas.
Hay 4 tipos de relaciones: Dependencia, Asociación, Generalización
Modelo Conceptual de UML:
“Relaciones”
Modelo Conceptual de UML:
“Relaciones”
Modelo Conceptual de UML:
“Diagramas”
Un diagrama es la representación gráfica de un conjunto de elementos,
visualizando la mayoría de las veces como un grafo conexo de nodos
(elementos) y arcos (relaciones).
Los diagramas se dibujan para visualizar el sistema desde diferentes
perspectivas, de forma que un diagrama es una proyección de un sistema.
UML incluye nueve tipos de diagramas fundamentales, clasificados en dos
grandes grupos, uno para modelar la estructura estática del sistema y otro
para modelar el comportamiento dinámico.
Modelo Conceptual de UML:
“Diagramas”
Si vemos el modelo de una Si analizamos el modelo
forma estática: de una forma dinámica
(comportamiento):
❑ Diagrama de clases
❑ Diagrama de casos de uso
❑ Diagrama de objetos
❑ Diagrama de secuencia
❑ Diagrama de componentes
❑ Diagrama de colaboración
❑ Diagrama de despliegue
❑ Diagrama de estados
❑ Diagrama de actividades
Diagrama de Clases
Nombre de
la Clase
Atributos
de la Clase
Operacione
s de la
Clase
Diagrama de Objetos
Diagrama de Casos de Uso
Diagrama de Estados Diagrama de Secuencias
Estado
Inicial
Estado 1
Estado 2
Estado 3
Estado 4
Estado Final
Diagrama de Actividades Diagrama de Colaboraciones
Las actividades que Permite representar el trabajo
ocurren dentro de un caso en conjunto de los elementos
de uso o dentro del de un sistema para cumplir
comportamiento de un con un objetivo propio del
objeto se dan, sistema.
normalmente en
Diagrama de Componente Diagrama de Distribución
Ambos diagramas dejan el
mundo de las lavadoras ya
que están intimanente
ligados con los sistemas
informáticos
EL diagrama de EL diagrama de
componentes es distribución muestra la
usado actualmente arquitectura física de un
en el desarrollo de sistema de información.
software, Se representan los
especialmente en el equipos y dispositivos,
desarrollo en equipo además la conexión
Características del UML
Paquetes Notas Estereotipos
Un estereotipo
permite crear
El paquete UML nuevos
le permite elementos a
agrupar los partir de
elementos de elementos
un diagrama. Se pueden existentes.
agregar
comentarios a
través de una
nota.
Modelo de casos de uso
◼
real O DE NEGOCIO
Muestra los casos de uso del negocio, trabajadores del
negocio, actores del negocio y las interacciones entre ellos
relacionadas con los procesos del negocio que se encuentran
dentro de la organización y dentro del alcance del sistema
que se está planeando realizar. Este servirá para proveer los
fundamentos para el artefacto Modelo de Casos de Uso.
Estereotipos
Actor del
Negocio
Modelo de casos de uso
real
Modelo de casos de uso real
O DE NEGOCIO
Es un documento narrativo que describe la secuencia
de eventos de un actor (agente externo) usando el
sistema para completar un proceso
Los casos de uso tienen las siguientes características:
1) Están expresados desde el punto de vista del
actor.
2) Se documentan con texto informal.
3) Describen tanto lo que hace el actor como lo
que hace el sistema cuando interactúa con él, aunque
el énfasis está puesto en la interacción.
4) Son iniciados por un único actor.
Definiciones Básicas
◼ Actores
Un actor es una agrupación uniforme de
personas, sistemas o máquinas que interactúan
con el sistema que estamos construyendo de la
misma forma. Por ejemplo, para una empresa
que recibe pedidos en forma telefónica, todos los
operadores que reciban pedidos y los ingresen en
un sistema de ventas, si pueden hacer las
mismas cosas con el sistema, son considerados
un único actor: Empleado de Ventas
actor
◼ También puede ocurrir que el actor sea
una máquina, en el caso en que el
software controle sus movimientos, o
sea operado por una máquina. Por
ejemplo, si estamos construyendo un
sistema para mover el brazo de un
robot, el hardware del robot será un
actor, asumiendo que dentro de nuestro
sistema están las rutinas de bajo nivel
que controlan al hardware.
actor
◼ Los actores se representan con
dibujos simplificados de personas,
llamados en inglés “stick man”
(hombres de palo).
Casos de uso
◼ Un caso de uso es iniciado por un actor. A partir de ese
momento, ese actor, junto con otros actores,
intercambian datos o control con el sistema,
participando de ese caso de uso.
◼ El nombre de un caso de uso se expresa con un verbo
en gerundio, seguido generalmente por el principal
objeto o entidad del sistema que es afectado por el
caso. Gráficamente, los casos de uso se representan
con un óvalo, con el nombre del caso en su interior.
Consideraciones acerca
de los CUN
◼ Su nombre y descripción breve son claras y
fáciles de comprender.
◼ Cada caso de uso del negocio es completo
desde la perspectiva de un actor externo.
◼ Cada caso de uso del negocio normalmente
se involucra con, al menos, un actor.
◼ Es posible que un caso de uso de apoyo no
interactúe con ningún actor.
ejemplo
◼ Es importante notar que el nombre
del caso siempre está expresado
desde el punto de vista del actor y no
desde el punto de vista del sistema.
Estructuración de
los CUN
◼ Relación de inclusión
◼ Relación de extensión
◼ Relación de Generalización-
especialización
Relación de inclusión
<include>
Una relación que especifica un
comportamiento definido para el CU de
inclusión que se inserta explícitamente
dentro del comportamieto definido para el
CU base.
El workflow del proceso entero está en el
caso de uso base y el (los) caso(s) de uso
incluido(s).
Relación de inclusión <include>
Se justifica cuando:
◼ Se puede reusar en otros CUN el
comportamiento incluido en el
caso de uso base, o
◼ Simplifica la comprensión del caso
de uso base.
Relación de inclusión <include>.
REUTILIZAR
<<include>>
Check-In
Pasajero Individual
Manipular
<<include>> Equipaje
Guía de Check-In
turismo de
Grupo
(Ejemplo: Aduana)
Relación de inclusión <include>.
PARTICIONAR
<<include>>
Venta de
Cliente producto
Verificar
Es un CU de apoyo que no política de
se relaciona con actores descuento
(Ejemplo: Empresa de servicios)
Relación de extensión <extend>
Una vez definido el workflow de un caso de uso del negocio,
se puede encontrar alguna conducta opcional u optativa .
Tiene sentido definir un nuevo CU cuando:
• Modelar un workflow complejo o un
subflujo separado, que raramente ocurre
u ocurre bajo ciertas condiciones.
• Flujos distintos que pueden ejecutarse en
base a la selección del actor.
Relación de extensión <extend>.
Pasajer
o
<<extend
>>
Check-In Individual Manejo Especial de
Equipaje
SOLO PARA ALGUNOS PASAJEROS HAY QUE IR
AL COUNTER DE EQUIPAJE ESPECIAL
(Ejemplo: Aduana)
Generalización - especialización
Se usa para mostrar
worksflows que comparten
estructuras, propósito y
comportamiento.
Un caso de uso padre se
puede especificar en uno o
más casos de uso hijos que
representan formularios
más especificos del padre.
Generalización - especialización
Se utiliza para:
Para no tener que describir el mismo flujo
varias veces, se puede colocar el
comportamiento común en un CUN.
Se recomienda usar cuando:
Se puede afirmar que constituyen tipos de procesos.
Generalmente tienen un comportamiento similar pero
con diferencias sustanciales que provocan que sean
considerados CUN diferentes.
Generalización – especialización.
Realizar
visitas
Jefe zonal
Realizar Visitas a Realizar visitas a
clientes potenciales clientes registrados
(Ejemplo: Vendedores ambulantes)
Generalización entre Actores
Varios actores del negocio pueden jugar el
mismo rol en un caso de uso particular del
negocio.
El rol compartido se modela como el actor del
cual heredan los actores con roles
compartidos (solo se representan si
interactúan como actor con otro CUN).
Generalización entre Actores. Ejemplo
Despachar medicamentos
en farmacia
Cliente
Asignar citas Administrador Administrador Asignar camas
Consulta Externa Hospitalización
(Ejemplo:Hospital)
