Manual UML

Universidad “San Pedro” Ingeniería de Software I

Ing. Oscar Ascón Valdivia 1

UUNNIIVVEERRSSIIDDAADD SSAANN PPEEDDRROO

FFAACCUULLTTAADD DDEE IINNGGEENNIIEERRIIAA

EESSCCUUEELLAA PPRROOFFEESSIIOONNAALL DDEE IINNGGEENNIIEERRIIAA

IINNFFOORRMMAATTIICCAA YY DDEE SSIISSTTEEMMAASS

AASSIIGGNNAATTUURRAA

IINNGGEENNIIEERRIIAA DDEE SSOOFFTTWWAARREE II

DDoocc eenntt eess :: II nnggºº OOss cc aarr AAss cc óónn VVaall ddii vv ii aa

CChhiimmbboottee 22001100



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

Notación

Proceso

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

Jacobson

Meyer

Harel

Wirfs- Brock

Fusion

Embly

Gamma et. al.

Shlaer-Mellor

Odell

Booch

Pre y Post condiciones

Máquinas de estado

Responsabilidades

Descripción de operaciones, numeración de mensajes

Singleton clases

Marcos de trabajo, patrones, notas

Ciclo de vida de objetos

Clasificación



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

1997 (Adoptada por OMG)

1998

(revisión editorial sin cambios significativos)

1999 (revisión menor

públicamente disponible)

2000 (planificada una revisión menor)

2001

(planificada una revisión menor)

2002 (planificada una revisión mayor)

<<document>>

UML 1.1

<<document>>

UML 1.2

<<document>>

UML 1.5

<<document>>

UML 1.3

<<document>>

UML 2.0

<<document>>

UML 1.4

<<document>>

ISO Publica especificación



Vistas de un modelo

Modelando con UML

Use Case Diagrams

Use Case Diagrams Diagramas de Casos de Uso

Scenario Diagrams

Scenario Diagrams Diagramas de Colaboración

State Diagrams

State Diagrams Diagramas de Componentes

Component Diagrams

Component Diagrams Diagramas de

Despliegue

State Diagrams

State Diagrams Diagramas de

Objetos

Scenario Diagrams

Scenario Diagrams Diagramas de

Estados

Use Case Diagrams

Use Case Diagrams Diagramas de

Secuencia

State Diagrams

State Diagrams Diagramas de

Clases

Diagramas de

Actividad

Modelo

“Un modelo es una descripción completa de un sistema desde una perspectiva concreta”

Vista lógica

Vista de procesos

Vista de despliegue

Vista de implementación

Vista de requerimientos

Diagrama de Clases

Diagrama de Objetos

Diagrama de Estado

Diagrama de Secuencia

Diagrama de Colaboración

Diagrama de Actividad

Diagrama de Casos de Uso

Diagrama de Componentes

Diagrama de Despliegue



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

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

Inicio n Elaboración Construcción Transición

tiempo



� 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

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

Riesgo inicial Campo de acción inicial del proyecto

Definir la iteración para consignar el mayor riesgo

Planificar y desarrollar la iteración

Estimar la iteración

Eliminación del riesgo

Revisión de la Evaluación de riesgo

Revisión del plan del proyecto

Iteración N



Nombre del Caso de Uso

Nombre del Actor

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.



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.

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

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.

Secretaria

Registra Matrícula

<<comunicates>>

Realizar cobranza

Cobranza con tarjeta

Cobranza en efectivo

Cobranza con cheque

Director de Escuela

Usuario

(Sist. Matrícula)



<<extend>>

Registrar matrícula extemporánea

Validar usuario

Aperturar cursos

<<include>>

Registrar matrícula

<<include>>

Director de Escuela

Usuario

Secretaria

<<comunicates>>

<<comunicates>>

2. Relación <<include>> El caso de uso A siempre incluye (o usa) el comportamiento de B.

3. Relación <<extend>> El caso de uso A, extiende al caso de uso B. A ocurre en casos especiales para extender B.

Ejemplo de Diagrama de Casos de Uso

Validar usuario

Aperturar cursos

<<include>> Registrar matrícula

<<include>>

Registrar matrícula <<extend>>

Registrar matrícula extemporánea



Reg.PersNat Reg.PersJur

ProcesadoCalcular Tiempo de Carceleria

Elaborar Informe de Reos en CarcelEstadistica

<<include>>

Reg.Firma estándar

Reg.Firma Extemporanea

Sentenciado

Registrar Persona

Suspender Regla de Conducta

Generar Cuaderno de Firmas

Elaborar Informe de Firmantes

Elaborar Res.BenPenit

<<include>>

Suspender Internamiento

Elaborar Res.FirmExt

Registrar Regla de Conducta

<<extend>>

Registrar Expediente

<<extend>>

Registrar Firma

Procesado y/o Sentenciado

Magistrado

Registrar Internamiento de P&S

<<extend>>

<<extend>>

<<extend>>

Diagrama de Casos de Uso


Ing. Oscar Ascón Valdivia Pág. 17

Actor

Use-Case

¿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

� Un caso de uso es una secuencia de acciones que un sistema realiza, que produce un 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



Actor

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

� Un actor puede ser un recipiente pasivo de la 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

1 2 3 4 5 6 7 8

Insert card

Jose actúa como un actor

Oscar actúa como un actor

Modelo de Caso de uso

Actor Caso de uso



Caso de Uso

Un usuario puede actuar como varios actores

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

1 2 3 4 5 6

Insert Jose como operador

Cliente

Operador Jose como

cliente

Jose



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:

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

Automovil

Matricula Color Velocidad Arrancar( ) Acelerar( ) Frenar( )

NombreClase

Atributo1 Atributo2 . . . Operacion1 operacion2 . . .

Ejemplo: La Clase Automóvil



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

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

Canal

Video

. . .

. . . Grabar(c : canal)

Televisión

. . .

. . . cambiar(c : canal)

camión auto avión helicóptero

Aéreo Terrestre

Vehículo



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.

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.

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

Acta Alumno 0..* 1..*

Computadora

CPU

Hard Disk

Teclado

Mouse WAN

Red

LAN

Monitor

HUB

Hombre

Extremidades

Tronco Cabeza



Ejemplo Diagrama de Clases

Cliente

CodigoNombreApellidoDireccion

Venta

CodigoFechaObservaciones

1..*

11

1..*

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

Codigo: C001Nombre: OscarApellido:Ascón ValdiviaDireccion: Nepeña

Venta

Codigo: FAC01Fecha: 27/09/2007Observaciones: Cancelo con $

1..*

11

1..*



Per_Natural

id_pers : Integerape_pat : Stringape_mat : Stringnom_per : Stringdir_per_nat : Stringlug_nac : Stringfec_nac : Datetip_doc : Stringnum_doc : String

Per_Juridica

id_pers : Integerraz_social : Stringnum_doc : Stringrep_legal : Stringdni_replegal : Stringdir_legal : String

Persona

id_pers : Integertip_pers : Stringobs_per : String

Buscar()Registrar()Modificar()

Involucrado

id_invol : Integerid_pers : Integerid_exp : Integerid_sitjur : Integer


1

0..*

1

0..*

Delito

id_del : Integerdes_delito : String


Resoluciones

id_res : Integertra_motivo : Stringfec_resol : Datenum_resol : Stringtip_res : Stringid_mand : Integer

Buscar()Registrar()Reportar()Modificar()

Firmas

id_fir : Integerid_mand : Integerfec_firma : Dateobs_fir : Stringid_cron : Date

Buscar()Registrar()Modificar()Expediente

id_exp : Integerid_dep : Integerfec_auto : Datenum_exp : String


*

1

*

1

Magistrado

id_mag : Integernom_mag : String


Mandatos

id_mand : Integerid_tipmand : Integerid_invol : Integerid_dep : Integerid_del : Integerfec_ini : Datefec_fin : Datenum_ficha : Integerest_ficha : Stringtip_mandato : String

Buscar()Registrar()Modificar()Reportar()Calcular_Carceleria()Gen_Cuad_Firm()

0..*

1

0..*

1

0..*

1

0..*

1

1

0..*

1

0..*

1..*

0..1

1..*

0..1

Res_Beneficio

id_res : Integerid_tipben : Integerid_dep : Integernum_beneficio : String

Dependencia

id_dep : Integerid_mag : Integerdep_nombre : Stringdep_ubi : String

Buscar()

1

0..*

1

0..*

*

1

*

1

1

0..*

1

0..*

1

0..*

1

0..*

DIAGRAMA CE CLASES DE DISEÑODiagrama de Clases



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

Cliente Vendedor Jefe Ventas

[Tarifa no OK]

[Tarifa OK]

Sol. de servicio Pide datos cliente

Consulta tarifa

Negoc. condiciones

Pide datos Servicio

Ingresa orden

Consulta disponib.

Decide costo



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”

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

Registra

Informe de

Inventario de Materiales

Coordinador del Evento

Entrega del Material

Solicitar Material

Proveedores de Materiales

Material

Reg. Entrega

Asistente de Abastecimiento

. . . Participantes

Reg. Recepción

Material

Control

Registra

Orden

de



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?



Participante

(from Business Use-Case Model)

Participante

MaterialAsistente de Abastecimiento

Entrega

Veri fica

Verifica

Veri fica

Registra

Registra

BOM: ENTREGAR MATERIALES

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.

P a r t i c i p a n t e E n t r e g a r M a t e r i a l e s

P r o v e e d o r

C o n t r o l a r s t o c kC o o r d i n a d o r

R e c e p c i o n a r M a t e r i a l e s

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



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.

Material

Prov eedor


Coordinador


Recepcion


OrdenCompra

Registrar

Registrar

Registrar

Verif icar

BOM: RECEPCIONAR MATERIALES

Coordinador (from Business Use-Case Model)

Material

Entrega

Recepcion


Inventario

Estadistica

Estadistica

BOM: CONTROLAR STOCK



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 r i a l

V e r i f ic a r P a rt ic i p a n t e

V e r i f ic a r E n t r e g a

V e r i f ic a r S t o c k

R e g is t r a r E n t r e g a

A c t u a l iz a r S t o c k d e M a t e r i a le s

n o

n o

n o

s i

s i

s i

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:

Participan te

(from Business Object M od...

Entrega

(from Business Object M od...

M ateria l

(fr om Business Obje ct Mod...

R ec epc ion

(fr om Busi ness Object Mod.. .

OrdenCom pra

(fr om Busi ness Object Mod.. .

M ODELO DE DOM INIO



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

Vendedor

Registrar Pedido



____________________________________________________________________________ ____________________________________________________________________________ ____________________________________________________________________________

____________________________________________________________________________ ____________________________________________________________________________ ____________________________________________________________________________

Ingresar Datos del C lienteUsuario

Verificar D ato s Cliente

<<in cl ude>>

Guardar Datos del C liente

<<in clude >>

Crear Cliente

Modificar ClienteUsuario

Eliminar Cliente

Usuario Actualizar Cliente



B) MODELO DE REQUERIMIENTOS: El Modelo de Requerimientos refleja el Compromiso que asumimos los desarrolladores en la construcción del Sistema. Es importante que el referido modelo sea validado por el cliente, de forma que queden establecidos los compromisos de construcción.

B.1. DIAGRAMA DE CASO DE USO DE REQUERIMIENTOS Es el diagrama de Casos de Uso donde aparece el Compromiso de Construcción, debe

detallar los comportamientos a construir, así como las relaciones entre ellos. Una forma fácil de construir un Diagrama de Requerimientos, es explotar los Casos de

Uso de Negocios, y transmitir en casos de uso mas pequeños su funcionamiento; luego de ello se debe proceder a depurar eliminando los Casos de Uso que no se implementaran (Manual), así como los casos de uso pequeños que sean previsibles su existencia.

Ejemplo:

Diagrama de Casos de Uso de Requerimiento Detallado

Actualizar stock

Verificar patron de participantes

Verficar registro de entrega

Verificar stock

Verificar estado de material

Registrar Entrega

Verifica orden de compra

Registra recepcionAlmacenero

Registra material

<<include>>

<<include>><<include>>

<<include>>

<<include>>

Verificar producto

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<extend>>

<<include>>

Inventario de materiales

Asistente

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

B.2. DIAGRAMAS DE ACTIVIDADES Opcional según necesidad, aplicar igual que en el Diagrama Mostrado en el

Modelo de Dominio.

Actualizar stock

Inventario de materialesEstadistica de entrega

Registra material

Registra recepcionAlmacenero

Registrar EntregaAsistente

<<include>>

<<include>>

<<extend>>

<<include>>



Matriz de Priorizacion de Casos de Uso

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.

Nª Caso Uso Rendimiento Frecuencia Importancia Urgencia Prioridad

1

Registrar Entrega

5 min 12 v/dia vital Inmediata 1ª

2

Registrar Recepción


3 Registrar Materiales 5 min 3 v/dia vital Inmediata 3º

4

Estadística de entrega


5 Inventario materiales




Especificación de Casos de Uso de Requerimientos 1 Registrar Entrega

Tabla Nº: Especificación Registrar Proyecto

Fuente: Elaboración Propia

CASO DE USO REGISTRAR ENTREGA Descripción El Sistema deberá permitir al Asistente registrar los

materiales entregados a los participantes.

Precondición

Paso Acción

1 El Asistente busca al participante para

entregarle material.

Secuencia Normal

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.

Postcondición El participante deberá estar inscrito

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

Excepciones

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



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

Son las entidades que participan en la interacción para lograr una funcionalidad, éstas envían y o reciben mensajes.

Indica la vida de un objeto durante la interacción y se representa mediante una línea vertical discontinua.

Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando una operación.

objeto:Clase

Objetos o actores

objeto:Clase

Línea de vida de un objeto

Activación o foco de Control

objeto:Clase



Son las invocaciones que envía un objeto a otro para que realice una tarea. Tipos de mensajes

objeto:Clase objeto:Clase

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:

Mensaje Así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.

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 persona

: Buscar persona

: Registrador de 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.

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

: Magistrado : Registrar persona

: Buscar persona

: Registrador de persona

: Persona

1: Registrar persona

2: Buscar persona

4: Obj. Persona

5: Registrar persona

3: Leer

6: Crear



Indicadores de Multiplicidad

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?

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

Exactamente uno

Cero o mas

Uno o mas

Cero o uno

Rango especificado

1

0..*

1..*

0..1

2..4

Muchos *

1..*

Persona Maestro

Curso

1



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?

� 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

¿Qué le dice este diagrama?

Curso Maestro

1 0..*

Alumno 0..*

3-10

Curso



� 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

� Entidad conceptual � Entidad programa

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:

Alumno 1..*

3-10

Curso

Calificación

Lista Enlazada

Camión

Proceso Químico



� 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

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)

Un Objeto tiene Identidad

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

Nombre: Joyce Clark Nº Empleado: 567138 Fecha de Contr.: 21 de marzo 1987 Estado: Adjunto

Profesor Clark

a + b =

Curso Algebra 101

Asignar profesor

(Retorna:confirmación) Registro del

Sistema

a + b =



¿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

Profesor “J Clark” enseña Algebra



a + b = 10

Clase Curso

Estructura Nombre

Ubicación Días ofrecidos

Créditos Hora de inicio

Hora de término

Comportamiento Agregar un alumno Borrar un alumno

Entregar una lista del curso

Determinar si está lleno



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

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

Objetos Profesor

Profesor Smith

Profesor Jones

Profesor Mellon



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

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

Profesor

Profesor Oscar

a + b = 10

Profesonombre empID

crear( ) grabar( ) borrar( ) cambiar( )

Profesor

nombre empID

Profesor

crear( ) grabar( ) borrar( ) cambiar( )

Profesor

Profesor



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

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

FormularioPrograma <<Boundary>>

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

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

Programa <<entity >>

ListaCursos <<entity>>

Catalogo <<entity >>

Curso <<entity >>

<<control>>

AdministradorDeRegistro



Diagrama de Colaboración Diagrama de Clases de Analisis

: Magistrado : IU_Registrar Persona

: Buscador de Persona

: Registrador de Persona

: Persona

: Persona Juridica

: Persona Natural

WORKFLOW DE ANALISIS: REGISTRAR PERSONA

1: Registrar Persona

6: Crear

2: Buscar Persona (NomboRazSoc,TipPer)

4: objPersona

5: Registrar Persona

3: Leer

Docente<<entity >> Alumno

<<entity >>

Herramienta Desarrollo<<entity >>

Recepcion<<entity >>

Proyecto<<entity >>

1..n

1

1..n

1

Feria<<entity >>

1..n

1..n

Curso<<entity >>

1..n

1..n

1..n

1..n

Semestre<<entity >>

Grupo<<entity >>

1..n

1..n

1..n

1..n

1..n

1

1..n

1

1..n

1

1..n

1

1..n

1

1..n

1

1..n

1

1..n

1

1..n

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



: Vendedor : IU_RegistrarPersona : Buscador de Persona : Persona : Registrador de 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"

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



DDDIII AAAGGGRRRAAAMMM AAA DDDEEE CCCLLL AAASSSEEESSS 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:

Objeto: Instancia particular de una clase. Distinguible por sus características específicas.

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.

PERRO raza, color... come, ladra... RAMBO bulldog gris come caviar ladra fuerte

CLASE define datos y

métodos

OBJETO ocupa

espacio y

dura un tiempo

Automovil

Matricula

Color

Velocidad

Arrancar( )

Acelerar( ) Frenar( )

NombreClase

Atributo1

Atributo2

. . .

Operacion1

operacion2 . . .

Ejemplo: La Clase Automóvil



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

Tipo proceso

codigo : String tipo : String

Maquinaria

codigo : String descripcion : String

Ingredientes

codigo : String descripcion : Stringfecha adquisición : Datefecha vencimiento : Date

Personal

codigo : Stringnombres : Stringapellidos : Stringdireccion : Stringturno : String

Avance

codigo : String estado : String

1..* 1 1..* 1

Detalle orden produccion

dodigo_equipo : Stringcodigo_ingred : Stringnro_orden : String

1..* 1 1..* 1

1..*

1

1..*

1

Orden produccion

nro_orden : Stringhora : Datefecha : Date

1..*

1

1..*

1

1..* 1 1..* 1

1..*

1

1..*

1

DIAGRAMA CLASE DISEÑO



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

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

ItemLineacantidad : Integer

Productodescripcion : Stringprecio unitario : Double

Orden Compra

fecha : Date1..* 1..* 1..* 1..*



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.

Modelo de Datos: Ejemplo

T_Orden Compra

fecha : DATETIMET_Orden Compra_ID : INT

<<PK>> PK_T_Orden Compra26()

T_Producto

descripcion : VARCHAR(255)precio unitario : FLOAT(64, 0)T_Producto_ID : INT

<<PK>> PK_T_Producto28()

T_ItemLinea cantidad : INTT_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()

1

0..*

1

0..*

<<Identifying>>

1

0..*

1

0..*

<<Identifying>>



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



Nivel descripcion : String

Administrativofecha contrato

Empleadonombre : Stringapellido : String direccion : String

Servicionombre : Stringdescripcion : Stringprecio : Double

Clinicanombre : Stringdireccion : Stringtelefono : Stringfax : String

1..*0..* 1..*0..*

Medico colegiatura : String

1..*

1..*

1..*

1..*

Especialidadnombre : String

0..*1 0..*1

Tipo proceso

codigo : Stringtipo : String

Maquinaria

codigo : Stringdescripcion : String

Ingredientes

codigo : Stringdescripcion : Stringfecha adquisición : Datefecha vencimiento : Date

Personal

codigo : Stringnombres : Stringapellidos : Stringdireccion : Stringturno : String

Avance

codigo : Stringestado : String

1..* 1 1..* 1

Detalle orden produccion

dodigo_equipo : Stringcodigo_ingred : Stringnro_orden : String

1..* 1 1..* 1

1..*

1

1..*

1

Orden produccion

nro_orden : Stringhora : Datefecha : Date

1..*

1

1..*

1

1..* 1 1..* 1

1..*

1

1..*

1

6. Generar la base de datos en SQL Server 2000 a partir del siguiente modelo de objetos



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.



Creado

Abierto

Cancelado

Anuladoanular

Documento Anulado

Agregar Pago

Agregar Pago

Documento Cancelado[ documento.deuda = detaliqui ]

2. Construya el siguiente Diagrama de Estados en Rational Rose, dentro de la

Clase Venta:

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.

Espera Venta Introduccion Productos

Espera Pago

introducirProducto

introducirProducto

Terminar Venta

Autorizacion Pago

efectuar Pago Efectivo

efectuar Pago Tarjeta

manejarRespuesta



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

Manual UML

Documents

Transcript of Manual UML