Está en la página 1de 69

Análisis y Diseño de Siste

INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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.

Page 1 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

Bases de datos.-
accede mediante Colección grande y organizada de información a la que se el
sistema. software siendo parte integral del funcionamiento del
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.

Page 2 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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.

Page 3 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

El Lenguaje Unificado de Modelado

El Triángulo de Desarrollo de Software

Proceso

Notación Herramienta Visual

Page 4 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Page 5 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Page 6 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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)

<<document>>
1999
UML 1.3
(revisión menor
públicamente disponible)
<<document>>
2000
UML 1.4
(planificada una revisión menor)

2001 <<document>>
(planificada una revisión menor) UML 1.5

2002 <<document>>
(planificada una revisión mayor) UML 2.0

Page 7 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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 Diagrama de
Vista de
implementación Secuencia Diagrama de
Vista de
requerimientos Colaboración Diagrama de
Vista de Estado Diagrama de
despliegue
Actividad Diagrama de

Componentes Diagrama de
Vista de
procesos Despliegue

Modelando con UML

Diagramas de
Casos de Uso Diagramas de
Diagramas de Clases
Diagramas de
Despliegue Objetos

Diagramas de Diagramas de
Componentes Secuencia
Modelo

Diagramas de Diagramas de
Diagramas de
Actividad Colaboración
Estados

Page 8 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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
 de reserva de pasajes con el sistema de reservaciones de Marriott, Hilton y
software
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

Page 9 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Page 10 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

Desarrollo Iterativo e Incremental


¿Qué es un Desarrollo Iterativo e Incremental?


 e incremental es el proceso de construir el sistema en
El desarrollo iterativo
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ón Construcción Transición

tiempo

Fase de Inicio 
 
Propósito

  un nuevo sistema o para la puesta
Eestablecer el caso de negocio para
 
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

Page 11 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

 
Productos

Un modelo del comportamiento del sistema, incluyendo el
  escenarios y modelos del dominio
contexto del sistema,
(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
 está listo para introducirse en la comunidad de
programa) que
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?


  que termina en la entrega de un
Una iteración es un ciclo de desarrollo
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

Page 12 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

  un número pequeño de escenarios que contengan los mayores
Seleccionar
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

Page 13 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

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

Page 14 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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
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

Page 15 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

2. Relación <<include>>

El caso de uso A siempre incluye (o usa) el comportamiento de B.


Registrar
<<include>>
matrícula
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.

Registrar matrícula
<<extend>>
Registrar matrícula
Extemporánea

Ejemplo de Diagrama de Casos de Uso

Registrar matrícula
extemporánea
<<extend>>

Registrar matrícula
Usuario
<<include>>

<<comunicates>>
Validar usuario

<<include>> Secretaria
Aperturar cursos
<<comunicates>>
Director de
Escuela

Page 16 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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>>

Page 17 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

¿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

el sistema, su ambiente, y la relación entre el sistema
Ellos describen
y su ambiente

Conceptos importantes al modelar el caso de uso


 cosa que
Un actor representa cualquier
 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

Page de of 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

Actores


Los actores no son parte del sistema, ellos
 representan 
roles que un usuario del sistema puede
desempeñar

activamente la
 Un actor puede intercambiar
información con el sistema
Acto 
 Un  ser un recipiente pasivo de la
actor puede
información

 a un humano, una
Un actor puede representar
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
Jose actúa 3
como un 4 5
actor 6

Oscar actúa
como un
actor

Modelo de Caso de uso

Actor Caso de uso

Page 19 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

Un usuario puede actuar como varios actores

Insert
Jose como
1 2 operador
3
4 5
6

Jose Operado
Jose como
cliente
Client

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 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
 todas las formas posibles de utilizar el
constituyen
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?

Page 20 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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:
La Clase Automóvil
Atributo1 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

Page 21 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Page 22 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Computador Monitor
a
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 Extremidade


s

Page 23 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

Ejemplo Diagrama de Clases

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

Page 24 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

Diagrama de Clases

Page 25 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Page 26 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Page 27 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

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

Page 28 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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.

Page 29 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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?

Page 30 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

DIAGRAMA DE CASOS DE USO DE NEGOCIO

Partici pante Entregar Materiales

Proveedor Recepcionar Materiales

Coordinador Controlar 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 M ateri al


(from Business Use-Case Model) Abastecimiento
Verifica

Registra

Entrega

Page 31 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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.

Page 32 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

M O D E L O D E D O M IN IO

P a rti c i p a n te
(from Business Object M od... R ec e pc io n
(fr om Busi ness Object Mod.. .

E n tre g a M a te ri a l O rd e n C o 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 ejecución

A continuación se describe el funcionamiento del Caso de Uso de Negocio Entregar


Materiales:

DA: ENTREGAR MATERIALES

Solicitar
Material

Verif icar
Participante

no

si
Verif icar
Entrega

no

si
Verif icar Stock

no

si

Registrar
Entrega

Actualizar Stock
de Materiales

Page 33 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

____________________________________________________________________________

____________________________________________________________________________

____________________________________________________________________________

Page 34 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

Crear Cliente

Usuario Actualizar Cliente


Usuario Modificar Cliente

Eliminar Cliente

____________________________________________________________________________

____________________________________________________________________________

____________________________________________________________________________

Verificar Datos Cliente

<<include>>
<<include>>

Usuario Ingresar Datos del Cliente

Guardar Datos del Cliente

____________________________________________________________________________

____________________________________________________________________________

____________________________________________________________________________

Page 35 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Page 36 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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.

Page 37 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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 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.

Page 38 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Page 39 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Page 40 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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.

Page 41 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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.

Page 42 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Page 43 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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


  de instancias de una clase que se relacionan con una
Multiplicidad es el número
instancia de otra clase

  decisiones de multiplicidad por hacer: una para
Para cada asociación, hay dos
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

Page 44 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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?

 máximo o mínimo de instancias que pueden ser ligadas
¿Cuál es el número
a una instancia?

Curso Maestro
0..* 1

¿Qué le dice este

Page 45 of 69
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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”
  (potencialmente) muchas relaciones a muchos objetos de
porque existen
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

Page 46 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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



 de un objeto es una de las posibles condiciones en que el objeto puede
El estado
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

Page 47 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

a+b=
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=

Asignar profesor
(Retorna:confirmación)
Registro del
Sistema Curso Algebra 101

Un Objeto tiene Identidad


 tiene una identidad única, incluso si su estado es idéntico al de otro
Cada objeto
objeto

Profesor “J Clark” Profesor “J Clark” Profesor “J Clark”


enseña Algebra enseña Algebra enseña Algebra

¿Qué son las Clases?

Page 48 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

 

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
  entre objetos (asociaciones y agregados) y una
manera de relacionarse
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
a+b=
Días ofrecidos Entregar una lista del
Créditos curso
Hora de inicio
Hora de

Clases y Objetos
¿Cuántas clases ve?

Page 49 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Profesor

Encontrando Clases
  
Una clase debe capturar una y solo una abstracción clave

  la información del estudiante y el
Mala abstracción: La clase estudiante que conoce
programa del semestre actual del estudiante

 Clases separadas. Una para el estudiante y otra programas
Buena abstracción:
del estudiante

Algebra 101
Historia Arte
Química

Asignando Nombre a una Clase



 la clase debe ser el sustantivo singular que mejor caracterice la
El nombre de
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

Page 50 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO


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


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 << >>

Page 51 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

Clase Frontera


 la comunicación entre el entorno del sistema y su
Una clase frontera modela
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

  de Cursos” , la información debe ser enviada al
En el escenario del “Registro
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

Page 52 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

<<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

 
Enelescenariodel“RegistrodeCursos”,laclase
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

Page 53 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

Diagrama de Clases de Analisis

<<entity >>
Herramienta Desarrollo

1
<<entity >>
<<entity >>
Feria
Recepcion 1..n 1..n

1..n

<<entity >> 1..n


1 Proyecto

<<entity >> 1..n


Semestre
1
1
1..n <<entity >>
Grupo
1..n
1..n

<<entity >>
<<entity >> 1..n <<entity >> 1 1..n Alumno
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

Page 54 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Page 55 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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.

Page 56 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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:

Page 57 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Page 58 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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.

Page 59 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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
fecha : Date 1 1..* estado : String

Maquinaria 1 1
1..*
codigo : String
Tipo proceso
descripcion : String 1 1..*
1..* codigo : String
Detalle orden produccion tipo : String
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:

Page 60 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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
descripcion : String
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

Page 61 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Page 62 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Page 63 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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
0..*
1

1..*

Nivel
descripcion : String

1..*

Clinica
Servicio
nombre : String
nombre : String
direccion : String descripcion : String
telefono : String
fax : String 0..* 1..*
precio : Double

Personal
codigo : String
nombres : String
apellidos : String
direccion : String
turno : String

1..*
Orden produccion Avance
nro_orden : String
codigo : String
hora : Date
fecha : Date 1 1..* estado : String

1
Maquinaria 1
1..*
codigo : String
Tipo proceso
descripcion : String 1 1..* 1..* codigo : String
Detalle orden produccion tipo : String
dodigo_equipo : String
codigo_ingred : String
nro_orden : String

1..*
Ingredientes
codigo : String
descripcion : String
fecha adquisición : Date 1
fecha vencimiento : Date

Page 64 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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.

Page 65 de 68
I
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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.

Page 66 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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 20xx
MODELO FISICO DE LA BASE DE DATOS RELACIONAL (SQL SERVER)
MODELO FISICO DE LA BASE DE DATOS RELACIONAL (NORMALIZADO)

12. CONCLUSIONES

Page 67 de 68
INSTITUTO DE EXCELENCIA
CARLOS SALAZAR ROMERO

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

Page 68 de 68

También podría gustarte