A. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo OCW 2013

Tamaño: px

Comenzar la demostración a partir de la página:

Download "A. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo OCW 2013"

Julián Molina Carrasco
hace 6 años
Vistas:

1 Tema 3: Diseño A. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo OCW 2013

2 Índice 1.- Introducción El rol del diseño en el CV Artefactos a conseguir durante el flujo de trabajo del diseño Decisiones de diseño tomadas en nuestro caso de estudio 2 - Diagramas de secuencia UML 3.- Realización ió de diagramas de secuencia 3.1.-Capas lógicas en el software: presentación, lógica del negocio y acceso a datos Patrones de responsabilidad GRASP 4 - Arquitecturas Software de varios niveles

3 Objetivo del diseño 1. Introducción Encontrar la forma (o solución) del sistema que cumpla con todos los requisitos it (funcionales y no funcionales) REQUISITOS: Do the right things / Haz lo correcto DISEÑO: Do the things right / Hazlo correcto Durante el diseño se escogen las herramientas: LP, SO, SGBD, GUI, concurrencia, distribución, componentes, Se divide el trabajo para que se pueda implementar en paralelo por equipos distintos Dfii Definir bien las interfaces, it que permita que los equipos se sincronicen i Usar una notación común Durante el diseño debe crearse una abstracción de la implementación del sistema: El diseño debe ser una buena entrada a la fase de implementación: que implementar sea directo a partir del diseño

4 1.1.-El rol del diseño en el CV Actividades Inicio Desarrollo Construcción Transición Captura Requisitos / Análisis R & A R & A R & A R & A Diseño D D D D Implementación I I I I Pruebas P P F P Despliegue D D D D Iteración 1 Iteración Iteración Iteración n Iteración n+1 Tiempo

5 1.1.- El rol del diseño en el CV Diseño Actividad principal en la fase de desarrollo, junto con el análisis El diseño ayuda a: Encontrar una arquitectura estable del sistema Crear un anteproyecto del modelo de implementación El modelo del diseño obtenido se debe mantener a lo largo de todo el proyecto Esto es, seguramente cambiará algo durante la implementación, y hay yq que ocuparse en actualizarlo

6 1.2.- Artefactos a conseguir durante el flujo de trabajo del diseño 1.- Realización/Diseño de los casos de uso Diagramas de secuencia 2.- Clases/Interfaces de diseño 3.- Descripción de la arquitectura

7 Realización/Diseño de los casos de uso Diagramas de secuencia Es una colaboración que indica cómo se realiza/ejecuta un CU, en términos de las clases de diseño y sus objetos Para cada CU habrá que añadir El diagrama de secuencia Flujo de eventos (en el diseño) Requisitos de implementación

8 Diagrama de Secuencia en UML : ACTOR 1: escribe d y solicita... obj1: IU_CU_X obj2: Gestor_X obj3: Clase_X 2: busca(d) 3: getatributoy()... return v...

9 Clases / Interfaces de diseño Una clase de diseño es una abstracción de una clase (o constructor similar existente) en el LP Operaciones, parámetros, atributos y tipos Visibilidad de atributos y operaciones Asociaciones y agregaciones (aunque luego se implementen añadiendo atributos) Generalizaciones (con la semántica del LP utilizado)

10 Clases / Interfaces de diseño Los métodos se especifican en lenguaje natural o en pseudocódigo Pueden especificarse requisitos de implementación ió de una clase Pueden ponerse estereotipos class module, form, user control en VB interface en Java

11 Descripción de la arquitectura Separación del sistema en N niveles/capas Definición de las relaciones entre niveles cliente, servidor y de datos Nivel Cliente Nivel Servidor Nivel de Datos Presentación Lógica del Negocio Cliente Web Contenedor Web Contenedor EJB Bases de Datos Presentación Cliente Applet Aplicación stand-alone Servlets, JSP Enterprise JavaBeans Java RMI objects Aplicaciones Legadas o Pre-Existentes Servicios, APIs, JNDI, RMI-IIOP Servicios, i APIs, JNDI, RMI-IIOP Servicios, i APIs, JNDI, RMI-IIOP

12 1.3.- Decisiones de diseño tomadas en nuestro caso de estudio El lenguaje de programación a usar es OO (Java) Las clases del modelo del dominio serán clases OO en el diagrama de clases del sistema (con sus atributos) Las asociaciones, generalizaciones, etc. las mantendremos en el diagrama de clases, siendo conscientes de que en la implementación se transformarán en atributos de clases, o en nuevas clases. Al ir construyendo los diagramas de secuencia, SE IRÁN AÑADIENDO nuevos métodos a las clases del diseño. Usaremos un sistema it de gestión de bases de dt datos OO (DB4o) Las clases/asociaciones/generalizaciones del modelo del dominio se transformarán directamente en clases con persistencia. Será necesario controlar la persistencia de cada uno de los objetos, tanto al consultar/recuperar como al insertar, modificar o borrar objetos.

Documentos relacionados

1. Asignar Responsabilidades a componentes de software es la habilidad más importante del AOO. Porque:

1. Asignar Responsabilidades a componentes de software es la habilidad más importante del AOO. Porque: Análisis y Diseño O.O. Preguntas del diseño : Cómo podrían asignarse responsabilidades a las clases de los objetos? Cómo podrían interactuar los objetos? Qué deberían hacer las clases? Patrones : Ciertas