wuolah-free-TEMA1.pdf

TEMA1.pdf pikopakoi Ingeniería de Sistemas de Información (Especialidad Sistemas de Información) 3º Grado en Ingeniería Informática Escuela Técnica Superior de Ingenierías Informática y de Telecomunicación Universidad de Granada...

TEMA1.pdf pikopakoi Ingeniería de Sistemas de Información (Especialidad Sistemas de Información) 3º Grado en Ingeniería Informática Escuela Técnica Superior de Ingenierías Informática y de Telecomunicación Universidad de Granada Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.  INGENIERIA DE SISTEMAS DE INFORMACIÓN Diseño. “Software design manifiesto”. - Un buen software: o Firmeza: Un programa no debería tener ningún error que inhibiese su función. o Comodidad: Un programa debe ser adecuado para los fines para los que fue destinado. Debe funcionar correctamente para lo que fue desarrollado. Debe resolver el problema para el que fue diseñado. o Deleite: La experiencia de usar el programa debe ser agradable. - Aquí tenemos los inicios de una teoría de diseño para el software. - A través del análisis se consiguen documentos que son capaces de describir lo que debe realizar el sistema. - Para diseñar el software, hay que crear nuestro modelo de datos. Además, también hay que hacer el diseño arquitectónico del sistema y una interfaz. Consejos de Pressman: - El diseño del software siempre debería empezar considerando los datos que son los cimientos para todos los demás elementos del diseño. - Una vez que los cimientos están en su sitio, se ha de derivar una arquitectura adecuada. - Sólo después de establecer la arquitectura del sistema se deben realizar las demás tareas de diseño (interfaces y componentes). El proceso de diseño. Hay dos maneras de construir un diseño de software. Una manera es hacerlo tan simple que obviamente no hay deficiencias, y la otra forma es hacerlo complicado que no presenta deficiencias obvias. Más complicado el primer método. Proceso iterativo mediante el cual se trasladan los requisitos en un “plano” [blueprint] para la construcción del software: - El diseño se representa a un nivel de abstracción alto (trazabilidad con los objetivos del sistema y sus requisitos más detallados). - Conforme avanzan las iteraciones de diseño, los refinamientos del diseño conducen a representaciones de menor nivel de abstracción (en las que la conexión con los requisitos del sistema es más sutil). Revisiones técnicas: - Evaluación de la calidad del diseño: o El diseño debe soportar todos los requisitos explicitos del sistema (los que aparecen en el documento de especificación de requisitos) y acomodar los requisitos implícitos deseados por los diferentes “stakeholders”. 1 a64b0469ff35958ef4ab887a898bd50bdfbbe91a-1674984 Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.  INGENIERIA DE SISTEMAS DE INFORMACIÓN o El diseño debe servir de guía comprensible para los encargados de su desarrollo, QA y soporte. o El diseño debe proporcionar una vista completa del sistema desde el punto de vista de su implementación. Calidad del diseño: Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. - Criterios teóricos para evaluar un diseño: o Arquitectura creada utilizando patrones y estilos arquitectónicos reconocibles. o Diseño modular (sistema dividido en elementos o subsistemas de forma lógica): componentes. o Arquitectura implementable iterativamente (para facilitar implementación y pruebas). o Representación de los datos, de la arquitectura, de las interfaces del sistema y de sus componentes. o Datos: estructuras de datos apropiadas. o Componentes: cohesión y acoplamiento. o Interfaces: Reducción de la complejidad de las conexiones entre componentes (y con sistemas externos). - FURPS: (Atributos de calidad (Hewlett-Packard) o Funcionalidad. o Usabilidad. o Fiabilidad. o Rendimiento. o Soporte. Técnicas de diseño. Evolución de las técnicas de diseño software. Orígenes: Se utilizaba un diseño descendente que consistía en aplicar Divide y Vencerás para conseguir problemas más simples. Más tarde, se empezó a desarrollar programas modulares. - Criterios para el desarrollo de programas modulares. - Métodos de refinamiento: Diseño descendente. Programación estructurada: Representar programa en forma de árbol. De forma descendiente se aplica Divide y Vencerás. Se puede ver como si la raíz del árbol fuese el main y las hojas fuesen las diferentes funciones para conseguir el propósito final. - Modularización. Dataflow programming (flujos de datos): Para organizar un sistema en función a los flujos de datos que se producen en ese sistema. Se tienen muchos programas pequeños que cada uno recibe y devuelve un flujo. Orientación a objetos: La idea es que vamos a tener una serie de módulos. Estos módulos se van a corresponder a los tipos de datos con los que estamos trabajando. Además, es capaz de realizar ocultación de información a través de atributos privados. Una tarjeta CRC es un análisis inicial de nuestras clases. Está formado por el nombre de la Clase y las Responsabilidades de esa clase y los colaborados de la clase. 2 a64b0469ff35958ef4ab887a898bd50bdfbbe91a-1674984 Tómate un descansito y cómete unos Flamin´ Hot Ingeniería de Sistemas de In... Banco de apuntes de la  INGENIERIA DE SISTEMAS DE INFORMACIÓN Otra forma de hacer este análisis es a través de un diagrama UML. - Ocultación de información. Diseño basado en componentes (CBD o CBSE). - Separation of Concerns (SoC). Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. - Middleware: EJB, COM, CORBA, SOA… Model-driven software development (MDSD). Caso práctico. Aplicaciones de gestión: - Requisitos funcionales: o Datos persistentes: Grandes volúmenes de datos organizados en bases de datos (relacionales, multidimensionales, NoSQL…). o Acceso concurrente: Múltiples usuarios accediendo al sistema. o Interfaz de usuario: GUI basada en ventanas, web y dispositivos móviles. o Integración con otras aplicaciones y sistemas: Uso de middleware e intercambio de datos. - Requisitos no funcionales: o Tiempo de respuesta. o “Responsividad”. o Latencia. o Throughput (trabajo/tiempo). o Escalabilidad:  Vertical: servidor más potente.  Horizontal: más servidores. - Evolución: o Mainframes:  Procesamiento por lotes y aplicaciones críticas.  Compatibilidad hacia atrás (software antiguo).  Redundancia: alta fiabilidad.  Sistemas de E/S: alto throughput.  Virtualización: alta utilización del hardware. o Virtualización:  Máquinas virtuales.  Instantáneas.  Migración y failover. o Arquitecturas cliente/servidor (C/S). o Arquitecturas multicapa:  Distribución física (3-tier architecture).  Clientes (GUI).  Servidores de aplicaciones.  Almacenamiento de datos.  Distribución lógica:  Capa de presentación (GUI y servicios).  Capa de aplicación (dominio).  Capa de acceso a los datos (DB y middleware). 3 a64b0469ff35958ef4ab887a898bd50bdfbbe91a-1674984 Tómate un descansito y cómete unos Flamin´ Hot  INGENIERIA DE SISTEMAS DE INFORMACIÓN o Arquitectura hexagonal. - ¿Dónde se implementa la lógica de la aplicación? o No es una buena idea implementarla en la capa de presentación (incrementa el coste de mantenimiento). o Alternativas habituales:  Rutinas: Procedimientos almacenados (RDBMS).  Módulos de datos: Herramientas de programación visual.  Módulos del dominio: Soluciones orientadas a objetos y MDSD.  Capa de servicio: Capa intermedia entre la capa de presentación y el modelo del dominio:  Provisión de un API para distintas aplicaciones.  Control de transacciones.  Comprobaciones de seguridad. 4 a64b0469ff35958ef4ab887a898bd50bdfbbe91a-1674984 Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad.