Modulo de Analisis y Diseño de Sistemas

2016
Anlisis y Diseo de Sistemas
CURSO
ANALISIS Y DISEO DE
SISTEMAS
SEMESTRE
III
CREADO POR
ING. OSCAR ASCON VALDIVIA
ADAPTADO POR
ING. EDWIN MANTILLA
GUEVARA
IESTP Carlos Salazar Romero
Sistemas de Informacin
Definicin de Sistema de Informacin
Es un conjunto de elementos que interactan entre s con el fin de apoyar las actividades
de una empresa o negocio.
Objetivos bsicos dentro de la organizacin

Automatizar los procesos operativos
Apoyar al proceso de toma de decisin
Lograr ventajas competitivas a travs de su implantacin y uso
Anlisis y diseo de sistemas
Se refiere al proceso de examinar la situacin de una empresa con el propsito de

mejorarla con mtodos o procedimientos ms adecuados. Tiene dos componentes:
Anlisis.- Proceso de clasificacin e interpretacin de hechos, diagnosticando

problemas y empleando la informacin que se tiene para recomendar mejoras,
especificando lo que el sistema debe hacer.
Diseo.- Se especifican las caractersticas del producto terminado y se establece
como alcanzar el objetivo.
Analista y diseador de sistemas.
Estudia la situacin de una empresa u organizacin con el fin de observar cmo trabaja
y decir si es deseable o factible una mejora, el utilizar o no una computadora es un
aspecto secundario.
Las actividades principales del analista de sistemas son tres:
Anlisis de sistemas. Se rene informacin y se determinan los requisitos.

Anlisis y diseo del sistema. El analista disea el nuevo sistema o aplicacin
que deber implementarse.
Anlisis, diseo y programacin del sistema. Desarrollo de las
especificaciones y escribir el software necesario para implementar el diseo.
Elementos de un sistema de informacin.
Software.- Programas de computadoras, estructuras de datos y documentacin

asociada que sirve para realizar el mtodo lgico.
Hardware.- Dispositivos electrnicos que proporcionan la capacidad de
computacin y las funciones del mundo exterior.
Gente.- individuos, usuarios u operadores del software y el hardware.
Bases de datos.- Coleccin grande y organizada de informacin a la que se

accede mediante el software siendo parte integral del funcionamiento del
sistema.
Documentacin.- Manuales impresos y dems informacin descriptiva que
explique el funcionamiento del sistema.
Procesamientos.- Pasos que define el uso especfico de cada elemento del
sistema o el contexto procedimental en que reside el sistema.
Control.- Los niveles de control tolerable de rendimiento que permite un mejor
trabajo del sistema
Caractersticas de los sistemas de informacin.
Los sistemas de informacin cuentan con muchas y muy variables caractersticas

algunas de las ms sobresalientes son:
Ahorro significativo de mano de obra.

Intensivos en entradas y salidas de informacin.
Clculos de procesos simples y poco sofisticados.
Gran manejo de datos para realizar operaciones.
Generan grandes volmenes de informacin.
Son recolectores de informacin.
Clasificacin de los sistemas de informacin.
Abiertos.- Intercambian informacin, materiales y energa con su ambiente.

Cerrados.- Son auto contenido y no interactan con el medio ambiente.
Probabilstico.- No conoce con certeza su comportamiento.
Determinstico.- Cualquier estado futuro que adopten puede determinarse con
anticipacin.
Tipos
Sistemas transaccionales
sistema de apoyo a las decisiones
Sistemas estratgicos
Sistemas Transaccionales
Automatizan tareas operativas

primer tipo de SI que se implantan
Muestran una intensa entrada y salida de informacin
Son fciles de justificar
Son adaptables a paquetes de aplicacin
Ejemplos: Sistema de facturacin, Sistema de matriculas, sistemas contables.

Sistemas de Apoyo a las decisiones
Suelen implantarse despus de los sistemas transaccionales.

Genera informacin de apoyo a los mandos intermedios
Suelen ser intensivos en clculos
Son sistemas interactivos y amigables
Ejemplos: Simulacin de negocios, proyecciones financieras, etc
Sistemas Estratgicos
Suelen desarrollarse dentro de la organizacin
Su evolucin es dentro de la organizacin
Su funcin es lograr ventajas frente a los competidores
Los sistemas no son eternos
Apoyan el proceso de innovacin de productos y procesos dentro de la empresa
Ejemplos: Sistemas de informacin que proporcione situaciones de crditos, etc.
SISTEMAS GERENCIALES
Herramienta para soportar funciones operativas. La finalidad de un Sistema de

Informacin Gerencial es la de suministrar a los gerentes la informacin adecuada en el
momento oportuno. Por lo tanto el valor de la informacin proporcionada por el sistema
debe cumplir con los siguientes cuatro supuestos bsicos, estos son: Calidad,
Oportunidad, Cantidad y Relevancia. Sus principales caractersticas son:
Proporcionan informacin para apoyar la toma de decisiones.

No pueden adaptarse fcilmente a paquetes disponibles en el mercado.
Tpicamente su forma de desarrollo es a base de incrementos y a travs de su
evolucin dentro de la organizacin.
Busca lograr ventajas que los competidores no posean, tales como ventajas en
costos y servicios diferenciados con clientes y proveedores. En este contexto, los
sistemas estratgicos son creados de barreras de entrada al negocio.
Apoyan los procesos de innovacin de productos y proceso dentro de la
empresa. Una forma de hacerlo es innovando o creando productos y procesos.
El Lenguaje Unificado de Modelado
El Tringulo de Desarrollo de Software
Proceso
Notacin Herramienta Visual

El Lenguaje Unificado de Modelado

Definicin:
El UML es un lenguaje grfico para la especificacin, visualizacin, construccin y
documentacin de modelos orientados a objetos que representan sistemas intensivos en
software.
= Unified Modeling Language
UML no es un mtodo sino un lenguaje de modelamiento
Objetivo del UML

Describir cualquier tipo de sistema en trminos de diagramas orientados a objetos
Algunas categoras de Sistemas
Sistemas de Informacin
Sistemas de Tiempo Real
Sistemas de Conocimiento
Sistemas Distribuidos
Sistemas de Negocios
UML toma lo mejor de varios mtodos
Rumbaugh
Booch Jacobson
Odell
Meyer
Clasificacin
Pre y Post condiciones
Shlaer-Mellor
Ciclo de vida de objetos Harel
Mquinas de estado
Gamma et. al.
Marcos de trabajo,
patrones, notas Embly
Wirfs-Brock
Singleton clases Fusion Responsabilidades
Descripcin de operaciones,
numeracin de mensajes
Caractersticas del UML

Proporciona a los desarrolladores un lenguaje de modelamiento ampliamente

aceptado y listo para usar.
Integra las mejores prcticas del desarrollo de software.
Permite el intercambio de modelos entre las diferentes herramientas de software.
Es independiente del lenguaje de programacin y de mtodos y procesos
particulares de desarrollo de software.
Proporciona sus propios mecanismos de extensin
Agrupa los conceptos de orientacin a objetos definiendo su significado.
Por qu aprender UML

- Porque UML es el lenguaje de modelado de objetos estndar dominante.
- Porque es apoyado por metodlogos y empresas importantes en Tecnologas de
Informacin.
- Porque cuenta con la aprobacin de la OMG como notacin estndar.
- Porque todas las herramientas modernas proporcionan soporte para UML.
- Porque nos facilita el aprendizaje del enfoque orientado a objetos pues basta
con aprender este estndar y no perdernos en toda la jungla de mtodos y
notaciones existentes.
Breve historia del UML

Los lenguajes de modelado orientados al objeto comenzaron a aparecer a
mediados de la dcada de '70.
El nmero de lenguajes que modelaban objetos aument de menos de 10 a ms
de 50 durante el perodo entre 1989-1994.
Muchos de los que utilizaban estos lenguajes no encontraban satisfaccin
completa en ninguno de ellos, esto motiv la llamada "Guerra de los
Mtodos".
. . . La Guerra de los Mtodos
Existan muchos mtodos y cada uno tena un lenguaje de

modelado propio.
Esto dificult el aprendizaje, aplicacin, construccin, uso de
herramientas, etc.
Pugna entre los distintos gurs que defendan sus propios mtodos y
simbologas.
Se observa la necesidad de una notacin estndar
El desarrollo del UML comenz en finales de 1994 en que Grady Booch

y Jim Rumbaugh de Rational Software Corporation, comenzaron su trabajo sobre la

unificacin de los mtodos de Booch y de OMT (Object Modeling Technique).
A finales de 1995, Ivar Jacobson y su compaa de Objectory se unieron a Rational y

combinaron sus mtodos.
Booch, Rumbaugh, y Jacobson, definieron el UML 0,9 y 0,91 en junio y octubre de

1996.
Versiones del UML
<<document>>
1997 UML 1.1
(Adoptada por OMG)
<<document>>
1998 <<document>> ISO Publica
(revisin editorial sin UML 1.2
cambios significativos)
especificacin
<<document>>
1999 UML 1.3
(revisin menor
pblicamente disponible)
<<document>>
2000 UML 1.4
(planificada una revisin menor)
2001 <<document>>
(planificada una revisin menor) UML 1.5
2002 <<document>>
(planificada una revisin mayor) UML 2.0
Vistas de un modelo
Un modelo es una descripcin completa de un sistema desde una perspectiva concreta
Vista
Diagrama de Casos de Uso
lgica
Diagrama de Clases
Diagrama de Objetos
Vista de
implementacin Diagrama de Secuencia
Vista de
Diagrama de Colaboracin
requerimientos
Vista de Diagrama de Estado
despliegue
Diagrama de Actividad
Diagrama de Componentes
Vista de
procesos Diagrama de Despliegue
Modelando con UML
Use Case
Use Case
Diagrams
Diagramas de State
Diagrams State
Component Casos de Uso Diagrams
Diagramas de State
Component Diagrams State
Diagrams
Diagramas de Clases Diagrams
Diagramas de
Diagrams Diagrams
Despliegue Objetos
State Use Case

State Use Case
Diagrams
Diagramas de Diagrams
Diagramas de
Diagrams Diagrams
Componentes Secuencia
Modelo
Scenario
Scenario Scenario
Diagramas de Scenario Diagrams
Diagramas de
Diagrams
Diagramas de Diagrams
Actividad Diagrams Colaboracin
Estados
La Crisis del Software

Ud. ser capaz de:

Explicar la crisis del software
Discutir las fortalezas de la tecnologa de objetos
Discutir dnde la tecnologa OO puede ser usada
Definir anlisis y diseo
Ejemplos
El departamento de vehculos motorizados de California gast ms de $43 millones
de dlares en un proyecto destinado a fusionar los sistemas de conductores y
registro de vehculos
El sistema fue abandonado sin ni siquiera haber sido usado
Un fallido esfuerzo de $165 millones de dlares de American Airlines de vincular su
software de reserva de pasajes con el sistema de reservaciones de Marriott, Hilton y
Budget
El aeropuerto de Denver computariz su sistema de equipaje, lo que result en
millones de dlares perdidos por la demora en la apertura del aeropuerto
Ejemplos extremos, PERO hay muchos desastres similares en una menor escala
En marzo de 1989, Arthur Andersen report ms de $300 mil millones al ao son

gastados en actividades de software comercial en los Estados Unidos
Slo el 8% resulta en software que es distribuido y funciona
Cules son las razones para la crisis del software?

Base inestable
Fallas en el manejo del riesgo
La complejidad del software
Base Inestable
Los requerimientos del negocio son ciclos de desarrollo ms cortos

Los usuarios esperan ms en trminos de flexibilidad
Los requerimientos iniciales usualmente estn mal definidos
Fallas en el Manejo de Riesgos

EL ciclo de vida de cascada retrasa la identificacin de problemas

No hay pruebas de que el sistema funcionar hasta que est cerca de ser terminado
El resultado es de mximo riesgo
Complejidad de Software
La demanda del software de negocios se est incrementando

Nadie entiende el sistema completo
Los sistemas antiguos deben ser mantenidos, pero los desarrolladores originales ya
no estn
Fortalezas de la Tecnologa de Objetos
Un solo paradigma
Un solo lenguaje usado por los usuarios, analistas, diseadores e
implementadores
Facilidad para elaborar la arquitectura y lograr el reutilizacin de cdigo
Los modelos reflejan mejor el mundo real
Mayor precisin describiendo datos corporativos y procesos
Descomposicin basada en divisiones naturales
Fcil de entender y mantener
Estabilidad
Un pequeo cambio en los requerimientos no significa cambios masivos en
el sistema en desarrollo
Desarrollo Iterativo e Incremental

Qu es un Desarrollo Iterativo e Incremental?
El desarrollo iterativo e incremental es el proceso de construir el sistema en

pequeos pasos
Beneficios
Reduccin de riesgos basado en una respuesta temprana
Mejor flexibilidad para acomodar requerimientos nuevos o modificados
Incrementar la calidad del programa
El Ciclo de Vida del Software

El ciclo de vida de un programa desencadena una secuencia de ciclos de desarrollo,
en la cual el resultado de estos ciclos es la generacin de un producto (Ejecutable)
Cada ciclo es una sucesin de fases
Inicio
Elaboracin
Construccin
Transicin
Inicion Elaboracin Construccin Transicin
tiemp
o
Fase de Inicio
Propsito
Establecer el caso de negocio para un nuevo sistema o para la
puesta al da de un sistema ya existente
Artefactos desarrollados
El ncleo de lo solicitado para el proyecto
Una asesora de riesgo inicial
Artefactos opcionales:
Un prototipo conceptual
Un modelo inicial de dominio (10% - 20% completo)
Fase de Elaboracin
Propsito
Analizar el dominio del problema
Establecer una arquitectura slida
Abordar el elemento ms riesgoso del proyecto
Desarrollar un plan integral para mostrar cmo el proyecto ser
terminado
Productos
Un modelo del comportamiento del sistema, incluyendo el

contexto del sistema, escenarios y modelos del dominio (80%
terminado)
Una arquitectura ejecutable
Una visin de la lnea base del producto a partir del modelo del
dominio
Una evaluacin del riesgo
Un plan de desarrollo
Criterios de evaluacin
Un manual preliminar para el usuario (opcional)
Estrategias de pruebas
Plan de pruebas

Fase de Construccin
Objetivo
Desarrollar incrementalmente un producto completo (un
programa) que est listo para introducirse en la comunidad de los
usuarios
Productos
Una secuencia de ejecutables
Prototipos de comportamiento
Resultados de calidad asegurados
Documentacin del usuario y del sistema
Plan de despliegue
Criterios de evaluacin para al menos la siguiente iteracin
Fase de Transicin
Propsito
Implantar el software en su entorno de operacin
Productos
Una secuencia de ejecutables.
Resultados de calidad asegurados
Documentacin del usuario y del sistema actualizada
Anlisis del rendimiento del proyecto Postmortem
Qu es una Iteracin?
Una iteracin es un ciclo de desarrollo que termina en la entrega de un

subconjunto de productos finales
Cada iteracin pasa por todos los aspectos de desarrollo del programa
Anlisis de Requerimientos
Diseo e Implementacin
Prueba
Documentacin
Cada entrega iterativa es una pieza totalmente documentada del
sistema final
Reduccin de Riesgo a travs de Iteraciones
Definir la iteracin para

Riesgo inicial consignar el mayor riesgo
Campo de accin inicial del
Planificar y desarrollar la
proyecto
iteracin
Iteracin
N Estimar la iteracin
Revisin del Eliminacin

plan del riesgo
del proyecto
Revisin de la Evaluacin de riesgo
Proceso de Planificacin de una Iteracin
Identificar y priorizar los riesgos del proyecto

Seleccionar un nmero pequeo de escenarios que contengan los
mayores riesgos
Los escenarios seleccionados son usados por:
Los desarrolladores para identificar lo que ser implementado
para la iteracin
Los probadores para desarrollar el plan de pruebas y el
procedimiento de prueba para la iteracin
Al final de la iteracin
Determinar qu riesgo ha sido reducido o eliminado
Determinar si algn nuevo riesgo ha sido descubierto
Poner al da el plan para las iteraciones restantes
Proceso Unificado Racional (RUP)

DIAGRAMAS UML
1. Diagramas de Casos de Uso
Definicin
Un Diagrama de Casos de Uso representa lo que
hace el sistema y como se relaciona con su entorno.
Representa los distintos requerimientos que hacen

los usuarios de un sistema.
Un diagrama de casos de uso esta compuesto por

- Casos de uso
- Actores
- Relaciones entre ellos
Elementos
Caso de Uso (Use Case)

Es una secuencia de acciones realizadas por el sistema que
producen un resultado observable y valioso para alguien en
particular. Nombre del Caso de Uso
Actor
Un actor es un conjunto externo uniforme de personas,
Nombre del Actor

sistemas, o cosas que solicita un servicio al sistema que estamos

modelando.
Relaciones entre los elementos
Relaciones entre actores

La nica relacin permitida entre los actores es la Relacin de Generalizacin.
Director de Usuario
Escuela (Sist. Matrcula)
Relaciones entre un actor y un caso de uso
La nica relacin permitida es una Asociacin y se le conoce como Relacin de
Comunicacin o <<comunicates>>.
<<comunicates>> Registra
Matrcula
Secretaria
Relaciones entre casos de uso

Pueden ser de tres tipos:
1. Relacin de generalizacin
El Caso de Uso de A hereda la especificacin del Caso de Uso B.
Cobranza en
efectivo
Realizar
cobranza
Cobranza
con tarjeta
Cobranza
con cheque
2. Relacin <<include>>
El caso de uso A siempre incluye (o usa) el comportamiento de B.
Registrar <<include>>
matrcula
Validar usuario
Aperturar cursos
<<include>>
3. Relacin <<extend>>
El caso de uso A, extiende al caso de uso B. A ocurre en casos especiales para extender
B.
Registrar matrcula
<<extend>>
Registrar matrcula
extempornea
Ejemplo de Diagrama de Casos de Uso
Registrar matrcula
extempornea
<<extend>>
Registrar matrcula
Usuario
<<include>>
<<comunicates>>
Validar usuario
<<include>>
Secretaria
Aperturar cursos
<<comunicates>>
Director de
Escuela
Diagrama de Casos de Uso
Registrar Persona
Registrar Regla de Conducta Elaborar Informe de Firmantes
Magistrado
<<extend>>
Suspender Regla de Conducta

Reg.PersNat Reg.PersJur
<<extend>>
<<extend>> Registrar Expediente Generar Cuaderno de FirmasElaborar Res.FirmExt
<<extend>>
Registrar Internamiento de P&S

Reg.Firma Extemporanea Elaborar Informe de Reos en Carcel
Estadistica
Procesado y/o
Sentenciado
Registrar Firma
<<include>>
Reg.Firma estndar
<<include>>
Elaborar Res.BenPenit Calcular Tiempo de CarceleriaSuspender Internamiento

Procesado Sentenciado
<<extend>>
Qu es el comportamiento del sistema?
El comportamiento de un sistema es cmo un sistema acta y reacciona

La actividad exterior visible y testeable de un sistema
El comportamiento del sistema es capturado en los casos de uso
Ellos describen el sistema, su ambiente, y la relacin entre el
sistema y su ambiente
Conceptos importantes al modelar el caso de uso
Un actor representa cualquier cosa que

interacte con l sistema
Actor
Un caso de uso es una secuencia de acciones

que un sistema realiza, que produce un
Use-Case
resultado observable de valor para un agente
Qu es un modelo de Caso de Uso?
Un modelo de caso de uso es un modelo de las funciones previstas del sistema

(casos de uso) y su entorno (actores)
El mismo modelo de caso de uso es usado en anlisis de requisitos, diseo y
prueba
Beneficios del modelo de Casos de Usos
El modelo de casos de usos

Es usado para comunicarse con el usuario final y el experto del dominio
Proporciona credibilidad en una etapa inicial del desarrollo del sistema
Asegura una comprensin mutua de los requisitos
Es usado para identificar
Quin interactuar con el sistema y qu deber hacer el sistema
Qu interfaz deber tener el sistema
Es usado para verificar que:
Se capturan todos los requisitos
Que los desarrolladores hayan entendido los requisitos
Actores
Los actores no son parte del sistema, ellos

representan roles que un usuario del sistema puede
desempear
Un actor puede intercambiar activamente la
informacin con el sistema
Acto Un actor puede ser un recipiente pasivo de la
r informacin
Un actor puede representar a un humano, una
mquina u otro sistema
Encontrando Actores: Preguntas tiles
Quin est interesado en cierto requisito?

Dnde en la organizacin se utilizar el sistema?
Quin proveer, utilizar y eliminar esta informacin del sistema?
Quin utilizar esta funcin?
Quin le dar soporte y mantenimiento al sistema?
Usa el sistema un recurso externo?
Qu actores necesita el caso de uso?
Un actor desempea varios roles?
Varios agentes desempean el mismo rol?
Instancias de Actores
Insert card
1 2
Jose acta 3
como un 4 5
6
actor 7 8
9 Oscar acta
* 0 # como un
actor
Modelo de Caso de uso
Actor Caso de uso
Un usuario puede actuar como varios actores

Jose como
Insert
card 1 2 operador
3
4 5
6
7 8
9
* 0 #
Jose Operado
Jose como r
cliente
Client
e
Casos de Uso
Un caso de uso modela un dilogo entre los

actores y el sistema
Un caso de uso puede ser iniciado por un actor
para invocar una cierta funcionalidad en el sistema
Caso de Uso Un caso de uso es un flujo de eventos completos y
significativos
Tomados al mismo tiempo, todos los casos de uso
constituyen todas las formas posibles de utilizar el
sistema
Encontrando Casos de Uso: Preguntas tiles
Cules son las tareas de este actor?

El actor, crear, guardar, cambiar, eliminar o leer la informacin en el
sistema?
Cul caso de uso crear, guardar, cambiar, eliminar o leer esta informacin?
Necesitar el actor informar al sistema sobre cambios externos e imprevistos?
Es necesario que el actor est informado sobre ciertas ocurrencias en el sistema?
Le proporciona una correcta secuencia el sistema a las tareas?
Cules casos de uso le darn soporte y mantenimiento al sistema?
Pueden todos los requerimientos funcionales ser realizados por los casos de uso?
2. Diagramas de Clases
Definicin
Un Diagrama de Clases muestra Clases (grupos de objetos que tienen las mismas
caractersticas y comportamiento) y sus relaciones.
Estos diagramas son los ms comunes en el modelado de sistemas orientados a objetos.
Un diagrama de clases esta compuesto por:
- Clases
- Relaciones entre clases
Clases
Definicin:
Es un conjunto de objetos que tienen los mismos atributos y comportamiento.
Representacin:
Se representa mediante un rectngulo con tres partes:
NombreClase Automovil
Ejemplo:
Atributo1 La Clase Automvil Matricula
Atributo2 Color
... Velocidad
Operacion1 Arrancar( )
operacion2 Acelerar( )
... Frenar( )
Relaciones entre Clases
1.- Relacin de Dependencia
2.- Relacin de Generalizacin
3.- Relacin de Asociacin
3.1.- Asociacin de Agregacin
3.2.- Asociacin de Composicin

1.- Relacin de dependencia

Es una relacin semntica entre dos elementos en la cual un cambio en un elemento (el
elemento independiente) puede afectar a la semntica del otro elemento (elemento
dependiente).
Video Televisin
... Canal ...
... ...
Grabar(c : canal) cambiar(c : canal)
2.- Relacin de generalizacin

Es una relacin entre dos clases en donde una de ellas, llamada subclase o clase hija
(subclass o child), hereda los atributos y el comportamiento de otra, llamada superclase
o clase padre (superclass o parent).
Vehculo
Terrestre Areo
camin auto avin helicptero

3.- Relacin de asociacin
Es una relacin estructural que describe un conjunto de enlaces o conexiones entre dos o
ms objetos. Esta relacin entre clases permite asociar objetos que colaboran entre si.
Acta Alumno
0..* 1..*
3.1.- Asociacin de Agregacin
Es un tipo especial de asociacin e indica que el objeto base utiliza al objeto incluido
para poder funcionar. Si el objeto base desaparece no desaparecen los objetos incluidos.
Muestra una relacin todo - parte.
Teclado
Red
CPU
Computador Monitor
a
WAN LAN Mouse
HUB Hard
Disk
3.2.- Asociacin de Composicin
Es un tipo de asociacin, en donde el tiempo de vida del objeto incluido est

condicionado por el tiempo de vida del que lo incluye. El objeto incluido slo existe
mientras exista el objeto base. El objeto se construye a partir de los objetos incluidos
pero no podra existir si ellos.
Ejemplo: El Hombre esta formado por cabeza, tronco y extremidades
Hombre
Cabeza Tronco Extremidade

s
Ejemplo Diagrama de Clases
Cliente
Venta
Codigo
1..* Codigo
Nombre
Fecha
Apellido
1 Observaciones
Direccion
3. Diagramas de Objetos
Definicin
Un Diagrama de Objetos muestra una instancia prototpica de un Diagrama de Clases
con el fin de ilustrar los objetos reales participantes en un determinado momento.
Un Diagrama de Objetos tiene los mismos elementos que un Diagrama de Clase pero
los objetos y sus atributos tienen valores conocidos.
Ejemplo Diagrama de Objetos
Cliente
Venta
Codigo: C001
1..* Codigo: FAC01
Nombre: Oscar
Fecha: 27/09/2007
Apellido:Ascn Valdivia
1 Observaciones: Cancelo con $
Direccion: Nepea
Diagrama de Clases
DIAGRAMA CE CLASES DE DISEO
Delito
Per_Juridica id_del : Integer
id_pers : Integer des_delito : String
Per_Natural raz_social : String
num_doc : String Buscar()
id_pers : Integer Registrar()
rep_legal : String
ape_pat : String Modificar()
dni_replegal : String
ape_mat : String 1
dir_legal : String
nom_per : String
0..*
dir_per_nat : String
Mandatos
lug_nac : String
fec_nac : Date id_mand : Integer
id_tipmand : Integer Firmas
tip_doc : String
num_doc : String Persona id_invol : Integer id_fir : Integer
id_pers : Integer id_dep : Integer id_mand : Integer
tip_pers : String id_del : Integer fec_firma : Date
obs_per : String fec_ini : Date obs_fir : String
0..1
fec_fin : Date id_cron : Date
Buscar() num_ficha : Integer 1..*
Registrar() est_ficha : String Buscar()
Modificar() tip_mandato : String Registrar()
1 Modificar()
Expediente 0..* Buscar()
id_exp : Integer 0..* Registrar() 1
id_dep : Integer Involucrado Modificar()
fec_auto : Date id_invol : Integer Reportar() Resoluciones
1
num_exp : String 1 id_pers : Integer Calcular_Carceleria()
0..* id_res : Integer
id_exp : Integer Gen_Cuad_Firm() tra_motivo : String
Buscar() *
id_sitjur : Integer 0..* fec_resol : Date
Registrar()
Modificar() num_resol : String
0..* Buscar() tip_res : String
Registrar() id_mand : Integer
Modificar()
Res_Beneficio
Buscar()
id_res : Integer Registrar()
Magistrado 1 id_tipben : Integer Reportar()
1
id_mag : Integer Dependencia 0..* id_dep : Integer Modificar()
nom_mag : String id_dep : Integer num_beneficio : String
1 id_mag : Integer 1
Buscar() * dep_nombre : String
Registrar() dep_ubi : String
Modificar()
Buscar()
Caso: Gestin de la Biblioteca

Se trata de gestionar los prstamos de libros de la Biblioteca Municipal de
Chimbote en la que se va a estudiar exclusivamente el funcionamiento de
las peticiones y devoluciones de libros.
Peticin de libros. Un usuario puede realizar una peticin de uno o

ms libros a la biblioteca. Para ello, es necesario presentar el carnet
de usuario de la biblioteca y una ficha en la que se detallan los libros
pedidos. Puede haber varios tipos de prstamo (prstamo de sala,
docente, proyecto fin carrera) en funcin de los cuales el usuario
puede disponer de los ejemplares durante un perodo de tiempo
especfico, como se indica en la siguiente tabla:
SALA El da de la peticin.
DOCENTE Una semana
PROYECTO FIN CARRERA Quince das.
Una vez entregados el carnet y la ficha, el sistema comprobar y

aceptar la peticin de los libros solicitados siempre que pueda
satisfacer la peticin, es decir, cuado haya ejemplares disponibles. Si
se acepta la peticin, se actualiza el nmero de unidades de los libros
de la biblioteca y se guarda la ficha de prstamo.
Devoluciones de libros. Un usuario no puede realizar ms peticiones

hasta que no haya efectuado todas las devoluciones de la peticin
anterior. El usuario, para hacer la peticin, necesita el carnet, que no
se le entrega hasta que no haya devuelto todos los libros. S puede
hacer una devolucin parcial de los libros. Cuando un usuario realice
una devolucin, el sistema actualizar el stock de libros y
comprobar la fecha de devolucin de cada ejemplar. Los usuarios
que entregaron despus de la fecha de entrega segn el tipo de
prstamo, se les sancionara con la retencin de su carnet por una
semana, lo cual les impedir solicitar nuevos prestamos.

El bibliotecario se encarga de las altas y bajas de los libros de la biblioteca.

Desarrollar:
Identificar Actores
Identificar Casos de Uso
Desarrollar el diagrama de Casos de Uso
4. Diagramas de Actividad
Definicin: Muestra las operaciones que se realizan para conseguir un objetivo. Se
utilizan para dar detalle a un caso de uso, modelando los flujos de trabajo u operaciones.
Un Diagrama de Actividad esta compuesto por:

- Estados de actividad o simplemente Actividad
- Estados de accin o simplemente Accin
- Transiciones
Elementos de un Diagrama de Actividad
Actividad.- Conjunto de acciones que buscar cumplir un objetivo. No son atmicos es

decir pueden descomponerse. Pueden ser interrumpidos y se consideran que toman
algn tiempo en completarse.
Accin.- Es una actividad que no se puede descomponer y permiten modelar un paso
dentro de un algoritmo. Se considera que su ejecucin toma un tiempo insignificante.
Transiciones.- Es el paso de una actividad a otra, una transicin ocurre al finalizar una
actividad.
Otros elementos
Decisin Barra de Sincronizacin Carriles Estados inicial y final
Ejemplo de Diagrama de Actividad

Muestre un proceso comn de una solicitud de servicio.
Cliente Vendedor Jefe Ventas

Pide datos cliente
Sol. de servicio
Pide datos
Servicio
Decide costo Consulta tarifa
[Tarifa no OK]
Negoc. condiciones
[Tarifa OK]
Consulta disponib.
Ingresa orden
SECUENCIA DE DESARROLLO DEL

PROYECTO INFORMATICO
PICTOGRAMA:
Herramienta til para recopilar informacin, o en su defecto para plasmar la
informacin recopilada, describiendo en ella el funcionamiento del sistema actual en la
organizacin.
Caractersticas:
- Debe mostrar a las personas, maquinas o sistemas que interactuan en los procesos
del sistema actual.
- Reflejar la comunicacin de los objetos anteriores describiendo el sentido y el
objetivo de la comunicacin.
- Representar la informacin que se almacena o lee de un registro.
- Utilizar grficos que faciliten la identificacin de los objetos, as como estandarizar
su representacin de acuerdo al tipo de objeto.
Ej.:
Sistema de Abastecimiento de Material
Solicitar Material Control

...
Participantes Material
Material Registra
Asistente de
Abastecimiento Registra
Entrega del Reg. Entrega
Material
Orden Informe de
Inventario de
de Materiales
Compra
Proveedores de Reg. Recepcin
Materiales
Coordinador
del Evento
REGLAS DEL NEGOCIO:

Util para tener claras las polticas de la organizacin referente a los procesos que atiende
el sistema. Una de las mejoras formas de establecerlas es basarse en cada flujo existente
entre los objetos del pictograma y plantearse interrogantes evaluando los posibles
escenarios que se pueden presentar; la respuesta a esas interrogantes en su mayora se

convierten en las Reglas de Negocio.
Ejemplo.
Accin: Participante Solicita Material.

Interrogantes: Cmo saber si la persona que viene a solicitar material es un
participante?.
Reglas de Negocio: Deber la persona presentar su DNI y el Asistente de
Abastecimiento verificar en la Lista de Participantes si es o no participante.
PROCESOS DE NEGOCIO:
Conforme vayamos analizando el comportamiento del sistema nos vamos dando cuenta
que existe un grupo de acciones que se orientan a ejecutar un proceso. Los cuales son
conocidos como Procesos de Negocios. Si bien es cierto que cada Proceso de Negocio
tendr que cumplir un conjunto de Reglas de Negocio, muchas veces es preferible de no
tener claridad establecer primero las Reglas de Negocio y luego los Procesos.
Ej.
Proceso de Negocio: Entrega de Material al Participante
Reglas de Negocio:
- Deben presentar DNI.
- Verificar que el nombre exista en la lista de participantes.
- Verificar si el participante ha recogido el material.
- Verificar si existe material para entregar.
- En caso no este conforme cambiarlo.
- Solo se entrega material los Viernes de 08:00 a 1:00 pm.
Proceso de Negocio: Recepcionar Materiales del Proveedor
Reglas de Negocio:
- Los materiales ha ingresar deben coincidir con la Orden de Compra.
- Los materiales ha recepcionar deben estar en buen estado.
- En caso de no estar conforme un porcentaje mnimo, se acepta parcialmente.
- En caso de no estar conforme con mas de 50%, se rechaza la entrega.
Proceso de Negocio: Controlar Stock de Materiales
Reglas de Negocio:
- Se debe realizar un Informe de Inventario de Materiales, solo cuando exista material
faltante o fallido.
RUP: PROCESO UNIFICADO DE RATIONAL

A) MODELO DE NEGOCIOS:
Centrado en buscar el entendimiento del Sistema. Se recomiendo aplicarlo, salvo
que el desarrollar conozca a la perfeccin el Sistema Actual.
A.1. DIAGRAMA DE CASOS DE USO DE NEGOCIOS:

En este diagrama se busca reflejar las principales funcionalidades del sistema
(casos de uso - procesos de negocio) y su interaccin con el entorno (actores).
Actor: Representa cualquier cosa que interacte con l sistema. Para encontrar
los actores de un sistema es til plantearse las siguientes interrogantes:
- Quin est interesado en cierto requisito?

- Dnde en la organizacin se utilizar el sistema?
- Quin proveer, utilizar y eliminar esta informacin del sistema?
- Quin utilizar esta funcin?
- Quin le dar soporte y mantenimiento al sistema?
- Usa el sistema un recurso externo?
- Qu actores necesita el caso de uso?
- Un actor desempea varios roles?
- Varios agentes desempean el mismo rol?
Caso de uso: es una secuencia de acciones que un sistema realiza, que produce
un resultado observable de valor para un agente
Para encontrar los Casos de Uso de un sistema es til plantearse las siguientes
interrogantes:
- Cules son las tareas de este actor?

- El actor, crear, guardar, cambiar, eliminar o leer la informacin en el
sistema?
- Cul caso de uso crear, guardar, cambiar, eliminar o leer esta
informacin?
- Necesitar el actor informar al sistema sobre cambios externos e
imprevistos?
- Es necesario que el actor est informado sobre ciertas ocurrencias en el
sistema?
- Le proporciona una correcta secuencia el sistema a las tareas?
- Cules casos de uso le darn soporte y mantenimiento al sistema?
- Pueden todos los requerimientos funcionales ser realizados por los casos
de uso?
D IA G R A M A D E C A S O S D E U S O D E N E G O C I O
P a rt i c i p a n t e E n tr e g a r M a t e ri a l e s
P ro v e e d o r R e c e p c i o n a r M a t e ri a l e s
C o o rd in a d o r C o n tro la r sto c k
A.2. MODELO DE OBJETO DE NEGOCIOS:

Es de utilidad para describir el funcionamiento de los casos de uso de negocio,
a este nivel aparecen otros objetos tales como los Workers (Trabajadores del
Sistema) y los Entity Class (Clases persistentes)
El secreto para la construccin de estos modelos esta en ir incluyendo los
objetos en el diagrama siguiendo la secuencia del funcionamiento del caso de
uso.
Ej.
BOM: ENTREGAR MATERIALES
Veri fi ca
Participante
Veri fi ca
Registra
Participante Asistente de M ateri al

(from Business Use-Case Model) Abastecimiento
Veri fi ca
Registra
Entrega
BOM : RECEPCIONAR MATERIALES
Registrar
Recepcion
Prov eedor
(from Business Use-Case Model) Registrar
Asistente de Material
Abastecimiento
Verif icar
Coordinador
(from Business Use-Case Model)
Registrar
OrdenCompra
BOM: CONTROLAR STOCK
Inventario
Material
Estadistica
Coordinador Asistente de Entrega

(from Business Use-Case Model) Abastecimiento
Estadistica
Recepcion
A.3. MODELO DE DOMINIO

Es la primera de vista de la Base de Datos que obtenemos, para ello debemos
colocar los objetos Entity Class, que aparecen en el Modelo de Objetos de
Negocio, y se establecen las relaciones.
Ej.
M O DE LO DE DO M INIO
P a rti ci p a n te R ec e pc io n
(from Business Object M od... (fr om Busi ness Object Mod.. .
E n tre g a M a te ri a l O rd e n Co m p ra
(from Business Object M od... (fr om Bu siness Obje ct Mo d... (fr om Busi ness Object Mod.. .
Nota: Suele ser til aplicar Diagramas de Actividad sobre los casos de Uso de
mayor complejidad, a fin de describir las actividades que se desencadenan y su
secuencia de ejecucin
A continuacin se describe el funcionamiento del Caso de Uso de Negocio Entregar

Materiales:
D A : E N T R E G A R M A TE R I A L E S
S o l ic i t a r
M a t e ria l
V e r if ic a r
P a rt ic i p a n t e
no
si
V e r if ic a r
E n t re g a
no
si
V e r if ic a r S t o c k
no
si
R e g is t r a r
E n t re g a
A c t u a liz a r S t o c k
d e M a t e r i a le s
Tipos de Requerimientos - Requisitos
Funcionales:
Describen la funcionalidad o servicios que el sistema se espera provea.
Indican como el sistema debera reaccionar a un ingreso en particular y como el
sistema debera comportarse en situaciones particulares.
No Funcionales:
Son requerimientos que no estn directamente relacionados con funciones
especificas que el sistema proveer.
Muchos de los requerimientos no funcionales se relacionan al sistema como un
todo.
Muchas veces son ms crticos que los requerimientos funcionales.
Ejemplo de Requisitos
El sistema mantendr un registro de todos los alumnos que se matriculen.
El sistema permitir a los usuarios realizar una bsqueda por titulo, autor.
La interfaz de usuario se implementar sobre un navegador Web.
El sistema deber soportar al menos 20 transacciones por segundo.
El sistema permitir que los nuevos usuarios se familiaricen con su uso en
menos de 15 minutos
Errores Comunes en la Especificacin de Casos de Uso
C liente
R egistrar Pedido
Vendedor
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
Crear Cliente
Usuario Actualizar Cliente

Usuario Modificar C liente
Eliminar Cliente
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
Verific ar D ato s C liente
<<in cl ude >>

<<in clude >>
U suario Ingresar Datos del C liente
Guardar D atos del C liente
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
B) MODELO DE REQUERIMIENTOS:
El Modelo de Requerimientos refleja el Compromiso que asumimos los desarrolladores en

la construccin del Sistema. Es importante que el referido modelo sea validado por el
cliente, de forma que queden establecidos los compromisos de construccin.
B.1. DIAGRAMA DE CASO DE USO DE REQUERIMIENTOS

Es el diagrama de Casos de Uso donde aparece el Compromiso de Construccin, debe
detallar los comportamientos a construir, as como las relaciones entre ellos.
Una forma fcil de construir un Diagrama de Requerimientos, es explotar los Casos de
Uso de Negocios, y transmitir en casos de uso mas pequeos su funcionamiento; luego
de ello se debe proceder a depurar eliminando los Casos de Uso que no se
implementaran (Manual), as como los casos de uso pequeos que sean previsibles su
existencia.
Ejemplo:
Diagrama de Casos de Uso de Requerimiento Detallado
<<include>>
Registrar Entrega Verificar producto

Asistente
<<include>>
<<include>>
<<include>>
<<include>>
<<include>> Actualizar stock
Verificar patron de participantes Verificar estado de material
Verificar stock
Verficar registro de entrega <<include>>
Verifica orden de compra

<<include>>
<<include>>
<<include>>
Registra recepcion
Almacenero
<<extend>>
<<include>>
Registra material
Inventario de materiales
Estadistica de entrega
En este diagrama podemos observar por ejemplo de color plomo el caso de uso
Verificar Estado del Material , este caso de uso no ser implementado pues es una
accin manual; de otra parte tambin eliminare los casos de uso de verificacin pues
asumi que son fciles de predecir su existencia, sobretodo por estar detallado en los
Modelos de Objetos de Negocio. Obtenindose el Diagrama de Casos de Uso de
Requerimientos que se muestra a continuacin.
Diagrama de Casos de Uso de Requerimiento
Estadistica de entrega Inventario de materiales
<<include>>
Registrar Entrega Actualizar stock

Asistente
<<include>>
Registra recepcion <<include>>

Almacenero
<<extend>>
Registra material
B.2. DIAGRAMAS DE ACTIVIDADES

Opcional segn necesidad, aplicar igual que en el Diagrama Mostrado en el
Modelo de Dominio.
Matriz de Priorizacion de Casos de Uso
N Caso Uso Rendimiento Frecuencia Importancia Urgencia Prioridad
1 Registrar Entrega 5 min 12 v/dia vital Inmediata 1
2 Registrar Recepcin 5 min 4 v/dia vital Inmediata 2
3 Registrar Materiales 5 min 3 v/dia vital Inmediata 3
4 Estadstica de entrega 5 min 3 v/dia vital Inmediata 4
5 Inventario materiales 5 min 3 v/dia vital Inmediata 5
Tabla N : Matriz de Priorizacion

Fuente: Elaboracin Propia
Requerimientos Funcionales
Registrar Entrega.
Registrar Recepcin
Registrar Materiales
Estadstica de entrega
Inventario materiales
Actualizar inventarios
Buscar Participantes
Verificar producto
Requerimientos No Funcionales
El sistema a desarrollarse correr bajo Windows XP, teniendo

como manejador de Base de Datos a SQL Server 2000 y como
Lenguaje de Programacin Visual Basic. Net
Realizar una copia de seguridad encriptada de toda la DATA.
Trabajara en una arquitectura Cliente/Servidor.
Solo ser utilizado por usuarios.
La clave de cada usuario debe tener un mximo de 4 caracteres.
Especificacin de Casos de Uso de Requerimientos
1 Registrar Entrega
CASO DE USO REGISTRAR ENTREGA

Descripcin El Sistema deber permitir al Asistente registrar los
materiales entregados a los participantes.
Precondicin
Secuencia Normal Paso Accin
1 El Asistente busca al participante para
entregarle material.
2 El Asistente debera verificar si es que se le
ha entregado el material, caso contrario se
le entregara el material registrando esta
transaccin.
El participante deber estar inscrito
Postcondicin
Excepciones Paso Accin
1 En el caso de que el participante no se
encuentre, deber mostrar un mensaje de
que el participante no esta inscrito
2 En caso de que ya se le haya entregado
material al participante, el sistema debera
mostrar un mensaje de que el participante
ya cuenta con material
Rendimiento El sistema deber realizar el registro de entrega de
material , en un tiempo de 1 minutos
Frecuencia 12 veces / da
Importancia Vital
Urgencia Inmediatamente
Comentarios Sin comentarios adicionales
Tabla N: Especificacin Registrar Proyecto

Fuente: Elaboracin Propia
Caso Prctico
El presidente del club de ftbol profesional del ISTP Carlos Salazar Romero le
ha solicitado a Ud., desarrollar un sistema que le permita realizar los siguientes
requerimientos:
Llevar un control de todos los deportistas pertenecientes al club (Cdigo,
DNI, Nombres, Apellidos, Fecha contrato, Fecha fin de contrato, club de
procedencia, pas, etc.)
El almacenamiento de la informacin debe de ser en SQL Server 2000.
Llevar un control de las tarjetas (amarillas y rojas) de cada jugador, para no
tener problemas en los partidos.
Tener un control de los jugadores en prstamo y a que club se los enva.
El programa debe de correr bajo plataforma Windows
El programa se debe de implementar en Visual Studio.NET (POO)
Tener un control de los Directores tcnicos y sus acompaantes (Cdigo,
DNI, Nombres, Apellidos, Fecha contrato, Fecha fin de contrato, club de
procedencia, pas, etc.).
El programa deber permitir aperturar el fitchur de las diferentes temporadas.
Desarrollar:
1. Diagrama de Casos de uso de Negocio

2. Diagrama de Objetos de Negocio
3. Diagrama de Requerimientos
5. Diagramas de Secuencia
Definicin
Un Diagrama de Secuencia muestra la interaccin de un conjunto de objetos, poniendo
nfasis en el orden cronolgico del envo de mensajes entre objetos.
Un diagrama de secuencia esta compuesto por:
- Objetos (o actores)
- Lnea de vida de un objeto
- Activacin o foco de Control
- Mensajes
Objetos o actores
objeto:Clase
Son las entidades que participan en la interaccin para lograr una funcionalidad, stas
envan y o reciben mensajes.
Lnea de vida de un objeto
objeto:Clase
Indica la vida de un objeto durante la interaccin y se representa mediante una lnea

vertical discontinua.
Activacin o foco de Control
objeto:Clase
Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando una

operacin.
Mensajes
objeto:Clase objeto:Clase
Son las invocaciones que enva un objeto a otro para que realice una tarea.
Tipos de mensajes
Mensaje Simple:
Se usa cuando no se conocen detalles del tipo de
comunicacin o cuando no resulta relevante en
el diagrama.
Mensaje Sncrono:
El objeto que enva el mensaje espera a que el
objeto que lo recibe le termine la operacin. El
mensaje sncrono ms comn es la llamada a
procedimientos.
Mensaje Asncrono:
Cuando el objeto que enva el mensaje sigue con su

trabajo sin esperar respuesta del objeto receptor del
mensaje.
Ejemplo de Diagrama de Secuencia

Un usuario desea imprimir un archivo para lo cual le enva la orden a la computadora, la
cual a su vez se la enva al servidor de impresin siendo este el encargado de dirigirlo a
la impresora. En caso de que la impresora este ocupada el archivo a imprimir se dirige
hacia la cola de impresin, la cual en su momento le indicar al servidor de impresin
que tiene el archivo pendiente por imprimir.
: Magistrado : Registrar : Buscar : Registrador de : Persona

persona persona persona
Registrar persona
Buscar persona
Leer
Obj. Persona
Registrar persona
Crear
6. Diagramas de Colaboracin
Definicin: Un Diagrama de Colaboracin muestra la interaccin de un conjunto de
objetos, poniendo nfasis en la estructura organizacional de los objetos que envan y
reciben mensajes.
Un diagrama de colaboracin esta compuesto por:
- Objetos
- Enlaces
- Flujo de Mensajes
Ejemplo de Diagrama de Colaboracin

Una nota de pedido contiene un rengln por cada artculo, que se est despachando. Si
la cantidad del artculo que an queda en almacn es menor que el punto de reorden,
est lanza una orden de compra del artculo, si hay existencias el pedido se atiende.
2: Buscar persona 3: Leer

: Buscar
persona
4: Obj. Persona
1: Registrar persona
: Magistrado : Registrar : Persona
persona
6: Crear
: Registrador de
5: Registrar persona persona
Diagramas de Secuencia y Colaboracin
Ambos diagramas muestran la interaccin entre objetos, pero el Diagrama de Secuencia

reserva una dimensin para el tiempo haciendo ms fcil observar el orden de ejecucin
de los mensajes, mientras que el Diagrama de Colaboracin los enumera. Ambos
diagramas representan lo mismo y puede transformarse de uno a otro sin prdida de
informacin.
C. ANALISIS
Diagramas de colaboracin
Diagramas de secuencia
Diagrama de clases
Diagrama de paquetes de anlisis
Relaciones
Multiplicidad para Asociaciones
Multiplicidad es el nmero de instancias de una clase que se relacionan

con una instancia de otra clase
Para cada asociacin, hay dos decisiones de multiplicidad por hacer: una
para cada final de la asociacin
Por ejemplo, en la conexin que existe entre las instancias que cumplen
el rol de maestro y curso
Para cada instancia de persona, muchos (ej. cero o mas) cursos
sern enseados
Para cada instancia de curso, exactamente una persona es el
maestro
Indicadores de Multiplicidad
Muchos
*
Exactamente uno
1
Cero o mas
0..*
Uno o mas
1..*
Cero o uno
0..1
Rango especificado
2..4
Ejemplo: Multiplicidad
Las decisiones de multiplicidad exponen muchas suposiciones ocultas

acerca del problema que esta siendo modelado
Puede ser posible que un maestro no dicte algn curso?
Puede un curso tener dos maestros?
Maestro
Persona
Curso
1 1..*
Qu significa Multiplicidad?
La multiplicidad responde a dos preguntas

La asociacin es obligatoria u opcional?
Cul es el nmero mximo o mnimo de instancias que pueden
ser ligadas a una instancia?
Curso Maestro
0..* 1
Qu le dice este
Clase Asociacin
Deseamos llevar un historial de las calificaciones de todos los cursos que

el alumno ha tomado
La relacin entre Alumno y Curso es una relacin de muchos a
muchos
Donde situamos los atributos de las calificaciones?
Alumno 0..* Curso
3-10
El atributo de calificaciones no puede ser situado en la clase Curso

porque existen (potencialmente) muchas relaciones a muchos objetos de
Alumno
Por lo tanto, el atributo pertenece realmente a la relacin individual
Alumno-Curso
Una clase asociacin es usada para almacenar informacin sobre la
relacin
Notacin de la Clase Asociacin
Una clase asociacin se representa usando el icono de clase

La clase asociacin se conecta con la asociacin usando la lnea
entrecortada
La clase de asociacin puede incluir mltiples propiedades de dicha
asociacin
Solamente una clase de asociacin est permitida por cada asociacin
Alumno 1..* Curso

3-10
Calificacin
Las Clases de Asociacin son regularmente usadas en asociaciones del

tipo muchos a muchos
Si la multiplicidad en cualquier extremo de la asociacin es muchos a

uno
Los atributos pueden ser situados dentro de una clase
Una clase de Asociacin an puede ser usada
Objetos y Clases
Qu es un Objeto?
Informalmente, un objeto representa una entidad, fsica, conceptual o programa

Entidad fsica
Camin
Entidad conceptual
Proceso Qumico
Entidad
programa
Lista Enlazada
Una Definicin Formal
Un objeto es un concepto, una abstraccin o una cosa con lmites bien

definidas y significado para una aplicacin
Un objeto es algo que tiene:
Estado
Comportamiento
Identidad
Un Objeto Tiene Estado

El estado de un objeto es una de las posibles condiciones en que el objeto
puede existir
El estado normalmente cambia en el transcurso del tiempo
El estado de un objeto es implementado por un conjunto de propiedades
(llamadas atributos), con los valores de las propiedades, adems de las
conexiones que deben tener con otros objetos
a+b=
10 Nombre: Joyce Clark
N Empleado: 567138
Fecha de Contr.: 21 de marzo 1987
Estado: Adjunto
Profesor Clark
Un Objeto Tiene Comportamiento
El comportamiento de un objeto determina cmo ste acta y reacciona

frente a las peticiones de otros objetos
El comportamiento de un objeto es modelado por un conjunto de
mensajes a los que puede responder (las operaciones que el objeto puede
realizar)
a+b=
10
Asignar profesor
(Clark)
(Retorna:confirmacin)
Registro del
Sistema Curso Algebra 101
Un Objeto tiene Identidad
Cada objeto tiene una identidad nica, incluso si su estado es idntico al

de otro objeto
Profesor J Clark Profesor J Clark Profesor J Clark

ensea Algebra ensea Algebra ensea Algebra
Qu son las Clases?

Hay muchos objetos identificados para cada dominio

Una clase es una descripcin de un grupo de objetos con propiedades en
comn (atributos), comportamiento similar (operaciones), la misma
manera de relacionarse entre objetos (asociaciones y agregados) y una
semntica en comn
Un objeto es una instancia de una clase
Una clase es una abstraccin en que:
Se enfatizan las caractersticas relevantes
Se suprimen otras caractersticas
La abstraccin nos ayuda a trabajar con cosas complejas
Ejemplo de una Clase
Clase
Curso
Estructura Comportamiento
Nombre Agregar un alumno
Ubicacin Borrar un alumno
a+b=
Das ofrecidos Entregar una lista del
10
Crditos curso
Hora de inicio Determinar si est lleno
Hora de
trmino
Clases y Objetos
Cuntas clases ve?
La Relacin Entre Clases y Objetos

Una clase es una definicin abstracta de un objeto
Define la estructura y el comportamiento compartidos por los
objetos
Sirve como modelo para la creacin de objetos
Los objetos pueden ser agrupados en clases
Objetos
Profesor
Profesor Profesor
Smith Mellon
Profesor
Jones
Encontrando Clases
Una clase debe capturar una y solo una abstraccin clave

Mala abstraccin: La clase estudiante que conoce la informacin del
estudiante y el programa del semestre actual del estudiante
Buena abstraccin: Clases separadas. Una para el estudiante y otra
programas del estudiante
Algebra 101
Historia Arte
Qumica
Espaol 101
Asignando Nombre a una Clase

El nombre de la clase debe ser el sustantivo singular que mejor
caracterice la abstraccin
La dificultad al nombrar la clase revela una pobre definicin de la
abstraccin
Los nombres deben provenir directamente del vocabulario del dominio
Gua de estilo en el nombramiento de clases
Una gua de estilo debe dictar convenciones para el nombramiento de
clases
Ejemplo de gua de estilo
Las clases son nombradas usando sustantivos singulares
Los nombres de las clases comienzan con letra mayscula
No se usa el subrayado
Los nombres compuestos por mltiples palabras se ponen

juntos y la primera letra de cada palabra se escribe con
mayscula
Ejemplo: Estudiante, Profesor, SistemaDePago
Representando Clases
Una clase es representada usando un compartimiento rectangular
a + b = 10
Profesor
Profesor Oscar
Compartimientos en la representacin grafica de una clase

Una clase est compuesta de tres secciones
La primera seccin contiene el nombre de la clase
La segunda seccin muestra la estructura (atributos)
La tercera seccin muestra el comportamiento (operaciones)
La segunda y la tercera seccin pueden ser suprimidas si se necesita que
no se vean en el diagrama
Profeso Profesor Profesor Profesor

r
nombre nombre
empID empID crear( )
crear( ) grabar( )
grabar( ) borrar( ) Profesor
borrar( ) cambiar( )
cambiar( )
Estereotipos
Un estereotipo es un nuevo tipo de elemento de modelado que extiende

la semntica del metamodelo
Deben estar basados en tipos o clases existentes en el
metamodelo
Cada clase debe tener al menos un estereotipo
Estereotipos comunes
Clase Frontera
Clase Entidad
Clase Control
Los estereotipos son mostrados en el compartimiento del nombre de la
clase encerrados entre << >>
Clase Frontera
Una clase frontera modela la comunicacin entre el entorno del sistema

y su funcionamiento interno
Clases interfaz tpicas
Windows (interfase del usuario)
Protocolo de comunicacin (interfase del sistema)
Interfase de la impresora
Sensores
En el escenario del Registrar Cursos a Tomar, un Formulario programa
es creado para aceptar la informacin del usuario
<<Boundary>>
FormularioPrograma
Interfaces con Otros Sistemas

Una clase frontera tambin es usada para modelar una interfaz a otro
sistema
Las caractersticas importantes de este tipo de clases frontera son:
La informacin que debe ser entregada al otro sistema
El protocolo de comunicacin usado para hablarle al otro
sistema
En el escenario del Registro de Cursos , la informacin debe ser
enviada al SistemaCobranza externo
Una clase llamada SistemaCobranza es creada para sostener la
interfaz con el sistema externo
<<Boundary>>
SistemaCobranza
Clase Entidad
Una clase entidad modela informacin y asocia comportamientos que

generalmente son de larga duracin (persistentes)
Puede reflejar un fenmeno de la vida real
Tambin puede ser necesitada por la tarea interna del sistema
Los valores de estos atributos normalmente son entregados por un
actor
El comportamiento es independiente del entorno
Las clases entidades en el caso de uso Registro de Cursos:
Curso
Programa
Catlogo
ListaCursos
<<entity>> <<entity >>

ListaCursos Curso
<<entity >> <<entity >>

Programa Catalogo
Clase Control
Una clase control modela el comportamiento especifico de uno o ms
casos de usos
La clase control
Crea, inicializa y borra objetos controlados
Controla la secuencia o coordina la ejecucin de los objetos
controlados
Controla asuntos concurrentes para las clases controladas
Es usualmente la implementacin de un objeto intangible
En el escenario del Registro de Cursos, la clase
AdministradorDeRegistro controla los procesos de registro
<<control>>
AdministradorDeRegistro
Diagrama de Colaboracin
WORKFLOW DE ANALISIS: REGISTRAR PERSONA
2: Buscar Persona (NomboRazSoc,TipPer) 3: Leer
4: objPersona
: Buscador de Persona : Persona Juridica
1: Registrar Persona
: Magistrado : IU_Registrar Persona : Persona
6: Crear
5: Registrar Persona
: Persona Natural
: Registrador de Persona
Diagrama de Clases de Analisis
<<entity >>
Herramienta Desarrollo
1
<<entity >>
<<entity >> Feria
Recepcion 1..n 1..n
1..n
<<entity >>
1 Proyecto 1..n
<<entity >> 1..n

Semestre
1
1
1..n <<entity >>
Grupo
1..n
1..n
<<entity >>
<<entity >> <<entity >> 1..n Alumno
1..n 1
Docente Curso
1..n
Caso Prctico
El videoclub MI VIDEOTEKA quiere mecanizar los procesos, El funcionamiento que
requiere el videoclub es el siguiente:
Un cliente del videoclub realiza los alquileres sealando los ejemplares que desea
alquilar. Para ello debe comprar unos bonos que indican, por un lado, el crdito (o
nmero de alquileres), y por otro, el perodo de alquiler, que puede ser de 24 horas, 48
horas y semanales. Un cliente puede comprar varios bonos del mismo tipo, en cuyo caso
se acumulan sus crditos.
Cada alquiler de un ejemplar relativo a una pelcula consume un crdito sobre el tipo de
bono elegido por el cliente. Una vez que el sistema comprueba que el cliente dispone de
crdito respecto al pedido de alquiler, lo acepta emitiendo un comprobante al cliente en
el que se especifican los ejemplares solicitados y la fecha de su devolucin, indicando

adems el crdito disponible.
Los clientes realizan la devolucin de los ejemplares alquilados, que puede no estar
completa, es decir, se devuelven menos ejemplares de los solicitados en un alquiler. El
sistema no aceptar nuevos alquileres de aquellos clientes que no hayan devuelto todos
los ejemplares. El sistema debe calcular una sancin econmica respecto a todos los
ejemplares entregados fuera de plazo, cargando un coste de F unidades monetarias por
ejemplar y da.
El sistema realiza pedidos de pelculas a los proveedores. Los datos de estos pedidos
vienen determinados por la direccin del videoclub a partir de la informacin
suministrada por los proveedores. Estos pedidos pueden ser sobre pelculas nuevas o
sobre aumento de ejemplares de pelculas existentes en el videoclub. Los proveedores
pueden satisfacer cada pedido en una o varias entregas. Cuando el sistema recoge las
entregas debe asignar un cdigo a cada ejemplar, que adems debe identificar a la
pelcula.
La Empresa MI VIDEOKA cuentan en total con 20 tiendas distribuidas en todo el
norte del pas (Per.)
Desarrollar
1. Diagrama de caso de uso de negocio
2. Modelo de Objeto de Negocio
3. Diagrama de Casos de uso de requerimiento detallado
4. Diagrama de colaboracin
5. Diagrama de Clases (Entity)
D. DISEO DE SISTEMAS
Diseo de Interfaces
Diagrama de Secuencia
Diagrama de Clases
Diagrama de Estados
CONSTRUCCION DE DIAGRAMAS DE SECUENCIA DE DISEO
Lo particular de la construccin de los diagramas de secuencia de diseo es que reflejan

el funcionamiento de la interfaz evaluando distintos escenarios. Eso quiere decir que
NO es cuestin de presionar F5 en el Rational Rose sobre los diagramas de
colaboracin de Anlisis, puesto que en la etapa de anlisis estbamos expresando que

debe hacer el sistema y ahora en el Diseo deseamos expresar como funcionara el
sistema.
Debemos ser conciente en todo momento que la construccin de diagramas de secuencia
de diseo me permitir refinar las interfaces puesto un diagrama de secuencia es tan
detallista que pareciera que estamos programando pero en papel.
Pautas para la Construccin de Diagramas de Secuencia de Diseo:

- Construir un diagrama de secuencia por cada interfaz.
- Colocar el objeto (instancia del actor que invocara la interfaz) y la interfaz a
describir su funcionamiento.
- Colocar el primer mensaje dirigido desde el actor hacia la interfaz (boundary),
dando como nombre de mensaje el evento a utilizar y el nombre de la interfaz.
(Ejm: Clic Registrar Cliente.)
- Suponer cual seria el procedimiento normal de un usuario manejando la interfaz,
y luego proceder a describir como se da el primer comportamiento que
desencadena la interfaz; para este punto colocar el mensaje desde el Actor hacia
la interfaz indicando el evento y objeto donde se desencadena el
comportamiento (Por ejemplo Clic botn buscar).
- Luego enviar un mensaje desde la interfaz a la Clase Control que tiene
implementado ese comportamiento. (Ejm de Clase Control: Buscador de
Persona), dando un nombre de mensaje que sea muy similar al nombre del
Control Class y consignar los argumentos que se le pase. (Ejm:
BuscarPersona(tipbus, codbus)).
- De all el Control Class de utilizar data almacenada, debers expresar en el
diagrama de secuencia un mensaje desde el Control Class a la Clase Entidad
(Ejm: Persona), el nombre del mensaje debe ser la accin que se hace sobre el
entity (Ejm: Leer, Crear, Eliminar, Actualizar)
- Ahora si el Control Class desea capturar registros, colocar un mensaje de retorno
hacia la interfaz (ojo esto es lo comn) donde vaya como mensaje un
objEntity (Ejm: objPersona), de suceder que solo requiere el Control Class
verificar si la accin se logro con xito enviar un mensaje de retorno
denominado varEntity (Ejm varPersona), acurdate que en esta representacin el
var significa que solo almacena un valor.
- Despus debes evaluar en la interfaz que hacer en base a lo que te enva el
control Class por ejemplo si te enva un obj. con data podras mostrarlo en la
interfaz, pero si llegara un obj. vaci debers enviar un mensaje al actor a fin de
que tome conocimiento que no hay nada que mostrar (Equivalente a los cuadros
de dialogo). Lo mismo sucede con los var debers evaluar en la interfaz si llega
el valor esperado de no ser as enviar mensaje al actor a fin de tome
conocimiento.
- Bueno estos pasos debers repetirlo por cada escenario que desencadene
comportamientos en la interfaz.
EJEMPLO DE DIAGRAMA DE SECUENCIA

: Vendedor : IU_RegistrarPersona : Buscador de Persona : Registrador de Persona : Persona

Registrar Persona
Clic Boton Buscar
BuscarPersona(tipbus, cadbus) Leer
si objPersona <> null mostrardatos
si objPersona == null mostrar mensaje "no se encontro personas"
Clic Boton Grabar RegistrarPersona(ape_pat, ape_mat, nom_per, dir_per)

Crear
si varPersona == 1 mensaje "Se registro la persona correctamente"
si varpersona == -1 mensaje "error grabando persona"
D
DIIA
AGGR
RAAM
MAAD
DEEC
CLLA
ASSE
ESS
CLASES Y OBJETOS:
Clase: Es una descripcin de un conjunto de objetos que comparten los mismos

atributos, operaciones, relaciones y semntica. Implementa una o ms interfaces.
Se representa mediante un rectngulo con tres partes:
NombreClase Automovil
Ejemplo:
Atributo1 La Clase Automvil Matricula
Atributo2 Color
... Velocidad
Operacion1 Arrancar( )
operacion2 Acelerar( )
... Frenar( )
Objeto: Instancia particular de una clase. Distinguible por sus caractersticas

especficas.
CLASE PERRO
define raza,
datos y color...
mtodos
come,
ladra...
OBJETO RAMBO
ocupa bulldog
espacio gris
y
dura un come caviar
tiempo ladra fuerte
DIAGRAMA DE CLASES:
Un Diagrama de Clases muestra Clases y sus relaciones.

Estos diagramas son los ms comunes en el modelado de sistemas orientados a objetos.
Un diagrama de clases esta compuesto por:

- Clases
- Relaciones entre clases
RELACIONES ENTRE CLASES:
Una relacin es una conexin entre elementos. En el modelado orientado a objetos hay
tres tipos de relaciones: dependencias, las generalizaciones, y las asociaciones.
Relacin de Dependencia
Relacin de Generalizacin
Relacin de Asociacin
o Asociacin de Agregacin
o Asociacin de Composicin
CONSTRUCCIN DEL DIAGRAMA DE CLASES DE DISEO

La construccin del diagrama de clases de diseo es uno de los mas importantes
diagramas del modelamiento de sistemas, ya que muestra la estructura final de la base
de datos orientada a objetos del sistema.
Para construir este diagrama debemos guiarnos del diagrama de clases de anlisis
(entidades), interfaces y diagramas de secuencia de diseo.
Pautas para la Construccin del Diagrama de Clase de Diseo:

- Trasladar todas las clases entidad de los diagramas de secuencia de diseo.
- Guindose de las interfaces, identificar que datos que se muestran o capturan en
ellas se deben almacenar en cada clase (consignar como atributos).
- Comprobar que los datos consignados en los mensajes de los diagrama de
secuencia, tengan forma de ser utilizados desde la clase. (nivel de atributos)
- Respecto a la identificacin de operaciones de las clases, debern tomar uno por
uno los diagramas de secuencia de diseo tomar una clase entidad, bajar por su
lnea de vida identificar los mensajes que le llegan y ver que clase control enva
el mensaje, el mensaje que invoca esa clase control seria una operacin de la
clase entidad. De esta forma debers proceder para identificar todas las
operaciones de las clases de tu diagrama de clases de diseo.
- Respecto a las relaciones puedes guiarte del diagrama de clases de anlisis,
revisando y validando eso si cada relacin.
- Finalmente debes tener en cuenta es que el diagrama de clases de diseo no debe
mostrar relaciones circulares (anillos), puesto que su existencia mermara el
rendimiento de la base de datos.
DIAGRAMA CLASE DISEO
Personal
codigo : String
nombres : String
apellidos : String
direccion : String
turno : String
1..*
Orden produccion
Avance
nro_orden : String
codigo : String
hora : Date
1 1..* estado : String
fecha : Date
1
Maquinaria 1
1..*
codigo : String Tipo proceso
descripcion : String 1 1..*
1..* codigo : String
tipo : String
Detalle orden produccion
dodigo_equipo : String
codigo_ingred : String
nro_orden : String
1..*
Ingredientes
codigo : String
descripcion : String
fecha adquisicin : Date 1
fecha vencimiento : Date
PRACTICA
EJERCICIO N 1: Para las siguientes situaciones complete los siguientes

diagramas de clases:
1. Se desea controlar las ventas de productos en una ferretera y se tienen las

clases: Cliente, Persona Natural, Persona Jurdica, Venta, Detalle Venta,
Producto, Vendedor.
2. En la ULADECH se desea tener un control de las matriculas realizadas para los
cursos de verano.
EJERCICIO N 2: Para las siguientes situaciones construya un diagrama de clases

que brinde solucin a su problema:
1. Sabiendo que una organizacin dedicada a la venta de pasajes a la ciudad de

Lima desea almacenar informacin de sus clientes, de sus ventas, as como tener
identificado a que bus corresponde la venta de un boleto. Construya el diagrama
de clases que le corresponda
2. Una organizacin dedicada a la venta de buses desea tener un control de a que
cliente le ha vendido que bus o buses, y con que documento de venta.
Generacin del modelo de datos a partir del modelo de objetos

1. Crear el modelo de objetos
a. Crear un paquete (package) llamado Diagrama de Clases en Logical
View\Design Model
b. En el paquete Diagrama de Clases crear un diagrama de clases (class
diagram) llamado Ejemplo
c. Crear el siguiente diagrama de clases
d. Colocar a todas las clases persistentes
Producto
Orden Compra
fecha : Date
precio unitario : Double
1..* 1..*
ItemLinea
cantidad : Integer
Modelo de Objetos Ejemplo
2. Crear la Base de datos

a. En el paquete Component View, hacer clic derecho y seleccionar Data
Modeler\New\Database. Aparece un nuevo paquete denominado DB_0
que contiene a la base de datos DB_0. Cambiar el nombre por
DB_Ejemplo
b. Seleccionar la base de datos DB_Ejemplo , hacer clic derecho y
seleccionar Open Specification . En la caja de dilogo Database
Specification for DB_Ejemplo, en la lista Target seleccionar el DBMS
Microsoft SQL Server 2000. Hacer clic en OK
3. Crear el Esquema
a. En el paquete Schemas en Logical View, hacer clic derecho y seleccionar
Data Modeler\New\Schema. Aparece un paquete denominado Schema
S_0
b. Hacer clic derecho en el paquete Schema S_0, seleccionar Open
Specification. En la caja de dilogo Schema Specification for S_0 en la
lista Database seleccionar la base de datos DB_Ejemplo. Hacer clic en
OK
c. Hacer clic derecho en el paquete Schema S_0, seleccionar Data

Modeler\New\Data Model Diagram y asignarle el nombre Ejemplo
4. Transformar el modelo de objetos a modelo de datos

a. En el paquete Diagrama de clases en Logical View\Design Model, hacer
clic derecho y seleccionar Data Modeler\Transform to Data Model
b. En la caja de dilogo Transform Object Model to Data Model, en la lista
Destination Schema seleccionar el esquema S_0, en la lista Target
Database seleccionar DB_Ejemplo , luego hacer clic en OK.
T_Orden Compra T_Producto

fecha : DATETIME descripcion : VARCHAR(255)
T_Orden Compra_ID : INT precio unitario : FLOAT(64, 0)
T_Producto_ID : INT
<<PK>> PK_T_Orden Compra26()
<<PK>> PK_T_Producto28()
1
1
<<Identifying>> <<Identifying>>
0..* 0..*
T_ItemLinea
cantidad : INT
T_Orden Compra_ID : INT
T_Producto_ID : INT
<<PK>> PK_T_ItemLinea27()
<<FK>> FK_T_ItemLinea27()
<<FK>> FK_T_ItemLinea26()
<<Index>> TC_T_ItemLinea92()
<<Index>> TC_T_ItemLinea91()
Modelo de Datos: Ejemplo
5. Generar los objetos de la base de datos

a. En el paquete Schema S_0 en Logical View\Schemas. Hacer clic derecho
en Data Modeler\Forward Engineer
b. Aparece el asistente Forward Engineering Wizard
i. En welcome , hacer clic en Next
ii. En choose Options, hacer clic en Next
iii. En choose to save and execute DDL, escribir el nombre del
archivo que va a contener el script de generacin . Opcional
mente hacer check en Execute para generar los objetos de la base
de datos directamente al Servidor de Base de datos, luego hacer
clic en Next
iv. En comlpeting... , hacer clic en Fins
CREATE TABLE T_Orden_Compra (

fecha DATETIME NOT NULL,
T_Orden_Compra_ID INT IDENTITY NOT NULL,
CONSTRAINT PK_T_Orden_Compra26 PRIMARY KEY NONCLUSTERED
(T_Orden_Compra_ID)
)
GO
CREATE TABLE T_Producto (
descripcion VARCHAR ( 255 ) NOT NULL,
precio_unitario FLOAT ( 64 ) NOT NULL,
T_Producto_ID INT IDENTITY NOT NULL,
CONSTRAINT PK_T_Producto28 PRIMARY KEY NONCLUSTERED (T_Producto_ID)
)
GO
CREATE TABLE T_ItemLinea (
cantidad INT NOT NULL,
T_Orden_Compra_ID INT NOT NULL,
T_Producto_ID INT NOT NULL,
CONSTRAINT PK_T_ItemLinea27 PRIMARY KEY NONCLUSTERED
(T_Producto_ID, T_Orden_Compra_ID)
)
GO
CREATE INDEX TC_T_ItemLinea91 ON T_ItemLinea (T_Producto_ID)
GO
CREATE INDEX TC_T_ItemLinea92 ON T_ItemLinea (T_Orden_Compra_ID)
GO
ALTER TABLE T_ItemLinea ADD CONSTRAINT FK_T_ItemLinea26 FOREIGN KEY
(T_Producto_ID) REFERENCES T_Producto (T_Producto_ID)
GO
ALTER TABLE T_ItemLinea ADD CONSTRAINT FK_T_ItemLinea27 FOREIGN KEY
(T_Orden_Compra_ID) REFERENCES T_Orden_Compra (T_Orden_Compra_ID)
GO
Srcipt Transact SQL : Ejemplo.DDL
6. Generar la base de datos en SQL Server 2000 a partir del siguiente modelo de
objetos
Empleado
nombre : String
apellido : String
direccion : String
Especialidad Medico Administrativo

nombre : String colegiatura : String fecha contrato
1 0..*
1..*
Nivel
1..*
Clinica
Servicio
nombre : String
nombre : String
direccion : String
telefono : String 1..*
0..* precio : Double
fax : String
Personal
codigo : String
nombres : String
apellidos : String
direccion : String
turno : String
1..*
Orden produccion
Avance
nro_orden : String
codigo : String
hora : Date
1 1..* estado : String
fecha : Date
1
Maquinaria 1 1..*
codigo : String Tipo proceso
descripcion : String 1 1..* 1..* codigo : String
tipo : String
Detalle orden produccion
dodigo_equipo : String
codigo_ingred : String
nro_orden : String
1..*
Ingredientes
codigo : String
fecha adquisicin : Date 1
fecha vencimiento : Date
CONSTRUCCION DE DIAGRAMAS DE ESTADO
CREANDO UN DIAGRAMA DE TRANSICION DE ESTADOS
1. Dar clic derecho sobre la clase que se desea especificar la transicin de estados.
2. Escoger la Opcin New / StateChart Diagram.
3. Colocarle el nombre al Diagrama de Estados creado, y presionar enter.
4. Dar doble clic sobre el Diagrama de Estado creado verificar ubicacin en la
Barra de Titulo.
CREANDO ESTADOS:
1. Seleccionar el Icono Estado de la Barra de Herramientas
2. Haga clic dentro del diagrama y digite el nombre del Estado.
3. Repita el paso 1 y 2 por cada Estado que tenga los objetos de la Clase en
Anlisis.
CREANDO TRANSICIONES DE ESTADO:

1. Seleccionar el Icono State Transtition de la Barra de Herramientas.
2. Haga clic en el Estado inicial y arrastre hacia el Estado Final.
3. Digite la accin o evento.
INCORPORANDO CONDICIONES:
1. Doble clic sobre la transicin que se desea aplicar una condicin.
2. Ubicarse en la Ficha: Detail.
3. Luego en Guard Condition digite la Condicin a aplicar.
EJERCICIOS:
1. Se le ha requerido elaborar un Diagrama de Estado para la Clase Documento de

un Sistema de Compra y Venta; adems se le comunicado que cada objeto de
esta clase pasa por los siguientes estados: Creado, Abierto, Cancelado o
Anulado. El estado Creado se le asigna a todo documento que recien a sido
registrado, mientras que Abierto se le considera a los Documentos que han
generado un pago pero que aun tienen saldo, el estado Cancelado se da cuando
el documento ya no tiene saldo pendiente producto de los pagos realizados, por
ultimo el estado Anulado es cuando se deja sin efecto un Documento. A
continuacin se le muestra el diagrama de estado que da solucin ha este caso,
constryalo en Racional Rose.
Agregar Pago Cancelado
Creado
Documento Cancelado[ documento.deuda = detaliqui ]
Agregar Pago
Abierto
Documento Anulado
anular
Anulado
2. Construya el siguiente Diagrama de Estados en Rational Rose, dentro de la

Clase Venta:
introducirProducto
Espera Venta introducirProducto Introduccion

Productos
Terminar Venta
manejarRespuesta
efectuar Pago Efectivo Espera
Pago
Autorizacion
Pago
efectuar Pago Tarjeta
3. Sabiendo que un Cliente de una Universidad puede pasar por los siguientes
estados: Postulante, Ingresante, Matriculado, Reservo Matricula, Egresado, y
Deserto; construya el Diagrama de Estados equivalente en Rational Rose, e
indique a que Clase corresponde este Diagrama.
4. Un nuevo programador le pedido detallar los estados posibles de los Usuarios de

un Sistema, construya el diagrama requerido en Rational Rose.
PUNTOS A CONSIDERAR EN LA PRESENTACION DEL INFORME

FINAL DEL PROYECTO DE ANALISIS Y DISEO DE SISTEMAS
1. CARATULA
2. DEDICATORIA
3. AGRADECIMIENTO
4. INDICE
5. RESUMEN
6. INTRODUCCION
7. GENERALIDADES
DESCRIPCION DE LA ORGANIZACION
ORGANIGRAMA
SITUACION PROBLEMA
8. MODELAMIENTO DEL NEGOCIO:
PICTOGRAMA
PROCESOS DE NEGOCIO
REGLAS DE NEGOCIO
MODELADO DE CASOS DE USO DEL NEGOCIO
DIAGRAMA DE ACTIVIDAD POR CADA CASO DE USO DE NEGOCIOS.
MODELO DE OBJETOS DEL NEGOCIO
MODELO DE DOMINIO
9. MODELO DE REQUERIMIENTOS
MODELO DE CASOS DE USO DE REQUERIMIENTOS DETALLADO

DIAGRAMA DE CASOS DE USO DE REQUERIMIENTOS
ESPECIFICACION DE CASOS DE USO DE NEGOCIO
10. ANALISIS
DIAGRAMAS DE COLABORACION
DIAGRAMA DE CLASES DE ANALISIS (ENTITIS)
11. DISEO
INTERFACES DE USUARIO
DIAGRAMAS DE SECUENCIA DE DISEO
DIAGRAMA DE CLASES DE DISEO
DIAGRAMA DE ESTADO (por lo menos de 3 clases)
MODELO FISICO DE LA BASE DE DATOS RELACIONAL (RATIONAL)
SCRIPT DE MIGRACION DE LA BASE DE DATOS A SQL SERVER 2000
MODELO FISICO DE LA BASE DE DATOS RELACIONAL (SQL SERVER)
MODELO FISICO DE LA BASE DE DATOS RELACIONAL (NORMALIZADO)
12. CONCLUSIONES
13. RECOMENDACIONES
14. REFERENCIAS BIBLIOGRAFICAS Y/O ENLACES WEB
15. BIBLIOGRAFIA
16. APENDICES Y ANEXOS

FORMATO DE ESPECIFICACION DE LOS CASOS DE USO DE REQUERIMIENTOS
FORMATO DE RECOPILACION DE LA INFORMACION (ENTREVISTAS,
CUESTIONARIOS, ETC)
COPIAS DE LA DOCUMENTOS FUENTES ENCONTRADOS.
OTROS
Nota:
La diferencia entre Apndices y Anexos, es que en el primero se considera todo el material
construido por los autores del informe, mientras que en anexos aquel material que ha sido
capturado por los autores del informe y ha sido de utilidad para la elaboracin del proyecto

Modulo de Analisis y Diseño de Sistemas

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Modulo de Analisis y Diseño de Sistemas

Загружено:

Авторское право:

Доступные форматы

2016

Anlisis y Diseo de Sistemas

Objetivos bsicos dentro de la organizacin

Anlisis y diseo de sistemas

Se refiere al proceso de examinar la situacin de una empresa con el propsito de

Anlisis.- Proceso de clasificacin e interpretacin de hechos, diagnosticando

Analista y diseador de sistemas.

Las actividades principales del analista de sistemas son tres:

Anlisis de sistemas. Se rene informacin y se determinan los requisitos.

Elementos de un sistema de informacin.

Software.- Programas de computadoras, estructuras de datos y documentacin

Bases de datos.- Coleccin grande y organizada de informacin a la que se

Caractersticas de los sistemas de informacin.

Los sistemas de informacin cuentan con muchas y muy variables caractersticas

Ahorro significativo de mano de obra.

Clasificacin de los sistemas de informacin.

Abiertos.- Intercambian informacin, materiales y energa con su ambiente.

Automatizan tareas operativas

Ejemplos: Sistema de facturacin, Sistema de matriculas, sistemas contables.

Sistemas de Apoyo a las decisiones

Suelen implantarse despus de los sistemas transaccionales.

Ejemplos: Simulacin de negocios, proyecciones financieras, etc

Herramienta para soportar funciones operativas. La finalidad de un Sistema de

Proporcionan informacin para apoyar la toma de decisiones.

El Lenguaje Unificado de Modelado

El Tringulo de Desarrollo de Software

Notacin Herramienta Visual

El Lenguaje Unificado de Modelado

= Unified Modeling Language

UML no es un mtodo sino un lenguaje de modelamiento

Objetivo del UML

UML toma lo mejor de varios mtodos

Caractersticas del UML

Proporciona a los desarrolladores un lenguaje de modelamiento ampliamente

Por qu aprender UML

Breve historia del UML

. . . La Guerra de los Mtodos

Existan muchos mtodos y cada uno tena un lenguaje de

El desarrollo del UML comenz en finales de 1994 en que Grady Booch

y Jim Rumbaugh de Rational Software Corporation, comenzaron su trabajo sobre la

A finales de 1995, Ivar Jacobson y su compaa de Objectory se unieron a Rational y

Booch, Rumbaugh, y Jacobson, definieron el UML 0,9 y 0,91 en junio y octubre de

Versiones del UML

Un modelo es una descripcin completa de un sistema desde una perspectiva concreta

Modelando con UML

State Use Case

La Crisis del Software

Ud. ser capaz de:

En marzo de 1989, Arthur Andersen report ms de $300 mil millones al ao son

Cules son las razones para la crisis del software?

Los requerimientos del negocio son ciclos de desarrollo ms cortos

Fallas en el Manejo de Riesgos

EL ciclo de vida de cascada retrasa la identificacin de problemas

La demanda del software de negocios se est incrementando

Fortalezas de la Tecnologa de Objetos

Desarrollo Iterativo e Incremental

Qu es un Desarrollo Iterativo e Incremental?

El desarrollo iterativo e incremental es el proceso de construir el sistema en

El Ciclo de Vida del Software

Inicion Elaboracin Construccin Transicin

Un modelo del comportamiento del sistema, incluyendo el

Una iteracin es un ciclo de desarrollo que termina en la entrega de un

Definir la iteracin para

Revisin del Eliminacin