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
Universidad “San Pedro”
Ingeniería de Software I
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.
Ing. Oscar Ascón Valdivia
2
Universidad “San Pedro”
Ingeniería de Software I
El Lenguaje Unificado de Modelado
El Triángulo de Desarrollo de Software
Proceso
Notación
Ing. Oscar Ascón Valdivia
Herramienta Visual
3
Universidad “San Pedro”
Ingeniería de Software I
El Lenguaje Unificado de Modelado Definición: El UML es un lenguaje gráfico para la especificación, visualización, construcción y documentación de modelos orientados a objetos que representan sistemas intensivos en software. =
Unified
Modeling
Language
UML no es un método sino un lenguaje de modelamiento Objetivo del UML Describir cualquier tipo de sistema en términos de diagramas orientados a objetos Algunas categorías de Sistemas • Sistemas de Información • Sistemas de Tiempo Real • Sistemas de Conocimiento • Sistemas Distribuidos • Sistemas de Negocios UML toma lo mejor de varios métodos Rumbaugh Booch
Jacobson
Odell Meyer
Clasificación
Pre y Post condiciones Shlaer-Mellor Ciclo de vida de objetos
Harel Máquinas de estado
Gamma et. al. Marcos de trabajo, patrones, notas Embly Singleton clases
Wirfs-Brock Fusion
Responsabilidades
Descripción de operaciones, numeración de mensajes
Ing. Oscar Ascón Valdivia
4
Universidad “San Pedro”
Ingeniería de Software I
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
Ing. Oscar Ascón Valdivia
5
Universidad “San Pedro”
Ingeniería de Software I
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)
<<document>>
UML 1.1 <<document>> <<document>>
UML 1.2
ISO Publica especificación
<<document>>
UML 1.3 <<document>>
2000 (planificada una revisión menor)
2001 (planificada una revisión menor)
2002 (planificada una revisión mayor)
Ing. Oscar Ascón Valdivia
UML 1.4 <<document>>
UML 1.5 <<document>>
UML 2.0
6
Universidad “San Pedro”
Ingeniería de Software I
Vistas de un modelo “Un modelo es una descripción completa de un sistema desde una perspectiva concreta”
Vista lógica
Diagrama de Casos de Uso Diagrama de Clases
Vista de requerimientos
Diagrama de Objetos
Vista de implementación
Diagrama de Secuencia Diagrama de Colaboración
Vista de despliegue
Diagrama de Estado Diagrama de Actividad Diagrama de Componentes
Vista de procesos
Diagrama de Despliegue
Modelando con UML
Component Component Diagrams Diagramas de Diagrams Despliegue
Use Case Use Case Diagrams Diagramas de Diagrams Casos de Uso
State State Diagrams Diagramas de Diagrams Componentes
Diagramas de Actividad
Ing. Oscar Ascón Valdivia
State State Diagrams Diagramas de Diagrams Clases
Modelo
Scenario Scenario Diagrams Diagramas de Diagrams Estados
State State Diagrams Diagramas de Diagrams Objetos
Use Case Use Case Diagrams Diagramas de Diagrams Secuencia
Scenario Scenario Diagrams Diagramas de Diagrams Colaboración
7
Universidad “San Pedro”
Ingeniería de Software I
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
Ing. Oscar Ascón Valdivia
8
Universidad “San Pedro”
Ingeniería de Software I
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
Ing. Oscar Ascón Valdivia
9
Universidad “San Pedro”
Ingeniería de Software I
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 Elaboración
Inicion
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 Ing. Oscar Ascón Valdivia
10
Universidad “San Pedro”
Ingeniería de Software I
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
Ing. Oscar Ascón Valdivia
11
Universidad “San Pedro”
Ingeniería de Software I
Reducción de Riesgo a través de Iteraciones
Riesgo inicial Campo de acción inicial del proyecto
Definir la iteración para consignar el mayor riesgo Planificar y desarrollar la iteración
Iteración N
Estimar la iteración
Revisión del plan del proyecto
Eliminación del riesgo Revisión de la Evaluación de riesgo
Proceso de Planificación de una Iteración Identificar y priorizar los riesgos del proyecto Seleccionar un número pequeño de escenarios que contengan los mayores riesgos Los escenarios seleccionados son usados por: Los desarrolladores para identificar lo que será implementado para la iteración Los probadores para desarrollar el plan de pruebas y el procedimiento de prueba para la iteración Al final de la iteración Determinar qué riesgo ha sido reducido o eliminado Determinar si algún nuevo riesgo ha sido descubierto • Poner al día el plan para las iteraciones restantes
Ing. Oscar Ascón Valdivia
12
Universidad “San Pedro”
Ingeniería de Software I
Proceso Unificado Racional (RUP)
DIAGRAMAS UML 1. Diagramas de Casos de Uso Definición Un Diagrama de Casos de Uso representa lo que hace el sistema y como se relaciona con su entorno. Representa los distintos requerimientos que hacen los usuarios de un sistema. Un diagrama de casos de uso esta compuesto por - Casos de uso - Actores - Relaciones entre ellos Elementos Caso de Uso (Use Case) Es una secuencia de acciones realizadas por el sistema que producen un resultado observable y valioso para alguien en particular.
Nombre del Caso de Uso
Ing. Oscar Ascón Valdivia
13 Nombre del Actor
Universidad “San Pedro”
Ingeniería de Software I
Actor Un actor es un conjunto externo uniforme de personas, sistemas, cosas que solicita un servicio al sistema que estamos modelando.
o
Relaciones entre los elementos Relaciones entre actores La única relación permitida entre los actores es la Relación de Generalización.
Usuario Director de 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
Ing. Oscar Ascón Valdivia
14
Universidad “San Pedro”
Ingeniería de Software I
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.
Registrar matrícula
<<extend>> Registrar matrícula extemporánea
Ejemplo de Diagrama de Casos de Uso Registrar matrícula extemporánea <<extend>> Registrar matrícula
Usuario
<<include>> <<comunicates>>
Validar usuario
<<include>> Secretaria Aperturar cursos <<comunicates>> Director de Escuela
Ing. Oscar Ascón Valdivia
15
Universidad “San Pedro”
Ingeniería de Software I
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>>
Registrar Expediente Generar Cuaderno de FirmasElaborar Res.FirmExt
<<extend>>
<<extend>>
Registrar Internamiento de P&S Reg.Firma Extemporanea Procesado y/o Sentenciado
Elaborar Informe de Reos en Carcel Registrar Firma
Estadistica
<<include>>
Reg.Firma estándar <<include>>
Procesado
Sentenciado
Elaborar Res.BenPenit
<<extend>>
Ing. Oscar Ascón Valdivia
16
Calcular Tiempo de CarceleriaSuspender Internamiento
Universidad “San Pedro”
Ingeniería de Software I
¿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
Use-Case
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
Ing. Oscar Ascón Valdivia
Pág. 17
Universidad “San Pedro”
Ingeniería de Software I
Actores
Acto r
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
Insert card 1 2 3 4 5 6 7 8
Jose actúa como un actor
Oscar actúa como un actor
Modelo de Caso de uso
Actor
Ing. Oscar Ascón Valdivia
Caso de uso
Pág. 18
Universidad “San Pedro”
Ingeniería de Software I
Un usuario puede actuar como varios actores
Jose como operador
Insert 1 2 3 4 5 6
Jose
Operado r
Jose como cliente Client e
Casos de Uso
Caso 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?
Ing. Oscar Ascón Valdivia
Pág. 19
Universidad “San Pedro”
Ingeniería de Software I
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 Atributo1 Atributo2 ...
Ejemplo: La Clase Automóvil
Operacion1 operacion2 ...
Automovil Matricula Color Velocidad Arrancar( ) 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
Ing. Oscar Ascón Valdivia
Pág. 20
Universidad “San Pedro”
Ingeniería de Software I
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
camión
Ing. Oscar Ascón Valdivia
auto
Aéreo
avión
helicóptero
Pág. 21
Universidad “San Pedro”
Ingeniería de Software I
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
0..*
1..*
Alumno
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 a
WAN
Monitor Mouse
LAN
Hard Disk
HUB
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
Ing. Oscar Ascón Valdivia
Tronco
Extremidade s
Pág. 22
Universidad “San Pedro”
Ingeniería de Software I
Ejemplo Diagrama de Clases
Cliente Codigo Nombre Apellido Direccion
Venta 1..* 1
Codigo Fecha Observaciones
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: C001 Nombre: Oscar Apellido:Ascón Valdivia Direccion: Nepeña
Ing. Oscar Ascón Valdivia
Venta 1..* 1
Codigo: FAC01 Fecha: 27/09/2007 Observaciones: Cancelo con $
Pág. 23
Universidad “San Pedro”
Ingeniería de Software I
DIAGRAMA CE CLASES DE DISEÑO Diagrama de Clases
Delito Per_Juridica
id_del : Integer des_delito : String
id_pers : Integer raz_social : String num_doc : String rep_legal : String dni_replegal : String dir_legal : String
Per_Natural id_pers : Integer ape_pat : String ape_mat : String nom_per : String dir_per_nat : String lug_nac : String fec_nac : Date tip_doc : String num_doc : String
Buscar() Registrar() Modificar() 1 0..* Mandatos id_mand : Integer id_tipmand : Integer id_invol : Integer id_dep : Integer id_del : Integer fec_ini : Date fec_fin : Date num_ficha : Integer est_ficha : String tip_mandato : String
Persona id_pers : Integer tip_pers : String obs_per : String Buscar() Registrar() Modificar() 1
Expediente id_exp : Integer id_dep : Integer fec_auto : Date num_exp : String
id_invol : Integer id_pers : Integer id_exp : Integer id_sitjur : Integer
1 *
Buscar() Registrar() Modificar()
0..*
0..* Involucrado
0..*
1
Buscar() Registrar() Modificar() Reportar() Calcular_Carceleria() Gen_Cuad_Firm()
0..*
Buscar() Registrar() Modificar() Res_Beneficio
Magistrado id_mag : Integer nom_mag : String Buscar() Registrar() Modificar()
1
1 1 *
Dependencia id_dep : Integer id_mag : Integer dep_nombre : String dep_ubi : String
0..*
id_res : Integer id_tipben : Integer id_dep : Integer num_beneficio : String
Firmas id_fir : Integer id_mand : Integer fec_firma : Date obs_fir : String id_cron : Date
0..1 1..*
Buscar() Registrar() Modificar() 1 Resoluciones 0..*
id_res : Integer tra_motivo : String fec_resol : Date num_resol : String tip_res : String id_mand : Integer Buscar() Registrar() Reportar() Modificar()
1
Buscar()
Ing. Oscar Ascón Valdivia
Pág. 24
Universidad “San Pedro”
Ingeniería de Software I
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 DOCENTE PROYECTO FIN CARRERA
El día de la petición. Una semana 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
Ing. Oscar Ascón Valdivia
Pág. 25
Universidad “San Pedro”
Ingeniería de Software I
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
Ing. Oscar Ascón Valdivia
Pág. 26
Universidad “San Pedro”
Ingeniería de Software I
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 Material
Reg. Entrega Informe de Inventario de Materiales
Orden de
Reg. Recepción
Proveedores de 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
Ing. Oscar Ascón Valdivia
Pág. 27
Universidad “San Pedro”
Ingeniería de Software I
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.
Ing. Oscar Ascón Valdivia
Pág. 28
Universidad “San Pedro”
Ingeniería de Software I
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?
Ing. Oscar Ascón Valdivia
Pág. 29
Universidad “San Pedro”
Ingeniería de Software I
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
E n tr e g a r M a t e ri a l e s
P a rt i c i p a n t e
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 (from Business Use-Case Model)
M ateri al
Asistente de Abastecimiento Veri fi ca
Registra Entrega
Ing. Oscar Ascón Valdivia
Pág. 30
Universidad “San Pedro”
Ingeniería de Software I
BOM : RECEPCIONAR MATERIALES
Registrar
Recepcion
Prov eedor (from Business Use-Case Model)
R egistrar
Material
Asistente de Abastecimiento Verif icar Coordinador (from Business Use-Case Model)
R egistrar OrdenCompra
BOM: CONTROLAR STOCK
Inventario
Material
Estadistica
Coordinador (from Business Use-Case Model)
Entrega
Asistente de 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.
Ing. Oscar Ascón Valdivia
Pág. 31
Universidad “San Pedro”
Ingeniería de Software I
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
Ing. Oscar Ascón Valdivia
Pág. 32
Universidad “San Pedro”
Ingeniería de Software I
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
____________________________________________________________________________ ____________________________________________________________________________ ____________________________________________________________________________
Ing. Oscar Ascón Valdivia
Pág. 33
Universidad “San Pedro”
Ingeniería de Software I
Crear Cliente
Usuario
Modificar C liente
Usuario
Actualizar Cliente
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
____________________________________________________________________________ ____________________________________________________________________________ ____________________________________________________________________________
Ing. Oscar Ascón Valdivia
Pág. 34
Universidad “San Pedro”
Ingeniería de Software I
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
Asistente
Verificar producto <<include>>
<<include>> <<include>>
<<include>>
<<include>> Actualizar stock Verificar estado de material
Verificar patron de participantes
Verificar stock Verficar registro de entrega
Verifica orden de compra
<<include>>
<<include>>
<<include>> <<include>>
Almacenero
Registra recepcion
<<extend>> <<include>>
Registra material
Inventario de materiales
Estadistica de entrega
Ing. Oscar Ascón Valdivia
Pág. 35
Universidad “San Pedro”
Ingeniería de Software I
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>>
Asistente
Actualizar stock
Registrar Entrega
<<include>>
Almacenero
Registra recepcion
<<include>>
<<extend>>
Registra material
B.2. DIAGRAMAS DE ACTIVIDADES Opcional según necesidad, aplicar igual que en el Diagrama Mostrado en el Modelo de Dominio.
Ing. Oscar Ascón Valdivia
Pág. 36
Universidad “San Pedro”
Ingeniería de Software I
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.
Ing. Oscar Ascón Valdivia
Pág. 37
Universidad “San Pedro”
Ingeniería de Software I
Especificación de Casos de Uso de Requerimientos
1 Registrar Entrega
CASO DE USO
REGISTRAR ENTREGA El Sistema deberá permitir al Asistente registrar los
Descripción
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
El sistema deberá realizar el registro de entrega de
Rendimiento
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
Ing. Oscar Ascón Valdivia
Pág. 38
Universidad “San Pedro”
Ingeniería de Software I
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
Ing. Oscar Ascón Valdivia
Pág. 39
Universidad “San Pedro”
Ingeniería de Software I
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.
Ing. Oscar Ascón Valdivia
Pág. 40
Universidad “San Pedro”
Ingeniería de Software I
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.
Ing. Oscar Ascón Valdivia
Pág. 41
Universidad “San Pedro”
Ingeniería de Software I
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
Ing. Oscar Ascón Valdivia
Pág. 42
Universidad “San Pedro”
Ingeniería de Software I
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 : Registrar persona
: Magistrado
: Persona
6: Crear 5: Registrar persona
: Registrador de 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 • • • • Relaciones
Diagramas de colaboración Diagramas de secuencia Diagrama de clases Diagrama de paquetes de análisis
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
Ing. Oscar Ascón Valdivia
Pág. 43
Universidad “San Pedro”
Ingeniería de Software I
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?
Persona
Maestro
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?
Ing. Oscar Ascón Valdivia
Pág. 44
Universidad “San Pedro”
Ingeniería de Software I
Maestro
Curso 1
0..*
¿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?
0..*
Alumno
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
Ing. Oscar Ascón Valdivia
Pág. 45
Universidad “San Pedro”
Ingeniería de Software I
1..*
Alumno
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:
Ing. Oscar Ascón Valdivia
Pág. 46
Universidad “San Pedro”
Ingeniería de Software I
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: Nº Empleado: Fecha de Contr.: Estado:
Joyce Clark 567138 21 de marzo 1987 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
Ing. Oscar Ascón Valdivia
Pág. 47
Universidad “San Pedro”
Ingeniería de Software I
Profesor “J Clark” enseña Algebra
Profesor “J Clark” enseña Algebra
Profesor “J Clark” 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 Nombre Ubicación Días ofrecidos Créditos Hora de inicio Hora de término
Ing. Oscar Ascón Valdivia
a+b= 10
Comportamiento Agregar un alumno Borrar un alumno Entregar una lista del curso Determinar si está lleno
Pág. 48
Universidad “San Pedro”
Ingeniería de Software I
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 Smith
Profesor Profesor 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
Ing. Oscar Ascón Valdivia
Pág. 49
Universidad “San Pedro”
Ingeniería de Software I
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 nombre empID crear( ) grabar( ) borrar( ) cambiar( )
Ing. Oscar Ascón Valdivia
Profesor nombre empID
Profesor crear( ) grabar( ) borrar( ) cambiar( )
Profesor
Profesor
Pág. 50
Universidad “San Pedro”
Ingeniería de Software I
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
Ing. Oscar Ascón Valdivia
Pág. 51
Universidad “San Pedro”
Ingeniería de Software I
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 >> Programa
<<entity >> 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
Ing. Oscar Ascón Valdivia
Pág. 52
Universidad “San Pedro”
Ingeniería de Software I
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
: IU_Registrar Persona
: Magistrado
: Persona 6: Crear
5: Registrar Persona
Diagrama de Clases de Analisis
: Persona Natural : Registrador de Persona
<<entity >> Herramienta Desarrollo 1 <<entity >> Feria
<<entity >> Recepcion 1..n
1..n 1..n 1
<<entity >> Proyecto 1..n 1..n
<<entity >> Semestre 1
1 1..n <<entity >> Grupo 1..n 1..n
<<entity >> 1..n Docente
<<entity >> 1 Curso
1..n
<<entity >> Alumno
1..n
Ing. Oscar Ascón Valdivia
Pág. 53
Universidad “San Pedro”
Ingeniería de Software I
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)
Ing. Oscar Ascón Valdivia
Pág. 54
Universidad “San Pedro”
Ingeniería de Software I
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 Ing. Oscar Ascón Valdivia
Pág. 55
Universidad “San Pedro”
-
Ingeniería de Software I
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"
Ing. Oscar Ascón Valdivia
Pág. 56
Universidad “San Pedro”
Ingeniería de Software I
D DIIA AG GR RA AM MA AD DE EC CL LA 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 Atributo1 Atributo2 ...
Automovil Ejemplo: La Clase Automóvil
Operacion1 operacion2 ...
Matricula Color Velocidad Arrancar( ) Acelerar( ) Frenar( )
Objeto: Instancia particular de una clase. Distinguible por sus características específicas. CLASE define datos y métodos
PERRO raza, color... come, ladra...
OBJETO ocupa espacio y dura un tiempo
RAMBO bulldog gris come caviar 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.
Ing. Oscar Ascón Valdivia
Pág. 57
Universidad “San Pedro”
Relación de Dependencia
Relación de Generalización
Relación de Asociación
Ingeniería de Software I
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.
Ing. Oscar Ascón Valdivia
Pág. 58
Universidad “San Pedro”
-
Ingeniería de Software I
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 1..* Orden produccion nro_orden : String hora : Date fecha : Date Maquinaria codigo : String descripcion : String 1
1..*
Avance 1
1..*
codigo : String estado : String
1
1 1..* Tipo proceso
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
Ing. Oscar Ascón Valdivia
Pág. 59
Universidad “San Pedro”
Ingeniería de Software I
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 Orden Compra fecha : Date 1..*
1..*
Producto descripcion : String precio unitario : Double
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
Ing. Oscar Ascón Valdivia
Pág. 60
Universidad “San Pedro”
Ingeniería de Software I
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_Producto descripcion : VARCHAR(255) precio unitario : FLOAT(64, 0) T_Producto_ID : INT
T_Orden Compra fecha : DATETIME T_Orden Compra_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
Ing. Oscar Ascón Valdivia
Pág. 61
Universidad “San Pedro”
Ingeniería de Software I
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
Ing. Oscar Ascón Valdivia
Pág. 62
Universidad “San Pedro”
Ingeniería de Software I
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 nombre : String 1
0..*
Medico colegiatura : String
Administrativo fecha contrato
1..* Nivel descripcion : String
1..* Clinica nombre : String direccion : String telefono : String 0..* fax : String
1..*
Servicio nombre : String descripcion : String precio : Double
Personal codigo : String nombres : String apellidos : String direccion : String turno : String 1 1..* Orden produccion nro_orden : String hora : Date fecha : Date Maquinaria codigo : String descripcion : String 1
1
1 1..*
1..* Detalle orden produccion dodigo_equipo : String codigo_ingred : String nro_orden : String
1..*
Avance codigo : String estado : String 1 1..* Tipo proceso codigo : String tipo : String
1..* Ingredientes codigo : String descripcion : String fecha adquisición : Date 1 fecha vencimiento : Date
Ing. Oscar Ascón Valdivia
Pág. 63
Universidad “San Pedro”
Ingeniería de Software I
CONSTRUCCION DE DIAGRAMAS DE ESTADO
CREANDO UN DIAGRAMA DE TRANSICION DE ESTADOS 1. 2. 3. 4.
Dar clic derecho sobre la clase que se desea especificar la transición de estados. Escoger la Opción New / StateChart Diagram. Colocarle el nombre al Diagrama de Estados creado, y presionar enter. 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.
Ing. Oscar Ascón Valdivia
Pág. 64
Universidad “San Pedro”
Ingeniería de Software I
Cancelado
Agregar Pago 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.
Ing. Oscar Ascón Valdivia
Pág. 65
Universidad “San Pedro”
Ingeniería de Software I
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
Ing. Oscar Ascón Valdivia
Pág. 66
Universidad “San Pedro”
Ingeniería de Software I
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
Ing. Oscar Ascón Valdivia
Pág. 67