ANLISIS Y DISEO DE
SISTEMAS INFORMTICOS
TINS Bsicos
INGENIERA DE SISTEMAS
Lima - Per
Vicerrectorado de Investigacin
Diseo y Diagramacin
Soporte acadmico
Instituto de Investigacin
Produccin
PRESENTACIN
El presente texto elaborado en el marco de desarrollo de la Ingeniera, es un
material de ayuda instruccional, en la carrera de Ingeniera de Sistemas para la
Asignatura de Anlisis y Diseo de Sistemas Informticos, en el sexto ciclo de estudios.
Plasma la iniciativa institucional de innovacin de la enseanza-aprendizaje
educativa universitaria, que en acelerada continuidad promueve la produccin de
materiales educativos, actualizados en concordancia a las exigencias de estos tiempos.
Esta primera edicin apropiadamente recopilada, de diversas fuentes
bibliogrficas, de uso frecuente en la enseanza de la Ingeniera de Sistemas, est
ordenada en funcin del syllabus de la Asignatura, arriba mencionada.
La conformacin del texto ha sido posible gracias al esfuerzo y dedicacin
acadmica del profesor Hernn Robalino Gmez; contiene siete captulos, cuyas
descripciones genricas son como sigue:
El capitulo I proporciona al alumno un panorama breve de los sistemas de
informacin; los conceptos bsicos de la tecnologa de objetos y del lenguaje unificado
de modelado.
El capitulo II tiene un resumen del modelado de negocios, requisitos anlisis y
diseo.
En el capitulo III se utiliza los conceptos del anlisis orientado a objetos para
organizar los elementos en paquetes, descripcin de casos de uso y elaboracin de los
diagramas de casos de uso.
En el capitulo IV se muestra el aspecto dinmico de los sistemas a travs de
los diagramas de secuencia y de colaboracin.
El capitulo V modela la vista esttica de un sistema, mediante las instancias de
los elementos contenidos en los diagramas de clases.
El capitulo VI modela el aspecto dinmico de los sistemas utilizando los
diagramas de actividad que se centra en las actividades que ocurren dentro del objeto,
y los diagramas de estado, que se centran en el comportamiento dirigidos por eventos
de un objeto.
Vicerrectorado de Investigacin
NDICE
CAPITULO I
1.1
1.2
1.3
1.4
Introduccin
Sistema de informacin
Conceptos Bsicos de la Tecnologa de Objetos
El Lenguaje Unificado de Modelado (UML)
11
11
15
17
CAPITULO II
2.1
2.2
2.3
2.4
21
22
22
23
CAPITULO III
3.1 Organizando los Elementos en Paquetes
3.2 Casos de Uso
3.3 Diagramas de Casos de Uso
25
25
31
CAPITULO IV
4.1 Diagramas de Interaccin
4.1.1 Diagrama de Secuencia
4.1.2 Diagrama de Colaboracin
37
37
43
CAPITULO V
5.1 Diagrama de Objetos
5.2 Clases
5.3 Diagrama de Clases
47
49
58
CAPITULO VI
6.1 Diagrama de Estado
6.2 Diagrama de Actividad
81
93
CAPITULO VII
7.1
7.2
7.3
7.4
Diagrama de Componentes
Diagrama de Distribucin
Trabajo Prctico
Arquitectura de Tres Capas
103
104
107
122
Bibliografa
129
DISTRIBUCIN TEMTICA
CLASE
N
1
2
3
4
9
10
11
12
13
14
15
16
17
18
19
TEMA
SEMANA
HORAS
03
2
3
03
03
03
03
03
03
03
9
10
11
12
13
03
03
03
03
03
14
03
15
03
16
17
18
19
03
03
03
03
10
CAPTULO I
1.1
INTRODUCCIN
Los altos ejecutivos, estadistas o cualquier persona que tiene un puesto de
responsabilidad en las empresas, instituciones privadas o estatales, encuentran cada
da ms difcil el tomar una decisin sobre el curso de accin para solucionar, de la
mejor forma un problema. Esta situacin hace que los sistemas de informacin sean
cada vez ms importantes para el desenvolvimiento diario de la empresa.
Sistema
Desde un punto de vista prctico un sistema es un conjunto de elementos
dinmicamente relacionados entre s, para alcanzar un objetivo.
Sistema Productivo
En un proceso industrial entran insumos (materia prima), que pasan por un proceso de
transformacin y se obtiene como resultado final un producto terminado. Paralelo a
este proceso industrial, existe un sistema de informacin que utiliza los datos de los
insumos, del proceso y del producto terminado
1.2
SISTEMA DE INFORMACIN (SI)
Un sistema informtico utiliza ordenadores para almacenar datos, procesarlos y
ponerlos a disposicin de quien se considere oportuno. Un sistema puede ser tan
simple como: una persona tiene un microordenador y le introduce datos tan
elementales, como por ejemplo las ventas diarias de una pequea empresa, se produce
una entrada por cada venta y en ella se declara el elemento vendido, por ejemplo un
yogur, la cantidad de elementos vendidos, por ejemplo cuatro y el precio de venta
unitario, por ejemplo 0.15 euros. Cada entrada se almacena como un registro de un
fichero en el disco. Al finalizar el da se puede obtener un informe de las ventas y las
tendencias. El usuario puede utilizar esta informacin para la gestin de almacn o
planificar campaas publicitarias. Habitualmente una empresa tiene ms de un
ordenador, por ejemplo uno para la gestin de ventas y otro para la contabilidad y
procesos asociados. Sin embargo la mayor parte de los sistemas son ms complejos.
Los sistemas de informacin tienen muchas cosas en comn, la mayora de ellos estn
formados por:
Personas.- son un componente esencial en
cualquier sistema de informacin, producen y
utilizan la informacin de sus actividades
diarias para decidir lo que se debe hacer. Las
decisiones pueden ser rutinarias o complejas.
Procedimientos.- los sistemas de informacin
deben soportar diversas clases de actividades
del usuario, por eso han de establecerse
procedimientos que aseguren que los datos
correctos llegan a las personas adecuadas en
su momento justo.
11
12
de despliegue grfico para producir salida en forma de grficos, mapas y dibujos. Los
cajeros automticos, a menudo exhiben instrucciones en pantalla para ayudar a los
clientes de un banco en la realizacin de sus operaciones. Tambin se puede preparar
respuestas con voz para proporcionar informacin de salida interna y externa.
Dispositivos.- Los dispositivos empleados en aplicaciones de procesamiento en lnea
tienen las siguientes caractersticas:
Permiten introducir datos directamente a la CPU.
Generalmente estn ubicados en o cerca de la fuente de datos, la cual puede estar
alejada de la CPU.
Permiten una relacin interactiva directa entre las personas y las computadoras.
Manejan en forma econmica un volumen de datos de entrada.
Ejemplos:
13
Un objeto tiene una identidad que denota una existencia separada de los otros objetos.
El comportamiento de un objeto se manifiesta ante acciones y reacciones en forma de
cambios de estado.
Wirfs-Brook et al, 1990.- bsicamente un objeto contiene determinada informacin y es
capaz de realizar determinadas operaciones
Snyder, 1993.- bsicamente un objeto es una entidad que juega un papel visible al
proporcionar servicios a clientes
Un objeto viene caracterizado por
identidad (Oid Object identifier)
a. identificador nico y global
b. independiente de las propiedades
c. invariable desde la creacin a la destruccin del objeto
estado (el estado de un objeto condiciona su comportamiento)
a. evoluciona a lo largo del tiempo
b. es funcin de los valores de los atributos
14
comportamiento
a. describe las acciones y reacciones de un objeto
b. las operaciones de un objeto se realizan como consecuencia de
estmulos realizados mediante el envo de mensajes
15
Oracle
Sterling Software
ICON Computing
Petch
Microsoft
IBM
MCI Systemhouse
i-Logix
Taskon A/S
....
DEC
Unisys
ObjectTime
Softeam
16
Ventajas de la unificacin
Reunir los puntos fuertes de cada mtodo
Idear nuevas mejoras
Proporcionar estabilidad al mercado
Proyectos basados en un lenguaje maduro
Aparicin de potentes herramientas
Eliminar confusin en los usuarios
Objetivos en el diseo de UML
Modelar sistemas, desde los requisitos hasta los artefactos ejecutables, utilizando
tcnicas Orientadas a Objetos.
Cubrir las cuestiones relacionadas con el tamao propio de los sistemas complejos
y crticos.
Lenguaje utilizable por las personas y las mquinas
Encontrar equilibrio entre expresividad y simplicidad.
UML y el modelado
UML es una notacin, no es un proceso
Se estn definiendo muchos procesos para UML.
Rational ha ideado RUP, Proceso Unificado de Rational.
Utilizable para sistemas que no sean software
UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos
(modelos) de un sistema que involucra una gran cantidad de software, desde una
perspectiva OO.
Por qu modelamos?
1. Construimos modelos para comprender mejor el sistema que estamos
desarrollando
2. Cuatro utilidades de los modelos:
Visualizar cmo es o queremos que sea el sistema
Especificar la estructura y comportamiento del sistema
Proporcionan plantillas que guan la construccin del sistema
Documentan las decisiones
3. Equivalen a los planos de un edificio
Una empresa software con xito es aquella que produce de manera consistente
software de calidad que satisface las necesidades de los usuarios
El modelado es la parte esencial de todas las actividades que conducen a la
produccin de software de calidad
Un modelo es una simplificacin de la realidad
Principios del modelado
La eleccin de los modelos tiene una profunda influencia sobre cmo se acomete el
problema y se moldea la solucin.
Todo modelo puede expresarse a diferentes niveles de detalle y usarse en diferentes
momentos del ciclo de vida.
Todo modelo debe estar ligado a la realidad.
17
18
19
20
CAPITULO II
2.1
MODELADO DEL NEGOCIO
El objetivo es comprender el conjunto de procesos de negocio que tienen lugar dentro
de una empresa, como paso previo a establecer los requisitos del sistema a desarrollar.
Una organizacin tiene una serie de objetivos que satisface a travs de Procesos de
Negocio.
Los elementos de un proceso de negocio son:
Flujo de Tareas, Agentes/Roles, Informacin y Reglas Negocio.
Las Reglas de Negocio regulan el funcionamiento de la empresa
Describen restricciones y comportamientos.
NO son requisitos, pero influyen en ellos.
Ejemplo
21
2.2
MODELADO DE REQUISITOS
El propsito de este modelo es establecer los requisitos funcionales y no funcionales
del sistema.
Tipos de requisitos
Funcionales.- Especifican los servicios que debe proporcionar la aplicacin
No funcionales.- Estn vinculados a:
Usabilidad
Fiabilidad
Rendimiento
Adaptabilidad, Mantenimiento, Configurable
Implementacin: lenguajes, herramientas,..
GUI
Legales
2.3
MODELADO DEL ANLISIS
A partir de los casos de uso obtener el diseo preliminar del sistema que deber ser
refinado en el modelo del diseo. Se tiene una visin ideal del sistema. Se define una
arquitectura del sistema.
Para cada caso de uso se define un diagrama de secuencia del sistema que muestra
los eventos que un actor genera durante la interaccin con el sistema (caja negra).
Cada evento da origen a una operacin del sistema. El efecto de las operaciones se
describe mediante contratos especificados mediante una plantilla (opcional).
22
Para cada operacin del sistema se define una colaboracin (diagrama de interaccin)
que muestra cmo deben colaborar los objetos para satisfacer la postcondicin
expresada en el contrato de dicha operacin.
Disear las colaboraciones, asignando responsabilidades a las clases. Crear el modelo
de clases a partir del modelo conceptual, conforme se definen las colaboraciones
El modelo de clases del anlisis se crea a partir del modelo conceptual. Se aade
una clase por cada tipo de objeto del dominio que participa en la colaboracin.
Se aaden atributos segn los contratos.
Se aaden mtodos segn las colaboraciones.
Para aquellas clases con objetos con comportamiento dependiente del estado, se
construye una mquina de estados
2.4
MODELADO DEL DISEO
El objetivo es Refinar el diseo del sistema del modelo del anlisis considerando los
requisitos no funcionales y restricciones del entorno de implementacin. De manera
iterativa se refina el modelo de clases y las colaboraciones del anlisis hasta obtener un
diseo del sistema adecuado para pasar a la implementacin.
Se debe:
23
24
CAPITULO III
3.1
ORGANIZANDO LOS ELEMENTOS EN PAQUETES
Los distintos componentes pueden agruparse en paquetes segn un criterio lgico y
con vistas a simplificar la implementacin. Son paquetes estereotipados en
<<subsistemas>>.
Ejemplo.- En este caso existen tres paquetes (que se muestran vacos en este caso,
con su contenido encapsulado), con dos de ellos dependiendo del Modelo del Mundo.
3.2
CASO DE USO
Un caso de uso especifica el comportamiento deseado del sistema. Representan los
requisitos funcionales del sistema.
Un caso de uso especifica una secuencia de acciones, incluyendo variantes, que el
sistema puede ejecutar y que produce un resultado observable de valor para un
particular actor
Describe un conjunto de interacciones entre actores externos y el sistema en
consideracin orientadas a satisfacer un objetivo de un actor. [D. Bredemeyer]
25
Actor.- Un actor representa un conjunto coherente de roles que juegan los usuarios de
los casos de uso al interaccionar con el sistema. Roles jugados por personas,
dispositivos, u otros sistemas. No forman parte del sistema. Inician la ejecucin de los
casos de uso. Un usuario puede jugar diferentes roles. En la realizacin de un caso de
uso pueden intervenir diferentes actores. Un actor puede intervenir en varios casos de
uso. Identificar casos de uso mediante actores y eventos externos. Un actor necesita el
caso de uso y/o participa en l.
Los actores solo se pueden conectar a los casos de uso a travs de asociaciones. Una
asociacin entre actor y un caso indica que el actor y el caso de uso se comunican entre si, y
cada uno puede enviar y recibir mensajes.
A. Cockburn distingue dos tipos de actores:
Primarios: Requieren al sistema el cumplimiento de un objetivo
Secundarios: El sistema necesita de ellos para satisfacer un objetivo
Es til encontrar primero los actores.
Se puede diferenciar entre (Fowler):
Objetivos del usuario:
formatear un documento
Interacciones del sistema:
definir un estilo, mover un estilo a otro documento.
Gua til: primero buscar los objetivos del usuario, y luego cubrir cada objetivo con
interacciones del sistema.
Propiedades de los casos de uso
Son iniciados por un actor con un objetivo en mente y es completado con xito cuando
el sistema lo satisface
y si el caso de uso se inicia automticamente?
Entonces el Actor sera el Sistema o Tiempo
Puede incluir secuencias alternativas que llevan al xito y fracaso en la consecucin
del objetivo.
El sistema es considerado como una caja negra y las interacciones se perciben
desde fuera.
26
El conjunto completo de casos de uso especifica todas las posibles formas de usar el
sistema, esto es el comportamiento requerido.
Cada caso de uso debe tener un nombre que lo distingue de otros casos de uso. Un
nombre es una cadena de caracteres. En la practica, los nombres de los casos de uso, son
expresiones verbales que describen algn comportamiento del vocabulario del sistema que se
esta modelando. Puede tener cualquier nmero de letras, dgitos o signos de puntuacin.
Ejemplos
Efectuar Pedido
Hacer pedido
Validar usuario
27
Comprar artculos
28
Flujo Principal: Un cliente llega al TPV con un conjunto de artculos. El Cajero registra
los artculos y se genera un ticket. El cliente paga en efectivo y recoge los artculos.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Ejemplo
Validar Usuario (contexto de un cajero automtico)
Validar Usuario
Flujo Principal: El sistema pide la Clave. El cliente lo introduce a travs del teclado y
pulsa Enter. El sistema comprueba la validez de la Clave. Si es vlido el sistema acepta
la entrada y finaliza el caso de uso.
Flujo Excepcional: El cliente puede cancelar la transaccin en cualquier momento,
pulsando el botn Cancelar, reiniciando el caso de uso.
Flujo Excepcional: Si la Clave introducida es invlida entonces se reinicia el caso de
uso. Si esto ocurre tres veces, el sistema cancela la transaccin completa y se queda
con la tarjeta.
Ejemplo
Prestar libro (contexto de una biblioteca)
Prestar Libro
29
Precondicin
Secuencia
Normal
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Importancia
Urgencia
Comentarios
30
3.3
DIAGRAMA DE CASOS DE USO
Un diagrama de Casos de Uso muestra las distintas operaciones que se esperan de
una aplicacin o sistema y cmo se relaciona con su entorno (usuarios u otras
aplicaciones).
Ejemplo
Ejemplo
31
Ejemplo
Ejemplo
32
Ejemplo
33
Facturar al Cliente
Hacer pedido
<<include>>
Seguir pedido
Validar cliente
<<include>>
<<Include>>
Ejemplo
Enviar pedido
Punto de extensin:
Materiales preparados
34
<<extend>>
Enviar Pedido parcial
Materiales preparados
Ejemplo
Realizar transacciones
con Tarjetas
cliente individual
Procesar
Comercio
Factura cliente
Ajustar transacciones
cliente
cliente corporativo
Gestionar cuenta
corriente
Entidad financiera
35
Evita redes complicadas de casos de uso: Cuidado con las relaciones include y
extend.
No considerar la interfaz del usuario
Los casos de uso slo consideran los requisitos funcionales del proyecto, hay que
aadir los no funcionales.
36
CAPITULO IV
4.1
DIAGRAMAS DE INTERACCIN
Los diagramas de interaccin (los diagramas de secuencias y colaboracin) son dos de los
cinco tipos de diagramas UML que se usan para modelar los aspectos dinmicos de los
sistemas. Un diagrama de interaccin muestra la interaccin, que incluye un conjunto de
objetos y sus relaciones y los mensajes que se pueden enviar entre ellos. Un diagrama de
secuencia es un diagrama que destaca la ordenacin temporal de los mensajes. Un
diagrama de colaboracin es un diagrama que destaca la organizacin estructural de los
objetos que envan y reciben mensajes.
Los diagramas de interaccin se usan para modelar los aspectos dinmicos de un sistema.
Se utilizan para visualizar, especificar, construir y documentaran la dinmica de una sociedad
particular de objetos o para modelar un flujo de control particular de un caso de uso.
Normalmente, los diagramas de interaccin contienen: objetos, enlaces y mensajes. Al igual
que otros diagramas pueden contener notas y restricciones.
4.1.1
Diagrama de secuencia.
37
Ejemplo
Diagrama de secuencia de Comprar Artculos
Algunas consideraciones
Un objeto puede enviarse a s mismo un mensaje:
a
m e n s a je
r e f l e x iv o
E l re t o rn o s e
c o n s id e ra im p lc it o
c u a n d o e l e n vo e s
s n c ro n o
38
b : aa
39
W h i le X
Loop
end Loop
If c o n d ic i n
e ls e
e n d if
40
Ejemplo
Diagrama de secuencia de prstamo de libro
Socio
Encargado
Coger libro
Libro
Ficha socio
Ficha libro
Solicitar prstamo
Verificar situacin socio
Situacin socio ok
Verificar situacin libro
Situacin libro ok
Introducir prstamo
Autorizar prstamo
Ejemplo
Diagrama de secuencia de efectuar llamada
41
Prstamo
Ejemplo
Diagrama de secuencia de Realizar Compra
Ejemplo
Diagrama de secuencia identificando la responsabilidad de cada clase
42
4.1.2
Diagrama de colaboracin.
43
1 *| | [i:=1..n] : Mensaje
B
A
[x>y] 1: Mensaje
B
A
1: distancia:= mover(x,y)
B
A
44
Ejemplo
Diagrama de colaboracin de prstamo de libro
1: Coger libro
: Libro
: Socio
2: Solicitar prstamo
3: Verificar situacin socio
: Ficha socio
8: Autorizar prstamo
4: Situacin socio ok
6: Situacin libro ok
: Encargado
7: Introducir prstamo
45
: Prstamo
46
CAPITULO V
5.1
DIAGRAMA DE OBJETOS
Los diagramas de objetos modelan las instancias de los elementos contenidos en los
diagramas en los diagramas de clase y muestran un conjunto de objetos y sus relaciones en
un momento concreto. Los diagramas de objetos se utilizan para modelar la vista de diseo
esttica o la vista de procesos esttica de un sistema.
Los diagramas de objetos normalmente contienen: objetos y enlaces (puede contener notas y
restricciones).
Tambin pueden contener paquetes o subsistemas, los que se usan para agrupar los
elementos de un modelo en partes ms grandes. Un diagrama de objetos es esencialmente
un diagrama de clases o la parte esttica de un diagrama de interaccin.
Ejemplo
Compaa : C
enlace
Departamento : d2
Departamento : d1
NombreD= I+D
Nombre D=ventas
objeto
Departamento : d3
Nombre D=ventasexterior
objeto annimo
Persona : per
Valor de atributo
InfoDeContacto :
Direccin =Bosques del Sur
Nombre =Francisco
IdEmpleado = 4578
Cargo =Gerente Ventas
...
47
5.2
CLASES
Las clases son los bloques de construccin ms importantes de cualquier sistema orientado a
objetos. Una clase describe un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semntica. Una clave implementa una o ms interfaces.
Las clases capturan el vocabulario del sistema que se esta desarrollando. Puede incluir
abstracciones que formen parte del dominio del problema o clases que constituyan una
implementacin. Pueden usarse para representar cosas que sean software, hardware o solo
conceptuales.
En UML todas las cosas se modelan con clases. Una clave no es un objeto individual, sino
que representa un conjunto de objetos.
Se representa por un rectngulo con tres divisiones internas (ver figura), son los elementos
fundamentales del diagrama: su nombre, sus atributos y sus operaciones.
Rectngulo
Atributos
float altura;
float base;
aadir ( );
ampliar ( );
mover ( );
estaVaco ( );
Nombre
Operaciones
Nombre
Cada clase ha de tener un nombre que la distinga de otra clases. Un nombre es una cadena
de texto. Tambin se puede dibujar mostrando solo su nombre. Un nombre solo se
denomina nombre simple; un nombre de camino consta de la clase precedido por el nombre
del paquete en el que se encuentra.
ReglasDelNegocio :: AgenteFraudes
Cliente
Empleado
Nombre de camino
Nombres simples
Atributos
Un atributo es una propiedad de una clase identificada con un nombre, que describe un rango
de valores que pueden tomar las instancias de la propiedad. Una clase puede tener cualquier
nmero de atributos o no tener ninguno. Un atributo representa alguna propiedad del
elemento que se esta modelando, que es compartida por todos los objetos de esa clase.
Ejemplo: todo rectngulo tiene altura y base.
48
Un atributo es una abstraccin de un tipo de datos o estado que puede incluir un objeto de la
clase. En un momento dado, un objeto tendr valores especficos para cada uno de los
atributos de la clase. Se ubican en el compartimiento que se encuentra debajo del nombre
de la clase.
[visibilidad] nombre [: tipo] [= valor_inicial ]
Visibilidad
+ = pblica
# = protegida
- = privada
nombre: nombre del atributo
tipo: tipo del atributo
valor_inicial: valor inicial o por defecto
Ejemplo
Pedido
int articulo;
int cantidad = 0;
boolean seentrego = false;
Adems:
Operaciones
49
Ejemplo
Rectngulo
aadir ( ),
ampliar ( );
mover ( );
esta Vaco ( );
Nivel Conceptual
Responsabilidades de la clase
Tarjetas CRC: Descripcin de alto nivel del propsito de la clase
Nivel Especificacin
Protocolo de la clase (operaciones pblicas)
Nivel Implementacin
Conjunto de mtodos de la clase
Responsabilidades
Una responsabilidad es un contrato u obligacin de una clase. Al crear una clase, se esta
expresando que todos los objetos de esa clase tiene el mismo tipo de estado y el mismo tipo
de comportamiento. En forma abstracta, los atributos y las operaciones son caractersticas
por medio de los cuales se llevan a cabo las responsabilidades de la clase. Una clase
50
Agente Fraudes
Responsabilidades
-- determinar el riesgo de un pedido de cliente.
-- manejar criterios de fraude especficos del
cliente
responsabilidades
Al modelar clases en UML hay que recordar que cada clase debe corresponderse con una
abstraccin tangible a conceptual en el dominio del problema. Un clase bien estructurada:
Debe proporcionar una abstraccin precisa de algo extrado del vocabulario del dominio
del problema.
Contiene un grupo de responsabilidades bien definidos, y los lleva a cabo en buena
forma.
Permite distinguir entre la especificacin de la abstraccin y su implementacin.
Es compresible y sencilla, a la vez que extensible y adaptable.
RELACIONES
En el proceso de abstraccin se concluye que pocas clases se hallan aisladas. En el
modelado orientado a objetos, hay tres tipos de relaciones importantes: dependencias, que
representan relaciones de uso entre clases;
generalizaciones, que conectan clases
generales con sus especializaciones; y asociaciones que representan relaciones
estructurales entre objetos.
Una Relacin es una conexin entre elementos. Grficamente se representa como una
lnea, usando diferentes tipos de lnea para diferenciar los diferentes tipos de relacin.
Una Dependencia es una relacin de uso que declara que un cambio en la especificacin de
un elemento puede afectar a otro elemento que le utiliza, pero no necesariamente a la
inversa. Se representa como una lnea discontinua dirigida hacia el elemento del cual
depende. Se usa cuando se quiere indicar de un elemento utiliza a otro.
51
La mayora de las veces, la dependencia se usan en el contexto de los clases, para indicar
que una clase utiliza a otro como argumento en la signatura de una operacin.
Ejemplo
Una dependencia puede tener un nombre, aunque es raro que se usen, a menos que se
tenga el caso de muchas dependencias y cada una daba distinguirse.
52
Figura
origen
Clase padre o superclase (base)
mover ( )
cambiarTamao ( )
dibujar
Rectngulo
generalizacin
Polgono
Circulo
punto esquina
lista : puntos
float radio
dibujar
cuadrado
Clase hoja
Clase hija
Ejemplo
Generalizacin y especializacin de clases
A b s t r a c c i o n e s m s g e n e r a le s .
ve h i c u lo
v e h i c u lo t e r r e s t r e
c a m io n
v e h ic u lo a r e o
co che
a vio n
h e li c o p t e r o
53
co che
fu n c i o n a n d o
e s tr o p e a d o
v e h i c u lo
a r e o
a v i o n
h e li c o p t e r o
c o c h e
fu n c io n a n d o
e s tr o p e a d o
54
comercial
vehiculo areo
militar
avion
helicoptero
d e m s d e 1 0 0 0 km s
fu n c i o n an d o
e s tr o p e a d o
conejo
con pelo
Herbvoro
con plumas
omnvoro
Animal
con escamas
carnvoro
Bipedo
Cuadrpedo
55
Animal
x Locomocin
Bpedo
x Alimento
Cuadrpedo
Herbvoro
Carnvoro
Una Asociacin es una relacin estructural que especifica que los objetos de un elemento
estn conectados con los objetos de otro. La asociacin entre dos clases permite navegar
desde un objeto de una clase hasta un objeto de la otra clase y viceversa. Una asociacin
que conecta exactamente 2 clases se dice binaria. Se puede tener asociaciones que
conectan ms de dos clases, se llaman n-arias. Se usan cuando se quiere representar
relaciones estructurales. Hay cuatro adornos que se aplican:
Nombre. Una asociacin puede tener nombre, que se usa para descubrir la naturaleza de la
relacin.
nombre
Trabaja para
Persona
Empresa
asociacin
56
Rol. Cuando una clase participa en una asociacin, tiene un rol especifico que juega en la
asociacin; un rol puede verse como la cara que la clase de un extremo de la asociacin
presenta a la clase del otro extremo. En la figura, una Persona que juega el rol de empleado
esta asociado con una Empresa que juega el rol de patrn.
asociacin
Persona
empleado
patrn
Empresa
rol
Una asociacin puede tener un nombre. Si se incluyen explcitamente los nombres de rol para
la asociacin, no se necesita incluir el nombre de la asociacin, excepto si se tiene un modelo
con muchas asociaciones y se hace necesario distinguir una de otra (en especial si hay ms
de una asociacin entre las mismas clases).
Multiplicidad. En muchas ocasiones es importante indicar cuantos objetos pueden
conectarse a travs de una instancia de la asociacin; a esto se denomina multiplicidad de la
asociacin. Se escribe como una expresin que se evala a un rango de valores o a un valor
explcito. Cuando se indica la multiplicidad se esta especificando que para cada objeto de la
clase en el extremo opuesto debe haber tantos objetos en este extremo. Se pueden indicar
multiplicidades como: exactamente uno ( 1 ), cero o uno ( 0..1 ), cero o muchos (0..*), uno o
mas ( 1..* ), o incluso indicar el nmero exacto.
multiplicidad
1..*
Persona
0..*
empleado
patrn
Empresa
Agregacin
Una asociacin representa una relacin estructural entre iguales, es decir que ambas clases
se encuentran conceptualmente al mismo nivel (no hay una parte mas importante). A veces
se desea modelar una relacin todo/parte, en la cual una clase representa una cosa grande
(el todo), que esta conformado por elementos pequeos (las partes). Este tipo de relacin
se denomina agregacin y se representa una relacin del tipo tiene-un. Se representa
aadiendo a una asociacin normal un rombo vaco en la parte del todo.
Empresa
todo
agregacin
parte
Departamento
57
Composicin
Es un caso particular de agregacin: exclusiva y dependiente. Las partes pueden
crearse despus del agregado compuesta al que pertenecen, pero una vez creadas
viven y mueren con ella. La parte slo puede formar parte de un agregado. El agregado
gestiona la creacin y destruccin de las partes. Las partes se pueden eliminar antes
de eliminar el agregado.
5.3
DIAGRAMAS DE CLASES
58
Trayectoria
1
Conductor
Responsabilidades:
--buscar camino
--evitar obstculos
1
Motor Principal
Motor Direccin
Motor
mover (Direccin d, Velocidad v)
parar ( )
reiniciarContador ( )
statusMotor ( )
int distancia ( )
59
SensorColisin
Debemos identificar aquellas clases del modelo cuyo estado debe trascender el tiempo
de vida de las aplicaciones.
Hay que crear un diagrama de clases que contenga estas clases y marcarlas como
persistentes (un valor etiquetado estndar).
Hay que expandir los detalles estructurales de estas clases. Esto significa especificar
los detalles de estos atributos y definir las asociaciones que se presentan, as como sus
cardinalidades.
Hay que buscar patrones comunes que complican el diseo fsico, como el caso de
asociaciones cclicas, asociaciones uno a uno y asociaciones n-arias. Donde deben
crearse abstracciones intermedias para simplificar la estructura lgica.
Donde sea posible, se debe utilizar herramientas que ayuden a transformar un diseo
lgico en un diseo fsico.
El diseo lgico de base de datos escapa al alcance de este curso. Aqu solo se pretende
mostrar como se puede modelar un esquema usando UML. Veamos el siguiente ejemplo:
60
(persistente)
Universidad
Nombre: nombre M
String: direccin
Long: telfono
Departamento (persistente)
tiene
Nombre: nombreD
1
1..*
adicionarEstudiante ( )
quitarEstudiante ( )
obtenerEstudiante ( )
listarTodosEstudiantes ( )
adicionarDepartamento
quitarDepartamento ( )
obtenerEstudiante ( )
listarTodosDepartamentos ( )
adicinProfesor ( )
retirarProfesor ( )
obtenerProfesor ( )
listarTodosProfesores ( )
0..1
asignado
dirige
0..1
1..*
Estudiante (persistente)
Miembro
*
Nombre: nombreE
String: codEstudiante
Curso
*
*
asiste
(persistente)
Nombre: nombreC
Long: idMateria
Profesor
*
1..*
ensea
1..*
(persistente)
Nombre: nombreP
Asociaciones calificadas
Nivel Conceptual: Dentro del mismo pedido no pueden existir dos lneas con el mismo
producto
Nivel Especificacin: El acceso a lineaPedido es indexado por productos
Nivel Implementacin: Se usa una tabla para almacenar las lneas de pedido
Ejemplo
61
Asociaciones n-arias
Asociacin entre tres o ms clases. Cada instancia de la asociacin es una n-tupla de
valores de cada una de las respectivas clases.
62
Ejercicio prctico
En una entidad educativa cuando se desea determinar la evaluacin de los alumnos, la
secretaria debe considerar:
Se pide desarrollar una aplicacin que permita determinar y mostrar el promedio final y
condicin de los alumnos.
Usted debe considerar los conocimientos aprendidos para disear dicha aplicacin.
63
Imprimir
Ingresa datos de
alumno
Alumno
Ingresa datos de
evaluacin
Secretaria
Calcular promedio
de prctica
<<Include>>
Calcular promedio
final y condicin
Diagrama de secuencia
:secretaria
<<include>>
:alumno
:evaluacion
Ingresadatoa( )
Ingresadatoe( )
Promediofinal
condicion( )
Promedio
practica( )
menornota()
64
Diagrama de colaboracin
Usted debe elaborar este diagrama
Diagrama de objetos
:alumno
:evaluacion
Coda: a01
Nom: Patty Ruiz
code : a01
codc : ad54
p1 : 12
p2 : 13
p3 : 11
p4 : 16
p5 : 15
ep : 17
ef : 10
es : 15
65
Diagrama de clases
Alumno
Private
Coda: char[4]
Nom: char[30]
Public
alumno();
char* codigoa();
char* nombre();
void ingresadatosa(char[], char[]);
void imprimira();
evaluacion
private
coda : char[4]
codc : char[4]
p1, p2, p3, p4, p5 : int
ep, ef, es: int
public:
evaluacion();
char* codigoe();
char* codigoc();
int n1();
int n2();
int n3();
int n4();
int n5();
int exp();
int exf();
int exs();
void ingresadatose(char[],char[],int,int,int, int, int, int, int, int);
void promedioFinalCondicion();
float promedioPractica();
int menorNota();
66
67
Mtodos (public)
evaluacion()
char* codigoe()
char* codigoc()
int n1()
int n2()
int n3()
int n4()
int n5()
int exp()
int exf()
int exs()
void ingresadatose(char[],char[],int,int,int, int, int, int, int, int)
void promedioFinalCondicion()
float promedioPractica()
int menorNota()
68
int n4()
{
Retornar el valor de p4
}
int n5()
{
Retornar el valor de p5
}
int exp()
{
Retornar el valor de ep
}
int exf()
{
Retornar el valor de ef
}
int exs()
{
Retornar el valor de es
}
void evaluacion::ingresadatose(char codi[],char codcu[],int pr1, int pr2, int pr3, int pr4, int
pr5, int epa, int efi, int esu)
{
Asignar a coda el valor de codi
Asignar a codc el valor de codcu
Asignar a p1 el valor de pr1 siempre que sea positivo
Asignar a p2 el valor de pr2 siempre que sea positivo
Asignar a p3 el valor de pr3 siempre que sea positivo
Asignar a p4 el valor de pr4 siempre que sea positivo
Asignar a p5 el valor de pr5 siempre que sea positivo
Asignar a ep el valor de epa siempre que sea positivo
Asignar a ef el valor de efi siempre que sea positivo
Asignar a es el valor de esu siempre que sea positivo
}
void evaluacion::promedioFinalCondicion()
{
Determinar el promedio final del alumno considerando el promedio de prctica, el
examen parcial y examen final
Si el alumno esta desaprobado se debe reemplazar la menor nota entre el examen
parcial y examen final por la notas del examen sustitutorio
Determinar nuevamente el promedio final del alumno considerando este
reemplazo
Mostrar el promedio final del alumno
Mostrar la condicin del alumno
}
69
float promedioPractica()
{
Determinar el promedio de prctica no considerando la menor de las prcticas
retornar este valor hallado
}
int menorNota()
{
Determinar el menor valor de de las cinco practicas
Retornar este menor valor hallado
}
Cuerpo principal
{
Crear el objeto a tipo alumno
Crear el objeto e tipo evaluacion
Solicitar los datos del alumno que son necesarios para el proceso de evaluacin
del alumno
Pasar los datos que le corresponden al objeto alumno
Pasar los datos que le corresponden al objeto evaluacion
Mostrar el codigo y nombre del objeto alumno
Determinar y Mostar el promedio final y condicion del alumno considerando el
objeto evaluacion
}
Ejercicio prctico
En una empresa se ha identificado cuatro tipos de trabajadores y cuando se desea
elaborar la planilla, la secretaria considera lo siguiente:
Se pide desarrollar una aplicacin que permita determinar y mostrar el pago de cada
uno de estos trabajadores.
Usted debe considerar los conocimientos aprendidos para disear dicha aplicacin.
70
71
trabajador
protected
codigo char[30]
nombre char[30]
Tipo4
salario float
Public
trabajador(char cod[], char nomb[] )
char* codigos()
char* nombres()
void imprimir()
Tipo1
Public
tipo1(char cod[], char nomb[], float s)
void salariosemanal(float s);
float pago();
void imprimir();
Tipo2
pagoh float
horast int
Public
tipo4(char cod[], char nomb[], float w, int h);
void pagohora(float w);
void horastrabajadas(int h);
float pago();
void imprimir();
Tipo3
salariob,comisiong float
cantidadp int
Pagoa float
Producciona int
Public
tipo2(char cod[], char nomb[], float s, float c, int q)
void salariobase(float s);
void comision(float c);
void cantidadarticulos(int q);
float pago();
void imprimir();
Public
tipo3(char cod[], char nomb[], float w, int q)
void pagoarticulo(float w);
void produccionarticulo(int q);
float pago();
void imprimir();
72
73
74
void comisin(float c)
{
Asignar a comisiong el valor de c
}
void cantidadarticulos(int q)
{
Asignar a cantidadp el valor de q
}
float pago()
{
Determinar el pago considerando el salario base y la comisin
Retornar el valor del pago
}
void imprimir()
{
Mostrar el titulo Trabajador tipo 2
Mostrar el codigo y nombre del trabajador
}
SubClase: tipo3
Responsabilidad: Manejar el pago del trabajador considerando los artculos
producidos
Atributos
pagoa numero real
producciona numero entero
Mtodos (public)
tipo3(char cod[], char nomb[], float w, int q);
void pagoarticulo(float w);
void produccionarticulo(int q);
float pago();
void imprimir();
Especificacin de los mtodos
tipo3(char cod[], char nomb[], float w, int q):trabajador(cod, nomb)
{
Llamar al metodo pagoarticulo
Llamar al metodo produccionarticulo
}
void pagoarticulo(float w)
{
Asignar a pagoa el valor de w
}
void produccionarticulo(int q)
{
Asignar a producciona el valor de q
}
75
float pago()
{
Determinar el pago considerando los articulos producidos
Retornar el valor del pago
}
void imprimir()
{
Mostrar el titulo Trabajador tipo 3
Mostrar el codigo y nombre del trabajador
}
SubClase: tipo4
Responsabilidad: Manejar el pago del trabajador considerando las horas trabajadas
Atributos
Pagoh numero real
Horast numero entero
Mtodos (public)
tipo4(char cod[], char nomb[], float w, int h);
void pagohora(float w)
void horastrabajadas(int h)
float pago()
void imprimir()
Especificacin de los mtodos
tipo4(char cod[], char nomb[], float w, int h):trabajador(cod, nomb)
{
Llamar al metodo pagohora
Llamar al metodo horastrabajadas
}
void pagohora(float w)
{
Asignar a pagoh el valor de w
}
void horastrabajadas(int h)
{
Asignar a horast el valor de h
}
float pago()
{
Determinar el pago considerando que si las horas son mayores a 40
este exceso se considera como horas extras
Retornar el valor del pago
}
76
void imprimir()
{
Mostrar el titulo Trabajador tipo 4
Mostrar el codigo y nombre del trabajador
}
Cuerpo principal
{
Crear el objeto t1 del tipo tipo1
Solicitar los datos para este objeto
Mostrar el tipo de trabajador, codigo y nombre
Determinar y mostrar el pago que le corresponde considerando el mtodo pago
de este objeto
Crear el objeto t2 del tipo tipo2
Solicitar los datos para este objeto
Mostrar el tipo de trabajador, codigo y nombre
Determinar y mostrar el pago que le corresponde considerando el mtodo pago
de este objeto
Crear el objeto t3 del tipo tipo3
Solicitar los datos para este objeto
Mostrar el tipo de trabajador, codigo y nombre
Determinar y mostrar el pago que le corresponde considerando el mtodo pago
de este objeto
Crear el objeto t4 del tipo tipo4
Solicitar los datos para este objeto
Mostrar el tipo de trabajador, codigo y nombre
Determinar y mostrar el pago que le corresponde considerando el mtodo pago
de este objeto
}
77
EJERCICIOS
En cada uno de los siguientes ejercicios se debe elaborar:
Descripcin del caso de uso
Diagrama de casos de uso
Diagrama de secuencia
Diagrama de colaboracin
Diagrama de objetos
Diagrama de clases
Especificacin de las clases
Construccin de la aplicacin (java con base de datos)
1. Supngase esta situacin: en una empresa se esta haciendo el estudio sobre las
edades promedios de los hijos de los trabajadores. Dicho proceso se realiza de la
siguiente manera: La secretaria debe ingresar los siguientes datos de cada uno de
los trabajadores: cdigo del trabajador, nombre del trabajador y las edades de cada
uno de sus hijos (hombres y mujeres), estas edades deben ser verificadas para ser
aceptados en el proceso. La idea es determinar y mostrar la edad promedio de los
hijos slo hombres y tambin determinar la edad promedio de las hijas mujeres.
Adems se debe determinar la edad promedio de todos los hijos.
2. En una empresa cuando se le paga a un trabajador se considera los siguientes
datos: Cdigo, Nombre, Categora (puede ser: 1, 2, 3), Ao de ingreso, Numero de
hijos, Estado civil (puede ser: s]oltero, c]asado, d]ivorciado, v]iudo) Sueldo bsico.
Seguidamente se desea determinar:
Bonificacin por aos de servicios (2% del sueldo bsico si tiene ms de 10 aos de
servicio)
Bonificacin por hijos (1% del sueldo bsico, si el estado civil es: c, d, v)
Bonificacin por categora (puede ser: 5%, 7%, 9% del sueldo bsico,
respectivamente)
Subtotal (sueldo bsico ms todas las bonificaciones)
Descuento (10% del sueldo bsico, si el trabajador es soltero)
Sueldo Neto (subtotal menos el descuento)
3. En una entidad educativa para matricular un alumno, a partir del segundo ciclo, se
consideran los siguientes datos: cdigo, nombre, nmero de cursos (en los cuales
se va a matricular), precio por cada curso (el precio es el mismo para cada curso) y
el promedio del ciclo anterior.
Se desea determinar y mostrar:
Monto total de los cursos (se sabe que el precio de los cursos se incrementa en un
15% de su valor en los meses de julio y diciembre)
Descuento (el alumno tendr un descuento del 5% sobre el monto total de los cursos
si el promedio es mayor o igual a 16, en caso contrario el descuento ser del 2% del
monto total de los cursos)
Importe a pagar (es lo que finalmente debe cancelar el alumno)
4. En una empresa para calcular el pago de cada uno de los trabajadores, el pagador
debe considerar los siguientes datos del trabajador: nombre, sueldo bsico, nmero
de hijos y fecha de contrato. Se sabe que los beneficios que recibe es un bono del
3% del sueldo bsico si este es menor a 450 soles, 8 soles por cada hijo siempre
que tenga menos de 5 hijos en caso contrario solo recibe 35 soles y recibe por cada
78
ao de servicio el 0.8% del sueldo bsico. Los descuentos son 5% del sueldo bsico
para AFP y 2% del sueldo bsico para ESSALUD.
La empresa tiene la necesidad de imprimir por separado los beneficios y los
descuentos, para finalmente imprimir los datos del trabajador con el pago
correspondiente
5. En una empresa que vende productos medicinales, cuando se le paga a los
trabajadores, se consideran los siguientes datos: cdigo, nombre, sueldo bsico y
categora (A, B y C)
Se desea determinar y mostrar:
Bonificacin por categora (si la categora es A la bonificacin es 3% del sueldo
bsico, si la categora es B la bonificacin es 2% del sueldo bsico y si la categora
es C la bonificacin es 1% del sueldo bsico. Adems se sabe que: a todos los
trabajadores se les da un gratificacin del 50% del sueldo bsico en el mes de julio y
diciembre)
Pago Bruto (todo el ingreso que recibe el trabajador)
Descuento (si el pago bruto es mayor a $980 el descuento es el 0.05% del pago
bruto, en caso contrario es el 0.025% del pago bruto)
Pago neto (es lo que finalmente se le debe pagar al trabajador)
6. En una empresa para calcular el pago de cada uno de los trabajadores, el pagador
debe considerar los siguientes datos del trabajador: nombre, sueldo bsico, nmero
de hijos y aos de servicios. Se sabe que por cada hijo recibe 10 soles y por cada
ao de servicio recibe el 0.3% del sueldo bsico. Adems se le debe hacer los
descuentos que por ley le corresponde: AFP que es el 5% del sueldo bsico y
ESSALUD que es el 7% del sueldo bsico.
Los datos estn almacenados de manera apropiada. Tambin se desea almacenar
los beneficios y descuentos que se estn haciendo.
7. En un industria para determinar el pago de los obreros se considera:
Cdigo del obrero
Nombre del obrero
Pago por hora (con dos cifra decimales)
Nmero de horas trabajadas (nmero entero)
Horas extras trabajadas (nmero entero)
Numero de hijos
Se debe mostrar
Monto de las horas normales
Monto de las hora extras
Bonificacin por hijos
Monto total
Descuento
Pago neto
Considerar:
El pago por hora extra es el 50% del pago por hora normal.
La bonificacin por cada hijo es de 5 nuevos soles
El monto de la horas extras es lo que ha ganado por trabajar las horas
extras
El monto total es la suma del monto de las horas que ha trabajado ms la
bonificacin por hijos
79
80
CAPITULO VI
6.1
DIAGRAMAS DE ESTADO
Todos los sistemas reales tienen una dimensin dinmica, y esta dinmica se activa por las
cosas que ocurren externa o internamente. En UML cada cosa que sucede se modela como
un evento, y permiten, cuando ocurren, pasar en un objeto de un estado a otro, al responder
con una accin.
Los aspectos dinmicos de un sistema se modelan usando mquinas de estados que la
mayora de las veces ser una clase, un caso de uso o un sistema completo.
Las mquinas de estados pueden visualizarse de dos formas: usando los diagramas de
actividades, centrndose en las actividades que ocurren dentro del objeto, y la segunda
usando los diagramas de estados, centrndose en el comportamiento dirigido por eventos de
un objeto (til en modelaje de sistemas reactivos).
Trminos y Conceptos
Una mquina de estados es un comportamiento que especifica las secuencias de estados
por las que pasa un objeto a lo largo de su vida en espera a eventos, junto con sus
respuestas a estos eventos. Un estado es una condicin o situacin en la vida de un objeto
durante la cual satisface a alguna condicin, realiza alguna actividad o espera algn evento.
Un evento es la especificacin de un acontecimiento significativo que ocupa lugar en el
tiempo y en el espacio.
En el contexto de las mquinas de estados, un evento es la aparicin de un estimulo que
puede disparar una transicin de estados. Una transicin es una relacin entre dos estados
que indica que un objeto que este en el primer estado realizar ciertas acciones y entrar en
el segundo estado cuando ocurra un evento especificado y se satisfagan unas condiciones
definidas. Una actividad es un ejecucin no atmica en curso, dentro de una mquina de
estados. Una accin es una computacin atmica ejecutable que produce un cambio de
estado del modelo o devuelve un valor. Grficamente un estado se presenta como un
rectngulo con las esquinas
Un estado es una condicin o situacin en la vida de un objeto durante la cual satisface
alguna condicin, realiza alguna actividad o espera algn evento. Un objeto permanece en un
estado durante una cantidad de tiempo finita. Ejemplo: un Calentador puede estar en
cualquiera de los siguientes cuatro estados:
Inactivo:
En preparacin:
Activo:
Apagando:
Cuando la mquina de estados de un objeto se halla en un estado dado, se dice que el objeto
est en ese estado. Ejemplo: el Calentador puede estar Activo o Apagando. Un estado tiene
varias partes:
81
1 Nombre:
3 Transiciones Internas:
4 Susbestados:
Eventos diferidos:
Un estado se representa con un rectngulo con las esquinas redondeadas. El estado inicial,
que indica el punto de comienzo por defecto para las mquinas de estado o subestado, se
representa con un crculo negro. El estado final, indica que la ejecucin de la mquina de
estados o del estado que lo contiene ha finalizado, se representa por un crculo negro dentro
de una circunferencia.
Una transicin es una relacin entre estados que indica que un objeto que esta en el primer
estado, realizar ciertas acciones y entrar en el segundo estado cuando ocurra el evento
especificado y se satisfagan las condiciones especificadas. Cuando esto ocurre se dice que la
transicin se ha disparado. Hasta que se dispara la transicin, se dice que el objeto esta en el
estado origen, despus de dispararse, se dice que esta en el estado destino.
Por ejemplo: un Calentador puede pasar del estado inactivo al estado Enpreparacin cuando
ocurra un evento como aguaFria (con el parmetro tempEsperada). Una transicin tiene 5
partes.
4 Accin:
5 Estado destino :
82
Un estado representa con una lnea continua dirigida desde el estado origen hacia el destino.
Una autotransicin es una transicin cuyos estados origen y destino son el mismo.
Es posible tenor un transicin sin disparador, representada por una transicin sin evento de
disparo. Una transicin sin disparador se dispara implcitamente cuando su estado origen ha
completado su actividad.
Los diagrama. de estados son autmatas jerrquicos que permiten expresar
concurrencia, sincronizacin y jerarquas de objetos. Los diagramas de estados son
grafos dirigidos. Los diagramas de estados de UML son deterministas, los estados
inicial y final estn diferenciados del resto, la transicin entre estados es instantnea y
se debe a la ocurrencia de un evento
contratar
en el paro
en activo
perder empleo
jubilarse
jubil arse
jubilado
1 : u n a p r e g u n ta
un
o b je t o
o t ro
o b j e to
2 : la re s p u e s ta
83
p l a n t e a r p re g u n ta
e s p e ra re s p u e s t a
re c ib ir re s p u e s t a
Evento[ condicin ]
Se puede especificar el hacer una accin como consecuencia de entrar, salir o estar en
un estado:
e s ta d o A
e n tr y : a c c i n p o r e n tr a r
e x i t: a c c i n p o r s a l i r
d o : a c c i n m i e n tr a s e n e s ta d o
Se puede especificar el hacer una accin cuando ocurre en dicho estado un evento que
no conlleva salir del estado:
e s ta d o A
o n e ve n to _ a c ti va d o r ( a r g 1 ) [ c o n d i c i n ]: a c c i n p o r e ve n to
84
e1
e2
e2
c
Quedara como:
e1
e2
b
e 2
e 0
Es preferible tener estados iniciales de entrada a un nivel de manera que desde los
niveles superiores no se sepa a qu subestado se entra:
85
e1
a
b
c
e2
e0
e1
e1
Historial
Por defecto, los autmatas no tienen memoria. Es posible memorizar el ltimo
subestado visitado para recuperarlo en una transicin entrante en el superestado que lo
engloba.
E n ju a g u e
L a va d o
S e c a d o
A b r i r P u e r ta
C e rra r P u e rta
E s p e ra
86
Las esperas son actividades que tienen asociada cierta duracin. La actividad de
espera se interrumpe cuando el evento esperado tiene lugar. Este evento desencadena
una transicin que permite salir del estado que alberga la actividad de espera. El flujo
de control se transmite entonces a otro estado
/ Abrir ranura
esperar dinero
entry: Mostrar mensaje
do: Esperar 30 segundos
exit: cerrar ranura
anular transaccin
Depsito efectuado
b
Ejemplo ASCENSOR
S U B IE N D O
o n C a m b io d e p is o / In d ic a d o r= P is o a c t u a l
L le g a d a p is o d e s t in o /
I nd ic ad or= P is o a ct u al
S e le c c io n a r[ p is o d e s t in o > p is o a c t u a l ]
E S T AT IC O
e n tr y/ A b ri r p u e r ta
e x it/ C e rr a r p u e r ta
S e le c c io n a r[ p is o d e s t in o < p is o a c t u a l ]
L le g a d a a p is o d e s t in o /
I nd ic ad or= P is o a ct u al
B AJAN D O
o n C a m b io d e p is o / In d ic a d o r= P is o a c t u a l
87
Descolgar
INICIO
Pulsar digito(n)
MARCANDO
[ number.isValid() ]
entry/ Number.append(n)
88
DISPONIBLE
S erv icio de
limpiez a
Ha c er
res erva
DESOCUPA DA
PA RA LIMPIA R
89
Ejemplo EMBOTELLADO
ROTA
EMBOTELLANDO
DeteccionRotura[
Vactual=0 ]
VACIA
GOTEANDO
[ Vactual=0 ]
do/ Vaciar
LLENANDO
on Comprobar[ Vactual<Vdeseado ]/ Aadir liquido
entry/ Vactual=0
[ Vactual=Vdeseado ]
DeteccionRotura
[ Vactual !=0 ]
PonerTapon
LLENA
SELLADA
90
Ejemplo CLIMATIZADOR
SELECCIONANDO T
do/ Display T seleccionada
Seleccionar T
Salir
INACTIVO
Apagar
Encender
Tambiente>T seleccionada
Tambiente=T seleccionada
Tambiente<T seleccionada
Tambiente=T seleccionada
CALENTANDO
on Paso 30 seg/ Medir T ambiente
entry/ Encender resistencias
exit/ Apagar resistencias
Tambiente>T seleccionada
Tambiente<T seleccionada
ENFRIANDO
on Cada 30 seg/ Medir T ambiente
entry/ Encender compresor
exit/ Apagar compresor
91
Subestados secuenciales.
Veamos los subestados secuenciales con un ejemplo: el modelar el comportamiento de
un cajero automtico. Hay 3 estados en los que puede estar el sistema Inactivo (en
espera de un cliente), Activo (procesando una transaccin de un cliente) y Mantenimiento
(recargando dinero).
Inactivo
Estado
compuesto
Activo
tarjetaIntroducida
Validacin
Cancelar
Seleccin
Subestado
secuencial
[Continuar]
Mantenimiento
Procesamiento
[no continuar]
Transicin desde subestado
Entry/leertarjeta
Exit/explusartarjeta
Impresin
Subestados concurrentes.
Los subestados secuenciales son los que aparecen con mayor frecuencia en el modelaje; sin
embargo en algunas situaciones debe trabajarse con subestados concurrentes, los cuales
permiten especificar dos o mas maquinas de estados que se ejecutan en paralelo en el
contexto que los contiene. Veamos el ejemplo de la figura.
Dados dos o ms subestados secuenciales al mismo nivel, un objeto estar en uno y solo uno
de los subestados. Dados dos o ms subestados concurrentes al mismo nivel, un objeto
estar en un estado secuencial de cada uno de los subestados concurrentes.
92
Inactivo
divisin
unin
Estado compuesto
mantener
Mantenimiento
Pruebas
subestados
concurrentes
Probar
perifricos
Auto
diagnostico
Orden
Espera
6.2
DIAGRAMA DE ACTIVIDAD
Los diagramas de actividades son uno de los cinco tipos de diagrama UML usados para
modelar los aspectos dinmicos de los sistemas. Un diagrama de actividades es
bsicamente un diagrama de flujo que muestra el flujo de control entre actividades.
Los diagramas de actividades se utilizan para modelar los pasos secuenciales y posiblemente
concurrentes de un proceso computacional. Tambin permite modelar el flujo de un objeto
conforme pasa de estado a estado en diferentes puntos del flujo de control. Los diagramas
de interaccin destacan el flujo de control entre objetos, los diagramas de actividades
destacan el flujo de control entre actividades.
Una actividad es una ejecucin no atmica en curso, dentro de una mquina de estados. Las
actividades producen alguna accin, compuesta de computaciones atmicas ejecutables que
producen un cambio en el estado del sistema o el retorno de un valor.
Los diagramas de actividades son similares a los diagramas Pert. Un diagrama de actividades
destaca la actividad que ocurre a lo largo del tiempo, mostrando las operaciones que se
pasan entre los objetos.
Trminos y conceptos
Un diagrama de actividades muestra el flujo de actividades. Una actividad es una ejecucin
no atmica en curso, dentro de una maquina de estados. Las actividades finalmente producen
93
una accin, que esta compuesta de computaciones atmicas ejecutables que producen un
cambio en el estado del sistema, o la devolucin de un valor. Las acciones incluyen llamadas
a otras operaciones, envo de seales, creacin o destruccin de objetos o simples clculos
(evaluar una expresin). Grficamente un diagrama de actividades es una coleccin de
nodos y arcos.
Normalmente un diagrama de actividades contiene:
Estado de actividad y estados de accin.
Transiciones
Objetos
Al igual que los dems diagramas, el diagrama de actividades pueden contener restricciones.
Estados de accin y estados de actividad
Un flujo de control modelado por un diagrama de actividades contiene diferentes sucesos,
como evaluacin de expresiones que asignen un valor a un atributo o devuelva un valor.
Tambin se puede invocar una operacin sobre un objeto, enviar una seal a un objeto o
crear o destruir objetos. Este tipo de computaciones ejecutables y atmicas se llaman
Estados de accin, porque son estados del sistema y cada una representa la ejecucin de
una accin. El estado de accin se representa por un ovalo donde se escribe cualquier
expresin.
accin simple
expresin
Preparar oferta
94
Preparar construccin ( )
Entry/poner Bloqueo ( )
accin de entrada
Los estados de actividad son importantes por ayudar a dividir clculos complejos en partes
ms simples, de la misma forma en que se utilizan las operaciones para agrupar y reutilizar
expresiones.
Transiciones
Cuando se completa la accin o la actividad de un estado, el flujo de control pasa
inmediatamente al siguiente estado de accin o estado de actividad. Este flujo se especifica
con transiciones que muestran el camino de un estado de actividad o estado de accin al
siguiente. En UML la transicin se representa como una lnea dirigida.
estado inicial
Elegir Sitio
estado de accin
Transicin
Contratar arquitecto
estado parada
Un flujo de control tiene que empezar y parar en algn sitio, por ello se puede especificar un
estado inicial (circulo relleno) y un estado final (circulo relleno dentro de un circunferencia).
Bifurcacin
Las transacciones secuenciales no son el nico tipo de camino en un flujo de control, tambin
se puede incluir una bifurcacin, que especifica caminos alternos, elegidos segn el valor de
alguna expresin booleana.
95
Parte de trabajo
expresin de guarda
[materiales no disponibles]
bifurcacin
Repetir planeacin
[materiales disponibles]
Asignar tareas
expresin de guarda
Se puede lograr el efecto de iteracin usando un estado de accin que establezca el valor de
la variable de control de una iteracin: otro estado de accin que incrementa el valor de la
variable y una bifurcacin si se ha terminado la iteracin.
Divisin y unin
Es posible encontrar flujos concurrentes, especialmente cuando se modelan flujos de trabajo
de procesos de negocio. En UML una divisin y la unin emplean una barra de
sincronizacin para especificarlas, la cual se representa como una lnea horizontal o vertical
ancha.
Ejemplo:
Preparar conversacin
divisin
Descomprimir
Gesticular ( )
Mover boca ( )
Emitir audio ( )
unin
Limpieza
96
El ejemplo considera los flujos implicados en el control de un dispositivo electrnico que emite
voz y gestos humanos. En la figura se presenta una divisin, que representa la separacin de
un flujo de control sencillo en dos o ms flujos concurrentes. Una divisin tiene una transicin
de entrada y dos o mas transiciones de salida, cada una representa un flujo de control
independiente. Despus de la divisin, las actividades de cada camino continan en paralelo.
En la figura, una unin representa la sincronizacin de dos o ms flujos de control
concurrentes. Una unin puede tener dos o ms transiciones de entrada y una de salida. En
la unin los flujos concurrentes se sincronizan, es decir, cada uno espera hasta que todos los
flujos de entrada han alcanzado a la unin y a partir de ese punto continua un nico flujo de
control que sale de la unin.
Las uniones y divisiones deben equilibrarse, es decir, el nmero de flujos que parten de una
divisin debe coincidir con el nmero de flujos que entran en la unin correspondiente.
[no zumo]
[hay zumo]
[hay caf
Coger taza
Coger zumo
Encender mquina
^cafetera.On
Caf en preparacin
indicador de fin
Servir caf
97
Beber
Carriles (swimlanes)
Cuando se modelan flujos de trabajo de procesos de organizaciones es til dividir los estados
de la actividad en grupos, donde cada uno representa la parte de la organizacin responsable
de esas actividades. En UML cada grupo se denomina carril porque, visualmente cada grupo
se separa de sus vecinos por una lnea vertical continua. Un carril especifica un lugar para las
actividades.
Pasajero
Vendedor
Airline
Solicitar pasaje
Verificar
existencia vuelo
Dar detalles vuelo
Informar alternativas
y precios
Seleccionar vuelo
Reservar plazas
Solicitar pago
Confirmar
plaza reservada
Pagar pasaje
Emitir billete
98
Cliente
Ventas
Almacn
Solicitar producto
carril
Procesar pedido
Extraer artculos
Enviar pedido
Recibir pedido
Facturar al cliente
Pagar factura
Cerrar pedido
Cada carril tiene un nombre nico en el diagrama. Un carril puede representar alguna entidad
del mundo real, que puede ser implementada por una o varias clases. En un diagrama de
actividades organizado por carriles, cada actividad pertenece a un nico carril, pero las
transiciones pueden cruzar los carriles.
Modelado de un flujo de trabajo
Al modelar un flujo de trabajo se hace hincapi en las actividades, tal como son observadas
por los actores que colaboran con el sistema. En el entorno de los sistemas con gran
cantidades software, existen flujos de trabajo y se usan para visualizar, especificar, construir y
documentar procesos de negocio que implican al sistema que s esta desarrollando. Es
posible hallar sistemas automticos que trabajan en el contexto de procesos de negocios de
ms alto nivel. Estos procesos de negocio son tipos de flujo de trabajo porque representan el
flujo de trabajo y objetos a travs del negocio. Por ejemplo, en un negocio de venta habr
algunos sistemas automticos y sistemas conformados por personas. Los diagramas de
99
actividades pueden utilizarse para modelar procesos en los que colaboran estos sistemas
automticos y humanos.
Para modelar un flujo de trabajo:
Hay que establecer un centro de inters apara el flujo de trabajo. En sistemas no triviales
no es posible mostrar todos los flujos de trabajo interesantes en un diagrama.
Se deben seleccionar los objetos del negocio que tienen las responsabilidades de ms alto
nivel en cada parte del flujo de trabajo global. En cualquier caso debe crearse un carril para
cada objeto importante.
Hay que identificar las precondiciones del estado inicial del flujo de trabajo las
poscondiciones del estado final; esto ayuda a modelar los lmites del flujo de trabajo.
Comenzando por el estado inicial del flujo de trabajo, hay que especificar las actividades y
acciones que ocurren a lo largo del tiempo, representndolos como estados de actividad
o estados de accin.
Hay que llevar las acciones complicadas o los conjuntos de acciones que aparezcan
muchas veces a estados de actividad, y ubicarlas en un diagrama de actividades
separado, expandindolas.
Cliente
Televentas
Contabilidad
Almacn
Solicitar devolucin
Obtener numero de
devolucin
Enviar articulo
Recibir articulo
Articulo : i
[devuelto]
Recolectar articulo
Actualizar cuenta
Articulo : i
[disponible]
Hay que representar las transiciones que conectan los estados de accin y de actividad.
Debe comenzarse con los flujos secuenciales del flujo de trabajo, luego considerar las
bifurcaciones y por ltimo tener en cuenta divisiones y uniones.
Si el flujo involucra objetos importantes, hay que representarlas en el diagrama de
actividades, mostrando sus valores y estado cuando cambien, mostrando el propsito del
flujo de objetos.
100
101
102
CAPITULO VII
7.1
DIAGRAMA DE COMPONENTES
Los diagramas de componentes describen los elementos fsicos del sistema y sus
relaciones.
Muestran las opciones de realizacin incluyendo cdigo fuente, binario y ejecutable.
Los componentes representan todos los tipos de elementos software que entran en la
fabricacin de aplicaciones informticas. Pueden ser simples archivos, paquetes de
Ada, bibliotecas cargadas dinmicamente, etc.
Cada clase del modelo lgico se realiza en dos componentes: la especificacin y el
cuerpo.
En C++ una especificacin corresponde a un archivo con un sufijo .h y un cuerpo a un
archivo con un sufijo .cpp.
En Ada la nocin de mdulo existe directamente en el lenguaje con el nombre del
paquete.
Las relaciones de dependencia se utilizan en los diagramas de componentes para
indicar que un componente utiliza los servicios ofrecidos por otro componente
Ejemplo
Control y Anlisis
Interfaz de Terminal
Comm
Comm
Gestin de Cuentas
Comm
Rutinas de Coneccion
Comm
Acceso a BD
Comm
usuario
103
7.2
DIAGRAMA DE DISTRIBUCIN
Los Diagramas de Distribucin muestran la disposicin fsica de los distintos nodos que
componen un sistema y el reparto de los componentes sobre dichos nodos
Nodo
c o n e x i n 7
< < R D S I> >
d is p o s it iv
o
104
Ejemplo
Servidor Central
Control y Anlisis
C
Acceso a BD
C
Rutinas de Coneccion
C
Terminal de Consulta
Rutinas de Coneccion
C
Punto de Venta
Rutinas de Coneccion
C
Gestin de Cuentas
C
Interfaz de Terminal
C
105
Interfaz de Terminal
C
Resumen
Captura de Requisitos
Anlisis y Diseo
Implementacin
Diagramas de
Estados
Diagramas de
Secuencia
Diagramas de
Casos de Uso
Diagramas de
Distribucin
Diagramas
De Clases
Diagramas de
Colaboracin
Diagramas de
Actividad
Diagramas de
Componentes
Diagramas de
Actividad
"You can model 80 percent of most problems by using about 20 percent of the UML."-- Grady
Booch
106
107
108
"Manejo Libros"
[ Caso Uso ] Reporte Libros
[ Actores ] Bibliotecario
[ Flujo Principal ] Reportes sobre la totalidad de los libros que posee la biblioteca
discriminados por materia, gnero, editorial o algn otro conjunto de parmetros propio
de los libros y definidos por el Bibliotecario. Se ejecuta mnimo una vez al mes.
[ Flujo Excepcional ] El sistema no est en capacidad de iniciar la elaboracin de este
reporte al momento de ser solicitado. Lo pospone para cuando sea posible.
[ Flujo Excepcional ] El bibliotecario no cuenta con el nivel de seguridad necesario para
solicitar este tipo de reporte. Se le informa al bibliotecario de dicha situacin.
109
110
111
112
113
Diagrama de Clases
o
Editorial
114
Autor
Libro
115
Prstamo
Usuario
116
Multas
117
Diagrama de Objeto
o
Editorial
Autor
Libro
118
Prstamo
Usuario
Multas
119
120
121
7.4
122
123
Los servicios de datos (data services) son los servicios de bajo nivel que apoyan los
servicios de negocio y son de una amplia gama de categoras como las siguientes:
El diseo fsico traduce el diseo lgico en una solucin implementable y costoefectiva o econmica.
El componente es la unidad de construccin elemental del diseo fsico. Las
caractersticas de un componente son:
124
En el diseo fsico se debe cuidar el nivel de granularidad (un componente puede ser
tan grande o tan pequeo segn su funcionalidad, es decir, del tamao tal que pueda
proveer de una funcionalidad compleja pero de control genrico) y la agregacin y
contencin (un componente puede reusar utilizando tcnicas de agregacin y
contencin, sin duplicar cdigo).
El diseo fsico debe involucrar:
125
126
Un extracto de datos es una copia de toda o una porcin de la base de datos maestra.
No se permite la actualizacin. Se usa un timestamp o etiqueta de tiempo para indicar
qu tan viejos son los datos.
Una rplica de datos es un fragmento de la bases de datos maestra que se puede
actualizar. Una rplica de datos es cuando el sitio de actualizacin cambia a un sitio
local. No se permiten actualizaciones en la base de datos rplica y en la base de datos
maestra a la vez, por lo que debe de haber sincronizacin entre ambas.
El diseo fsico est ntimamente ligado a una alternativa tecnolgica. Ante la acelerada
evolucin tecnolgica es importante considerar los estndares del momento y las
tendencias ya que una mala decisin implicar un costo enorme (en dinero y en tiempo)
al actualizarse a otra plataforma distinta.
La tendencia actual en la arquitectura cliente/servidor es crear el back-end como un
servidor robusto multitareas y multithreading y el front-end como un cliente muy delgado
que no acapare al servidor comunicndose entre s en una plataforma internet con
protocolos estndar en redes heterogneas.
127
128
BIBLIOGRAFA
JAMES MARTIN & JAMES ODELL. (1997) Mtodos Orientados a Objetos: Conceptos
Fundamentales. Prentice hall
129