Unified Modeling Language 2 - INAOE - Ciencias …pgomez/cursos/ingsw/acetatos/UML 2_0... · UML es...

Unified Modeling Language 2.0

Tomás Balderas Contreras [email protected]

Pilar Gómez-Gil

[email protected]

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”

http://ccc.inaoep.mx/~pgomez/cursos/ingsw/acetatos/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:




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


Requerimientos:




físicas.




3. Para ambos tipos de cliente

debe ser posible obtener su

calificación de crédito.

46 15/11/2012 (c) INAOE 2011-2012


Requerimientos:




físicas.







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


Requerimientos:




físicas.







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


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


Requerimientos:





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


Requerimientos:








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


Requerimientos:








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


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


Requerimientos:






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


Requerimientos:






compra.





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


Requerimientos:






compra.





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


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


Requerimientos:


compra contiene






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


Requerimientos:


compra contiene








de varias entradas




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


Requerimientos:


compra contiene








de varias entradas




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


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


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:



qué ingenieros de diseño

están asignados al

desarrollo de cada

producto.



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

Unified Modeling Language 2 - INAOE - Ciencias …pgomez/cursos/ingsw/acetatos/UML 2_0... · UML es...

Documents

Transcript of Unified Modeling Language 2 - INAOE - Ciencias …pgomez/cursos/ingsw/acetatos/UML 2_0... · UML es...