Analisis y Diseño

IESTP “Carlos Salazar Romero”
2016
Análisis y Diseño de Sistemas
CURSO
ANALISIS Y DISEÑO DE SISTEMAS
SEMESTRE
III
CREADO POR
ING. OSCAR ASCON VALDIVIA
ADAPTADO POR
ING. EDWIN MANTILLA GUEVARA
Sistemas de Información
Definición de Sistema de Información
Es un conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades
de una empresa o negocio.
Objetivos básicos dentro de la organización

• Automatizar los procesos operativos
• Apoyar al proceso de toma de decisión
• Lograr ventajas competitivas a través de su implantación y uso
Análisis y diseño de sistemas
Se refiere al proceso de examinar la situación de una empresa con el propósito de

mejorarla con métodos o procedimientos más adecuados. Tiene dos componentes:
 Análisis.- Proceso de clasificación e interpretación de hechos, diagnosticando

problemas y empleando la información que se tiene para recomendar mejoras,
especificando lo que el sistema debe hacer.
 Diseño.- Se especifican las características del producto terminado y se establece
como alcanzar el objetivo.
Analista y diseñador de sistemas.
Estudia la situación de una empresa u organización con el fin de observar cómo 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:
 Análisis de sistemas. Se reúne información y se determinan los requisitos.

 Análisis y diseño del sistema. El analista diseña el nuevo sistema o aplicación
que deberá implementarse.
 Análisis, diseño y programación del sistema. Desarrollo de las
especificaciones y escribir el software necesario para implementar el diseño.
Elementos de un sistema de información.
 Software.- Programas de computadoras, estructuras de datos y documentación

asociada que sirve para realizar el método lógico.
 Hardware.- Dispositivos electrónicos que proporcionan la capacidad de
computación y las funciones del mundo exterior.
 Gente.- individuos, usuarios u operadores del software y el hardware.
 Bases de datos.- Colección grande y organizada de información a la que se
accede mediante el software siendo parte integral del funcionamiento del
sistema.
 Documentación.- Manuales impresos y demás información descriptiva que

explique el funcionamiento del sistema.
 Procesamientos.- Pasos que define el uso específico 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
Características de los sistemas de información.
Los sistemas de información cuentan con muchas y muy variables características

algunas de las más sobresalientes son:
 Ahorro significativo de mano de obra.

 Intensivos en entradas y salidas de información.
 Cálculos de procesos simples y poco sofisticados.
 Gran manejo de datos para realizar operaciones.
 Generan grandes volúmenes de información.
 Son recolectores de información.
Clasificación de los sistemas de información.
 Abiertos.- Intercambian información, materiales y energía con su ambiente.

 Cerrados.- Son auto contenido y no interactúan con el medio ambiente.
 Probabilístico.- No conoce con certeza su comportamiento.
 Determinístico.- Cualquier estado futuro que adopten puede determinarse con
anticipación.
Tipos
• Sistemas transaccionales
• sistema de apoyo a las decisiones
• Sistemas estratégicos
Sistemas Transaccionales
• Automatizan tareas operativas

• primer tipo de SI que se implantan
• Muestran una intensa entrada y salida de información
• Son fáciles de justificar
• Son adaptables a paquetes de aplicación
Ejemplos: Sistema de facturación, Sistema de matriculas, sistemas contables.

Sistemas de Apoyo a las decisiones
Suelen implantarse después de los sistemas transaccionales.

Genera información de apoyo a los mandos intermedios
Suelen ser intensivos en cálculos
Son sistemas interactivos y amigables
Ejemplos: Simulación de negocios, proyecciones financieras, etc
Sistemas Estratégicos
Suelen desarrollarse dentro de la organización
Su evolución es dentro de la organización
Su función es lograr ventajas frente a los competidores
Los sistemas no son eternos
Apoyan el proceso de innovación de productos y procesos dentro de la empresa
Ejemplos: Sistemas de información que proporcione situaciones de créditos, etc.
SISTEMAS GERENCIALES
Herramienta para soportar funciones operativas. La finalidad de un Sistema de

Información Gerencial es la de suministrar a los gerentes la información adecuada en el
momento oportuno. Por lo tanto el valor de la información proporcionada por el sistema
debe cumplir con los siguientes cuatro supuestos básicos, estos son: Calidad,
Oportunidad, Cantidad y Relevancia. Sus principales características son:
 Proporcionan información para apoyar la toma de decisiones.

 No pueden adaptarse fácilmente a paquetes disponibles en el mercado.
 Típicamente su forma de desarrollo es a base de incrementos y a través de su
evolución dentro de la organización.
 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 estratégicos son creados de barreras de entrada al negocio.
 Apoyan los procesos de innovación 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 Triángulo de Desarrollo de Software
Proceso
Notación Herramienta Visual
El Lenguaje Unificado de Modelado

Definición:
El UML es un lenguaje gráfico para la especificación, visualización, construcción y
documentación de modelos orientados a objetos que representan sistemas intensivos en

software.
= Unified Modeling Language
UML no es un método sino un lenguaje de

modelamiento
Objetivo del UML

Describir cualquier tipo de sistema en términos de diagramas orientados a objetos
Algunas categorías de Sistemas
 Sistemas de Información
 Sistemas de Tiempo Real
 Sistemas de Conocimiento
 Sistemas Distribuidos
 Sistemas de Negocios
UML toma lo mejor de varios métodos
Rumbaugh
Booch Jacobson
Odell
Meyer
Clasificación
Pre y Post condiciones
Shlaer-Mellor
Ciclo de vida de objetos Harel
Máquinas de estado
Gamma et. al.
Marcos de trabajo,
patrones, notas Embly
Wirfs-Brock
Singleton clases Fusion Responsabilidades
Descripción de operaciones,
numeración de mensajes
Características del UML

 Proporciona a los desarrolladores un lenguaje de modelamiento ampliamente
aceptado y listo para usar.
 Integra las mejores prácticas del desarrollo de software.

 Permite el intercambio de modelos entre las diferentes herramientas de software.
Es independiente del lenguaje de programación y de métodos y procesos
particulares de desarrollo de software.
 Proporciona sus propios mecanismos de extensión
 Agrupa los conceptos de orientación a objetos definiendo su significado.
Por qué aprender UML

- Porque UML es el lenguaje de modelado de objetos estándar dominante.
- Porque es apoyado por metodólogos y empresas importantes en Tecnologías de
Información.
- Porque cuenta con la aprobación de la OMG como notación estándar.
- Porque todas las herramientas modernas proporcionan soporte para UML.
- Porque nos facilita el aprendizaje del enfoque orientado a objetos pues basta
con aprender este estándar y no perdernos en toda la jungla de métodos y
notaciones existentes.
Breve historia del UML

 Los lenguajes de modelado orientados al objeto comenzaron a aparecer a
mediados de la década de '70.
 El número de lenguajes que modelaban objetos aumentó de menos de 10 a más
de 50 durante el período entre 1989-1994.
 Muchos de los que utilizaban estos lenguajes no encontraban satisfacción
completa en ninguno de ellos, esto motivó la llamada "Guerra de los
Métodos".
. . . La “Guerra de los Métodos”
Existían muchos métodos y cada uno tenía un lenguaje de

modelado propio.
Esto dificultó el aprendizaje, aplicación, construcción, uso de

herramientas, etc.
Pugna entre los distintos gurús que defendían sus propios

métodos y simbologías.
Se observa la necesidad de una notación estándar

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
unificación de los métodos de Booch y de OMT (Object Modeling Technique).
A finales de 1995, Ivar Jacobson y su compañía de Objectory se unieron a Rational y

combinaron sus métodos.
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
(revisión editorial sin UML 1.2 especificación
cambios significativos)
1999 <<document>>
(revisión menor UML 1.3
públicamente disponible)
2000 <<document>>
(planificada una revisión menor) UML 1.4
2001
<<document>>
(planificada una revisión menor)
UML 1.5
2002
(planificada una revisión mayor) <<document>>
UML 2.0
Vistas de un modelo
“Un modelo es una descripción completa de un sistema desde una perspectiva concreta”
Vista Diagrama de Casos de Uso

lógica
Diagrama de Clases
Diagrama de Objetos
Vista de
implementación Diagrama de Secuencia
Diagrama de Colaboración
Vista de Vista de Diagrama de Estado
requerimientos despliegue
Diagrama de Actividad
Diagrama de Componentes
Vista de
Diagrama de Despliegue
procesos
Modelando con UML
Diagramas de
Casos de Uso Diagramas de
Diagramas de Clases
Despliegue Diagramas de
Objetos
Diagramas de Diagramas de
Componentes Modelo Secuencia
Diagramas de Diagramas de Diagramas de

Actividad Estados Colaboración
La Crisis del Software
 Ud. será capaz de:

 Explicar la crisis del software
 Discutir las fortalezas de la tecnología de objetos
 Discutir dónde la tecnología OO puede ser usada
 Definir análisis y diseño
Ejemplos
 El departamento de vehículos motorizados de California gastó más de $43 millones
de dólares en un proyecto destinado a fusionar los sistemas de conductores y
registro de vehículos
 El sistema fue abandonado sin ni siquiera haber sido usado
 Un fallido esfuerzo de $165 millones de dólares 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 dólares 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ó más de $300 mil millones al

año son gastados en actividades de software comercial en los Estados Unidos
 Sólo el 8% resulta en software que es distribuido y funciona
¿Cuáles 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 más cortos

 Los usuarios esperan más en términos de flexibilidad
 Los requerimientos iniciales usualmente están mal definidos
Fallas en el Manejo de Riesgos
 EL ciclo de vida de cascada retrasa la identificación de problemas

 No hay pruebas de que el sistema funcionará hasta que está cerca de ser
terminado
 El resultado es de máximo 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 están
Fortalezas de la Tecnología de Objetos
 Un solo paradigma
 Un solo lenguaje usado por los usuarios, analistas, diseñadores e
implementadores
 Facilidad para elaborar la arquitectura y lograr el reutilización de código
 Los modelos reflejan mejor el mundo real
 Mayor precisión describiendo datos corporativos y procesos
 Descomposición basada en divisiones naturales
 Fácil de entender y mantener
 Estabilidad
 Un pequeño 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 pequeños pasos
 Beneficios
 Reducción 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 generación de un producto
(Ejecutable)
 Cada ciclo es una sucesión de fases
 Inicio
 Elaboración
 Construcción
 Transición
Inicio Elaboració Construcció Transició

n n n
tiemp
o
Fase de Inicio
 Propósito
 Eestablecer el caso de negocio para un nuevo sistema o para la
puesta al día de un sistema ya existente
 Artefactos desarrollados
 El núcleo de lo solicitado para el proyecto
 Una asesoría de riesgo inicial
 Artefactos opcionales:
 Un prototipo conceptual
 Un modelo inicial de dominio (10% - 20% completo)
Fase de Elaboración
 Propósito
 Analizar el dominio del problema
 Establecer una arquitectura sólida
 Abordar el elemento más riesgoso del proyecto
 Desarrollar un plan integral para mostrar cómo 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 visión de la línea base del producto a partir del modelo del
dominio
 Una evaluación del riesgo
 Un plan de desarrollo
 Criterios de evaluación
 Un manual preliminar para el usuario (opcional)
 Estrategias de pruebas
 Plan de pruebas

Fase de Construcción
 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
 Documentación del usuario y del sistema
 Plan de despliegue
 Criterios de evaluación para al menos la siguiente iteración
Fase de Transición
 Propósito
 Implantar el software en su entorno de operación
 Productos
 Una secuencia de ejecutables.
 Resultados de calidad asegurados
 Documentación del usuario y del sistema actualizada
 Análisis del rendimiento del proyecto “Postmortem”
¿Qué es una Iteración?
 Una iteración es un ciclo de desarrollo que termina en la entrega de un

subconjunto de productos finales
 Cada iteración pasa por todos los aspectos de desarrollo del programa
 Análisis de Requerimientos
 Diseño e Implementación
 Prueba
 Documentación
 Cada entrega iterativa es una “pieza” totalmente documentada del
sistema final
Reducción de Riesgo a través de Iteraciones
Definir la iteración para

Riesgo inicial consignar el mayor riesgo
Campo de acción inicial
Planificar y desarrollar la
del proyecto
iteración
Iteración N
Estimar la iteración
Revisión del plan Eliminación

del proyecto del riesgo
Revisión de la Evaluación de riesgo
Proceso de Planificación de una Iteración
 Identificar y priorizar los riesgos del proyecto

 Seleccionar un número pequeño de escenarios que contengan los
mayores riesgos
 Los escenarios seleccionados son usados por:
 Los desarrolladores para identificar lo que será implementado
para la iteración
 Los probadores para desarrollar el plan de pruebas y el
procedimiento de prueba para la iteración
 Al final de la iteración
 Determinar qué riesgo ha sido reducido o eliminado
 Determinar si algún nuevo riesgo ha sido descubierto
• Poner al día el plan para las iteraciones restantes
Proceso Unificado Racional (RUP)
DIAGRAMAS UML
1. Diagramas de Casos de Uso

Definición
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
Nombre del Caso de Uso

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.
Actor
Un actor es un conjunto externo uniforme de personas, sistemas, o cosas
que solicita un servicio al sistema que estamos modelando.
Relaciones entre los elementos
Relaciones entre actores

La única relación permitida entre los actores es la Relación de Generalización.
Director de Usuario
Escuela (Sist. Matrícula)
Relaciones entre un actor y un caso de uso
La única relación permitida es una Asociación y se le conoce como Relación de
Comunicación o <<comunicates>>.
<<comunicates>> Registra
Matrícula
Secretaria
Relaciones entre casos de uso

Pueden ser de tres tipos:
1. Relación de generalización
El Caso de Uso de A hereda la especificación del Caso de Uso B.
Cobranza en
efectivo
Realizar
cobranza
Cobranza
con tarjeta
Cobranza
con cheque
2. Relación <<include>>
El caso de uso A siempre incluye (o usa) el comportamiento de B.
Registrar matrícula <<include>>
Validar usuario
Aperturar cursos <<include>>
3. Relación <<extend>>
El caso de uso A, extiende al caso de uso B. A ocurre en casos especiales para extender
B.
Ejemplo de Diagrama de Casos de Uso
Registrar matrícula
extemporánea
<<extend>>
Usuario Registrar matrícula

<<include>>
<<comunicates>>
Validar usuario
<<include>>
Secretaria
Aperturar cursos
<<comunicates>>
Director de
Escuela
<<extend>> Registrar matrícula
Registrar matrícula
Extemporánea
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 estándar
<<include>>
Elaborar Res.BenPenit Calcular Tiempo de CarceleriaSuspender Internamiento

Procesado Sentenciado
<<extend>>
¿Qué es el comportamiento del sistema?
 El comportamiento de un sistema es cómo un sistema actúa 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 relación entre el
sistema y su ambiente
Conceptos importantes al modelar el caso de uso
 Un actor representa cualquier cosa que

interactúe 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 análisis de requisitos,
diseño 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 comprensión mutua de los requisitos
 Es usado para identificar
 Quién 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
desempeñar
 Un actor puede intercambiar activamente la
información con el sistema
Acto  Un actor puede ser un recipiente pasivo de la
r información
 Un actor puede representar a un humano, una
máquina u otro sistema
Encontrando Actores: Preguntas Útiles
 ¿Quién está interesado en cierto requisito?

 ¿Dónde en la organización se utilizará el sistema?
 ¿Quién proveerá, utilizará y eliminará esta información del sistema?
 ¿Quién utilizará esta función?
 ¿Quién le dará soporte y mantenimiento al sistema?
 ¿Usa el sistema un recurso externo?
 ¿Qué actores necesita el caso de uso?
 ¿Un actor desempeña varios roles?
 ¿Varios agentes desempeñan el mismo rol?
Instancias de Actores
Insert card
1 2 3
Jose actúa 4 5 6
como un 7 8 9
* 0 #
actor
Oscar actúa
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 diálogo entre los

actores y el sistema
 Un caso de uso puede ser iniciado por un actor
para invocar una cierta funcionalidad en el
Caso de Uso sistema
 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
 ¿Cuáles son las tareas de este actor?

 ¿El actor, creará, guardará, cambiará, eliminará o leerá la información en
el sistema?
 ¿Cuál caso de uso creará, guardará, cambiará, eliminará o leerá esta
información?
 ¿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?
 ¿Cuáles casos de uso le darán soporte y mantenimiento al sistema?
 ¿Pueden todos los requerimientos funcionales ser realizados por los
casos de uso?
2. Diagramas de Clases
Definición
Un Diagrama de Clases muestra Clases (grupos de objetos que tienen las mismas
características y comportamiento) y sus relaciones.
Estos diagramas son los más comunes en el modelado de sistemas orientados a objetos.
Un diagrama de clases esta compuesto por:
- Clases
- Relaciones entre clases
Clases
Definición:
Es un conjunto de objetos que tienen los mismos atributos y comportamiento.
Representación:
Se representa mediante un rectángulo con tres partes:
NombreClase Automovil
Ejemplo:
Atributo1 La Clase Automóvil Matricula
Atributo2 Color
... Velocidad
Operacion1 Arrancar( )
operacion2 Acelerar( )
... Frenar( )
Relaciones entre Clases
1.- Relación de Dependencia
2.- Relación de Generalización
3.- Relación de Asociación
3.1.- Asociación de Agregación
3.2.- Asociación de Composición
1.- Relación de dependencia

Es una relación semántica entre dos elementos en la cual un cambio en un elemento (el
elemento independiente) puede afectar a la semántica del otro elemento (elemento
dependiente).
Video Televisión
... Canal ...
... ...
Grabar(c : canal) cambiar(c : canal)
2.- Relación de generalización

Es una relación 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).
Vehículo
Terrestre Aéreo
camión auto avión helicóptero
3.- Relación de asociación
Es una relación estructural que describe un conjunto de enlaces o conexiones entre dos o
más objetos. Esta relación entre clases permite asociar objetos que colaboran entre si.
Acta Alumno
0..* 1..*
3.1.- Asociación de Agregación
Es un tipo especial de asociación 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 relación todo - parte.
Teclado
Red
CPU
Computadora Monitor
WAN LAN Mouse
HUB Hard
Disk
3.2.- Asociación de Composición
Es un tipo de asociación, en donde el tiempo de vida del objeto incluido está

condicionado por el tiempo de vida del que lo incluye. El objeto incluido sólo existe
mientras exista el objeto base. El objeto se construye a partir de los objetos incluidos
pero no podría existir si ellos.
Ejemplo: El Hombre esta formado por cabeza, tronco y extremidades
Hombre
Cabeza Tronco Extremidades
Ejemplo Diagrama de
Clases
Cliente
Venta
Codigo
1..* Codigo
Nombre
Fecha
Apellido
1 Observaciones
Direccion
3. Diagramas de Objetos
Definición
Un Diagrama de Objetos muestra una instancia prototípica 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
Codigo: FAC01
1..*
Nombre: Oscar
Fecha: 27/09/2007
Apellido:Ascón Valdivia
1 DIAGRAMA CEObservaciones:
CLASES DECancelo
DISEÑO
con $
Direccion: Nepeña
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
Diagrama de Clases
obs_per : String fec_ini : Date
fec_fin : Date
0..1
obs_fir : String
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: Gestión de la Biblioteca
Se trata de gestionar los préstamos 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.
 Petición de libros. Un usuario puede realizar una petición de uno o

más 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 préstamo (préstamo de sala,
docente, proyecto fin carrera) en función de los cuales el usuario
puede disponer de los ejemplares durante un período de tiempo
específico, como se indica en la siguiente tabla:
SALA El día de la petición.

DOCENTE Una semana
PROYECTO FIN CARRERA Quince días.
Una vez entregados el carnet y la ficha, el sistema comprobará y

aceptará la petición de los libros solicitados siempre que pueda
satisfacer la petición, es decir, cuado haya ejemplares disponibles. Si
se acepta la petición, se actualiza el número de unidades de los libros
de la biblioteca y se guarda la ficha de préstamo.
 Devoluciones de libros. Un usuario no puede realizar más peticiones

hasta que no haya efectuado todas las devoluciones de la petición
anterior. El usuario, para hacer la petición, necesita el carnet, que no
se le entrega hasta que no haya devuelto todos los libros. Sí puede
hacer una devolución parcial de los libros. Cuando un usuario realice
una devolución, el sistema actualizará el stock de libros y
comprobará la fecha de devolución de cada ejemplar. Los usuarios
que entregaron después de la fecha de entrega según el tipo de
préstamo, se les sancionara con la retención 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
Definición: 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 acción o simplemente Acción
- Transiciones
Elementos de un Diagrama de Actividad
Actividad.- Conjunto de acciones que buscar cumplir un objetivo. No son atómicos es

decir pueden descomponerse. Pueden ser interrumpidos y se consideran que toman
algún tiempo en completarse.
Acción.- Es una actividad que no se puede descomponer y permiten modelar un paso
dentro de un algoritmo. Se considera que su ejecución toma un tiempo insignificante.
Transiciones.- Es el paso de una actividad a otra, una transición ocurre al finalizar una
actividad.
Otros elementos
Decisión Barra de Sincronización Carriles Estados inicial y final
Ejemplo de Diagrama de Actividad

Muestre un proceso común 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 información, o en su defecto para plasmar la
información recopilada, describiendo en ella el funcionamiento del sistema actual en la
organización.
Características:
- Debe mostrar a las personas, maquinas o sistemas que interactuan en los procesos
del sistema actual.
- Reflejar la comunicación de los objetos anteriores describiendo el sentido y el
objetivo de la comunicación.
- Representar la información que se almacena o lee de un registro.
- Utilizar gráficos que faciliten la identificación de los objetos, así como estandarizar
su representación 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. Recepción
Materiales
Coordinador
del Evento
REGLAS DEL NEGOCIO:

Util para tener claras las políticas de la organización 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 mayoría se
convierten en las Reglas de Negocio.
Ejemplo.
Acción: Participante Solicita Material.

Interrogantes: ¿Cómo 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 mínimo, 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 perfección 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 interacción con el entorno (actores).
Actor: Representa cualquier cosa que interactúe con él sistema. Para encontrar
los actores de un sistema es útil plantearse las siguientes interrogantes:
- ¿Quién está interesado en cierto requisito?

- ¿Dónde en la organización se utilizará el sistema?
- ¿Quién proveerá, utilizará y eliminará esta información del sistema?
- ¿Quién utilizará esta función?
- ¿Quién le dará soporte y mantenimiento al sistema?
- ¿Usa el sistema un recurso externo?
- ¿Qué actores necesita el caso de uso?

- ¿Un actor desempeña varios roles?
- ¿Varios agentes desempeñan 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:
- ¿Cuáles son las tareas de este actor?

- ¿El actor, creará, guardará, cambiará, eliminará o leerá la información en el
sistema?
- ¿Cuál caso de uso creará, guardará, cambiará, eliminará o leerá esta
información?
- ¿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?
- ¿Cuáles casos de uso le darán soporte y mantenimiento al sistema?
- ¿Pueden todos los requerimientos funcionales ser realizados por los casos
de uso?
DIAGRAMA DE CASOS DE USO DE NEGOCIO
Partici pante Entregar M ateri al es
Proveedor Recepcionar M ateri al es
Coordi nador Control ar stock
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 construcción 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
Verifica
Participante
Verifica
Registra
Participante Asistente de Material

(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.
MODELO DE DOMINIO
Participante Recepcion
(from Business Object Mod... (from Business Object Mod...
Entrega Material OrdenCompra

(from Business Object Mod... (from Business Object Mod... (from Business 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 ejecución
A continuación se describe el funcionamiento del Caso de Uso de Negocio Entregar

Materiales:
DA: ENTREGAR MATERIALES
Solicitar
Material
Verif icar
Part icipante
no
si
Verif icar
Entrega
no
si
Verif icar Stock
no
si
Registrar
Entrega
Act ualizar Stock

de Materiales
Tipos de Requerimientos - Requisitos
Funcionales:
• Describen la funcionalidad o servicios que el sistema se espera provea.
• Indican como el sistema debería reaccionar a un ingreso en particular y como el
sistema debería comportarse en situaciones particulares.
No Funcionales:
• Son requerimientos que no están 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 más críticos 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 búsqueda 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 Especificación de Casos de Uso
Cliente
Registrar Pedido
Vendedor
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
Crear Cliente
Usuario Actualizar Cliente

Usuario Modificar Cliente
Eliminar Cliente
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
Verificar Datos Cliente
<<include>>
<<include>>
Usuario Ingresar Datos del Cliente
Guardar Datos del Cliente
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
B) MODELO DE REQUERIMIENTOS:
El Modelo de Requerimientos refleja el Compromiso que asumimos los desarrolladores en
la construcción del Sistema. Es importante que el referido modelo sea validado por el
cliente, de forma que queden establecidos los compromisos de construcción.
B.1. DIAGRAMA DE CASO DE USO DE REQUERIMIENTOS

Es el diagrama de Casos de Uso donde aparece el Compromiso de Construcción, debe
detallar los comportamientos a construir, así como las relaciones entre ellos.
Una forma fácil de construir un Diagrama de Requerimientos, es explotar los Casos de
Uso de Negocios, y transmitir en casos de uso mas pequeños 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 pequeños 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
acción manual; de otra parte también eliminare los casos de uso de verificación pues
asumió que son fáciles de predecir su existencia, sobretodo por estar detallado en los
Modelos de Objetos de Negocio. Obteniéndose el Diagrama de Casos de Uso de
Requerimientos que se muestra a continuación.
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 según necesidad, aplicar igual que en el Diagrama Mostrado en el
Modelo de Dominio.
Matriz de Priorizacion de Casos de Uso

Rendimie Frecuen Importan Urgenc Priorid

Nª Caso Uso nto cia cia ia ad
1 Registrar Entrega 5 min 12 v/dia vital Inmediata 1ª
2 Registrar Recepción 5 min 4 v/dia vital Inmediata 2ª
3 Registrar Materiales 5 min 3 v/dia vital Inmediata 3º
4 Estadística 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: Elaboración Propia
Requerimientos Funcionales
 Registrar Entrega.
 Registrar Recepción
 Registrar Materiales
 Estadística 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 Programación 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 máximo de 4 caracteres.
Especificación de Casos de Uso de Requerimientos
1 Registrar Entrega
CASO DE USO REGISTRAR ENTREGA

Descripción El Sistema deberá permitir al Asistente
registrar los materiales entregados a los
participantes.
Precondición
Secuencia Normal Paso Acción
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 transacción.
El participante deberá estar inscrito
Postcondición
Excepciones Paso Acción
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 / día
Importancia Vital
Urgencia Inmediatamente
Comentarios Sin comentarios adicionales
Tabla Nº: Especificación Registrar Proyecto

Fuente: Elaboración Propia
Caso Práctico
El presidente del club de fútbol 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 (Código,
DNI, Nombres, Apellidos, Fecha contrato, Fecha fin de contrato, club de
procedencia, país, etc.)
 El almacenamiento de la información 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 préstamo y a que club se los envía.
 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 técnicos y sus acompañantes (Código,
DNI, Nombres, Apellidos, Fecha contrato, Fecha fin de contrato, club de
procedencia, país, 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
Definición
Un Diagrama de Secuencia muestra la interacción de un conjunto de objetos, poniendo
énfasis en el orden cronológico del envío de mensajes entre objetos.
Un diagrama de secuencia esta compuesto por:
- Objetos (o actores)
- Línea de vida de un objeto
- Activación o foco de Control
- Mensajes
Objetos o actores
objeto:Clase
Son las entidades que participan en la interacción para lograr una funcionalidad, éstas
envían y o reciben mensajes.
Línea de vida de un objeto
objeto:Clase
Indica la vida de un objeto durante la interacción y se representa mediante una línea

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

operación.
Mensajes
objeto:Clase objeto:Clase
Son las invocaciones que envía un objeto a otro para que realice una tarea.
Tipos de mensajes
Mensaje Simple:
Se usa cuando no se conocen detalles del tipo de

comunicación o cuando no resulta relevante en
el diagrama.
Mensaje Síncrono:
El objeto que envía el mensaje espera a que el

objeto que lo recibe le termine la operación. El
mensaje síncrono más común es la llamada a
procedimientos.
Mensaje Asíncrono:
Cuando el objeto que envía 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 envía la orden a la computadora, la
cual a su vez se la envía al servidor de impresión 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 impresión, la cual en su momento le indicará al servidor de impresión
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 Colaboración
Definición: Un Diagrama de Colaboración muestra la interacción de un conjunto de
objetos, poniendo énfasis en la estructura organizacional de los objetos que envían y
reciben mensajes.
Un diagrama de colaboración esta compuesto por:
- Objetos
- Enlaces
- Flujo de Mensajes
Ejemplo de Diagrama de Colaboración

Una nota de pedido contiene un renglón por cada artículo, que se está despachando. Si
la cantidad del artículo que aún queda en almacén es menor que el punto de reorden,
está lanza una orden de compra del artículo, 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 Colaboración
Ambos diagramas muestran la interacción entre objetos, pero el Diagrama de Secuencia

reserva una dimensión para el tiempo haciendo más fácil observar el orden de ejecución
de los mensajes, mientras que el Diagrama de Colaboración los enumera. Ambos
diagramas representan lo mismo y puede transformarse de uno a otro sin pérdida de
información.
C. ANALISIS
 Diagramas de colaboración
 Diagramas de secuencia
 Diagrama de clases
 Diagrama de paquetes de análisis
Relaciones
Multiplicidad para Asociaciones
 Multiplicidad es el número de instancias de una clase que se relacionan

con una instancia de otra clase
 Para cada asociación, hay dos decisiones de multiplicidad por hacer: una
para cada final de la asociación
 Por ejemplo, en la conexión que existe entre las instancias que cumplen
el rol de maestro y curso
 Para cada instancia de persona, muchos (ej. cero o mas) cursos
serán enseñados
 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 algún curso?
 ¿Puede un curso tener dos maestros?
Maestro
Persona
Curso
1 1..*
¿Qué significa Multiplicidad?
 La multiplicidad responde a dos preguntas

 ¿La asociación es obligatoria u opcional?
 ¿Cuál es el número máximo o mínimo de instancias que pueden
ser ligadas a una instancia?
Curso Maestro
0..* 1
¿Qué
¿Quéleledice
diceeste
estediagrama?
diagrama?
Clase Asociación
 Deseamos llevar un historial de las calificaciones de todos los cursos que

el alumno ha tomado
 La relación entre “Alumno” y “Curso” es una relación 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 relación individual
Alumno-Curso
 Una clase asociación es usada para almacenar información sobre la
relación
Notación de la Clase Asociación
 Una clase asociación se representa usando el icono de clase

 La clase asociación se conecta con la asociación usando la línea
entrecortada
 La clase de asociación puede incluir múltiples propiedades de dicha
asociación
 Solamente una clase de asociación está permitida por cada asociación
Alumno 1..* Curso

3-10
Calificación
 Las Clases de Asociación son regularmente usadas en asociaciones del

tipo muchos a muchos
 Si la multiplicidad en cualquier extremo de la asociación es “muchos a
uno”
 Los atributos pueden ser situados dentro de una clase

 Una clase de Asociación aún puede ser usada
Objetos y Clases
¿Qué es un Objeto?
Informalmente, un objeto representa una entidad, física, conceptual o programa

 Entidad física
Camión
 Entidad conceptual
Proceso Químico
 Entidad programa
Lista Enlazada
Una Definición Formal
 Un objeto es un concepto, una abstracción o una cosa con límites bien

definidas y significado para una aplicación
 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, además 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 cómo éste actúa 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:confirmación)
Registro del
Sistema Curso Algebra 101
Un Objeto tiene Identidad
 Cada objeto tiene una identidad única, incluso si su estado es idéntico al

de otro objeto
Profesor “J Clark” Profesor “J Clark” Profesor “J Clark”

enseña Algebra enseña Algebra enseña Algebra
¿Qué son las Clases?
 Hay muchos objetos identificados para cada dominio

 Una clase es una descripción de un grupo de objetos con propiedades en

común (atributos), comportamiento similar (operaciones), la misma
manera de relacionarse entre objetos (asociaciones y agregados) y una
semántica en común
 Un objeto es una instancia de una clase
 Una clase es una abstracción en que:
 Se enfatizan las características relevantes
 Se suprimen otras características
 La abstracción nos ayuda a trabajar con cosas complejas
Ejemplo de una Clase
Clase
Curso
Estructura Comportamiento
Nombre Agregar un alumno
Ubicación Borrar un alumno
Días ofrecidos a+b= Entregar una lista del
10
Créditos curso
Hora de inicio Determinar si está lleno
Hora de
término
Clases y Objetos
¿Cuántas clases ve?
La Relación Entre Clases y Objetos

 Una clase es una definición abstracta de un objeto
 Define la estructura y el comportamiento compartidos por los
objetos
 Sirve como modelo para la creación 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 abstracción clave

 Mala abstracción: La clase estudiante que conoce la información del
estudiante y el programa del semestre actual del estudiante
 Buena abstracción: Clases separadas. Una para el estudiante y otra
programas del estudiante
Algebra 101
Historia Arte
Química
Español 101
Asignando Nombre a una Clase

 El nombre de la clase debe ser el sustantivo singular que mejor
caracterice la abstracción
 La dificultad al nombrar la clase revela una pobre definición de la
abstracción
 Los nombres deben provenir directamente del vocabulario del dominio
Guía de estilo en el nombramiento de clases
 Una guía de estilo debe dictar convenciones para el nombramiento de
clases
 Ejemplo de guía de estilo
 Las clases son nombradas usando sustantivos singulares
 Los nombres de las clases comienzan con letra mayúscula
 No se usa el subrayado
 Los nombres compuestos por múltiples palabras se ponen
juntos y la primera letra de cada palabra se escribe con
mayúscula
 Ejemplo: Estudiante, Profesor, SistemaDePago

Representando Clases
 Una clase es representada usando un compartimiento rectangular
a + b = 10
Profesor
Profesor Oscar
Compartimientos en la representación grafica de una clase

 Una clase está compuesta de tres secciones
 La primera sección contiene el nombre de la clase
 La segunda sección muestra la estructura (atributos)
 La tercera sección muestra el comportamiento (operaciones)
 La segunda y la tercera sección 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 semántica 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 comunicación entre el entorno del sistema

y su funcionamiento interno
 Clases interfaz típicas
 Windows (interfase del usuario)
 Protocolo de comunicación (interfase del sistema)
 Interfase de la impresora
 Sensores
 En el escenario del “Registrar Cursos a Tomar”, un Formulario programa
es creado para aceptar la información del usuario
<<Boundary>>
FormularioPrograma
Interfaces con Otros Sistemas

 Una clase frontera también es usada para modelar una interfaz a otro
sistema
 Las características importantes de este tipo de clases frontera son:
 La información que debe ser entregada al otro sistema
 El protocolo de comunicación usado para “hablarle” al otro
sistema
 En el escenario del “Registro de Cursos” , la información 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 información y asocia comportamientos que

generalmente son de larga duración (persistentes)
 Puede reflejar un fenómeno de la vida real
 También 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
 Catálogo
 ListaCursos
<<entity>> <<entity >>

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

Programa Catalogo
Clase Control
 Una clase control modela el comportamiento especifico de uno o más
casos de usos
 La clase control
 Crea, inicializa y borra objetos controlados
 Controla la secuencia o coordina la ejecución de los objetos
controlados
 Controla asuntos concurrentes para las clases controladas
 Es usualmente la implementación de un objeto intangible
 En el escenario del “Registro de Cursos”, la clase
AdministradorDeRegistro controla los procesos de registro
<<control>>
AdministradorDeRegistro
Diagrama de Colaboración
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 Práctico
El videoclub “MI VIDEOTEKA” quiere mecanizar los procesos, El funcionamiento que
requiere el videoclub es el siguiente:
Un cliente del videoclub realiza los alquileres señalando los ejemplares que desea
alquilar. Para ello debe comprar unos bonos que indican, por un lado, el crédito (o
número de alquileres), y por otro, el período 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 créditos.
Cada alquiler de un ejemplar relativo a una película consume un crédito sobre el tipo de
bono elegido por el cliente. Una vez que el sistema comprueba que el cliente dispone de
crédito 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 devolución, indicando

además el crédito disponible.
Los clientes realizan la devolución 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 sanción económica respecto a todos los
ejemplares entregados fuera de plazo, cargando un coste de F unidades monetarias por
ejemplar y día.
El sistema realiza pedidos de películas a los proveedores. Los datos de estos pedidos
vienen determinados por la dirección del videoclub a partir de la información
suministrada por los proveedores. Estos pedidos pueden ser sobre películas nuevas o
sobre aumento de ejemplares de películas existentes en el videoclub. Los proveedores
pueden satisfacer cada pedido en una o varias entregas. Cuando el sistema recoge las
entregas debe asignar un código a cada ejemplar, que además debe identificar a la
película.
La Empresa “MI VIDEOKA” cuentan en total con 20 tiendas distribuidas en todo el
norte del país (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 colaboración
5. Diagrama de Clases (Entity)
D. DISEÑO DE SISTEMAS
 Diseño de Interfaces
 Diagrama de Secuencia
 Diagrama de Clases
 Diagrama de Estados
CONSTRUCCION DE DIAGRAMAS DE SECUENCIA DE DISEÑO
Lo particular de la construcción de los diagramas de secuencia de diseño es que reflejan

el funcionamiento de la interfaz evaluando distintos escenarios. Eso quiere decir que
NO es cuestión de presionar F5 en el Rational Rose sobre los diagramas de
colaboración de Análisis, puesto que en la etapa de análisis estábamos expresando que

debe hacer el sistema y ahora en el Diseño deseamos expresar como funcionara el
sistema.
Debemos ser conciente en todo momento que la construcción de diagramas de secuencia
de diseño me permitirá refinar las interfaces puesto un diagrama de secuencia es tan
detallista que pareciera que estamos programando pero en papel.
Pautas para la Construcción de Diagramas de Secuencia de Diseño:

- 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 botón 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, deberás 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 acción 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 común) donde vaya como mensaje un
“objEntity” (Ejm: objPersona), de suceder que solo requiere el Control Class
verificar si la acción se logro con éxito enviar un mensaje de retorno
denominado varEntity (Ejm varPersona), acuérdate que en esta representación el
var significa que solo almacena un valor.
- Después debes evaluar en la interfaz que hacer en base a lo que te envía el
control Class por ejemplo si te envía un obj. con data podrías mostrarlo en la
interfaz, pero si llegara un obj. vació deberás 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 deberás 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 deberás 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"

DIAGRAMA DE CLASES
CLASES Y OBJETOS:
Clase: Es una descripción de un conjunto de objetos que comparten los mismos

atributos, operaciones, relaciones y semántica. Implementa una o más interfaces.
Se representa mediante un rectángulo con tres partes:
NombreClase Automovil
Ejemplo:
Atributo1 La Clase Automóvil Matricula
Atributo2 Color
... Velocidad
Operacion1 Arrancar( )
operacion2 Acelerar( )
... Frenar( )
Objeto: Instancia particular de una clase. Distinguible por sus características

específicas.
CLASE PERRO
define raza,
datos y color...
métodos
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 más comunes en el modelado de sistemas orientados a objetos.
Un diagrama de clases esta compuesto por:

- Clases
- Relaciones entre clases
RELACIONES ENTRE CLASES:
Una relación es una conexión entre elementos. En el modelado orientado a objetos hay
tres tipos de relaciones: dependencias, las generalizaciones, y las asociaciones.
 Relación de Dependencia
 Relación de Generalización
 Relación de Asociación
o Asociación de Agregación
o Asociación de Composición
CONSTRUCCIÓN DEL DIAGRAMA DE CLASES DE DISEÑO
La construcción del diagrama de clases de diseño 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 análisis
(entidades), interfaces y diagramas de secuencia de diseño.
Pautas para la Construcción del Diagrama de Clase de Diseño:

- Trasladar todas las clases entidad de los diagramas de secuencia de diseño.
- Guiándose 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 identificación de operaciones de las clases, deberán tomar uno por

uno los diagramas de secuencia de diseño tomar una clase entidad, bajar por su
línea de vida identificar los mensajes que le llegan y ver que clase control envía
el mensaje, el mensaje que invoca esa clase control seria una operación de la
clase entidad. De esta forma deberás proceder para identificar todas las
operaciones de las clases de tu diagrama de clases de diseño.
- Respecto a las relaciones puedes guiarte del diagrama de clases de análisis,
revisando y validando eso si cada relación.
- Finalmente debes tener en cuenta es que el diagrama de clases de diseño no debe
mostrar relaciones circulares (anillos), puesto que su existencia mermara el
rendimiento de la base de datos.
DIAGRAMA CLASE DISEÑO
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 adquisición : 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 ferretería y se tienen las

clases: Cliente, Persona Natural, Persona Jurídica, 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 solución a su problema:
1. Sabiendo que una organización dedicada a la venta de pasajes a la ciudad de

Lima desea almacenar información 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 organización 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.
Generación 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 diálogo 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 diálogo 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 diálogo 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 generación . 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 Finís
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 adquisición : 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 transición de estados.
2. Escoger la Opción 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 ubicación 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
Análisis.
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 acción o evento.
INCORPORANDO CONDICIONES:
1. Doble clic sobre la transición que se desea aplicar una condición.
2. Ubicarse en la Ficha: Detail.
3. Luego en Guard Condition digite la Condición a aplicar.
EJERCICIOS:
1. Se le ha requerido elaborar un Diagrama de Estado para la Clase Documento de

un Sistema de Compra y Venta; además 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
continuación se le muestra el diagrama de estado que da solución ha este caso,
constrúyalo 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 DISEÑO 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. DISEÑO
INTERFACES DE USUARIO
DIAGRAMAS DE SECUENCIA DE DISEÑO
DIAGRAMA DE CLASES DE DISEÑO
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 Apéndices 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 elaboración del proyecto

Analisis y Diseño

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Analisis y Diseño

Încărcat de

Drepturi de autor:

Formate disponibile

IESTP “Carlos Salazar Romero”

Análisis y Diseño de Sistemas

Objetivos básicos dentro de la organización

Análisis y diseño de sistemas

Se refiere al proceso de examinar la situación de una empresa con el propósito de

 Análisis.- Proceso de clasificación e interpretación de hechos, diagnosticando

Analista y diseñador de sistemas.

Las actividades principales del analista de sistemas son tres:

 Análisis de sistemas. Se reúne información y se determinan los requisitos.

Elementos de un sistema de información.

 Software.- Programas de computadoras, estructuras de datos y documentación

 Documentación.- Manuales impresos y demás información descriptiva que

Características de los sistemas de información.

Los sistemas de información cuentan con muchas y muy variables características

 Ahorro significativo de mano de obra.

Clasificación de los sistemas de información.

 Abiertos.- Intercambian información, materiales y energía con su ambiente.

• Automatizan tareas operativas

Ejemplos: Sistema de facturación, Sistema de matriculas, sistemas contables.

Suelen implantarse después de los sistemas transaccionales.

Son sistemas interactivos y amigables

Ejemplos: Simulación de negocios, proyecciones financieras, etc

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

 Proporcionan información para apoyar la toma de decisiones.

El Lenguaje Unificado de Modelado

El Triángulo de Desarrollo de Software

Notación Herramienta Visual

El Lenguaje Unificado de Modelado

documentación de modelos orientados a objetos que representan sistemas intensivos en

= Unified Modeling Language

UML no es un método sino un lenguaje de

Objetivo del UML

UML toma lo mejor de varios métodos

Características del UML

 Integra las mejores prácticas del desarrollo de software.

Por qué aprender UML

Breve historia del UML

. . . La “Guerra de los Métodos”

Existían muchos métodos y cada uno tenía un lenguaje de

Esto dificultó el aprendizaje, aplicación, construcción, uso de

Pugna entre los distintos gurús que defendían sus propios

Se observa la necesidad de una notación estándar

A finales de 1995, Ivar Jacobson y su compañía 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

Vista Diagrama de Casos de Uso

Modelando con UML

Diagramas de Diagramas de Diagramas de

La Crisis del Software

 Ud. será capaz de:

 En marzo de 1989, Arthur Andersen reportó más de $300 mil millones al

¿Cuáles son las razones para la crisis del software?

 Los requerimientos del negocio son ciclos de desarrollo más cortos

Fallas en el Manejo de Riesgos

 EL ciclo de vida de cascada retrasa la identificación de problemas

 La demanda del software de negocios se está incrementando

Fortalezas de la Tecnología de Objetos

Desarrollo Iterativo e Incremental

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

El Ciclo de Vida del Software

Inicio Elaboració Construcció Transició

¿Qué es una Iteración?

 Una iteración es un ciclo de desarrollo que termina en la entrega de un

Reducción de Riesgo a través de Iteraciones