La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

INGENIERIA DE SOFTWARE

Presentaciones similares


Presentación del tema: "INGENIERIA DE SOFTWARE"— Transcripción de la presentación:

1 INGENIERIA DE SOFTWARE
UNT – INGENIERIA INDUSTRIAL INGENIERIA DE SOFTWARE Ing. Francisco Rodríguez Novoa

2 Ing. Francisco Rodríguez
Tema 8 Modelo de Diseño Ing. Francisco Rodríguez 2

3 Rational Unified Process (RUP)
3 3

4 AGENDA Diseño Diseño Orientado a Objetos Artefactos de Diseño Trabajadores Actividades del Diseño Orientado a Objetos

5 VISION GENERAL

6 Diseño – Diagramas UML

7 Flujo de trabajo del DOO
El objetivo del diseño es entender la solución refinando el modelo de análisis con la intención de desarrollar un modelo de diseño que permita una transición sin problemas a la fase de construcción. En el diseño, nos adaptamos al entorno de implementación y despliegue.

8 Descomponer el modelo de análisis en subsistemas que
VISION GENERAL Acercar el modelo de análisis al modelo de implementación “Los milagros más comunes de la ingeniería del software son las transiciones desde el análisis hasta el diseño y desde el diseño al código” (Richard Due). Identificar requisitos no funcionales y restricciones en relación a: lenguajes de programación, reutilización de componentes, sistemas operativos, tecnologías de: distribución, concurrencia, bases de datos, interfaces de usuario, gestión de transacciones, etc. Descomponer el modelo de análisis en subsistemas que puedan desarrollarse en paralelo. Definir la interfaz de cada subsistema. Derivar una representación arquitectónica del sistema

9 Actividades del Diseño

10 Actividades del Análisis y diseño

11 Artefactos del Diseño Modelo de Diseño.
Elementos del modelo de diseño: capas, subsistemas con clases de diseño (como servlets, beans y otras) e interfaces, librerías con clases utilitarias, y realizaciones de diseño de casos de uso. Diagramas de realizaciones de diseño de casos de uso: diagrama de clases y diagramas de secuencia. Diagrama de componentes, cuyos elementos son los componentes de la aplicación. Modelo de Despliegue. Diagrama de despliegue, cuyos elementos son artefactos y nodos

12 Artefactos del Diseño

13 Artefactos del Diseño

14 ARTEFACTOS Y TRABAJADORES
ARQUITECTO MODELO DE DISEÑO DESARROLLO DESCRIPCION DE LA ARQUITECTURA INGENIERO DE CASOS DE USO REALIZACION DE CASOS DE USO - ANALISIS COMPONENTES SUBSISTEMA DE DISEÑO INTERFAZ CLASES Responsable de

15 Arquitecto ARQUITECTO RESPONSABLE DE VISTA DE LA ARQUITECTURA

16 Ingeniero de Casos de Uso
Realización de caso de Uso - diseño INGENIERO DE CASOS DE USO RESPONSABLE DE

17 Ingeniero de Componentes
Clase de Diseño Interfaz RESPONSABLE DE

18 Workers - Diseño Arquitecto: responsable de la integridad del modelo de Análisis y de crear una vista arquitectónica que permita avanzar en el desarrollo. Ingeniero de Casos de Uso: responsable de la integridad de las realizaciones de casos de uso. Ingeniero de Componentes: responsable de la integridad de clases de análisis y sus relaciones, y la integridad de paquetes de análisis

19 Realizar los Diagramas de Interacción de los casos de uso del sistema.
Especificación del Caso de Uso del Negocio Solicitar Servicio 1.Actores 1.1Artista 2.Propósito Solicitar los servicios de la galería para realizar una exposición de arte. 3.Breve Descripción El caso de uso comienza cuando el Artista se dirige a la galería para solicitar los servicios para una exposición de arte. Se entrevista con el Anfitrión quien le pide los datos necesarios y llena la solicitud de servicio de la galería. El caso de uso termina cuando el Artista recibe una copia de la Solicitud de Servicio o del Documento de Rechazo de Pedido. 4.Flujo Básico de Eventos Acción del Actor Respuesta del Proceso del Negocio 1.El Artista solicita el servicio de para una exposición 2.El Anfitrión solicita los datos personales del Artista 3.El Artista entrega sus datos personales al Anfitrión 4.El Anfitrión busca si los datos del Artista están registrados previamente en la galería 5.El Anfitrión solicita información de las obras de arte al Artista. 6.El Artista entrega la información de las obras al Anfitrión 7.El Anfitrión registra la información de las obras de arte. 8.El Anfitrión busca la información sobre las técnicas que maneja la galería en el sistema LogiSis 9.El sistema LogiSis entrega la información sobre las técnicas que maneja la galería. 10.El Anfitrión recibe la información sobre las técnicas y determina si la galería maneja las técnicas de las obras de arte. 11.El Anfitrión llena la solicitud de servicio. 12.El Anfitrión archiva la Solicitud de Servicio y entrega una copia al Artista 13.El artista recibe la copia de la Solicitud de Servicio : Profesor : GestorTutorias asignatura : TutoriaAsignatura nuevoPeriodoTutoria : Periodo setAsignaturaEnTutoria( ) setEnTutoria( ) enTutoria := estaEnTutoria( ) [enTutoria] create( ) setInicioPerido( ) setPeridoActual(PeriodoTutoria) Mantener cliente : Profesor : GestorTutorias asignatura : TutoriaAsignatura nuevoPeriodoTutoria : Periodo 1: setAsignaturaEnTutoria( ) 3: enTutoria := estaEnTutoria( ) 5: create( ) 6: setInicioPerido( ) 7: setPeridoActual(PeriodoTutoria) 2: setEnTutoria( ) 4: [enTutoria]

20 Diagrama de Colaboración
Realizar los Diagramas de Interacción de los casos de uso del sistema. Los Diagramas de Interacción describen la interacción o intercambio de mensajes entre los objetos que participan en cada caso de uso. Existen dos tipos de Diagramas de Interacción. Diagrama de Secuencia Diagrama de Colaboración

21 Diagrama de Colaboración
Diagrama de Secuencia Diagrama de Colaboración Describe el intercambio de mensajes ordenado en el tiempo. Describe el intercambio de mensajes organizado por los objetos participantes.

22 Ejemplo de Diagrama de Secuencia.

23 Muestra la interacción de mensajes entre los objetos que participan en un caso de uso.
Ordenados según la secuencia de ocurrencia en el tiempo. Vista gráfica de la mecánica de interacción de los objetos a través del intercambio de mensajes de las clases a que pertenecen en un determinado escenario. Diagrama de Secuencia Describe el intercambio de mensajes ordenado en el tiempo.

24 Diagrama de Secuencia Está formado por. Objetos. Líneas de vida.
Barra de tiempo. Mensaje. Diagrama de Secuencia Describe el intercambio de mensajes ordenado en el tiempo. 16/02/2019

25 Objeto Barra de tiempo Mensaje Línea de vida A1:Clase1 Mensaje()
B1:Clase2 Barra de tiempo Mensaje Línea de vida

26 Objeto. Se muestra en la parte superior sobre la línea punteada vertical (línea de vida). Representa a los objetos que participan en el caso de uso. Se coloca una columna por cada clase que participa en el caso de uso. Clase1

27 Representa la vida del objeto durante la interacción.
Línea de vida. Representa la vida del objeto durante la interacción. Da idea del tiempo de vida de los objetos de la clase en el caso de uso. El tiempo se lee de arriba hacia abajo. Se modela utilizando una línea discontinua que se desplaza hacia abajo. Clase1

28 Barra de tiempo. Representa el conjunto de mensajes que mantienen relación consecutiva. Se modela utilizando una barra blanca encima de la línea de vida y la longitud de la barra se interpreta como la duración de la secuencia. Clase1 16/02/2019

29 Mensaje. Se modela utilizando una línea continua con punta de flecha entre las líneas de vida de los objetos de las clase. Encima se coloca el nombre del mensaje. El nombre significa el propósito de la operación. A1:Clase1 Mensaje() B1:Clase2

30 Diseño de las clases Identificar las responsabilidades de las clases de diseño (papeles en los casos de uso) Identificar: Operaciones Atributos relaciones en las que participa estados (diagramas de estados) métodos que soportan sus operaciones Requisitos nuevos…

31 Diseño de las clases Identificar operaciones
En el lenguaje de implementación Mirar responsabilidades que tiene en los casos de uso Identificar atributos Describirlos en el lenguaje de programación Considerar los atributos de las clases de análisis de las que se derivan

32 Diseño de las clases Identificar asociaciones y agregaciones
Las interacciones en los diagramas de secuencia precisan de asociaciones entre las clases que interactúan. Minimizar el número de relaciones entre clases (disminuir el acoplamiento). Refinar multiplicidad, papeles, etc. Refinar la navegabilidad (dirección) de las asociaciones en base a los diagramas de secuencia. Identificar generalizaciones-especializaciones

33 Diseño de las clases Describir métodos
Algoritmos para implementar alguna operación (lenguaje natural). Esqueletos de métodos generado por la herramienta. En general, esto se suele hacer en implementación. Describir estados Algunos objetos reaccionan en función de su estado actual. Utilizar diagramas de transición de estados

34 DIAGRAMA DE CLASES 1..n realiza 1 0..n reside está compuesta
Factura noFactura : Integer fecha : Date = DATE() igv : Double = 18.00 descuento : Currency = 0 Cliente codCliente : Integer direccion : String telefono : Long Producto codProducto : Integer descripcion : String um : String pu : Currency = 0.00 presentacion : String DetalleFactura noItem : Integer cantidad : Integer = 0 descuento : Double Pais codPais : Integer Descripcion : String PersonaNatural nombre : String dni : String PersonaJuridica razonSocial : String ruc : String 1..n realiza 1 0..n reside está compuesta está asociada

35

36

37 Importancia del diseño
Porque no se va directo a la implementación? Modelo de análisis no es suficientemente formal así nosotros necesitamos para: Refinar el análisis de clases Determinar operaciones Determinar como las clases deben de comunicarse El sistema debe estar adaptado a la implementación del entorno. Nosotros queremos validar los resultados del análisis Cuán bien el modelo de análisis y el modelo de requerimientos dsecriben el sistema? 39 39

38 FIN


Descargar ppt "INGENIERIA DE SOFTWARE"

Presentaciones similares


Anuncios Google