Ads Manual

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS
UNIVERSIDAD TECNOLGICA DEL PER

Vicerrectorado de Investigacin
ANLISIS Y DISEO DE
SISTEMAS INFORMTICOS
TINS Bsicos
INGENIERA DE SISTEMAS
TEXTOS DE INSTRUCCIN BSICOS (TINS) / UTP
Lima - Per
ANLISIS Y DISEO DE SISTEMAS

INFORMTICOS
Desarrollo y Edicin
Elaboracin del TINS
Profesor Hernn Robalino Gmez
Diseo y Diagramacin
Julia Saldaa Balandra
Soporte acadmico
Instituto de Investigacin
Produccin
Imprenta Grupo IDAT
Queda prohibida cualquier forma de reproduccin, venta, comunicacin pblica y

transformacin de esta obra.
El presente material contiene una compilacin de obras de Anlisis y

Diseo de Sistemas Informticos publicadas lcitamente, resmenes de los
temas a cargo del profesor; constituye un material auxiliar de enseanza
para ser empleado en el desarrollo de las clases en nuestra institucin.
ste material es de uso exclusivo de los alumnos y docentes de la
Universidad Tecnolgica del Per, preparado para fines didcticos en
aplicacin del Artculo 41 inc. C y el Art. 43 inc. A., del Decreto
Legislativo 822, Ley sobre Derechos de Autor.
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.
En el capitulo VII de describen los elementos fsicos del sistema y sus

relaciones. Adems, la disposicin fsica de los distintos nodos que componen un
sistema.
Finalmente, al cierre de estas lneas, el agradecimiento Institucional, por la
labor cumplida al profesor Ing. Hernn Robalino Gmez; as mismo el reconocimiento a
quienes han hecho posible la presente edicin.
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
Modelado del Negocio

Modelado de Requisitos
Modelado del Anlisis
Modelado del Diseo
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
Introduccin a los Sistemas de Informacin:

Enfoque Sistmico, Enfoque Orientado a Objeto
Conceptos Bsicos de la Tecnologa de Objetos
Anlisis y Diseo de Sistemas Orientado a Objetos
(Modelando en UML)
Casos de Uso
Diagramas de Casos de Uso. Organizando los
Elementos de Paquetes
Casos de Uso
Diagramas de Casos de Uso. Organizando los
Elementos de Paquetes (Continuacin)
Diagrama de Interaccin:
Diagrama de Secuencia
Diagrama de Colaboracin
Diagrama de Interaccin:
Diagrama de Colaboracin (Continuacin)
Diagrama de Objetos
Comparacin del Anlisis Orientado a Objetos y el
Diseo Orientado a Objetos
Diagramas de Clases
EXAMEN PARCIAL
Diagrama de Clases (Continuacin)
Especificacin de la Lgica General
Diagramas de Comportamiento:
Diagrama de Estado
Diagrama de Actividad
Diagramas de Comportamiento:
Diagrama de Estado
Diagrama de Actividad (Continuacin)
Diagrama de implementacin:
Diagrama de Componentes
Diagrama de distribucin
Arquitectura Clsica de Tres Capas
Diagrama de despliegue
Revisin, Nivelacin
EXAMEN FINAL
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
Equipo.- es decir los ordenadores y todos los dispositivos necesarios.

Tipos de Sistemas de Informacin
Es importante distinguir los diferentes tipos de sistemas de informacin, de acuerdo con
la tecnologa aplicada. Estos tipos de sistemas de informacin se diferencian uno de
otro por el uso de diversos elementos:
1. Dispositivos de entrada/salida.
2. Medios de almacenamiento.
3. Sistemas operativos.
4. Etctera.
S. I. de Proceso de Datos en Lotes (Batch)

Captura de datos.- Por lo general los datos se capturan de documentos fuentes como:
notas de ventas, remisiones y nominas de salarios. La informacin se puede registrar
directamente en lugar donde se efectan las transacciones.
Proceso de datos.- Este tipo de procesamiento es adecuado para ciertos procesos,
por ejemplo: los datos de los sueldos de los empleados y los movimientos de cargo y
crdito de los clientes son acumulados en lotes de transacciones y procesados en
intervalos programados.
Salida.- La salida de este procesamiento puede ser:
Interna: Es la informacin para uso interno de la organizacin. Ejemplo:

archivos actualizados, informes, etctera.
Externa: Es la informacin que se utilizar fuera de la organizacin.
Ejemplo: avisos enviados a los clientes, cheques de empleados y
proveedores, etctera.
S.I. de Proceso de Datos en Lnea (On Line)

Captura de datos.- los datos entran a travs del teclado (dispositivo de captura de
datos en lnea) o de algn otro dispositivo en lnea, en el momento en que ocurre la
transaccin.
Proceso de datos.- Este proceso permite localizar y actualizar directamente cualquier
registro sin necesidad de leer el que le precede. Cuando una computadora esta
procesando un acceso directo, normalmente acepta la introduccin de datos desde un
teclado conectado, un dispositivo de Coleccin de datos o un archivo de transacciones.
Adems de la velocidad de actualizacin de los registros directos sin tener que
clasificar el archivo, el proceso de acceso directo puede proveer informacin
instantnea en respuesta a solicitudes de informacin formuladas desde las estaciones
de lnea.
Salida.- Las personas utilizan terminales para introducir datos en el sistema y para
solicitar y recibir informacin del sistema. Cuando se utiliza terminales de punto de
venta, o terminales de operaciones financieras, la computadora suele responder con
una salida impresa producida por la terminal. Esta salida puede tener la finalidad
exclusiva de ser utilizada por los miembros de una organizacin. Los terminales de
despliegue visuales son los dispositivos ms comunes empleados para recibir salida
durante el procesamiento de acceso directo. Tambin pueden utilizarse las terminales
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:
Terminales porttiles de captura de datos.

Terminales de punto de venta.
Terminales para operaciones financieras.
Terminales de despliegue visual.
S.I. de Procesos Distribuidos (Distributed Processing)

Las tecnologas de hardware, de software, de base de datos y de redes contribuyen
todas ellas a la arquitectura de computadoras distribuidas y cooperativas. En su forma
ms general, un sistema raz, que tpicamente ser una gran computadora, acta como
un depsito de los datos corporativos. El sistema raz est conectado con servidores
(que tpicamente son estaciones de trabajo potentes, o PC) y que poseen un doble
papel. Los servidores actan para actualizar y solicitar los datos corporativos
mantenidos por el sistema raz. Adems mantienen sistemas departamentales locales y
desempean un papel clave al poner en red los PC de nivel de usuario a travs de una
red de rea local (LAN).
S.I. de Proceso en Tiempo Real (Real Time)
Un sistema en Tiempo Real esta en una relacin paralela de tiempo con una actividad
en marcha y produce informacin con la rapidez necesaria para ser utilizada en el
control de esa actividad. Por tanto, las palabras Tiempo Real describen un sistema de
acceso directo o de procesamiento en lnea con limitaciones severas de tiempo. En
este tipo de proceso muchas estaciones estn conectadas directamente por medio de
lneas de telecomunicaciones de alta velocidad a una o ms CPU. Los archivos se
actualizan cada minuto y las consultas se contestan por medio de accesos que tardan
fracciones de segundo a los registros actualizados al instante. Sin embargo, es posible
tener sistemas de acceso directo a los registros para propsitos de consulta, sin hacer
uso de un sistema de tiempo real.
Categoras de los SI
Puede decirse, en lneas generales, que esta evolucin ha tenido lugar en tres grandes
etapas
Sistema de Procesamiento de Transacciones.- tienen como objetivo automatizar
procesos basados en la informacin (ej. facturacin) buscando simplemente mejorar el
rendimiento operativo mediante la sustitucin del trabajo de los hombres por las
mquinas
13
Sistema de Informacin para la Direccin.- permiten a los directivos aprovechar la

gran cantidad de datos acumulados, por los sistemas antes mencionados, para
incrementar la efectividad de sus actividades de gestin y satisfacer sus necesidades
de informacin
Sistema de Informacin Estratgicos.- En la dcada de los ochenta la forma de
actuar de algunas organizaciones innovadoras ponen de manifiesto la posibilidad de
utilizar los sistemas de informacin para mejorar directamente la posicin competitiva
de una empresa alterando la naturaleza, el comportamiento o la orientacin de los
negocios.
Se debe aclarar que estos tres sistemas se superponen; es decir: los tres se
complementan.
1.3 CONCEPTOS BSICOS DE LA TECNOLOGA DE OBJETOS

Clase: Es una descripcin para producir objetos de esa clase o tipo. Una clase esta
formada por los mtodos y los atributos, que definen las caractersticas comunes a
todos los objetos de esa clase. Una clase se puede considerar como una plantilla para
crear objetos de esa clase o tipo.
Objetos: Es una encapsulacin genrica de datos y de los procedimientos para
manipularlos. Dicho de otra forma un objeto es una entidad que tiene unos atributos
particulares (los datos) y una forma de operar sobre ellos (los mtodos y los
procedimientos).
Jzquel 1996.- Un objeto describe una abstraccin caracterizada por una entidad del
mundo real Existe en el tiempo
Puede estar en diferentes estados (cambiantes)

Puede ser creada y destruida
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
Mensajes: Cuando se utiliza el AOO, los objetos estn recibiendo, interpretando y

respondiendo a mensajes de otros objetos. El conjunto de mensajes a los que un objeto
puede responder se le llama protocolo.
Mtodos: Un mtodo determina cmo tiene que actuar el objeto cuando recibe un
mensaje. Un mtodo tambin puede enviar mensajes a otros objetos solicitando una
accin o informacin. La descripcin de un mtodo se denomina operacin.
Herencia: Es el mecanismo para compartir automticamente mtodos y datos entre
clases y subclases.
Encapsulamiento: Se refiere a la prctica de incluir dentro de un objeto todo lo que
necesita, de tal forma que ningn otro objeto necesite conocer nunca su estructura
interna.
Polimorfismo: Es una caracterstica que permite implementar mltiples formas de un
mismo mtodo, dependiendo de cada una de ellas de la case sobre la que se realice la
implementacin.
Anlisis orientado a objetos(OOA)
Estudio de un problema previamente a tomar cualquier decisin sobre l
Incluye o presupone un Anlisis del dominio
Necesita una especificacin de requisitos
Funcionales
No funcionales
El OOA se lleva a cabo desde la perspectiva de las clases y objetos que forman
parte del vocabulario del dominio
Especificacin del comportamiento observable externamente
Establecimiento explcito de lo que se necesita
consistente, completo, factible
Cobertura funcional
Cuantificacin de las caractersticas operacionales
Diseo orientado a objetos (OOD)

La fase de diseo comienza al acabar la de anlisis
Se extiende el modelado de clases a
interfaz, utilidades, clases bsicas, gestin de la persistencia
De forma gradual el nfasis pasa del dominio de la aplicacin al dominio de la
computacin
Estrategia de implementacin
Representacin de los datos
Algoritmos
Deteccin de clases de la implementacin
15
Programacin Orientada a Objetos (OOP)

mtodo de implementacin en el cual los programas se organizan como colecciones
colaborativas de objetos, cada uno de los cuales representa un ejemplar de una
clases, y cada una de las clases forma parte de una jerarqua de clases ligadas por
relaciones de herencia
Ensamblado de componentes ms que programacin
Componentes de software ms que programas
1.4
EL LENGUAJE UNIFICADO DE MODELADO, UML
A mediados de los noventa existan muchos mtodos de anlisis y diseo OO.
Mismos conceptos con distinta notacin.

Mucha confusin.
Guerra de los mtodos
En 1994, Booch, Rumbaugh (OMT) y Jacobson (Objectory/OOSE) deciden unificar sus

mtodos: Unified Modeling Language (UML)
Proceso de estandarizacin promovido por el OMG
El consorcio OMG
Rational Software
Hewlett-Packard
IntelliCorp
Platinum Technology
Reich Technologies
Oracle
Sterling Software
ICON Computing
Petch
Microsoft
IBM
MCI Systemhouse
i-Logix
Taskon A/S
....
DEC
Unisys
ObjectTime
Softeam
Las races tcnicas de UML

OMT - Object Modeling Technique (Rumbaugh et al.)
Especialmente bueno para anlisis de datos de SI.
Entre otros, usa extensiones de los diagramas ER.
Mtodo-Booch (G. Booch)
Especialmente til para sistemas concurrentes y de tiempo real.
Fuerte relacin con lenguajes de programacin, como Ada.
OOSE - Object-Oriented Software Engineering (I. Jacobson)
Desarrollo guiado por los use cases.
Buen soporte de Ingeniera de Requisitos e Ingeniera de Informacin
Modelado y simulacin de sistemas de telecomunicaciones
UML unifica estos conceptos e introduce otros nuevos
Los rivales de UML
Otras propuestas enviadas a OMG
Catalysis (D. DSouza, A. Willis)
Syntropy (S. Cook et al., IBM)
OML/Open (B. Henderson-Sellers)
Fusion (D. Coleman, HP)
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
Un nico modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a

travs de un pequeo conjunto de modelos casi independientes, que muestran
distintos aspectos.
Por qu las empresas no hacen modelado?
La mayor parte de las empresas software no realizan ningn modelado.
El modelado requiere:
aplicar un proceso de desarrollo
formacin del equipo en la tcnicas
tiempo
Algunos problemas en el desarrollo de software
Retrasos en los plazos
Proyectos cancelados
Rpido deterioro del sistema instalado
Tasa de defectos o fallos
Requisitos mal comprendidos
Cambios frecuentes en el dominio del problema
Muchas de las interesantes caractersticas del software no proporcionan beneficios
al cliente
Utilidad del modelado
Se facilita la comunicacin entre el equipo al existir un lenguaje comn.
Se dispone de documentacin que trasciende al proyecto.
Hay estructuras que trascienden lo representable en un lenguaje de programacin.
Utilidad de UML
Permite especificar todas las decisiones de anlisis, diseo e implementacin,
construyndose modelos precisos, no ambiguos y completos.
UML puede conectarse a lenguajes de programacin:
Ingeniera directa e inversa
Permite documentar todos los artefactos de un proceso de desarrollo (requisitos,
arquitectura, pruebas, versiones,..)
Diagramas de UML (http://www.agilemodeling.com/essays/umlDiagrams.htm)

Diagramas de Casos de Uso
Diagramas de Clases
Diagramas de Objetos
Diagramas de Interaccin
Diagrama de Colaboracin (UML 2.0)
Diagramas de Estados
Diagramas de Actividades
Diagramas de Componentes
Diagramas de Despliegue
Composite Structure Diagram (UML 2.0)
Package Diagram (UML 2.0)
Interaction Overview Diagram (UML 2.0)
Timing Diagram (UML 2.0)
18
Reglas de uso de UML

Especifican cmo construir modelos bien formados (auto consistentes y en armona
con otros modelos relacionados)
Proporcionan reglas semnticas para:
Nombres (a qu se puede llamar elementos, relaciones y diagramas)
Alcance (contexto que da significado especfico a un nombre)
Visibilidad (cmo los nombres pueden ser vistos y usados por otros)
Integridad (cmo los elementos se relacionan entre s de forma consistente)
Ejecucin (significado de simular o ejecutar un modelo dinmico)
Puede ser necesario trabajar con modelos mal formados:
Con omisiones (incluso intencionadamente, para simplificar las vistas)
Incompletos (faltan an elementos, relaciones por identificar)
Inconsistentes (no se garantiza la integridad del modelo)
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
Etapas del modelado del negocio
Identificar y definir los procesos de negocio segn los objetivos de la

organizacin.
Definir un caso de uso del negocio para cada proceso del negocio
(diagrama de casos de uso del negocio muestra el contexto y los lmites de
la organizacin).
Identificar los roles implicados en los diferentes procesos del negocio
(diagrama de roles)
Modelar el flujo de tareas asociado a cada proceso de negocio mediante
escenarios (diagramas de secuencia) y diagramas de procesos (diagramas
de actividades) que muestran la interaccin entre roles para conseguir el
objetivo.
Especificar las informaciones y actividades incluidas en cada diagrama de
actividades.
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
Cmo podemos pasar del modelo de negocio al modelo de requisitos?

Extraer los casos de uso del sistema a partir de las actividades que
aparecen en los diagramas de actividades.
Establecer el modelo conceptual a partir de las informaciones incluidas en
los diagramas de actividades.
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:
Identificar clases (atributos y mtodos) e interfaces en el modelo de clases

del diseo
Establecer asociaciones entre clases.
Establecer navegabilidad para todas las asociaciones.
Determinar visibilidad entre clases.
Incluir relaciones de dependencia entre clases.
Definir la arquitectura del sistema.
Establecer los subsistemas: Paquetes.
Identificar estructuras de datos.
Disear las interfaces del usuario.
Distribucin.
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>>.
Los subsistemas organizan la vista de realizacin de un sistema

Cada subsistema puede contener componentes y otros subsistemas
La descomposicin en subsistemas no es necesariamente una descomposicin
funcional
Paquetes (Categoras) y clases en el nivel lgico. Paquetes (Subsistemas) y
componentes en el nivel fsico
Un paquete incluye un conjunto de elementos de cualquier naturaleza.
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
Es una coleccin de posibles secuencias de interacciones entre el sistema en

discusin y sus actores externos, relacionado con un objetivo particular. [A. Cockburn]
Es una descripcin de un conjunto de secuencias de acciones, incluyendo variantes,
que ejecuta un sistema para producir un resultado observable de valor para un actor
[UML]
Adems:
Describen qu hace el sistema, no cmo lo hace.

Son tcnica de recoleccin y especificacin de requisitos.
Fciles de comprender/validar por los usuarios.
Guan todo el proceso de desarrollo.
Ayudan a la planificacin/desarrollo incremental.
Tradicionalmente ligados a la OO, pero no obligatorio
Ayudan a determinar la interfaz de usuario.
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
Por qu casos de uso?

Ofrecen un medio sistemtico e intuitivo para capturar los requisitos
funcionales, centrndose en el valor aadido para el usuario
Dirigen todo el proceso de desarrollo puesto que la mayora de actividades
(planificacin, anlisis, diseo, validacin, test,..) se realizan a partir de los
casos de uso.
Mecanismo importante para soportar trazabilidad entre modelos.
Crtica a los casos de uso (B.Meyer, E. Berard)
Los casos de uso no son adecuados en el modelado orientado a objetos porque:
i) Favorecen un enfoque funcional, basado en procesos
ii) Se centran en secuencias de acciones
iii) Se basan en los escenarios actuales del sistema
Solo deben ser usados por equipos expertos en desarrollo OO.
tiles para validacin.
Utilidad de los casos de uso
Hay consenso en considerar casos de uso como esenciales para capturar requisitos y
guiar el modelado. Pero existe mucha confusin sobre cmo usarlos.
Diferentes opiniones sobre el nmero de casos de uso conveniente:
20 para un proyecto 10 personas/ao (Jacobson)
100 para un proyecto 10 personas/ao (Fowler)
depende de la granularidad
Granularidad (M. Fowler)
Diferente granularidad
Un caso de uso puede describir:
Un objetivo o propsito del usuario
Una interaccin con el sistema
27
Un objetivo implica una o ms interacciones.

Primero construir un caso de uso por cada objetivo del usuario.
Despus escribir casos de uso para cada interaccin que corresponda a un objetivo.
Granularidad (A. Cockburn)
Organizacin
Objetivo estratgico para la empresa, de mucho valor
Sistema (objetivo del usuario)
Funcionalidad del sistema, tarea del usuario o proceso de negocio elemental
Subfunciones
Un paso en la descripcin de un caso de uso (validar, buscar, log on)
Tipos de casos de uso (Larman)
Descripcin breve, informal o completa
Descripcin muy general o conversacin entre actor y sistema.
Primarios, Secundarios u Opcionales
Segn su importancia en el sistema
Esenciales vs. Reales
Segn su grado de abstraccin
Un caso de uso real describe el proceso en trminos de su diseo actual,
teniendo en cuenta tecnologa de E/S.
Especificacin de requisitos
La ERS (Especificacin de Requisitos del Software) puede estar formada por:
Diagrama de casos de uso
Modelo del dominio (modelo conceptual)
(Para cada caso de uso)
Descripcin textual (usando una plantilla)
Descripciones de las interfaces de usuario
Requisitos no funcionales
Descripcin de un caso de uso
En cada momento de la especificacin de caso de uso, una representacin (Larman):
Descripcin breve (prrafo en lenguaje natural)
Descripcin informal (prrafo en lenguaje natural para escenario principal y
alternativo)
Descripcin completa (plantilla)
Describir el flujo de eventos
Texto estructurado informal
Texto estructurado formal (pre y postcondiciones)
Notaciones grficas: Diagramas de Secuencia
Debe ser legible y comprensible para un usuario no experto.
Debe indicarse: inicio y final, actores, objetos que fluyen, flujo principal y flujos
excepcionales.
Ejemplo
Comprar artculos (en un terminal de punto de venta)
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.
El cliente llega al TPV con los artculos.

El cajero registra el identificador de cada artculo.
El sistema obtiene el precio de cada artculo y aade la informacin a la
transaccin de venta.
Al acabar el cajero indica la finalizacin de la introduccin de artculos.
El sistema calcula el total de la compra y lo muestra.
El Cajero le dice al cliente el total.
El cliente realiza el pago.
El cajero registra la cantidad de dinero recibida.
El sistema muestra la cantidad a retornar al cliente y genera un recibo.
El cajero deposita el dinero recibido y saca la cantidad a devolver que entrega al
cliente junto al ticket de compra.
El sistema almacena la compra completada.
El cliente recoge los artculos comprados.
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
Nombre del caso de uso: Prestar Libro

Propsito: Hacer posible el prstamo de libros a los usuarios
Actor(es):.
Resumen:.
Precondiciones:.
Postcondiciones:
Tambin se puede utilizar la siguiente plantilla para la descripcin de un caso de
Uso
RF- <id del requisito>
Versin
Autores
Fuentes
Objetivos asociados
Descripcin
Precondicin
Secuencia
Normal
Postcondicin
Excepciones
Rendimiento
Frecuencia esperada
Importancia
Urgencia
Comentarios
<nombre del requisito funcional>

<numero de versin y fecha>
<autor>
<fuente de la versin actual>
<nombre del objetivo>
El sistema deber comportarse tal como se describe en
el siguiente caso de uso { concreto cuando <evento de
activacin> , abstracto durante la realizacin de los
casos de uso <lista de casos de uso>}
<precondicin del caso de uso>
Paso Accin
1
{El <actor> , El sistema} <accin realizada por el
actor o sistema>, se realiza el caso de uso
< caso de uso RF-x>
2
Si <condicin>, {el <actor> , el sistema} <accin
realizada por el actor o sistema>>, se realiza el
caso de uso < caso de uso RF-x>
3
4
5
6
n
<postcondicin del caso de uso>
Paso Accin
1
Si <condicin de excepcin>,{el <actor> , el
sistema} }<accin realizada por el actor o
sistema>>, se realiza el caso de uso
< caso de uso RF-x>, a continuacin este caso
de uso {continua, aborta}
2
3
Paso Cota de tiempo
1
n segundos
2
n segundos
<n de veces> veces / <unidad de tiempo>
{sin importancia, importante, vital}
{puede esperar, hay presin, inmediatamente}
<comentarios adicionales>
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
Casos de uso y Colaboraciones

Con un caso de uso se describe un comportamiento esperado del sistema, pero no se
especifica cmo se implementa. Un caso de uso se implementa a travs de una
colaboracin:
Sociedad de clases y otros elementos que colaborarn para realizar el comportamiento
expresado en un caso de uso. Una colaboracin tiene una parte esttica (diagramas
de clases) y una parte dinmica (diagramas de secuencia).
Ejemplo
32
El objetivo de la arquitectura del sistema es encontrar el conjunto mnimo de

colaboraciones bien estructuradas, que satisfacen el comportamiento especificado en
todos los casos de uso del sistema
Organizacin de los casos de uso
Los casos de usos se pueden organizar agrupndolos en paquetes, de la misma manera que
se organizan las clases.
Tres tipos de relaciones:
Generalizacin
Un caso de uso hereda el comportamiento y significado de otro
Inclusin
Un caso de uso base incorpora explcitamente el comportamiento de otro en algn
lugar de su secuencia.
Extensin
Un caso de uso base incorpora implcitamente el comportamiento de otro caso de uso
en el lugar especificado indirectamente por este otro caso de uso.
Ejemplo
En el ejemplo se puede observar que:

La relacin de inclusin permite factorizar un comportamiento en un caso de uso
aparte y evitar repetir un mismo flujo en diferentes casos de uso.
Ejemplo caso de uso Seguir Pedido: Obtener y verificar el nmero de pedido. Include
(Validar usuario). Examinar el estado de cada parte del pedido y preparar un informe
para el usuario.
33
La relacin de extensin en el caso de uso base incluye una serie de puntos de

extensin. Sirve para modelar:
la parte opcional del sistema
un subflujo que slo se ejecuta bajo ciertas condiciones
varios flujos que se pueden insertar en un punto
Ejemplo caso de uso Hacer Pedido: Include (Validar usuario). Recoger los items del
pedido del usuario. (establecer prioridad). Enviar pedido para ser procesado.
Ejemplo Modelando el comportamiento de un elemento para un sistema de venta
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
Sistema de validacin de tarjetas de

crdito
Realizar transacciones
con Tarjetas
cliente individual
Procesar
Comercio
Factura cliente
Ajustar transacciones
cliente
cliente corporativo
Gestionar cuenta
corriente
Entidad financiera
Modelado del contexto de un sistema
Recomendaciones (E. Berard)

Un caso de uso no debe considerar cuestiones de implementacin.
Conveniencia de una herramienta para la gestin de los casos de uso.
Encontrar contradicciones entre casos de uso.
Preocupacin por mantener la validez y consistencia del conjunto de casos de uso.
Cmo se comprueba que los casos de uso incluyen toda la funcionalidad del
sistema?
Cada compaa debe tener un manual sobre uso de los casos de uso.
A qu nivel de detalle se describe un caso de uso?
Qu granularidad es apropiada para un caso de uso?
Pinchar botn, Aadir Empleado,.. son casos de uso?
Recomendaciones (M. Fowler)
Cuidado con el empleo de la relacin uses
NO HAGAS UNA DESCOMPOSICIN FUNCIONAL!
No abusar de la estructuracin de casos de uso
No es necesario aplicar la abstraccin
USA CASOS DE USO CONCRETOS!
Recomendaciones (A. Pols)
Primero establecer los objetivos del proyecto.
Despus identificar actores y sus responsabilidades, y las tareas que ejecutan son los
casos de uso.
Contrastar casos de uso frente a los objetivos.
Cuidado con la ambigedad
No profundizar en la descripcin de un caso de uso
No te preocupes en exceso de la notacin
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.
El diagrama de secuencia destaca la ordenacin temporal de los mensajes. Un diagrama se

secuencia se forma colocando inicialmente los objetos que participan en la interacciones en la
parte superior del diagrama (a lo largo del eje X). Normalmente, se coloca a la izquierda el
objeto que inicia la interaccin y los objetos subordinados a la derecha. A continuacin se
colocan los mensajes que estos envan y reciben (a lo largo del eje Y) en orden de sucesin
en el tiempo desde arriba hasta abajo.
Los diagramas de secuencia tienen dos caractersticas que los distinguen de los diagramas
de colaboracin:
a. La lnea de vida de un objeto es la lnea discontinua vertical que representa la existencia
del objeto a lo largo del tiempo. La mayora de los objetos que aparecen en el diagrama
de interaccin existirn mientras dure la a interaccin, as que los objetos se ubican en la
parte superior del diagrama, con su lneas de vidas dibujadas desde arriba hacia abajo.
Durante una interaccin se pueden crear objetos, tambin pueden destruirse (mensaje
destroy y una X que marca el final de su vida).
b. El foco de control es un rectngulo delgado y estrecho que representan el periodo del
tiempo durante el cual un objeto ejecuta una accin, bien sea directamente o a travs de
un procedimiento subordinando. La parte superior del rectngulo se alinea con el
comienzo de la accin; la inferior con su terminacin (pudiendo marcarse con un mensaje
de retorno).
En un diagrama de secuencia se muestra explcitamente la lnea de vida de un objeto, lo cual
no ocurre en un diagrama de colaboracin.
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
Normalmente no es necesario indicar el retorno del control:

a
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
En el caso asncrono el retorno, si existe, se debe representar:

a : aa
b : aa
El Diagrama de Secuencia refleja de manera indirecta las opciones de control. Un

control centralizado tiene una forma como esta:
Un control descentralizado tiene una forma como esta:
39
Podemos representar iteraciones en el envo de mensajes, p.e., mientras se cumpla

una condicin:
W h i le X
Loop
end Loop
La iteracin puede expresarse tambin como parte del mensaje:

* [ c o n d ic i n ] M e n s a je
Las bifurcaciones condicionales pueden representarse de esta forma:
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.
Un diagrama de colaboracin destaca la organizacin de los objetos que participan en una

interaccin.
Un diagrama de colaboracin se construye colocando primero los objetos que participan en la
colaboracin, como nodos del grafo, Luego, se presentan los enlaces que conectan esos
objetos como arcos del grado. Por ultimo, estos enlaces se adornan con los mensajes que
envan y reciben los objetos.
Este diagrama permite visualizar el flujo de control en el contexto de la organizacin
estructural de los objetos que colaboran.
Los diagramas de colaboracin tienen dos caractersticas que los distinguen de los diagramas
de secuencia:
a. El camino. Para indicar como se enlaza un objeto a otro, se puede asociar un estereotipo
de camino al extrema ms lejano de un enlace (como <<local>> que indica que el objeto
designado es local al emisor) Normalmente, solo se necesita representar explcitamente
el camino del enlace para los camino local, parameter, global y self (pero no en
association).
b. El nmero de secuencia. Para indicar la ordenacin temporal de un mensaje, se precede
de un nmero (iniciando con el numero ), que se incrementa secuencialmente por cada
nuevo mensaje en el flujo de control (2, 3, etc.). Para representar anidamiento se usa la
numeracin Dewey (1 es el primer mensaje, 1.1 es el primer mensaje dentro del mensaje
1, 1.2 es el segundo mensaje dentro del mensaje 1, etc.).
La mayora de las veces se modelar flujos de controles simples y secuenciales. Sin
embargo, tambin se pueden modelar flujos ms complejos, que impliquen iteracin y
bifurcacin. Una iteracin representa una secuencia repetida de mensajes. Una condicin
representa un mensaje cuya ejecucin depende de la evaluacin de una expresin booleana.
Tanto en la iteracin como en el bifurcacin, UML permite el uso del pseudocdigo o la
sintaxis de un lenguaje de programacin especifico.
Los diagramas secuencia y colaboracin son semnticamente equivalentes. Aunque debe
tenerse en cuanta que los diagramas de colaboracin muestran como se enlazan los objetos,
mientras el diagrama de secuencia no lo muestra.
Un mensaje desencadena una accin en el objeto destinatario. Un mensaje se enva si
han sido enviados los mensajes de una lista (sincronizacin):
A.1, B.3 / 1:Mensaje
43
Un mensaje se enva iterada y secuencialmente a un conjunto de instancias:

1 *[i:=1..n] : Mensaje
B
A
Un mensaje se enva iterada y concurrentemente a un conjunto de instancias:
1 *| | [i:=1..n] : Mensaje
B
A
Un mensaje se enva de manera condicionada:
[x>y] 1: Mensaje
B
A
Un mensaje que devuelve un resultado:
1: distancia:= mover(x,y)
B
A
Los argumentos de un mensaje pueden ser valores obtenidos como consecuencia de

las llamadas anteriores. Los argumentos pueden ser tambin expresiones de
navegacin construidas a partir del objeto cliente. Los argumentos pueden omitirse en
el diagrama.
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
5: Verificar situacin libro

: Ficha libro
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:
Nivel Conceptual: Los clientes tienen un nombre

Nivel de Especificacin: El cliente puede almacenar y consultar su nombre
Nivel de Implementacin: Cliente tiene un campo de tipo string que almacena
su nombre y un mtodo que lo devuelve
Operaciones
Una operacin es la implementacin de un servicio que puede ser requerido a cualquier

objeto de la clase para que muestre un comportamiento. Una operacin es una abstraccin
de algo que se puede hacer a un objeto y que es compartido por todos los objetos de la clase.
Una clase puede tener cualquier nmero de operaciones o ninguna. Grficamente, las
operaciones se listan en un compartimiento debajo de los atributos de la clase. Se puede
representar mostrando slo sus nombres.
49
Ejemplo
Rectngulo
aadir ( ),
ampliar ( );
mover ( );
esta Vaco ( );
[visibilidad] nombre [(lista_parametros)] [: tipo_retorno]

Visibilidad
+ = pblica
# = protegida
- = privada
nombre: nombre de la operacin
lista_parmetros: lista de parmetros separados por comas
tipo retorno: tipo de valor devuelto por la operacin
Ejemplo
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
AgenteFraudes puede ubicarse en una aplicacin de tarjetas de crdito, y se responsabiliza

de procesar pedidos y determinar si son sospechosos, fraudulentos o legales.
Una clase puede tener cualquier numero de responsabilidades, aunque una clase bien
construida tendr al menos una responsabilidad y a lo sumo unas pocas. El refinamiento de la
clase, traduce esas responsabilidades en un conjunto de atributos y operaciones que mejor
satisfagan las responsabilidades definidas para esa clase.
Grficamente se pueden ubicar en un comportamiento separado al final de la clase, y son
texto libre escrito como una frase.
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.
La Generalizacin es una relacin entre un elemento general (llamado superclase o padre) y

un caso mas especifico de ese elemento (llamado subclase o hijo), la generalizacin tambin
se denomina como una relacin es-un-tipo-de. La generalizacin significa que los objetos
hijo se pueden emplear en cualquier lugar que pueda aparecer el padre, pero no a la inversa.
Una clase hija hereda las propiedades de sus clases padres (atributos y operaciones). En
ocasiones, el hijo aade atributos y operaciones a las que hereda de sus padres. En
ocasiones, el hijo redefine operaciones (con el mismo nombre) definidas por la clase padre
(esto se denomina polimorfismo). Se representa como una lnea dirigida continua, con una
gran parte de flecha vaca (pequeo tringulo) que apunta a la superclase.
Una clase puede no tener clase padre. Si tiene uno o ms hijos se denominan clase base.
Una clase sin hijos se llama clase hoja. Una clase con un nico padre se dice que es una
herencia simple; si tiene ms de una clase padre, utiliza herencia mltiple.
52
Ejemplo de generalizacin y especializacin de clases (en el contexto de figuras

geomtricas)
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
La especializacin es una tcnica muy eficaz para la extensin y reutilizacin
53
co che
fu n c i o n a n d o
e s tr o p e a d o
Particionamiento del espacio de objetos => Especializacin Esttica
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
Particionamiento del espacio de estados de los objetos => Especializacin Dinmica
c o c h e
fu n c io n a n d o
e s tr o p e a d o
En la Especializacin Esttica, el objeto es instancia de la subclase desde su creacin y

la superclase en las que fue creado. Esta pertenencia es inmutable. Puede haber ms
de una especializacin esttica o dinmica a partir de la misma superclase
54
comercial
vehiculo areo
militar
avion
helicoptero
En la Especializacin Dinmica un objeto puede migrar durante su vida entre las

distintas subclases de la especializacin. La migracin puede definirse en funcin de su
estado o de los eventos que le acontezcan.
d e m e n o s de 1 0 0 0 k m s
c oc he
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
Uso disciplinado de la herencia mltiple
conejo
con pelo
Herbvoro
con plumas
omnvoro
Animal
con escamas
carnvoro
Bipedo
Cuadrpedo
55
La herencia no es una necesidad absoluta y siempre puede sustituirse por delegacin.

Disminuye el acoplamiento: el cliente no conoce directamente al proveedor y el
proveedor puede ser modificado sobre la marcha Permite implementar herencia
mltiple en lenguajes con herencia simple.
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
Un diagrama de clases muestra un conjunto de clases, interfaces y colaboraciones, as como

sus relaciones. Se usan para modelar la vista esttica (estructura esttica) de un sistema. Son
los ms utilizados en el modelado de un sistema orientado a objetos.
Un diagrama de estructura esttica muestras un conjunto de clases y objetos importantes que
hacen parte de un sistema, junto con los relaciones existentes entre estas clases y objetos.
Trminos y conceptos
Un diagrama de clases es un diagrama que muestra un conjunto de nodos (clases,
colaboraciones o interfaces) y arcos (relaciones).
Un diagrama de clases contiene normalmente los siguientes elementos:
Clases
Interfaces
Colaboraciones
Relaciones de dependencias, generalizacin y asociacin.
Usos
Los diagramas de clase se utilizan para modelar la estructura esttica del sistema. Es la vista
que soporta los requisitos funcionales de un sistema, los servicios que se proporciona a los
usuarios finales.
Los diagramas de clases se utilizan en una de las siguientes formas:
1. Para modelar las colaboraciones simples
2. Para modelar un esquema lgico de base de datos.
58
Modelado de colaboraciones simples

Ninguna clase se encuentra aislada, cada una trabaja en colaboracin con otras para llevar a
cabo una semntica mayor que la asociada cada clase individual.
Cuando se crea un diagrama de clase, se esta modelando una parte de los elementos y
relaciones que configuran la vista de diseo del sistema. Por ello, cada diagrama de clases
debe centrase en una colaboracin cada vez.
Para modelar una colaboracin:
Hay que identificar los mecanismos que se quieren modelar. Un mecanismo representa
una funcin o comportamiento de la parte del sistema que se esta modelando que
resulta de la interaccin de una sociedad de clases, interfaces y otros elementos.
Para cada mecanismo, hay que identificar las clase, interfaces y otras colaboraciones que
participan en la colaboracin que se esta modelando. Tambin se debe identificar las
relaciones entre esos elementos.
Hay que usar escenarios para recorrer la interaccin entre esos elementos. Durante su
recorrido se descubrirn partes faltantes y errores semnticos.
Debemos asegurarnos de rellenar estos elementos con su conteniendo. Para las clases,
hay que comenzar obteniendo un reparto equilibrado de responsabilidades, Despus,
con el tiempo, stas se deben convertir atributos y operaciones concretas.
En la figura se representa un conjunto de clases extradas de la implementacin de un robot
autnomo, la cual se centra en las clases implicadas en el mecanismo para mover el robot a
travs de una trayectoria. Hay una clase abstracta (Motor) con dos hijos (Motor Direcciones y
Motor Principal), las cuales se muestran como partes de otra clase (Conductor). La clase
AgenteTrayectoria tiene asociacin uno a muchos con Conductor y una asociacin uno a
muchos con SensorColisin. No se muestra atributos mi operaciones para Agentetrayectoria,
aunque si se indica las responsabilidades.
Si cada una de estas colaboraciones es traslada en un diagrama diferente, se proporciona
una vista comprensible del sistema desde diferentes perspectivas.
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
Modelado de un esquema lgico de la base de datos

Muchos de los sistemas que se modelan tendrn objetos persistentes, lo que significa que
estos objetos podrn ser almacenados en una base de datos con el fin de poderlos recuperar
posteriormente. La mayora de las veces se emplear una base de datos relacional, una
base de datos orientada a objetos o una base de datos hbrida objeto-relacional para el
almacenamiento persistente. UML permite modelar esquemas lgicos de base de datos, as
como bases de datos fsicas.
Los diagramas UML son un superconjunto de los diagramas Entidad-Relacin (E-R),
herramientas de uso frecuente. Los diagramas E-R se centran en los datos, los
diagramas de clase permiten, adems, modelar el comportamiento. En la base de datos
fsica, estas operaciones lgicas normalmente se convierten en disparadores (triggers)
o procedimientos almacenados.
Para modelar un esquema:
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.
Hay que revisar el comportamiento de las clases persistentes expandiendo las

operaciones que sean importantes para el acceso a los datos y la integridad de los
datos. Se puede emplear la encapsulacin para trabajar las reglas del negocio que
manipulan conjuntos de objetos.
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.
Ejemplo de diagrama de clase
Los Diagramas de Clases y los Diagramas de Objetos pertenecen a dos vistas

complementarias del modelo.
Un Diagrama de Clases muestra la abstraccin de una parte del dominio.
Un Diagrama de Objetos representa una situacin concreta del dominio.
Cada objeto es instancia de una clase.
Ciertas clases (clases abstractas o diferidas) no pueden ser instanciadas.
62
Ejercicio prctico
En una entidad educativa cuando se desea determinar la evaluacin de los alumnos, la
secretaria debe considerar:
Datos de los alumnos (cdigo y nombre)

Datos de las evaluaciones que han obtenido en los cursos (cdigo del
curso, cinco notas de prctica, una nota del examen parcial, una nota del
examen final y una nota del examen sustitutorio)
El promedio de practicas se determinar con las cuatro mayores notas de las
prcticas
El promedio final se determinar considerando la nota del examen parcial,
nota del examen final y el promedio de prctica
La condicin ser aprobado si el promedio final es mayor o igual a 10.5, en
otro caso la condicin ser desaprobado
Si el alumno esta desaprobado la nota del examen sustitutorio reemplaza a
la nota ms baja entre el examen parcial y el examen final, seguidamente
se vuelve a determinar el promedio final y su condicin
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.
Descripcin del caso de uso

Nombre: Calculo del promedio final y condicin de los alumnos
Propsito: Conocer el promedio final y condicin de los alumnos
Actores: Alumno, Secretaria
Resumen: Aceptar los datos de los alumnos que son necesarios para determinar el
promedio final y la condicin. El promedio de las prcticas son con las
cuatro notas mayores de las prcticas. En el promedio final se considera la
nota del examen parcial, nota del examen final y el promedio de prctica.
La condicin ser aprobado si el promedio final es mayor o igual a 10.5,
sino la condicin ser desaprobado. Si el alumno esta desaprobado la nota
del examen sustitutorio reemplaza a la nota ms baja entre el examen
parcial y el examen final, seguidamente se vuelve a determinar el promedio
final y su condicin.
Precondiciones:
El alumno debe ser un alumno regular (estar matriculado en los cursos).
Postcondiciones:
Se actualizara las evaluaciones del alumno en los cursos
Se emitir un informe sobre las evaluaciones del alumno.
63
Imprimir
Ingresa datos de
alumno
Alumno
Ingresa datos de
evaluacin
Secretaria
Calcular promedio
de prctica
<<Include>>
Calcular promedio
final y condicin
Calcular menor nota
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
Especificacin de las clases

Clase: alumno
Responsabilidad: Manejar los datos personales del alumno
Atributos (private)
coda cadena de 4 caracteres
nom cadena de 30 caracteres
Mtodos (public)
alumno();
char* codigoa();
char* nombre();
void ingresadatosa(char[], char[]);
void imprimira();
Especificacin de los mtodos
alumno()
{
Inicializar los atributos con espacios en blanco
}
char* codigoa()
{
Retornar el valor de coda
}
char* nombre()
{
Retornar el valor de nom
}
Void ingresadatosa(char codi[], char nomb[])
{
Asignar a coda el valor de codi
Asignar a nom el valor denomb
}
void alumno::imprimira()
{
Mostrar el cdigo del alumno
Mostrar el nombre del alumno
}
Clase: evaluacion
Responsabilidad: Manejar las evaluaciones del alumno
Atributos (private)
coda cadena de 4 caracteres
codc cadena de 4 caracteres
p1, p2, p3, p4, p5 nmero entero
ep, ef, es nmero entero
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()

evaluacion()
{
Inicializa code con espacios en blanco
Inicializa codc con espacios en blanco
Inicializa p1, p2, p3, p4, p5, ep, ef y es en cero
}
char* codigoe()
{
Retornar el valor de coda
}
char* codigoc()
{
Retornar el valor de codc
}
int n1()
{
Retornar el valor de p1
}
int n2()
{
}
int n3()
{
}
68
int n4()
{
}
int n5()
{
}
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 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:
Datos de los trabajadores (cdigo y nombre)

Si el trabajador es tipo 1, tiene un salario fijo
Si el trabajador es tipo 2, tiene un salario base y gana una comisin
(porcentaje ) sobre la cantidad de productos que ha vendido (esta cantidad
esta expresada en soles)
Si el trabajador es tipo 3, tiene un pago fijo por cada producto que ha
elaborado, es decir , se debe considerar tambin los productos elaborados
Si el trabajador es tipo 4, tiene un pago fijo por hora normal trabajada
(hasta 40 horas) y tiene un pago de 50% ms del pago por hora normal, por
aquellas horas extras (el exceso respecto a las 40 horas normales).
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

Usted debe hacer esta descripcin
Diagrama de objetos
71
Diagrama de clases (Herencia y Polimorfismo)
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

Clase: trabajador
Responsabilidad: Manejar los datos personales del trabajador
Atributos (protected)
Codigo cadena de 30 caracteres
nombre cadena de 30 caracteres
Mtodos (public)
trabajador(char cod[], char nomb[] );
char* codigos();
char* nombres();
void imprimir();
trabajador(char cod[], char nomb[])
{
Inicializar los atributos con espacios en blanco
}
char* codigos()
{
Retornar el valor de codigo
}
char* nombres()
{
Retornar el valor de nombre
}
Void imprimir()
{
Mostrar el codigo del trabajador
Mostrar el nombre del trabajador
}
SubClase: tipo1
Responsabilidad: Manejar el pago fijo del trabajador
Atributos
salario numero real
Mtodos (public)
tipo1(char cod[], char nomb[], float s);
void salariosemanal(float s);
float pago();
void imprimir();
73

tipo1(char cod[], char nomb[], float s):trabajador(cod, nomb)
{
Llamar al mtodo salariosemanal
}
void salariosemanal(float s)
{
Asignar a salario el valor de s
}
float pago()
{
Hacer que el pago sea el valor del salario
Retornar el valor del pago
}
void imprimir()
{
Mostrar el titulo Trabajador tipo 1
Mostrar el codigo y nombre del trabajador
}
SubClase: tipo2
Responsabilidad: Manejar el pago con comisin del trabajador
Atributos
salariob,comisiong nmero real
cantidadp numero entero
Mtodos (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();
tipo2(char cod[], char nomb[], float s, float c, int q):trabajador(cod, nomb)
{
Llamar al metodo salariobase
Llamar al metodo comisin
Llamar al metodo cantidadarticulos
}
void salariobase(float s)
{
Asignar a salariob el valor de s
}
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
}
void imprimir()
{
}
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();
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
}
void imprimir()
{
}
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()
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
}
76
void imprimir()
{
}
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
de este objeto
de este objeto
de este objeto
}
77
EJERCICIOS
En cada uno de los siguientes ejercicios se debe elaborar:
Diagrama de objetos
Diagrama de 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
El descuento es el 0.5% del monto total si este es menor a 800, en caso

contrario ser el 1% del monto total
El pago neto es la diferencia del monto total y el descuento
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:
Esperando la orden para calentar agua

Se ha encendido, pero esta esperando que la temperatura se eleve.
La energa esta encendida y el servicio de calefaccin funciona
La energa se ha cortado pero el calentador an continua funcionando,
enviando el agua calentada residual
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:
Una cadena de texto que distinguen el estado de otros
Acciones ejecutadas al entrar y salir del estado,

2 Acciones de entrada/salida : respectivamente
3 Transiciones Internas:
Transiciones que no producen un cambio de estado
4 Susbestados:
Estructura anidada en un estado, que engloba

susbestados disjuntos (activos secuenciales) o
concurrentes (activos Concurrentemente)
lista de eventos que no se manejan en ese estado sino

que se posponen y se aaden a una cola para ser
manejados por el objeto en otro estado
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.
El estado afectado por la transicin; si un objeto esta en el estado

origen, una transicin de salida puede dispararse cuando el objeto
Estado origen:
reciba el evento de disparo de la transicin, y si la condicin de
guarda se satisface.
Evento cuya recepcin por el objeto que esta en el estado origen
Evento de disparo: provoca el disparo de la transicin si se satisface su condicin de
guarda.
Condicin de
guarda:
Expresin booleana que se evala cuando se activa la transicin; si

la expresin toma el valor verdadero, la transicin se puede
disparar, de lo contrario no se dispara y si no hay otra transicin
que pueda ser disparada por el mismo evento, sta se pierde.
4 Accin:
Computacin atmica ejecutable que puede actuar directamente

sobre el objeto asociado a la mquina de estados.
5 Estado destino :
El estado activo tras completarse la transicin.
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
Ejemplo de un Diagrama de Estados para la clase persona:
contratar
en el paro
en activo
perder empleo
jubilarse
jubil arse
jubilado
La comunicacin bidireccional puede representarse mediante comunicacin asncrona.

Por ejemplo en un Diagrama de Colaboracin:
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
Si la comunicacin es sncrona el cliente debe esperar la respuesta. Con lo cual en el

cliente tendramos:
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
Las guardas permiten condicionar la transicin:
Evento[ condicin ]
Podemos especificar la ejecucin de una accin como consecuencia de la transicin:
Evento[ condicin ] / accin
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
Podemos reducir la complejidad de estos diagramas usando la generalizacin de

estados. Distinguimos as entre superestado y subastados. Un estado puede contener
varios subestados disjuntos. Los subestados heredan las variables de estado y las
transiciones externas.
e1
e2
e2
c
Quedara como:
e1
e2
Las transiciones de entrada deben ir hacia subestados especficos:

e 1
a
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
La agregacin de estados es la composicin de un estado a partir de varios estados

independientes. La composicin es concurrente por lo que el objeto estar en alguno de
los estados de cada uno de los subestados concurrentes
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
La destruccin de un objeto es efectiva cuando el flujo de control del autmata

alcanza un estado final no anidado. La llegada a un estado final anidado implica la
subida al superestado asociado, no el fin del objeto.
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
Conteste a las siguientes preguntas:

1. Si estamos en el estado SUBIENDO y se produce el evento Llegada piso
destino A qu estado se llega?
2. Qu evento debe ocurrir para que se dispare la transicin desde el estado
ESTTICO al estado SUBIENDO?
3. Qu eventos al menos habrn sucedido y en que orden para pasar del estado
SUBIENDO al estado BAJANDO?
4. Partiendo del estado inicial a qu estado se llega si ocurre la siguiente
secuencia de eventos: (1) Seleccionar[piso destino<piso actual],
(2) Llegada a piso destino,
(3) Seleccionar[piso destino<piso actual]
Ejemplo MARCAR NMERO TELEFNICO

Pulsar digito(n)
Descolgar
INICIO
Pulsar digito(n)
entry/ Iniciar tono marcado

exit/ Finalizar tono marcado
MARCANDO
[ number.isValid() ]
entry/ Number.append(n)

1. Si estamos en el estado INICIO y se produce el evento Pulsar dgino(n) A qu
estado se llega?
2. Qu evento provoca que se llegue al estado INICIO?
3. Qu eventos y/o condiciones habrn sucedido como mnimo y en qu orden
para pasar del estado inicial al estado final?
4. Partiendo del estado inicial a qu estado se llega si ocurre la siguiente
secuencia de eventos y condiciones: (1) Descolgar,
(2) Pulsar digito(n), y
(3) Pulsar digito(n).
88
Ejemplo HABITACIN HOTEL
DISPONIBLE
S erv icio de
limpiez a
Canc elac ion

res erv a
Ha c er
res erva
DESOCUPA DA
PA RA LIMPIA R
Sa lid a del clie nte
HA BITA CION OCUPA DA

HA BITA CION
RESERV A DA
Lle gad a d el c lie nte

o n Uso m i n i b a r/ In cre m e n to cu e n ta
e n try/ In i ci a r fa ctu ra
e xi t/ E m i ti r fa ctu ra
entr y/ A notar re ser va

1. A qu estado llegaremos si estamos en el estado HABITACIN RESERVADA
y se produce el evento Cancelacin reserva?
2. Si estamos en el estado HABITACIN OCUPADA y se llega DESOCUPADA
PARA LIMPIAR Qu evento habr sucedido?
para pasar del estado DISPONIBLE al estado DESOCUPADA PARA LIMPIAR?
4. Partiendo del estado DESOCUPADA PARA LIMPIAR a qu estado se llega si
ocurre la siguiente secuencia de eventos y condiciones:
(1) Servicio de limpieza,
(2) Hacer reserva, y
(3) Cancelacin de la reserva.
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

1. Si una botella esta en el subestado GOTEANDO del estado compuesto ROTA
Qu evento o condicin puede provocar el cambio de estado?
2. Estamos en el subestado LLENANDO del estado compuesto
EMBOTELLANDO, se produce el evento DeteccionRotura[Vactual=0] A qu
estado se llega?
3. Qu eventos y/o condiciones habrn sucedido como mnimo y en qu orden si
se pasa del estado inicial al estado SELLADA?
4. Partiendo del subestado LLENANDO del estado compuesto EMBOTELLANDO,
a qu estado se llega si ocurre la siguiente secuencia de eventos y
condiciones:
(1) Comprobar[Vactual<Vdeseado],
(2) DeteccionRotura[Vactual!=0], y
(3) [Vactual=0]
90
Ejemplo CLIMATIZADOR
SELECCIONANDO T
do/ Display T seleccionada
Seleccionar T
Salir
INACTIVO
Apagar
Encender
on Paso 30 seg/ Medir T ambiente

do/ Display T ambiente
entry / Medir T ambiente
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

1. Si estamos en el estado INACTIVO y llegamos al estado SELECCIONANDO T
Qu evento ha sucedido?
2. Si estamos en el estado INACTIVO y la temperatura ambiente es mayor que la
temperatura seleccionada A qu estado se llega?
para pasar del estado inicial al estado ENFRIANDO si se ha de seleccionar
previamente la temperatura?
4. Partiendo del estado INACTIVO a qu estado se llega si ocurre la siguiente
secuencia de eventos y condiciones:
(1) Seleccionar T,
(2) Salir,
(3) [Tambiente<Tseleccionada], y
(4) [Tambiente>Tseleccionada].
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
Manejo de Ordenes [continuar]
Orden
Espera
Tecla Pulsada [no continuar]
En el estado compuesto por subestados concurrentes, la ejecucin de stos contina en

paralelo. Si un subestado concurrente alcanza su estado final antes que el otro, el control de
ese subestado espera en su estado final hasta que el otro u otros subestados concurrentes
alcancen sus respectivos estados finales, luego de lo cual se vuelven a unir en un mismo flujo.
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
Indice = buscar(e) +3;
Los estados de accin no se pueden descomponer. Los estados de accin son

atmicos, lo que significa que pueden ocurrir eventos, pero no se interrumpe la
ejecucin del estado de accin. Se considera que la ejecucin de un estado de
accin se realiza en un tiempo insignificante.
Los estados de actividades pueden descomponerse an ms, representando su
actividad con otros diagramas de actividades. Los estados de actividades no son
atmicos. Es decir, pueden ser interrumpidos y en general invierten algn tiempo en
completarse.
Un estado de accin se puede ver como un caso especial de un estado de
actividad. Un estado de actividad puede verse como un elemento compuesto, cuyo
flujo de control se compone de otros estados de actividad y estados de accin.
Entrando en detalles, en un estado de actividades se encontrar otro diagrama de
actividades. Se usa la misma notacin para estados de accin y estados de
actividad, con la excepcin que un estado de actividad puede tener partes
adicionales, como acciones de entrada y salida y especificaciones de submquinas.
94
Preparar construccin ( )
Entry/poner Bloqueo ( )
Procesar factura (f)

submaquinas
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.
Ejemplo de diagrama de actividad
[no zumo]
[no hay caf]

Buscar Bebida
[hay zumo]
[hay caf
Poner caf en filtro
Aadir agua al depsito
Coger taza
Coger zumo
Poner filtro en mquina
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
En el ejemplo de la figura anterior, se muestra un diagrama de actividades de un negocio de

venta que especifica el flujo de trabajo cuando un cliente devuelve un artculo de un pedido.
El proceso comienza con la accin SolicitarDevolucin del Cliente y despus pasa a travs de
Televentas a Obtener nmero de devolucin, vuelve al Cliente a Enviar articulo y despus
pasa al almacn que ejecutas dos acciones Recibir artculo y Recolocar artculo y finalmente
llega a Contabilidad que ejecuta Actualizar cuenta.
En el diagrama se indica que hay un objeto significativo (el Artculo:i) tambin fluye en el
proceso, cambiando del estado devuelta a disponible.
En este ejemplo no se presenta bifurcaciones, ni divisiones ni uniones, caractersticas propias
de flujos de trabajo ms complejos.
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
Los estereotipos permiten precisar la naturaleza del equipo:

Dispositivos
Procesadores
Memoria
Los nodos se interconectan mediante soportes bidireccionales (en principio) que
pueden a su vez estereotiparse
< < P ro c e s a d o r>

Nodo
< < < < T C P /I P > > > >

c o n e x i n 1
c o n e x i n 7
< < R D S I> >
d is p o s it iv
o
104
< < d i s p o s i t i vo > >

nodo2
Ejemplo
Servidor Central
Control y Anlisis
C
Acceso a BD
C
C
Terminal de Consulta
C
Punto de Venta
C
Gestin de Cuentas
C
C
105
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
7.3 TRABAJO PRCTICO

Documentacin Diagrama Casos de Uso
"Circulacin Libros Biblioteca"
[ Caso Uso ] Manejo Usuarios
[ Actores ] Bibliotecario, Usuario
[ Flujo Principal ] Manejar las novedades relacionadas con los usuarios de la biblioteca.
Inicia cuando el Bibliotecario abre una sesin ante el sistema identificndose ante l de
manera satisfactoria. Termina en cualquier momento que el bibliotecario desee cerrar
su sesin.
[ Flujo Excepcional ] El sistema no puede determinar la identidad y las actividades
permitidas para el bibliotecario.
[ Caso Uso ] Manejo Libros

[ Flujo Principal ] Manejar las novedades relacionadas con los libros de la biblioteca. Se
inicia cuando el bibliotecario abre una sesin ante el sistema. Termina en cualquier
momento que el bibliotecario desee cerrar su sesin.
[ Flujo Excepcional ] El sistema no puede determinar la identidad y las actividades
permitidas para el bibliotecario o usuario.
"Manejo Usuarios"
[ Caso Uso ] Reporte Usuarios
[ Actores ] Bibliotecario
[ Flujo Principal ] Reportes sobre la totalidad de los usuarios discriminados por tipos.
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.
107
[ Caso Uso ] Estado Usuarios

[ Flujo Principal ] Reportes sobre los usuarios que a la fecha incurren en mora con sus
prstamos. Calcula y actualiza los montos de las multas. Se ejecuta una vez al da, tan
pronto ha concluido la atencin al publico.
solicitar este tipo de reporte. Se le informa al Bibliotecario de dicha situacin.
reporte al momento de ser solicitado. Debe ser solicitado nuevamente por el
Bibliotecario. Se le informa al Bibliotecario de dicha situacin.
[ Caso Uso ] Movimiento Usuarios

[ Flujo Principal ] Registrar todas las novedades relacionadas con los usuarios de la
biblioteca.
[ Flujo Excepcional ] El Bibliotecario no cuenta con el nivel de seguridad requerido para
acceder a la informacin pertinente a los usuarios. Se le informa al
Bibliotecario de dicha situacin.
[ Flujo Excepcional ] El sistema no est en capacidad de iniciar este proceso al
momento de ser solicitado. Debe ser requerido nuevamente por el Bibliotecario. Se le
informa al Bibliotecario de dicha situacin.
[ include ] Adicionar, Actualizar
[ Caso Uso ] Adicionar
[ Flujo Principal ] Registrar ante el sistema la informacin pertinente a los nuevos
usuarios de la biblioteca. Inicia cuando el usuario le solicita al Bibliotecario ser
registrado como Usuario valido de la biblioteca y aporta sus datos. Termina cuando el
Usuario es registrado en el sistema apropiadamente.
[ Flujo Excepcional ] El usuario no cumple con los requisitos mnimos para ser un
Usuario valido de la biblioteca. El Bibliotecario informa al usuario de tal situacin.
108
[ Caso Uso ] Actualizar

[ Flujo Principal ] Registrar ante el sistema los cambios en los datos personales
aportados por un determinado Usuario de la biblioteca. Se inicia cuando el Usuario
manifiesta las novedades en sus datos al Bibliotecario. Termina cuando al sistema se
ingresan los nuevos datos del Usuario.
"Manejo Libros"
[ Caso Uso ] Reporte Libros
[ 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.
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.
[ Caso Uso ] Estado Libros

[ Flujo Principal ] Reportes sobre los libros clasificados segn los diferentes estados
contemplados por la biblioteca. Se puede ejecutar cuando el Bibliotecario lo desee.
solicitar este tipo de reporte. Se le informa al Bibliotecario de dicha situacin.
reporte al momento de ser solicitado. Debe ser solicitado nuevamente por el
bibliotecario. Se le informa al bibliotecario de dicha situacin.
109
[ Caso Uso ] Movimiento Libros

[ Flujo Principal ] Registrar todas las novedades relacionadas con los libros de la
biblioteca. Se inicia con la interaccin del Usuario y Bibliotecario.
[ include ] Consultas, Prestamos, Reservas, Adicionar, Devoluciones
[ Caso Uso ] Consultas
[ Actores ] Usuario, Bibliotecario
[ Flujo Principal ] Desea saber que libros y el estado de los mismos, posee la biblioteca
sobre un tema, materia o algn conjunto de parmetros por quien desee levar a cabo la
operacin. La inicia el Usuario o el Bibliotecario. Termina cuando se han desplegado
los libros segn los criterios de bsqueda.
[ Flujo Excepcional ] El sistema no est en capacidad de llevar a cabo este proceso al
momento de ser solicitado. Debe ser solicitado nuevamente por el usuario. Se le
informa al Bibliotecario responsable dicha situacin.
[ Caso Uso ] Prestamos

[ Flujo Principal ] Desea registrar en el sistema que un determinado Usuario tiene en su
poder un libro de la biblioteca. La inicia el Usuario suministrando los datos pertinentes
para que el Bibliotecario pueda entregar el libro a quien lo solicita. Termina cuando se
ha registrado la accin en el sistema y se ha entregado el libro al Usuario.
[ Flujo Excepcional ] El Usuario no cumple con las condiciones estipuladas para prestar
libros.
110
[ Caso Uso ] Renovaciones

[ extend ] Prestamos
[ Flujo Principal ] Desea registrar en el sistema que un determinado Usuario quiere
extender el periodo de prstamo de un libro en su poder. La inicia el Usuario
suministrando los datos pertinentes para que el Bibliotecario pueda actualizar el
prstamo del libro a quien lo solicita. Termina cuando se ha registrado la accin en el
sistema. Punto de extensin: nueva fecha de devolucin del libro.
[ Flujo Excepcional ] El Usuario o el periodo del prstamo o no cumple con las
condiciones para ser extendido.
momento de ser solicitado. Debe ser solicitado nuevamente por el Usuario. Se le
informa al Bibliotecario dicha situacin.
[ Caso Uso ] Reservas

[ Flujo Principal ] Registrar en el sistema que un determinado Usuario est esperando
por un libro que en el momento no se encuentra disponible.
La inicia el Usuario suministrando los datos pertinentes para que el Bibliotecario pueda
contactar a quien lo solicita cuando el libro se encuentre disponible.
Termina cuando se ha registrado la accin en el sistema.
[ Caso Uso ] Devoluciones

[ Flujo Principal ] Registrar en el sistema que un determinado Usuario ha devuelto un
libro a la biblioteca. Determina si el prstamo se ha cumplido dentro de los plazos
establecidos. Lo inicia el Usuario suministrando al Bibliotecario el libro que se
encontraba en su poder.
111
Termina cuando se ha registrado la accin en el sistema, y el libro se encuentra

nuevamente en su ubicacin fsica correspondiente.
Circulacin de Libros en una biblioteca

A continuacin se presentan algunos Diagramas UML que modelizan la circulacin de
libros en una biblioteca.
Tarea:
Complete los diagramas que representen los aspectos no cubiertos del modelo o
los que usted considere se puedan mejorar.
Diagrama de Casos de Uso (Contexto)
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
Diagrama de Secuencia (Prstamo de libro)
120
Diagrama de Actividades (Prstamo de libro)
121
Diagrama de Estados (Del objeto libro)
7.4
ARQUITECTURA DE TRES CAPAS
La arquitectura tradicional de cliente/servidor tambin es conocida como arquitectura de

dos capas. Requiere una interfaz de usuario que se instala y corre en una PC o
estacin de trabajo; y que enva solicitudes a un servidor para ejecutar operaciones
complejas. Por ejemplo, una estacin de trabajo utilizada como cliente puede correr una
aplicacin de interfaz de usuario que interroga a un servidor central de bases de datos.
La arquitectura de tres capas se refiere a un diseo reciente que introduce una capa
intermedia al proceso. Cada capa es un proceso separado y bien definido corriendo en
122
plataformas separadas. En la arquitectura tradicional de tres capas se instala una

interfaz de usuario en la computadora del usuario final (el cliente). La arquitectura
basada en WEB transforma la interfaz de bsqueda existente (el explorador de WEB),
en la interfaz del usuario final.
La tercera capa generalmente es el sistema de administracin de la base de datos. Es
decir donde los datos requeridos por la capa intermedia son almacenados. La tercera
capa se localiza en un servidor separado conocido como el servidor de base de datos.
El servidor de aplicaciones fue introducido como parte del diseo de tres capas. Es
relativamente nuevo y an no bien definido. Las empresas del mundo entero estn
esforzndose para producir su propia versin de lo que creen que es un servidor de
aplicaciones. Martn Marshall, de Zona Research, sugiere que hay confusin en el
trmino servidor de aplicaciones.
La definicin ms comn de un servidor de aplicaciones es la de software corriendo en
una capa intermedia entre un cliente pequeo basado en un explorador y una base de
datos. Generalmente se acepta que un servidor de aplicaciones maneja todas las
transacciones lgicas y de conectividad que histricamente compartan el cliente y el
servidor en un diseo cliente/servidor.
Segn [Microsoft 1997], el diseo de software se realiza a tres niveles: conceptual,
lgico y fsico.
Arquitectura lgica de tres capas de una aplicacin cliente/servidor

En el diseo lgico conceptualmente se divide en tres niveles de servicios con el fin de
que la aplicacin resulte flexible ante los cambios de requerimientos y/o de tecnologa
cambiando nicamente la capa o capas necesarias. Los tres niveles son: servicios de
usuario, servicios de negocio y servicios de datos.
123
Los servicios de usuario (user services) controlan la interaccin. Un servicio de

usuario son personas, aplicaciones, otros servicios o la combinacin de stos.
Generalmente involucra una interfase grfica de usuario (GUI) o pude ser no visual
(mensajes o funciones), maneja todos los aspectos de la interaccin con la aplicacin.
El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar
la informacin. Un servicio de usuario incluye un contenido (qu se necesita comunicar
al usuario) y una forma (cmo se comunica el contenido) cuando es necesaria la
comunicacin.
Los servicios de negocio (bussines services) convierten datos recibidos de los
servicios de datos y de usuario en informacin (datos + regla de negocio) y pueden usar
otros servicios de negocio para completar su tarea.
Las tareas de los servicios de negocio son:
Dar formato a los datos

Obtener y mover datos desde y hasta los servicios de datos
Transformar los datos en informacin
Validar los datos inmediatamente en el contexto o en forma diferida una vez
terminada la transaccin.
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:
Declaracin del esquema y su evolucin (estructuras de datos, tipos, acceso

indexado, SQL, APIs)
Respaldo y recuperacin (recuperacin de datos si un evento falla)
Bsqueda y Lectura (bsquedas, compilacin, optimizacin y ejecucin de
solicitudes, formacin de un conjunto de resultados)
Insercin, actualizacin y borrado (procesar modificaciones consistentemente
transaccional). Una transaccin es atmica (ocurre o no), consistente
(preserva integridad), aislada (otras transacciones ocurren antes o despus) y
durable (una vez completada, sta sobrevive).
Bloqueo (permite al acceso concurrente a los datos)
Validacin de datos (verifica la integridad del dominio, triggers y gateways para
verificar el estado de los datos antes de aceptarlos, manejo de errores)
Seguridad (acceso seguro a los objetos, operaciones, permisos a usuario y
grupos y servicios)
Administracin de la conexin (mecanismos bsicos para establecer una sesin
de los servicios de datos). Establecer una conexin involucra: una
identificacin, la colocacin y provisin de datos, tiempo de sesin, el tipo de
interaccin (conversacional, transaccional, multiusuario, monousuario).
Distribucin de datos (Distribuye informacin, a mltiples unidades de
recuperacin, bases de datos heterogneas, segn la topologas de la red).
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
Se define segn cmo interacta con otros

Encapsula sus funciones y sus datos
Es reusable a travs de las aplicaciones
Puede verse como una caja negra
Puede contener otros componentes
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:
El diseo para distribucin debe minimizarse la cantidad de datos que pasan

como parmetros entre los componentes y stos deben enviarse de manera
segura por la red.
El diseo para multitarea debe disearse en trminos de la administracin
concurrente de dos o ms tareas distintas por una computadora y el
multithreading o mltiples hilos de un mismo proceso)
El diseo para uso concurrente el desempeo de un componente remoto
depende de si est corriendo mientras recibe una solicitud.
El diseo con el manejo de errores y prueba de eventos:
o Validando los parmetros- a la entrada antes de continuar con
cualquier proceso.
o Protegiendo recursos crticos manejar excepciones para evitar la falla
o terminacin sin cerrar archivos, liberar objetos sincronizados o
memoria.
o Protegiendo datos importantes contar con una excepcin a la mitad
de la actuacin en las bases de datos.
o Debugging crear una versin para limpiar errores.
o Proteccin integral de transacciones de negocios los errores deben
regresarse al componente que llama.
125
Arquitectura fsica de tres capas de la aplicacin cliente/servidor
El diseo fsico comprende las siguientes tareas:
Definir los componentes

Refinar el empaquetamiento y distribucin de componentes
Especificar las interfases de los componentes
Distribuir los componentes en la red
Distribuir los repositorios fsicos de datos
Examinar la tolerancia a fallas y la recuperacin de errores
Validar el diseo fsico
De las tareas anteriores la ms importante es la distribucin de los datos que pueden

ser centralizados, una particin, un extracto o una rplica.
Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar
central. No hay copias de los datos.
Una particin de datos es una segmentacin de la base de datos maestra. Es til
cuando los datos se pueden fragmentar fcilmente y actualizarse en un sitio local con
cambios frecuentes. No hay sobreposicin entre particiones. En una particin horizontal
cada hilera existe en una sola base de datos. En una particin vertical cada columna es
contenida en una y solo una base de datos.
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
VAR JACOBSON, GRADY BOOCH, JAMES RUMBAUGH (1999). El lenguaje

Unificado de Modelado. Addision Wesly Longman, Inc.
GRADY BOOCH (1996) Anlisis y Diseo Orientado a Objetos con Aplicaciones. 2

Edicin Addison-. Wesley/Daz de Santos.
JAMES MARTIN (1993). Anlisis y Diseo de Orientado a Objetos. Prentice Hall.
JAMES MARTIN & JAMES ODELL. (1997) Mtodos Orientados a Objetos: Conceptos
Fundamentales. Prentice hall
JAMES RUMBAUGH Y OTROS Modelado y Diseo Orientados a Objetos, Metodologa

OMT.
129

Ads Manual

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ads Manual

Caricato da

Copyright:

Formati disponibili

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

UNIVERSIDAD TECNOLGICA DEL PER

TEXTOS DE INSTRUCCIN BSICOS (TINS) / UTP

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

ANLISIS Y DISEO DE SISTEMAS

Elaboracin del TINS

Profesor Hernn Robalino Gmez

Julia Saldaa Balandra

Imprenta Grupo IDAT

Queda prohibida cualquier forma de reproduccin, venta, comunicacin pblica y

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

El presente material contiene una compilacin de obras de Anlisis y

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

En el capitulo VII de describen los elementos fsicos del sistema y sus

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

Modelado del Negocio

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

Introduccin a los Sistemas de Informacin:

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

Equipo.- es decir los ordenadores y todos los dispositivos necesarios.

S. I. de Proceso de Datos en Lotes (Batch)

Interna: Es la informacin para uso interno de la organizacin. Ejemplo:

S.I. de Proceso de Datos en Lnea (On Line)

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

Terminales porttiles de captura de datos.

S.I. de Procesos Distribuidos (Distributed Processing)

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

Sistema de Informacin para la Direccin.- permiten a los directivos aprovechar la

1.3 CONCEPTOS BSICOS DE LA TECNOLOGA DE OBJETOS

Puede estar en diferentes estados (cambiantes)

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

Mensajes: Cuando se utiliza el AOO, los objetos estn recibiendo, interpretando y

Diseo orientado a objetos (OOD)

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

Programacin Orientada a Objetos (OOP)

Mismos conceptos con distinta notacin.

En 1994, Booch, Rumbaugh (OMT) y Jacobson (Objectory/OOSE) deciden unificar sus

Las races tcnicas de UML

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

Un nico modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a

Diagramas de UML (http://www.agilemodeling.com/essays/umlDiagrams.htm)

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

Reglas de uso de UML

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

Etapas del modelado del negocio

Identificar y definir los procesos de negocio segn los objetivos de la

Cmo podemos pasar del modelo de negocio al modelo de requisitos?

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

Identificar clases (atributos y mtodos) e interfaces en el modelo de clases

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

Los subsistemas organizan la vista de realizacin de un sistema

Un paquete incluye un conjunto de elementos de cualquier naturaleza.

ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

Es una coleccin de posibles secuencias de interacciones entre el sistema en

Describen qu hace el sistema, no cmo lo hace.