unified modeling language 2 - ccc.inaoep.mxccc.inaoep.mx/~pgomez/cursos/ingsw/acetatos/uml...
TRANSCRIPT
Unified Modeling Language 2.0
Tomás Balderas Contreras [email protected]
Pilar Gómez-Gil
Ingeniería de Software
Ciencias Computacionales
INAOE 2011-2012
15/11/2012 (c) INAOE 2011-2012 1
Contenido
1. La importancia de modelar.
2. Fundamentos de UML. Modelo conceptual
Elementos
Relaciones
Diagramas
3. Modelado estructural Diagrama de casos de uso.
Diagrama de clases
Diagrama de componentes e interfaces
4. Modelado del comportamiento Diagrama de secuencia y comunicación
5. Modelado arquitectónico Diagrama de despliegue
2 15/11/2012 (c) INAOE 2011-2012
3
1. LA IMPORTANCIA DE MODELAR
15/11/2012 (c) INAOE 2011-2012
Modelado (1/2)
Una técnica de ingeniería probada y aceptada. Es parte
central en todas las actividades que conducen a la
producción de buen software.
Los modelos arquitectónicos de casas y rascacielos
ayudan a visualizar el producto final. Los modelos
matemáticos permiten analizar los efectos de vientos o
terremotos.
Aeronáutica, ingeniería automotriz, dispositivos
eléctricos y electrónicos, películas, sociología,
economía, gestión de empresas.
4 15/11/2012 (c) INAOE 2011-2012
Modelado (2/2)
¿Qué es un modelo? Un modelo es una simplificación
de la realidad.
¿Para qué modelamos?
Para controlar riesgos.
Para comunicar la estructura deseada y el comportamiento del
sistema.
Para visualizar y controlar la estructura del sistema.
Para comprender mejor el sistema que se está construyendo.
Un único modelo no basta. Un sistema se entiende
mejor si hay un conjunto de modelos casi
independientes con múltiples puntos de vista [1]
5 15/11/2012 (c) INAOE 2011-2012
6
2. FUNDAMENTOS DE UML
15/11/2012 (c) INAOE 2011-2012
Orientación a objetos (1/2) [3]
7
1. ¿Qué es un objeto? Es una representación de una entidad del
mundo real que es responsable de tener un estado y llevar a cabo
operaciones.
2. ¿Qué es un atributo y qué es una operación? Los atributos
corresponden a datos encapsulados en un objeto y las
operaciones a los algoritmos que procesan esos datos.
15/11/2012 (c) INAOE 2011-2012
Orientación a objetos (2/2) [3]
3. ¿Qué es una clase? Es una descripción generalizada que describe
una colección de objetos similares.
4. ¿Qué es el análisis y diseño orientado a objetos? Durante el
análisis se definen las clases del sistema, incluyendo los atributos
y operaciones, y la forma en que se relacionan las clases unas con
otras. Durante el diseño se define una arquitectura de software
organizada en capas, se especifican subsistemas, se describen las
clases y se definen los mecanismos de comunicación entre los
componentes.
8 15/11/2012 (c) INAOE 2011-2012
Evolución [2]
9 15/11/2012 (c) INAOE 2011-2012
(2005)
Definición de UML
1. UML es un lenguaje estándar para desarrollar los “planos”
de un sistema de software. Debe ser usado junto con un
proceso de desarrollo[1].
2. UML es un meta-modelo basado en Meta-Object Facility
(MOF) que consiste de un conjunto de meta-clases que
definen a los elementos de modelado del lenguaje.
10 15/11/2012 (c) INAOE 2011-2012
Aplicaciones [2]
Usos de UML:
Visualización.
Especificación.
Construcción.
Documentación.
UML combina notaciones provenientes desde:
Modelado Orientado a Objetos .
Modelado de Datos.
Modelado de Componentes .
Modelado de Flujos de Trabajo (Workflows).
Permite modelar sistemas de información, aplicaciones
distribuidas en web, sistemas embedded, entre otros.
11 15/11/2012 (c) INAOE 2011-2012
Herramientas
12 15/11/2012 (c) INAOE 2011-2012
Herramienta recomendada
13
+ +
+ + =
Model-Driven Engineering
15/11/2012 (c) INAOE 2011-2012
Elementos principales de UML [1]
Para entender UML se requiere adquirir
un modelo conceptual de éste, y esto
requiere aprender 3 elementos
importantes:
1. Los bloques básicos para construir
2. Las reglas sobre como combinar los bloques
básicos
3. Los mecanismos que se aplican en UML
15/11/2012 (c) INAOE 2011-2012 14
Modelo Conceptual de UML
15/11/2012 (c) INAOE 2011-2012 15
UML 1. Bloques
1.1 Elementos
1.2. Relaciones
1. 3. Diagramas
2. Reglas Sintácticas
Semánticas
3. Mecanismos
3.1 Especificaciones
3.2 Adornos
3.3 Divisiones
comunes
3.4 De extensibilidad
Ver “Modelo conceptual UML.pdf”
Bloques básicos de UML
Elementos: 1. Estructurales (parte
estática)
2. Comportamiento (parte dinámica)
3. De agrupación (paquetes)
4. De anotación (notas)
Relaciones: 1. Dependencia.
2. Asociación.
3. Generalización.
4. Realización.
Diagramas: 1. Clases.
2. Objetos.
3. Componentes.
4. Estructura compuesta.
5. Casos de uso.
6. Secuencia.
7. Comunicación.
8. Estados.
9. Actividades.
10. Despliegue.
11. Paquetes.
12. Tiempos
13. Visión global de interacciones
16 15/11/2012 (c) INAOE 2011-2012
Elementos de UML
15/11/2012 (c) INAOE 2011-2012 17
1.1 Elementos
1.1.1 Estructurales
1.1.2 Comportamiento
1.1.3 Agrupación
1.1.4 Anotación
Elementos estructurales
Clases
Interfaces
Colaboraciones
Casos de uso
Clases activas
Componentes
Artefactos
Nodos
15/11/2012 (c) INAOE 2011-2012 18
Elementos estructurales (2/2)
15/11/2012 (c) INAOE 2011-2012 19
Elementos de comportamiento
Mensajes (interacciones)
Estados (máquinas de estados)
Acciones (actividades)
15/11/2012 (c) INAOE 2011-2012 20
Elementos de agrupación y de notación
Paquetes (agrupación)
Notas (anotación)
15/11/2012 (c) INAOE 2011-2012 21
Relaciones en UML 1/2
15/11/2012 (c) INAOE 2011-2012 22
Relaciones en UML 2/2
15/11/2012 (c) INAOE 2011-2012 23
Relación de dependencia
Una dependencia es una relación
semántica entre dos elementos, en el cual
un cambio en un elemento (el elemento
independiente) puede afectar la semántica
del otro elemento (el elemento
dependiente) [1]
15/11/2012 (c) INAOE 2011-2012 24
Relación de asociación (1/2)
Es una relación estructural entre clases que describe un
conjunto de enlaces, conectando instancias de una
clase
Representada por una línea, la cual puede estar dirigida,
incluir una etiqueta, adornos (multiplicidad y nombres en
el extremo). Ejemplo
(continúa…)
15/11/2012 (c) INAOE 2011-2012 25
0..1 *
empresario empleado
Relación de asociación (2/2)
La agregación es un tipo especial de asociación, que
representa una relación estructural entre un todo y sus
partes
La composición indica que en la relación la existencia de
la parte depende de la existencia del todo
15/11/2012 (c) INAOE 2011-2012 26
Ejemplos [4]
15/11/2012 (c) INAOE 2011-2012 27
Relación de Generalización
Es una relación de tipo especialización/generalización,
en la cual el elemento especializado (el hijo) se basa en
la especificación del elemento generalizado (el padre).
El hijo comparte la estructura y comportamiento del
padre.
Se representa con una flecha con la punta apuntando al
padre
15/11/2012 (c) INAOE 2011-2012 28
Realización
Relación semántica entre clasificadores (elementos
estructurales), donde un clasificador especifica el
contrato que otro clasificador garantiza que se cumplirá.
Existen entre interfaces y clases, con los componentes
que las realizan, y entre casos de uso y las
colaboraciones que las realizan.
Se representan como una mezcla entre una
generalización y una relación de dependencia:
15/11/2012 (c) INAOE 2011-2012 29
30
3. MODELADO ESTRUCTURAL
15/11/2012 (c) INAOE 2011-2012
31
3.1 DIAGRAMA DE CASOS DE USO
15/11/2012 (c) INAOE 2011-2012
Casos de uso
Un caso de uso es un conjunto de escenarios enlazados
juntos por una meta del usuario común.
Un escenario es una secuencia de pasos que describe
una interacción entre un usuario y un sistema.
UML describe la construcción de un diagrama de casos
de uso, que muestra cómo los casos de uso se
relacionan unos con otros.
Casi siempre el valor de los casos de uso está en la
descripción de su contenido puesto que un diagrama sin
descripción es de valor limitado.
32 15/11/2012 (c) INAOE 2011-2012
Escenario para una tienda en línea
El cliente revisa el catálogo y añade los artículos deseado a al
carrito de compra. Cuando el cliente desea pagar indica la
información de su tarjeta de crédito, así como la dirección de envío,
y confirma la venta. El sistema verifica la autorización de la tarjeta y
confirma la venta tanto inmediatamente y por correo electrónico.
Variantes del mismo escenario:
¿Qué pasa si la autorización de la tarjeta de crédito falla?
¿Es posible que el sistema de la tienda en línea pueda almacenar los
datos de usuarios frecuentes?
Meta de estos escenarios comunes: comprar un producto.
33 15/11/2012 (c) INAOE 2011-2012
Actores
A los usuarios se les denomina actores, que representan roles que
los usuarios juegan con respecto al sistema.
Ejemplos de actores:
Cliente.
Representante de servicio a cliente.
Analista de producto.
Los actores llevan a cabo los casos de uso.
Un actor puede participar en varios casos de uso; de manera
inversa, cada caso de uso puede involucrar a varios actores.
Un actor puede representar a una persona o a otro tipo de entidad.
El término más adecuado no es actor, sino rol.
34 15/11/2012 (c) INAOE 2011-2012
Contenido de un caso de uso
No hay una forma estándar de redactar los escenarios y se aceptan
diferentes formatos.
Se puede comenzar seleccionando uno de los escenarios del caso
de uso como el escenario exitoso principal (MSS), el cual se redacta
como una serie de pasos numerados.
Después se pueden redactar las extensiones, descritas en términos
de variaciones al escenario exitoso principal.
Cada caso de uso tiene asociado un actor principal que invoca al
sistema para proporcionar el servicio. El sistema se comunica con
los actores secundarios para completar el caso de uso.
35 15/11/2012 (c) INAOE 2011-2012
Ejemplo de descripción de caso de uso
36 15/11/2012 (c) INAOE 2011-2012
Diagrama de casos de uso
37 15/11/2012 (c) INAOE 2011-2012
38
3.2 DIAGRAMA DE CLASES
15/11/2012 (c) INAOE 2011-2012
Diagramas de clases
Describe el tipo de los objetos en el sistema y
las diferentes relaciones estáticas que existen
entre ellos.
Muestra los rasgos (propiedades y operaciones)
de cada clase.
Ilustra las restricciones que se aplican a la forma
en que están conectados los objetos.
39 15/11/2012 (c) INAOE 2011-2012
Diagrama de clases simple[2]
40 15/11/2012 (c) INAOE 2011-2012
Propiedades como atributos
visibilidad nombre: tipo multiplicidad = default {cadena-propiedad}
visibilidad: publico (+), privado (-) o protegido (#).
nombre: Cómo se refiere la clase al atributo. Corresponde
vagamente a un campo de una estructura.
tipo: Indica una restricción sobre qué tipo de objetos pueden
colocarse en el atributo. Corresponde al tipo de un campo en una
estructura.
multiplicidad: Una indicación de a cuántos objetos se refiere el
atributo.
default value: El valor del atributo para un objeto recién creado si no
se especifica un valor para el atributo.
{cadena-propiedad}: Especifica propiedades adicionales.
41 15/11/2012 (c) INAOE 2011-2012
Propiedades como asociaciones
42 15/11/2012 (c) INAOE 2011-2012
Operaciones
visibilidad nombre (lista-parámetros): tipo {cadena-propiedad}
visibilidad: publico (+), privado (-) o protegido (#).
nombre: Una cadena de caracteres.
lista-parámetros: Es una lista de parámetros para la operación.
tipo: Es el tipo del valor regresado por la operación, si lo hay.
{cadena-propiedad}: Especifica propiedades adicionales.
dirección nombre: tipo = default
dirección: Indica si el parámetro es de entrada, salida o ambos. Si no
se especifica dirección, se asume un parámetro de entrada.
nombre, tipo, default: Igual que para los atributos.
43 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para el registro de
órdenes de compra y clientes (1/18)
Requerimientos:
1. Debe llevar registro de
clientes corporativos y de
clientes que sean personas
físicas.
44 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (2/18)
Requerimientos:
1. Debe llevar registro de
clientes corporativos y de
clientes que sean personas
físicas.
2. La información general de los
clientes incluye su nombre (o
razón social) y su dirección.
45 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (3/18)
Requerimientos:
1. Debe llevar registro de
clientes corporativos y de
clientes que sean personas
físicas.
2. La información general de los
clientes incluye su nombre (o
razón social) y su dirección.
3. Para ambos tipos de cliente
debe ser posible obtener su
calificación de crédito.
46 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (4/18)
Requerimientos:
1. Debe llevar registro de
clientes corporativos y de
clientes que sean personas
físicas.
2. La información general de los
clientes incluye su nombre (o
razón social) y su dirección.
3. Para ambos tipos de cliente
debe ser posible obtener su
calificación de crédito.
4. La información de los clientes
corporativos incluye datos de
la persona de contacto, la
calificación de crédito y su
límite de crédito.
47 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (5/18)
Requerimientos:
1. Debe llevar registro de
clientes corporativos y de
clientes que sean personas
físicas.
2. La información general de los
clientes incluye su nombre (o
razón social) y su dirección.
3. Para ambos tipos de cliente
debe ser posible obtener su
calificación de crédito.
4. La información de los clientes
corporativos incluye datos de
la persona de contacto, la
calificación de crédito y su
límite de crédito.
48 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (6/18)
Requerimientos:
5. El sistema debe almacenar
el número de tarjeta de
crédito de los clientes que
sean personas físicas.
49 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (7/18)
Requerimientos:
5. El sistema debe almacenar
el número de tarjeta de
crédito de los clientes que
sean personas físicas.
6. La calificación de crédito de
una persona física es
limitada (para la mayoría
de ellas al menos).
50 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (8/18)
Requerimientos:
5. El sistema debe almacenar
el número de tarjeta de
crédito de los clientes que
sean personas físicas.
6. La calificación de crédito de
una persona física es
limitada (para la mayoría
de ellas al menos).
7. El sistema debe llevar el
registro de los agentes de
ventas asignados a los
clientes corporativos como
representantes.
51 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (9/18)
Requerimientos:
5. El sistema debe almacenar
el número de tarjeta de
crédito de los clientes que
sean personas físicas.
6. La calificación de crédito de
una persona física es
limitada (para la mayoría
de ellas al menos).
7. El sistema debe llevar el
registro de los agentes de
ventas asignados a los
clientes corporativos como
representantes.
52 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (10/18)
Requerimientos:
8. El sistema también registra
los productos que la
compañía fabrica, los
cuales son comercializados
mediante órdenes de
compra.
53 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (11/18)
Requerimientos:
8. El sistema también registra
los productos que la
compañía fabrica, los
cuales son comercializados
mediante órdenes de
compra.
9. Una orden de compra debe
contener la información de
la fecha en que se expide,
su folio y el monto total del
pedido.
54 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (12/18)
Requerimientos:
8. El sistema también registra
los productos que la
compañía fabrica, los
cuales son comercializados
mediante órdenes de
compra.
9. Una orden de compra debe
contener la información de
la fecha en que se expide,
su folio y el monto total del
pedido.
10. Cada cliente puede haber
colocado varias órdenes de
compra. Y cada orden de
compra (identificada por su
folio) ha sido colocada por
un único cliente.
55 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (13/18)
Requerimientos:
8. El sistema también registra
los productos que la
compañía fabrica, los
cuales son comercializados
mediante órdenes de
compra.
9. Una orden de compra debe
contener la información de
la fecha en que se expide,
su folio y el monto total del
pedido.
10. Cada cliente puede haber
colocado varias órdenes de
compra. Y cada orden de
compra (identificada por su
folio) ha sido colocada por
un único cliente.
56 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (14/18)
Requerimientos:
11. Una entrada de la orden de
compra contiene
información sobre la
cantidad de producto
adquirido, la descripción de
tal producto y el costo por
esa cantidad de producto.
57 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (15/18)
Requerimientos:
11. Una entrada de la orden de
compra contiene
información sobre la
cantidad de producto
adquirido, la descripción de
tal producto y el costo por
esa cantidad de producto.
12. Cada orden de compra
puede contener un conjunto
de varias entradas
ordenadas, cada una con la
información correspondiente
a un producto específico.
58 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (16/18)
Requerimientos:
11. Una entrada de la orden de
compra contiene
información sobre la
cantidad de producto
adquirido, la descripción de
tal producto y el costo por
esa cantidad de producto.
12. Cada orden de compra
puede contener un conjunto
de varias entradas
ordenadas, cada una con la
información correspondiente
a un producto específico.
13. Cuando la calificación de
crédito del cliente no es
buena el sistema debe
registrar que el pago por la
orden debe ser anticipado.
59 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (17/18)
Requerimientos:
11. Una entrada de la orden de
compra contiene
información sobre la
cantidad de producto
adquirido, la descripción de
tal producto y el costo por
esa cantidad de producto.
12. Cada orden de compra
puede contener un conjunto
de varias entradas
ordenadas, cada una con la
información correspondiente
a un producto específico.
13. Cuando la calificación de
crédito del cliente no es
buena el sistema debe
registrar que el pago por la
orden debe ser anticipado.
60 15/11/2012 (c) INAOE 2011-2012
Ejemplo: Sistema de información para… (18/18)
61 15/11/2012 (c) INAOE 2011-2012
Sistema de información para el registro de órdenes de
compra, clientes, empleados y proyectos
Requerimientos:
1. El sistema de información
debe llevar un registro de
todos los empleados. Los
puestos que pueden
ocupar son: gerente,
ingeniero de diseño,
ingeniero de campo,
representante de ventas y
administrativo.
2. La empresa diseña y
manufactura varios tipos
de computadoras,
teléfonos móviles,
reproductores de música y
el sistema de información
debe llevar un registro de
las especificaciones de
cada producto.
62 15/11/2012 (c) INAOE 2011-2012
Sistema de información para el registro de órdenes de
compra, clientes, empleados y proyectos
Requerimientos:
3. El sistema de información
debe llevar un registro de
qué ingenieros de diseño
están asignados al
desarrollo de cada
producto.
4. El sistema de información
debe llevar un registro de
qué ingenieros de campo
proporcionan servicios de
consultoría a cada cliente
corporativo.
5. La compañía está
organizada en
departamentos de R&D,
cada uno de ellos con su
gerente y su equipo de
ingenieros de diseño.
63 15/11/2012 (c) INAOE 2011-2012
64
3.3 DIAGRAMA DE
COMPONENTES
15/11/2012 (c) INAOE 2011-2012
Fundamentos
Un componente es una parte modular que oculta su
implementación detrás de un conjunto de interfaces
externas. Un componente proporciona la realización de
un conjunto de interfaces.
Los componentes que comparten las mismas interfaces
se pueden sustituir siempre y cuando tengan el mismo
comportamiento lógico.
La implementación de un componente puede expresarse
conectando partes y conectores; las partes pueden
incluir componentes más pequeños.
65 15/11/2012 (c) INAOE 2011-2012
Interfaces
Una interfaz es una colección de operaciones que
representan el comportamiento completo de una clase o
componente, o sólo una parte de ese comportamiento.
Una interfaz especifica un conjunto de operaciones
(prototipos), pero nunca un conjunto de
implementaciones.
Una interfaz raramente se encuentra aislada.
66 15/11/2012 (c) INAOE 2011-2012
Notación de interfaces [2]
67 15/11/2012 (c) INAOE 2011-2012
Definición de interfaces [2]
68 15/11/2012 (c) INAOE 2011-2012
Notación de componentes
69 15/11/2012 (c) INAOE 2011-2012
Componentes e Interfaces
15/11/2012 (c) INAOE 2011-2012 70
Puertos en un componente
15/11/2012 (c) INAOE 2011-2012 71
Son las ventanas explícitas dentro de un componente
Ejemplo
72 15/11/2012 (c) INAOE 2011-2012
73
4. MODELADO DEL
COMPORTAMIENTO
15/11/2012 (c) INAOE 2011-2012
INTERACIONES
En UML los aspectos dinámicos se modelan mediante interacciones
Las interacciones establecen escenarios presentando todos los objetos que colaboran para realizar una acción, e incluyen los mensajes enviados entre objetos
Se utilizan para controlar flujo de control
Se pueden usar diagramas de secuencia o diagramas de comunicación
Roles: pueden ser instancias prototípicas de clases, interfaces, componentes, nodos y casos de uso
15/11/2012 (c) INAOE 2011-2012 74
Mensajes
Los objetos son entidades de software que colaboran y
se envían mensajes entre ellos.
75 15/11/2012 (c) INAOE 2011-2012
Mensajes
15/11/2012 (c) INAOE 2011-2012 76
Booch et al. 2006]
Mensajes, enlaces y secuenciación
15/11/2012 (c) INAOE 2011-2012 77
Booch et al. 2006]
Asociaciones, enlaces y conectores
15/11/2012 (c) INAOE 2011-2012 78
Booch et al. 2006]
El flujo de control y el tiempo (secuencia)
15/11/2012 (c) INAOE 2011-2012 79
Booch et al. 2006]
El flujo de control por organización
(comunicación)
15/11/2012 (c) INAOE 2011-2012 80
Booch et al. 2006]
81
4.1 DIAGRAMAS DE SECUENCIA Y
COMUNICACION
15/11/2012 (c) INAOE 2011-2012
Diagrama de Secuencia
Es un diagrama que ilustra la interacción entre objetos.
Consta de un conjunto de objetos y sus relaciones,
incluyendo los mensajes enviados entre ellos.
Destaca la ordenación temporal de los mensajes entre
los objetos que interaccionan.
82 15/11/2012 (c) INAOE 2011-2012
Diagrama de secuencia
15/11/2012 (c) INAOE 2011-2012 83
Booch et al. 2006]
Tipos de operadores de control (controles)
estructurados
ETIQUETA DESCRIPCIÓN
opt Ejecución opcional. El cuerpo del operador se ejecuta si una
condición de guarda es cierta cuando se entra en el operador
alt Ejecución condicional. El cuerpo de control se divide en varias
sub-regiones separadas por líneas discontinuas horizontales.
Cada sub-región tiene una condición de guardia. Solo se ejecuta
una subregión como máximo. Si no es cierta ninguna condición,
el control continúa después del operador. Una condición puede ser [else]
par Ejecución paralela. El cuerpo se divide en varias subregiones y
cada una representa una ejecución concurrente. En la mayoría
de los casos, cada sub-región implica diferentes líneas de vida
loop Ejecución iterativa. Una condición de guarda aparece sobre una
línea de vida dentro del cuerpo. El cuerpo se ejecuta
repetidamente mientras la condición es cierta antes de cada
iteración
15/11/2012 (c) INAOE 2011-2012 84
[Booch et al. 2006]
Operadores de Control estructurados
15/11/2012 (c) INAOE 2011-2012 85
Booch et al. 2006]
Problema: Modelar el proceso de cálculo del
precio total de una orden de compra
1. La instancia de la clase Order contiene una operación que al
invocarla inicie el proceso de cálculo.
2. Para cada entrada en la orden de compra (instancia de OrderLine)
se necesita calcular el costo total por producto; éste se calcula en
base a:
La cantidad de producto solicitado.
El precio unitario de tal producto.
3. La instancia de la clase Order suma los costos de todos los
productos en la orden y realiza otros posibles cálculos para
determinar el precio base.
4. El precio final incluye un descuento que se aplica de forma distinta
dependiendo del tipo de cliente. La instancia de la clase Order
consulta la información sobre el cliente para determinar el monto
de descuento y entonces calcular el costo total de la orden.
86 15/11/2012 (c) INAOE 2011-2012
Diagrama de clases extendido del ejemplo
87 15/11/2012 (c) INAOE 2011-2012
Diagrama de secuencia para el ejemplo
88 15/11/2012 (c) INAOE 2011-2012
Ejercicio
La clase Order tiene un método llamado dispatch() que inicia el
proceso de entrega de los productos que conforman una orden de
compra de acuerdo a los siguientes criterios:
Si el costo total por la cantidad de producto es menor que el límite de $10,000
entonces se indica a un distribuidor regular que haga el reparto del producto,
bajo medidas estándar de seguridad.
Si el costo total por la cantidad de producto rebasa el límite de $10,000 entonces
se indica a un distribuidor especial (diferente al anterior) que haga el reparto del
producto, bajo medidas más rígidas de seguridad.
La empresa tiene un mensajero que, de ser necesario, confirma que
los pedidos de cada producto hayan sido despachados de forma
correcta.
89 15/11/2012 (c) INAOE 2011-2012
Diagrama del ejercicio
90 15/11/2012 (c) INAOE 2011-2012
Ejercicio
Modele, mediante un sencillo diagrama de secuencia en UML 2.0,
la interacción entre un usuario (instancia de la clase Persona) y un
cajero electrónico (instancia de la clase ATM):
Al principio, el diagrama debe ilustrar que el usuario proporciona su NIP al cajero
y que este le informa si el NIP es válido o no. El diagrama debe ilustrar que este
proceso se realiza de forma iterativa mientras el NIP ingresado sea inválido. Por
simplicidad asuma que el cajero es capaz de recibir el NIP del usuario un
número indeterminado de veces.
A continuación, el diagrama debe ilustrar la interacción en la cual el usuario
indica la cantidad a retirar y la interacción en la que el cajero entrega el efectivo
(si es que cuenta con efectivo suficiente) o un mensaje de error (en caso de que
no haya suficiente efectivo). Todas las interacciones en este punto se realizan
únicamente si el NIP ingresado por el usuario anteriormente es válido.
91 15/11/2012 (c) INAOE 2011-2012
Diagrama del ejercicio
92 15/11/2012 (c) INAOE 2011-2012
Creación dinámica de instancias
93 15/11/2012 (c) INAOE 2011-2012
Ejercicio: procesamiento de cheques en un sistema
de información para banco
El módulo principal de un sistema de información bancario crea una
instancia de la clase Cheque cuando algún cajero introduce los datos
de un cheque de dicho banco que ha recibido de algún cliente portador.
Estos datos incluyen el folio, la fecha de expedición, el número de
cuenta de la persona que expidió el cheque y el monto del cheque.
El módulo gestor de cuentas entra en acción para verificar que el
cliente que expidió el cheque dispone de fondos suficientes, mediante
una consulta a la cuenta del cliente que expidió el cheque.
Si el balance en la cuenta anterior es mayor o igual al monto del
cheque entonces el gestor resta le resta esta cantidad de la cuenta del
titular y después se la suma a la cuenta del cliente que porta el
cheque.
Si el balance en la cuenta de la persona que expidió el cheque es
menor al monto del cheque entonces el gestor le aplica una cuota de
penalización al titular a través de la cuenta y después le envía un
correo electrónico informándole de la situación.
94 15/11/2012 (c) INAOE 2011-2012
95
5. MODELO ARQUITECTÓNICO
15/11/2012 (c) INAOE 2011-2012
96
5.1 DIAGRAMA DE DESPLIEGUE
15/11/2012 (c) INAOE 2011-2012
DIAGRAMA DE DESPLIEGUE
Sirven para visualizar el diseño
arquitectónico
Permiten ver los aspectos físicos
(computadoras, sistemas, dispositivos)
que implementan un sistema
Incluyen nodos, artefactos y las relaciones
entre ellos.
15/11/2012 (c) INAOE 2011-2012 97
Nodo
Es un elemento físico que existe en tiempo de ejecución y que representa un recurso computacional, que generalmente tien algo de memoria y a menudo capacidad de procesamiento
Se pueden organizar agrupándolos en paquetes y se pueden conectar entre sí, normalmente como asociaciones
Pueden tener atributos y operaciones
15/11/2012 (c) INAOE 2011-2012 98
nombre
Artefacto
Representan el empaquetamiento de
elementos lógicos, bits, código
En los nodos se ejecutan los artefactos
15/11/2012 (c) INAOE 2011-2012 99
100 15/11/2012 (c) INAOE 2011-2012
Ejemplo: modelado de procesadores y
dispositivos
15/11/2012 (c) INAOE 2011-2012 101
Booch et al. 2006]
Modelado de un sistema cliente-servidor
15/11/2012 (c) INAOE 2011-2012 102
Booch et al. 2006]
Modelado de un sistema completamente
distribuido
15/11/2012 (c) INAOE 2011-2012 103
Booch et al. 2006]
Modelado de un sistema embebido
15/11/2012 (c) INAOE 2011-2012 104
Booch et al. 2006]
Referencias
1. Booch, G., Rumbaugh, J. y Jacobson, I; El Lenguaje Unificado de
Modelado; Segunda Edición; Addison-Wesley; 2006.
2. Fowler, M; UML Distilled. A Brief Guide to the Standard Object
Modeling Language; Tercera Edición; Addison-Wesley; 2004.
3. Pressman, R; Software Engineering: A Practitioner's Approach;
Séptima Edición; Mc-Graw Hill; 2010.
4. Weilkieins, T. y Oestereich, B; UML 2 Certification Guide:
Fundamental and Intermediate Exams; Morgan Kaufmann; 2006.
105 15/11/2012 (c) INAOE 2011-2012