Apuntes del tema - CTR

Introducción - Definición• Perspectiva del Proceso• Diseñar es el esfuerzo para definir laarquitectura, componentes, interfaces y otrascaracterísticas de un sistema o componente [IEEE610-1990].• El Diseño de Software es la actividad del ciclo de vidadel software en la cual se analizan los requisitos paraproducir una descripción de la estructura interna delsoftware que sirva de base para su construcción.• La salida es un conjunto de modelos y artefactos queregistran las principales decisiones adoptadas.Francisco Ruiz, Michael González Harbour - IS14.7Introducción - Definición• Perspectiva del Resultado• Un Diseño es el resultado de dicho esfuerzo.• Un Diseño Software describe:• La arquitectura del software (cómo estádescompuesto y organizado en componentes),• La interfaces entre dichos componentes, y• Los componentes a un nivel de detalle que permita suconstrucción.Francisco Ruiz, Michael González Harbour - IS14.84

Introducción – Diseño Arquitectural vs Detallado• Durante el diseño arquitectural es necesarioadoptar algunas decisiones:• ¿Existe una arquitectura genérica que pueda ser usada?• ¿Cómo será distribuido el sistema?• ¿Qué estilos arquitectónicos son apropiados?• ¿Qué aproximación se utilizará para estructurar elsistema?• ¿Cómo se descompondrá el sistema en módulos?• ¿Qué estrategia de control se utilizará?• ¿Cómo se evaluará el diseño arquitectural resultante?• ¿Cómo se documentará la arquitectura?Francisco Ruiz, Michael González Harbour - IS14.11Principios del Diseño de Software• Principios• Verdades básicas o leyes generales que se utilizan comobase de razonamiento o como guía para actuar.• Los Principios del Diseño Software son nocionesclave consideradas fundamentales en muchasaproximaciones y conceptos de diseño diferentes.Francisco Ruiz, Michael González Harbour - IS14.126

Principios del Diseño de Software• Abstracción• Olvidar información que diferencia ciertas cosas y asípoder tratarlas como si fueran similares.• En Software los mecanismos básicos de abstracciónson:• Parametrización• Especificación• Abstracción Procedural• Abstracción de Datos• Abstracción de Control (iteración)Francisco Ruiz, Michael González Harbour - IS14.13Principios del Diseño de Software• Acoplamiento y Cohesión• Acoplamiento: Fortaleza de las relaciones entremódulos• INTER• Cohesión: cómo están relacionados loselementos de un mismo módulo.• INTRAFrancisco Ruiz, Michael González Harbour - IS14.147

Principios del Diseño de Software• Descomposición• Descomponer un software en diversas unidadesmás pequeñas, habitualmente con el fin de situardiferentes funcionalidades o responsabilidades endiferentes componentes.• Encapsulamiento [ocultamiento de información]• Consiste en agrupar y empaquetar los elementosy detalles internos de una abstracción y hacer quedichos detalles sean inaccesibles desde fuera.Francisco Ruiz, Michael González Harbour - IS14.15Principios del Diseño de Software• Separación de Interfaz e Implementación• Definir un componente especificando una interfazpública,• conocida por otros componentes o clientes,• separada de los detalles de cómo dicho componenteestá realizado (implementado).• Suficiencia y Completitud• Asegurar que un componente software capturatodas las características importantes de unaabstracción y ninguna más.Francisco Ruiz, Michael González Harbour - IS14.168

Principios del Diseño de Software - Descomposición• Hay dos tipos de Descomposición• Estructuración/Organización del sistema:• El sistema en subsistemas• Descomposición modular:• Subsistemas en módulos.• Subsistemas vs Módulos• No siempre hay una diferenciación clara• Subsistema: Un sistema en sí mismo, cuyofuncionamiento es independiente de los servicios provistospor otros subsistemas.• Módulo: Componente de un sistema que provee serviciosa otros componentes y que no se considera un sistemaseparado.Francisco Ruiz, Michael González Harbour - IS14.17Principios del Diseño de Software - Descomposición• Aproximaciones para Descomposición Modular:• Objetos• El (sub)-sistema se decompone en objetos que interactúan.• Tubería o Flujo de Datos [orientado a funciones]• El (sub)-sistema se decompone en módulos funcionales quetransforman entradas en salidas.Francisco Ruiz, Michael González Harbour - IS14.189

Principales Retos• Al diseñar software es necesario enfrentarse a variosproblemas o dificultades importantes.• Atributos de Calidad que deben satisfacerse.• Ej: Rendimiento.• Cómo descomponer, organizar y empaquetarcomponentes.• Aspectos del comportamiento del software que no sondel dominio del problema o aplicación, sino de dominioslaterales que afectan de manera transversal a lafuncionalidad del sistema.• Estos aspectos no suelen suponer unidades de descomposiciónfuncional, sino que son propiedades que afectan a diversoscomponentes (en su rendimiento o semántica) de formasistemática.Francisco Ruiz, Michael González Harbour - IS14.19Principales Retos• En los últimos años se está abordando el problema delDiseño de Sistemas Software Genéricosmediante Líneas de Producto Software• Su objetivo es el diseño de familias deprogramas, es decir, colecciones de programas quetienen muchas cosas en común.• Ej: Gestión de Tiendas de Venta al Público• Haciendo reutilización al máximo, pero permitiendoadaptación y variabilidad en cada productoparticular.• Gestión de Tiendas de Ropa / Videoclubs / SupermercadosFrancisco Ruiz, Michael González Harbour - IS14.2010

Principales Retos - Aspectos• Los principales Aspectos Software a enfrentarson:• Concurrencia.• Cómo repartir el software en procesos, tareas o hilosde ejecución y abordar los problemas de eficiencia,atomicidad, sincronización y planificación asociados.• Control y Manejo de Eventos.• Cómo organizar datos y flujo de control.• Cómo manejar eventos reactivos y temporales• mediante mecanismos como invocación implícita o llamadashacia atrás (callbacks).Francisco Ruiz, Michael González Harbour - IS14.21Principales Retos - Aspectos• Los principales Aspectos Software a enfrentar son(cont.):• Distribución de componentes.• Cómo distribuir el software en el hardware.• Cómo comunicar los componentes.• Cómo utilizar el middleware para tratar con softwareheterogéneo.• Manejo de Errores y Excepciones y Toleranciaa Fallos.• Cómo prevenir y tolerar fallos y tratar condicionesexcepcionales (no previstas).Francisco Ruiz, Michael González Harbour - IS14.2211

Arquitectura del Software• Arquitectura• Estructura interna de algo• Forma en que algo es construido u organizado• Arquitectura Software• Descripción n de los subsistemas y componentes de unsistema software y de las interrelaciones entre ellosFrancisco Ruiz, Michael González Harbour - IS14.25Arquitectura del Software• Disponer de la Arquitectura de forma explícitasupone las siguientes ventajas• Comunicación con los interesados• Puede utilizarse para la discusión sobre cómo será el sistema.• Análisis del Sistema• Permite el análisis del cumplimiento de los requisitos nofuncionales.• Reutilización a gran escala• Puede servir para un grupo de sistemas parecidos.Francisco Ruiz, Michael González Harbour - IS14.2613

Arquitectura del Software• Los atributos de calidad del sistema (requisitos nofuncionales) se ven afectados por la arquitectura:• Rendimiento• Utilizar componentes grandes en vez de grano fino para concentrar lasoperaciones críticas y minimizar las comunicaciones.• Seguridad• Usar una arquitectura por capas con los activos críticos en las capas másinternas.• Protección• Localizar las características de protección críticas en un pequeño númerode componentes.• Disponibilidad• Incluir componentes redundantes y mecanismos de tolerancia a fallos.• Mantenibilidad• Usar componentes de grano fino más fácilmente sustituibles.Francisco Ruiz, Michael González Harbour - IS14.27Arquitectura del Software• Pero pueden aparecer conflictos:• Rendimiento vs Mantenibilidad• Usar componentes grandes mejora el rendimiento pero reduce lamantenibilidad.• Disponibilidad vs Seguridad• Introducir datos redundantes mejora la disponibilidad pero hacemás difícil la seguridad.• Protección vs Rendimiento• Localizar las características de protección en diversoscomponentes suele significar más comunicación y por tanto, unrendimiento peor.Francisco Ruiz, Michael González Harbour - IS14.2814

Arquitectura del Software• Se suele expresar mediante un diagrama de bloquesque resume la estructura del sistema.Arquitecturade un sistemade control deun robot deempaquetarFrancisco Ruiz, Michael González Harbour - IS14.29Arquitectura del Software - Vistas• Un Diseño Software se puede/debe describir ydocumentar mediante diferentes vistas.• Una Vista representa un aspecto parcial de un arquitecturasoftware que muestra propiedades específicas de unsistema software.• Un Diseño Software es un artefacto multiperspectivageneralmente compuesto de vistasrelativamente independientes y ortogonales.Francisco Ruiz, Michael González Harbour - IS14.3015

Arquitectura del Software - Vistas• Ejemplos de vistas son:• Lógica (requisitos funcionales)• De Proceso (concurrencia)• Física (distribución)• Desarrollo (descomposición del diseño en unidades deimplementación)• Otra clasificación también usada es:• Comportamiento• Funcional• Estructural• Modelado de DatosFrancisco Ruiz, Michael González Harbour - IS14.31Arquitectura del Software – Estilos Arquitecturales• Un estilo arquitectural es un conjunto derestricciones que definen un conjunto o familia dearquitecturas afines, que satisfacen dichasrestricciones.• Puede ser visto como un modelo de modelos (metamodelo)que enmarca a muy alto nivel laorganización del software (macro-arquitectura).• En sistemas grandes heterogéneos es comúncombinar varios estilos arquitecturales.Francisco Ruiz, Michael González Harbour - IS14.3216

Arquitectura del Software - Estilos Arquitecturales• Principales estilos arquitecturales :• Estructura General• Capas, tuberías y filtros, repositorio compartido (pizarra)• Sistemas Distribuidos• Cliente-servidor, tres capas, broker• Sistemas Interactivos• MVC (Modelo-Vista-Controlador), PAC (Presentación-Abstracción-Control)• Sistemas Adaptables• Micro-núcleo, reflexión• Otros• Batch (lotes), intérpretes, control de procesos, basado en reglasFrancisco Ruiz, Michael González Harbour - IS14.33Arquitectura del Software - Estilos Arquitecturales• Capas (Máquina Abstracta)• Organiza el sistema en un conjunto de capas, cada una delas cuales provee una serie de servicios a las capassuperiores usando los de las capas inferiores.Sistema de Gestión de la Configuración del SoftwareSistema de Gestión de ObjetosSistema de Base de DatosSistema OperativoFrancisco Ruiz, Michael González Harbour - IS14.3417

Arquitectura del Software - Estilos Arquitecturales• Repositorio Compartido• Los datos comunes a los subsistemas se almacenan enuna base de datos central o repositorio.• Se emplea cuando se comparten muchos datos.• Ventajas• Eficiente para compartir grandes cantidades de datos.• Los subsistemas no necesitan “preocuparse” de la gestión(backups, seguridad, …) de los datos.• Existe un modelo de datos compartido (esquema del repositorio).• Desventajas• Todos los subsistemas deben usar el mismo modelo de datos.• La evolución de datos es difícil y costosa.• No caben políticas de gestión de datos específicas.• Es difícil hacer una distribución eficiente.Francisco Ruiz, Michael González Harbour - IS14.35Arquitectura del Software - Estilos Arquitecturales• Cliente Servidor• Estructura un sistema distribuido en:• Servidores autosuficientes que proveen servicios (impresión,gestión de datos, ..).• Clientes que invocan dichos servicios.Cliente 1 Cliente 2 Cliente 3 Cliente 4Internet / RedServidor delcatálogocatálogoServidor deVideosarchivosde videoServidor deImágenesFotografíasdigitalesServidor WebmetadatosFrancisco Ruiz, Michael González Harbour - IS14.3618

Arquitectura del Software - Estilos Arquitecturales• Cliente Servidor• Ventajas• La distribución de datos es real y directa;• Se hace uso eficaz de sistemas en red. El hardware para ellopuede ser barato;• Es fácil añadir nuevos servidores o actualizar los existentes.• Desventajas• Los subsistemas usan diferentes modelos de datos. Esto puedehacer ineficiente el intercambio de datos;• Gestión redundante en cada servidor;• No existe un registro central de nombres y servicios. Puede serdifícil averiguar qué servidores y servicios están disponibles.Francisco Ruiz, Michael González Harbour - IS14.37Arquitectura del Software – Estilos de Control• Estos estilos arquitecturales están enfocados al flujode control entre subsistemas.• Control Centralizado• Un subsistema tiene toda la responsabilidad paracontrolar, iniciar y parar los otros subsistemas.• Llamada–Retorno (Call-Return)• Gestor (Manager)• Control basado en Eventos• Cada subsistema puede responder a eventos generadosexternamente por los otros subsistemas o el entorno delsistema.• Difusión (Broadcast)• Guiado por InterrupcionesFrancisco Ruiz, Michael González Harbour - IS14.3819

Arquitectura del Software – Estilos de Control• Control Centralizado• Llamada-Retorno• Jerarquía Top-Down de Subrutinas (operaciones)Francisco Ruiz, Michael González Harbour - IS14.39Arquitectura del Software – Estilos de Control• Control basado en Eventos• Difusión (Broadcast)• Cuando ocurre un evento el control se transfiere alsubsistema que puede tratarlo.• Cada subsistema decide sobre los eventos que leinteresan.Subsistema1Subsistema2Subsistema3Subsistema4Manejador de eventos y mensajesFrancisco Ruiz, Michael González Harbour - IS14.4020

Arquitectura del Software – Estilos de Control• Control basado en Eventos• Guiado por Interrupciones• Cada interrupción tiene un manejador.Francisco Ruiz, Michael González Harbour - IS14.41Arquitectura del Software – Patrones de Diseño• Patrón• Solución común a un problema común en un contextodado.• Los estilos arquitecturales pueden ser vistoscomo patrones para la organización de alto nivel delsoftware (patrones macro-arquitecturales).• Otros patrones de diseño sirven para describir a unnivel más bajo, más local (patrones microarquitecturales).Francisco Ruiz, Michael González Harbour - IS14.4221

Arquitectura del Software – Patrones de Diseño• Principales clases de patrones de diseño [microarquitecturales].• Creacionales• Constructor (builder), factoría (factory), prototipo (prototype),ente único (singleton)• Estructurales• Adaptador (adapter), puente (bridge), compuesto (composite),decorador (decorator), fachada (facade), peso mosca (flyweight),delegado (proxy)• De Comportamiento• De órdenes (command), intérprete (interpreter), iterador(iterator), mediador (mediator), memento, observador (observer),estado (state), estrategia (strategy), plantilla (template), visitante(visitor)Francisco Ruiz, Michael González Harbour - IS14.43Notaciones• Existen muchas notaciones y lenguajes pararepresentar los artefactos del diseño software.• Unas son para representar la estructura y otras elcomportamiento• Unas sirven principalmente durante el diseñoarquitectural, otras durante el diseño detallado, y algunasdurante ambos.• Algunas se emplean principalmente en el contexto demétodos específicosFrancisco Ruiz, Michael González Harbour - IS14.4422

Notaciones – Descripciones Estructurales• Las siguientes notaciones describen aspectosestructurales (estática), es decir, los componentesy sus interconexiones.• Lenguajes de Descripción de Arquitecturas (ADLs)• Lenguajes textuales formales ideados para describir unaarquitectura software en términos de componentes y conectores.• Diagramas de Clases y Objetos• Para representar un conjunto de clases (y objetos) y susinterrelaciones.• Diagramas de Componentes• Para representar un conjunto de componentes (partes físicas yreemplazables de un sistema que son conformes a y proveen unconjunto de interfaces) y sus interrelaciones.Francisco Ruiz, Michael González Harbour - IS14.45Notaciones – Descripciones Estructurales• Las siguientes notaciones describen aspectosestructurales (estática), es decir, los componentesy sus interconexiones (cont).• Tarjetas CRC (Clase Responsabilidad Colaborador)• Para denotar los nombres de los componentes (clases), susresponsabilidades, y los nombres de los componentes con los quecolaboran.• Diagramas de Despliegue• Para representar un conjunto de nodos físicos y susinterrelaciones, modelando los aspectos físicos de un sistema.• Diagramas Entidad-Interrelación• Para representar modelos conceptuales de los datos almacenadosen sistemas de información.Francisco Ruiz, Michael González Harbour - IS14.4623

Notaciones – Descripciones Estructurales• Las siguientes notaciones describen aspectosestructurales (estática), es decir, los componentesy sus interconexiones (cont).• Lenguajes de Descripción de Interfaces (IDLs)• Similares a los lenguajes de programación normales, sirven paradefinir las interfaces (nombres y tipos de las operacionesexportadas) de los componentes software.• Diagramas de Estructura de Jackson• Para describir las estructuras de datos en términos de secuencia,selección e iteración.• Grafo de Estructura• Para describir la estructura de llamadas de los programas (quémódulos llaman y son llamados por qué módulos).Francisco Ruiz, Michael González Harbour - IS14.47Notaciones – Descripciones del Comportamiento• Las siguientes notaciones y lenguajes sirvan paradescribir el comportamiento (dinámica) de unsoftware y sus componentes.• Diagramas de Actividad• Para mostrar el flujo de control entre actividades (ejecuciones noatómicas dentro de una máquina de estados).• Diagramas de Colaboración• Para mostrar las interacciones entre un grupo de objetos,haciendo énfasis en los objetos, sus conexiones y los mensajesque intercambian en dichas conexiones.• Diagramas de Flujo de Datos (DFDs)• Para representar el flujo de datos entre un conjunto de procesos.Francisco Ruiz, Michael González Harbour - IS14.4824

Notaciones – Descripciones del Comportamiento• Las siguientes notaciones y lenguajes sirvan paradescribir el comportamiento (dinámica) de unsoftware y sus componentes (cont).• Tablas y Diagramas de Decisión• Para representar combinaciones complejas de condiciones yacciones.• Diagramas de Flujo [Estructurados]• Para representar el flujo de control y las acciones asociadas quedeben ser realizadas.Francisco Ruiz, Michael González Harbour - IS14.49Notaciones – Descripciones del Comportamiento• Las siguientes notaciones y lenguajes sirvan paradescribir el comportamiento (dinámica) de unsoftware y sus componentes (cont).• Diagramas de Secuencia• Para mostrar las interacciones entre un grupo de objetos, conénfasis en la ordenación temporal de los mensajes.• Diagramas de Transición de Estados y Grafos deMáquinas de Estados• Para mostrar el flujo de control entre estados de una máquina deestados.Francisco Ruiz, Michael González Harbour - IS14.5025

Notaciones – Descripciones del Comportamiento• Las siguientes notaciones y lenguajes sirvan paradescribir el comportamiento (dinámica) de unsoftware y sus componentes (cont).• Lenguajes de Especificación Formal• Lenguajes textuales que usan nociones básicas matemáticas(lógica, conjuntos, secuencia) para definir de forma rigurosa yabstracta las interfaces y el comportamiento de los componentes(habitualmente en términos de pre y post-condiciones).• Pseudocódigo y Lenguajes de Diseño de Programas• Lenguajes, al estilo de los tradicionales de programaciónestructurada, usados para describir, normalmente en la etapa dediseño detallado, el comportamiento de un procedimiento ométodo.Francisco Ruiz, Michael González Harbour - IS14.51Tipos de Modelos• Muchas de las notaciones anteriores son de tipográfico (Modelos).• En una clasificación alternativa a la anterior(estructura-comportamiento), algunos de losprincipales tipos de modelos del software son• De Contexto• De Procesos• De Comportamiento• De Flujo de Datos• De Máquinas de Estados• De Datos• De ObjetosFrancisco Ruiz, Michael González Harbour - IS14.5226

Tipos de Modelos• Modelos de Contexto• Ilustran el contexto operacional de un sistema, mostrandolos demás sistemas con los que se interactúa.Contexto de un CajeroAutomáticoSistemaContable de laSucursalSistemaAuxiliar de laSucursalFrancisco Ruiz, Michael González Harbour - IS1Sistema deProtecciónCajeroAutomáticoSistema deMantenimientoBase de Datosde cuentasBase de Datosde uso común4.53Tipos de Modelos• Modelos de Procesos (de Negocio)• Muestran los procesos soportados por el sistema.Proceso de adquisición deequipamientoFrancisco Ruiz, Michael González Harbour - IS14.5427

Tipos de Modelos• Modelos de Comportamiento – Procesamientode Datos• Muestran cómo los datos son procesados por el sistema.DFDCarnetSELEC.TIPOCARNET1CarnetEstudianteCarnetTrabajadorTRATARESTUDIANTE2TRATARTRABAJADOR3EntradaEntradaFrancisco Ruiz, Michael González Harbour - IS14.55Tipos de Modelos• Modelos de Comportamiento – Máquinas deEstado• Muestran la respuesta del sistema ante eventos.Statechart de un microondasFrancisco Ruiz, Michael González Harbour - IS14.5628

Tipos de Modelos• Modelos de Datos• Describen la estructuralógica de los datosprocesados por elsistema.E-R de un sistema depréstamo electrónico deartículosFrancisco Ruiz, Michael González Harbour - IS14.57Tipos de Modelos• Modelos de Objetos• Describen el sistema en términos de clases de objetos ysus asociaciones.• Objetos/clases son una forma de reflejar las entidades delmundo real manipuladas por el sistema.• Otras entidades más abstractas pueden ser difíciles demodelar con esta aproximación.• Las clases reflejan entidades del dominio de aplicación queserán reutilizables en distintas partes del sistema.• UML es el estándar para este tipo de modelosFrancisco Ruiz, Michael González Harbour - IS14.5829

Tipos de Modelos• Modelos de ObjetosHerenciaJerarquía de clases deuna bibliotecaFrancisco Ruiz, Michael González Harbour - IS14.59Tipos de Modelos• Modelos de ObjetosAgregaciónDescomposición de un“paquete de estudio”Francisco Ruiz, Michael González Harbour - IS14.6030

Tipos de Modelos• Modelos de ObjetosComportamientoDiagrama deSecuencia del caso“préstamoelectrónico deartículos”Francisco Ruiz, Michael González Harbour - IS14.61Tipos de Modelos - Arquitecturales• Se emplean para documentar la arquitectura del sistema• Pueden ser• Estructurales estáticos, para mostrar los componentes principales osubsistemas.• De Proceso dinámicos, para mostrar la estructura de procesos delsistema.• De Interfaces, para definir las interfaces de los subsistemas.• De Relaciones, para mostrar las relaciones entre subsistemas deforma similar a un DFD.• De Distribución, para mostrar cómo los subsistemas de distribuyenentre diversas máquinas.Francisco Ruiz, Michael González Harbour - IS14.6231

Estrategias y Métodos• Las estrategias generales de diseño de softwaremás conocidas son• Divide y vencerás• Refinamiento en pasos sucesivos• Top-down vs bottom-up• Abstracción de datos y ocultamiento deinformación• Uso de heurísticas• Uso de patrones• Aproximación iterativa e incrementalFrancisco Ruiz, Michael González Harbour - IS14.63Estrategias y Métodos – Diseño Estructurado• Método clásico de diseño de software basadoen• Identificar las funciones principales, y• Elaborarlas y refinarlas en un estilo top-down.• Se realiza después del análisis estructurado,para producir, entre otros:• Diagramas de Flujos de Datos (DFDs)• Descripciones de los procesos asociados.Francisco Ruiz, Michael González Harbour - IS14.6432

Estrategias y Métodos – Diseño EstructuradoDiseño dealto nivel(arquitectónico)Diseño debajo nivel(detallado)Actividades del Diseño EstructuradoEnfoque de datosModelo lógico de datosModelo físico de datosEsquema de BDy ficherosE-RERSDFDCodificación/ProgramaciónArquitectura de procesosEstructura detallada:programas y módulosCuadernos decargaEnfoque funcionalAnálisis (Qué)Lenguaje comprensiblepara el usuario/clienteDiseñoDecisiones generalesy abstractas (organizaciónlógica)(Cómo)Decisiones concretasy específicas (optimizacióny rendimiento)ImplementaciónLenguaje comprensiblepor la máquinaFrancisco Ruiz, Michael González Harbour - IS14.65Estrategias y Métodos – Diseño EstructuradoTécnicas de Especificación según el enfoque de modeladoINFORMACIONER-DFD- Matriz Entidad-función- Diagrama de historia de vida- Matriz entidad-eventoDFDFUNCION- Diagrama Transiciónestado- Redes de petriTIEMPOLista deeventosFrancisco Ruiz, Michael González Harbour - IS14.6633

Estrategias y Métodos – Diseño Estructurado• Diagrama de Flujo de Datos (DFD): Diagrama enforma de grafo dirigido que representa el flujo de datos y lastransformaciones que se aplican sobre ellos al moverse desdela entrada hasta la salida del sistema.• Elementos:• Procesos• Almacenes• Entidades externas• Flujos de datosFlujos de datosProcesosAlmacenes dedatosYourdon, DeMarcoGane y SarsonSSADMMÉTRICAEntidadesexternasFrancisco Ruiz, Michael González Harbour - IS14.67Estrategias y Métodos – Diseño Estructurado• Diagrama de ContextoEjemplos DFDsBibliotecarioAltas_Bajas_LibrosPetición_LibrosUsuarioDevol_Libros0GestionarBibliotecaSanciónFrancisco Ruiz, Michael González Harbour - IS14.6834

Estrategias y Métodos – Diseño EstructuradoEjemplos DFDsPetición_Libros1GestionarPeticionesPréstamosDevol_Libros2GestionarDevoluciones• Diagrama deSistemaLibros3ActualizarLibrosSanciónAltas_Bajas_LibrosFrancisco Ruiz, Michael González Harbour - IS14.69Estrategias y Métodos – Diseño EstructuradoEjemplos DFDs• Diagrama de Sistema detalladoPetición_LibrosPréstamos1.1ValidarPréstamoPréstamo_Validado1.2RealizarPréstamoLibrosFrancisco Ruiz, Michael González Harbour - IS14.7035

Estrategias y Métodos – Diseño Estructurado• Habitualmente, a partir de los DFDs (comportamiento) segenera un Diagrama de Estructura (DE)A11 2cbA2d3CaopciónLeer Opción12 3Francisco Ruiz, Michael González Harbour - IS14.71Estrategias y Métodos – Diseño Estructurado• Existen varios tipos de Diagramas de Estructura(cambian en la simbología usada):• Diagramas de Jackson• Diagrama de Cuadros de Constantine (usados en METRICA 3)• Un DE muestra la descomposición de un sistema enmódulos incluyendo• Jerarquía de Control Llamadas entre Módulos• Parámetros que se intercambian en las llamadas• Elementos Principales:1. Módulos2. Conexiones entre Módulos3. Comunicación entre MódulosFrancisco Ruiz, Michael González Harbour - IS14.7236

Estrategias y Métodos – Diseño Estructurado• Diagrama de EstructuraIteraciónPET_ACEPTADACONSULTARSTOCKPET_ACEPTADADecisiónGESTIONARPETICIONESTRATARPETICIONINFORMEPRESTAMOMóduloINFORMEPRESTAMOINFORMARPETICIONDatosPET_PRESTAMOLEERPETICIONPRESTAMOEOFRECHAZARPETICIONPET_RECHAZADAControl (flag)Módulo PredefinidoFrancisco Ruiz, Michael González Harbour - IS14.73Estrategias y Métodos – Diseño OO• Obviamente el Diseño OO está relacionado con el Análisis y laProgramación OO• Análisis OO• Desarrollar un modelo de objetos del dominio de aplicación• Diseño OO• Desarrollar un modelo del sistema orientado a objetos que satisfagalos requisitos.• Programación OO• Implementar un diseño OO usando un lenguaje de programación OO.Francisco Ruiz, Michael González Harbour - IS14.7437

Estrategias y Métodos – Diseño OO• Existentes muchos métodos de diseñobasados en objetos• Desde los iniciales [80’s]• Nombre->objeto, verbo->método, adjetivo->atributo• Centrales [90’s]• Herencia y polimorfismo juegan un papel clave• Diseño basado en Componentes (CBD) [00’s]• Meta-información que puede ser definida y accedida(mediante reflexión)Francisco Ruiz, Michael González Harbour - IS14.75Estrategias y Métodos – Diseño OO• En general, en todos los métodos de DiseñoOO se llevan a cabo las siguientesactividades:• Definir el contexto y modos de uso delsistema;• Diseñar la arquitectura del sistema;• Identificar los objetos principales del sistema;• Desarrollar los modelos de diseño;• Especificar las interfaces de los objetos.Francisco Ruiz, Michael González Harbour - IS14.7638

Estrategias y Métodos – Diseño OO• Ejemplo• Se necesita un sistema de mapas climáticos paragenerar mapas del tiempo de una forma regular usandolos datos recopilados de estaciones meteorológicasremotas automáticas y otras fuentes como observadores,globos y satélites. Las estaciones meteorológicastransmiten sus datos al computador del sistema cuandoreciben una petición al respecto desde dicha máquina.• El computador del sistema valida los datos recopilados ylos integra con los datos de otras fuentes diferentes. Losdatos integrados se archivan y, usando dichos datos y unabase de datos de mapas digitalizados, se elabora un juegode mapas del tiempo locales. Los mapas puedenimprimirse para su distribución en una impresora demapas especializada o pueden mostrarse en variosformatos diferentes.Francisco Ruiz, Michael González Harbour - IS14.77Estrategias y Métodos – Diseño OO• Ejemplo - Contexto del Sistema(subsistemas)«subsistema»Recogida datos«subsistema»Visualización DatosObservadorEstaciónMeteorológicaComunicacionesSatéliteGloboInterfaz deUserusuario inter faceMapasVisualizadorde MapasImpresorade Mapas«subsistema»Procesamiento Datos«subsistema»Archivo DatosControlDatosIntegraciónDatosAlmacénMapasData Datastorage storageAlmacénDatosFrancisco Ruiz, Michael González Harbour - IS14.7839

Estrategias y Métodos – Diseño OO• Ejemplo – Modelos de Uso• Casos de UsoIniciarApagarInformarCalibrarSistema Estación MeteorológicaCaso de Uso InformarActores Sistema de recolección de datos climáticos, Estación meteorológicaLa estación meteorológica envía un resumen de los datos climáticos quehan sido recogidos de los instrumentos en el período de recolección alsistema de recolección de datos climáticos. Los datos enviados son:Datos temperaturas mínima, máxima y media de tierra y aire; presiónatmosférica máxima, mínima y media; velocidad del viento máxima,mínima y media; total de lluvia caída; y dirección del viento. Se tomanmuestras de estos datos cada 5 minutos.El sistema de recolección de datos climáticos establece una conexión porEstímulos modem con la estación meteorológica y le requiere la transmisión dedatos.Los datos resumidos (agregados) se envían al sistema de recolección deRespuestadatos.Habitualmente las estaciones meteorológicas reciben la petición deComentariosinformar una vez por hora, pero esta frecuencia puede diferir de unaestación a otra y cambiar en el futuro.ProbarFrancisco Ruiz, Michael González Harbour - IS14.79Estrategias y Métodos – Diseño OO• Ejemplo – Arquitectura por capasEstación Meteorológica«subsistema»InterfazGestiona todaslas comunicacionesexternas«subsistema»Recogida DatosRecopila y resumedatos del tiempo«subsistema»InstrumentosPaquete deinstrumentos pararecogida física de datosNo más m s de 7 entidades en un modelo arquitecturalFrancisco Ruiz, Michael González Harbour - IS14.8040

Estrategias y Métodos – Diseño OO• Ejemplo – Identificar objetos (clases)EstacionMeteorologicaidentifierreportWeather()calibrate (instruments)test ()startup (instruments)shutdown (instruments)DatosClimaticosairTemperaturesgroundTemperatureswindSpeedswindDirectionspressuresrainfallcollect ()summarise ()Termometrotemperaturatest ()calibr ate ()AnemometrowindSpeedwindDirectiontest ()Barometropressureheighttest ()calibrate()Francisco Ruiz, Michael González Harbour - IS14.81Estrategias y Métodos – Diseño OO• Ejemplo – Modelos de Diseño• Estático: Objetospor Subsistemas«subsistema»Interfaz«subsistema»Recogida DatosControladorComunicDatosClimaticosEstacionMeteorologicaEstadoInstrumentos«subsistema»InstrumentosTermometroAirePluviometroAnemometroTermometroTierraBarometroVeletaFrancisco Ruiz, Michael González Harbour - IS14.8241

Estrategias y Métodos – Diseño OO• Ejemplo – Modelos de Diseño• Dinámico: Secuencia del caso de uso “Informar”:ControladorComunic:EstacionMeteorologica:DatosClimaticosrequest(report)acknowledge()report()summarise()reply(report)send(report)acknowledge()Francisco Ruiz, Michael González Harbour - IS14.83Estrategias y Métodos – Diseño OO• Ejemplo – Modelos de Diseño• Dinámico: Máquina de estados de “EstacionMeteorologica”Operacióncalibrate()Calibrandocalibración OKstartup()test()Apagado Esperando Probandoshutdown()transmisión realizadaprueba completadarelojRecopilandorecogidarealizadaResumiendoreportWeather()Transmitiendoresumen completadoFrancisco Ruiz, Michael González Harbour - IS14.8442

Estrategias y Métodos – Diseño OO• Ejemplo – Interfaz Java de “EstacionMeteorologica”interface WeatherStation {public void WeatherStation () ;public void startup () ;public void startup (Instrument i) ;public void shutdown () ;public void shutdown (Instrument i) ;public void reportWeather ( ) ;public void test () ;public void test ( Instrument i ) ;public void calibrate ( Instrument i) ;public int getID () ;} //WeatherStationFrancisco Ruiz, Michael González Harbour - IS14.85Estrategias y Métodos – Diseño Centrado en los Datos• En estos métodos las estructuras de datos guíanel diseño.• Método de Jackson• Método de Warnier-Orr• Se diferencian de los estructurados en que el focoson las estructuras de datos que manipula unprograma y no las funciones que realiza con ellas.• Hay dos pasos principales:• Describir las estructuras de datos de entrada y salida(Diagramas de estructura de Jackson)• Desarrollar las estructuras de control basadas en dichasestructuras de datos.Francisco Ruiz, Michael González Harbour - IS14.8643

Estrategias y Métodos – Diseño con Componentes• Diseño Basado en Componentes (CBD)• Un Componente Software es una unidadindependiente con interfaces y dependencias biendefinidas, que pueda ser desarrollada ydesplegada de forma independiente.• Principio de Caja Negra.• CBD aborda problemas para proveer,desarrollar e integrar componentes.• Su finalidad es mejorar la reutilización.Francisco Ruiz, Michael González Harbour - IS14.8744