UML

Universidad “San Pedro” Ingeniería de Software I
UNIVERSIDAD SAN PEDRO
FACULTAD DE INGENIERIA
ESCUELA PROFESIONAL DE INGENIERIA

INFORMATICA Y DE SISTEMAS
A S IG N A T U R A
INGENIERIA DE SOFTWARE I
Docentes: Ingº Oscar Ascón Valdivia
Chimbote 2010
Ing. Oscar Ascón Valdivia 1

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

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
Gamma et. al. estado
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
cambios significativos)
especificación
<<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

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
Vista de
Diagrama de Colaboración
requerimientos
Vista de Diagrama de Estado
despliegue
Diagrama de Actividad
Diagrama de Componentes
Vista de
procesos Diagrama de Despliegue
Modelando con UML
Use Case
Use Case
Diagrams
Diagramas de State
Diagrams State
Component Casos de Uso Diagrams
Diagramas de State
Component Diagrams State
Diagrams
Diagramas de Clases Diagrams
Diagramas de
Diagrams Diagrams
Despliegue Objetos
State Use Case

State Use Case
Diagrams
Diagramas de Diagrams
Diagramas de
Diagrams Diagrams
Componentes Secuencia
Modelo
Scenario
Scenario Scenario
Diagramas de Scenario Diagrams
Diagramas de
Diagrams
Diagramas de Diagrams
Actividad Diagrams Colaboración
Estados

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
Inicion Elaboración Construcción Transición
tiemp
o
Fase de Inicio
Propósito
Establecer 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 del
Planificar y desarrollar la
proyecto
iteración
Iteración
N Estimar la iteración
Revisión del Eliminación

plan del riesgo
del proyecto
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
Caso de Uso (Use Case)

Es una secuencia de acciones realizadas por el sistema que
producen un resultado observable y valioso para alguien en
Nombre del Caso de Uso
particular.
Nombre del Actor

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.
<<extend>>
extemporánea
Ejemplo de Diagrama de Casos de Uso
extemporánea
<<extend>>
Usuario
<<include>>
<<comunicates>>
Validar usuario
<<include>>
Secretaria
Aperturar cursos
<<comunicates>>
Director de
Escuela

Diagrama de Casos de Uso
Registrar Persona
Registrar Regla de Conducta Elaborar Informe de Firmantes
Magistrado
<<extend>>
Suspender Regla de Conducta

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

Reg.Firma Extemporanea Elaborar Informe de Reos en Carcel
Estadistica
Procesado y/o
Sentenciado
Registrar Firma
<<include>>
Reg.Firma 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
Ing. Oscar Ascón Valdivia Pág. 17

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
Jose actúa 3
como un 4 5
6
actor 7 8
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
1 2 operador
3
4 5
6
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 sistema
Caso de Uso Un caso de uso es un flujo de eventos completos y
significativos
Tomados al mismo tiempo, todos los casos de uso
constituyen todas las formas posibles de utilizar el
sistema
Encontrando Casos de Uso: Preguntas Útiles
¿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
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

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
1..* Codigo: FAC01
Nombre: Oscar
Fecha: 27/09/2007
Apellido:Ascón Valdivia
1 Observaciones: Cancelo con $
Direccion: Nepeña

Diagrama de Clases
DIAGRAMA CE CLASES DE DISEÑO
Delito
Per_Juridica id_del : Integer
id_pers : Integer des_delito : String
Per_Natural raz_social : String
num_doc : String Buscar()
id_pers : Integer Registrar()
rep_legal : String
ape_pat : String Modificar()
dni_replegal : String
ape_mat : String 1
dir_legal : String
nom_per : String
0..*
dir_per_nat : String
Mandatos
lug_nac : String
fec_nac : Date id_mand : Integer
id_tipmand : Integer Firmas
tip_doc : String
num_doc : String Persona id_invol : Integer id_fir : Integer
id_pers : Integer id_dep : Integer id_mand : Integer
tip_pers : String id_del : Integer fec_firma : Date
obs_per : String fec_ini : Date obs_fir : String
0..1
fec_fin : Date id_cron : Date
Buscar() num_ficha : Integer 1..*
Registrar() est_ficha : String Buscar()
Modificar() tip_mandato : String Registrar()
1 Modificar()
Expediente 0..* Buscar()
id_exp : Integer 0..* Registrar() 1
id_dep : Integer Involucrado Modificar()
fec_auto : Date id_invol : Integer Reportar() Resoluciones
1
num_exp : String 1 id_pers : Integer Calcular_Carceleria()
0..* id_res : Integer
id_exp : Integer Gen_Cuad_Firm() tra_motivo : String
Buscar() *
id_sitjur : Integer 0..* fec_resol : Date
Registrar()
Modificar() num_resol : String
0..* Buscar() tip_res : String
Registrar() id_mand : Integer
Modificar()
Res_Beneficio
Buscar()
id_res : Integer Registrar()
Magistrado 1 id_tipben : Integer Reportar()
1
id_mag : Integer Dependencia 0..* id_dep : Integer Modificar()
nom_mag : String id_dep : Integer num_beneficio : String
1 id_mag : Integer 1
Buscar() * dep_nombre : String
Registrar() dep_ubi : String
Modificar()
Buscar()

Caso: 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
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?

D IA G R A M A D E C A S O S D E U S O D E N E G O C I O
P a rt i c i p a n t e E n tr e g a r M a t e ri a l e s
P ro v e e d o r R e c e p c i o n a r M a t e ri a l e s
C o o rd in a d o r C o n tro l a r s to c k
A.2. MODELO DE OBJETO DE NEGOCIOS:

Es de utilidad para describir el funcionamiento de los casos de uso de negocio,
a este nivel aparecen otros objetos tales como los Workers (Trabajadores del
Sistema) y los Entity Class (Clases persistentes)
El secreto para la 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
Veri fi ca
Participante
Verifi ca
Registra
Participante Asistente de M ateri al

(from Business Use-Case Model) Abastecimiento
Veri fi ca
Registra
Entrega

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

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

Es la primera de vista de la Base de Datos que obtenemos, para ello debemos
colocar los objetos Entity Class, que aparecen en el Modelo de Objetos de
Negocio, y se establecen las relaciones.
Ej.

M O DE LO DE DO M INIO
P a rti ci p a n te R ec e pc io n
(from Business Object M od... (fr om Busi ness Object Mod.. .
E n tre g a M a te ri a l O rd e n Co m p ra
(from Business Object M od... (fr om Bu siness Obje ct Mo d... (fr om Busi ness Object Mod.. .
Nota: Suele ser útil aplicar Diagramas de Actividad sobre los casos de Uso de
mayor complejidad, a fin de describir las actividades que se desencadenan y su
secuencia de ejecución
A continuación se describe el funcionamiento del Caso de Uso de Negocio Entregar

Materiales:
D A : E N T R E G A R M A TE R I A L E S
S o l ic i t a r
M a t e ria l
V e r i f ic a r
P a r t ic i p a n t e
no
si
V e r i f ic a r
E n tre g a
no
si
V e r if ic a r S t o c k
no
si
R e g is t r a r
E n tre g a
A c t u a liz a r S t o c k
d e M a t e r i a le s

Tipos de Requerimientos - Requisitos
Funcionales:
• Describen la funcionalidad o servicios que el sistema se espera provea.
• Indican como el sistema 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
C liente
R egistrar Pedido
Vendedor
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________

Crear Cliente
Usuario Actualizar Cliente

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

< <in clude >>
U suario Ingresar Datos del C liente
Guardar D atos del C liente
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________

B) MODELO DE REQUERIMIENTOS:
El Modelo de Requerimientos refleja el Compromiso que asumimos los desarrolladores en
la 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
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.

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 de la USP 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é le dice este

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=
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
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
a+b=
Días ofrecidos 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

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

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
Diagrama de Clases de Analisis : Registrador de Persona
<<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"

D
DIIA
AGGR
RAAM
MAAD
DEEC
CLLA
ASSE
ESS
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 INGENIERIA DE SOFTWARE I
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

UML

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UML

Uploaded by

Copyright:

Available Formats

Universidad “San Pedro” Ingeniería de Software I

UNIVERSIDAD SAN PEDRO

ESCUELA PROFESIONAL DE INGENIERIA

Docentes: Ingº Oscar Ascón Valdivia

Ing. Oscar Ascón Valdivia 1

Objetivos básicos dentro de la organización

• Automatizan tareas operativas

Sistemas de Apoyo a las decisiones

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

Ejemplos: Sistemas de información que proporcione situaciones de créditos, etc.

Ing. Oscar Ascón Valdivia 2

El Lenguaje Unificado de Modelado

El Triángulo de Desarrollo de Software

Notación Herramienta Visual

Ing. Oscar Ascón Valdivia 3

El Lenguaje Unificado de Modelado

= Unified Modeling Language

UML no es un método sino un lenguaje de modelamiento

Objetivo del UML

UML toma lo mejor de varios métodos

Ing. Oscar Ascón Valdivia 4

Características del UML

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

Ing. Oscar Ascón Valdivia 5

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

Ing. Oscar Ascón Valdivia 6

Modelando con UML

State Use Case

Ing. Oscar Ascón Valdivia 7

La Crisis del Software

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

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

Ing. Oscar Ascón Valdivia 8

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

Ing. Oscar Ascón Valdivia 9

Desarrollo Iterativo e Incremental

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

El Ciclo de Vida del Software

Inicion Elaboración Construcción Transición

Ing. Oscar Ascón Valdivia 10

¿Qué es una Iteración?

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

Ing. Oscar Ascón Valdivia 11

Reducción de Riesgo a través de Iteraciones

Definir la iteración para

Revisión del Eliminación

Proceso de Planificación de una Iteración

Identificar y priorizar los riesgos del proyecto

Ing. Oscar Ascón Valdivia 12

Proceso Unificado Racional (RUP)

Representa los distintos requerimientos que hacen

Un diagrama de casos de uso esta compuesto por

Caso de Uso (Use Case)

Ing. Oscar Ascón Valdivia 13

Nombre del Actor

Relaciones entre los elementos