1 Ingeniería del Software Diseñó de Software Universidad de los Andes Demián Gutierrez Mayo 2011.

Presentación del tema: "1 Ingeniería del Software Diseñó de Software Universidad de los Andes Demián Gutierrez Mayo 2011."— Transcripción de la presentación:

1 1 Ingeniería del Software Diseñó de Software Universidad de los Andes Demián Gutierrez Mayo 2011

2 2 ¿Qué es Diseño de Software? En Ingeniería del Software, el diseño es definir como se transformará el que en el como Definición de Requerimientos Diseño de Sistema y de Software Implementación y Pruebas de Unidades Integración y Prueba del Sistema Operación y Mantenimiento ¿Que voy a hacer? ¿Cómo lo voy a hacer? ¿Cómo se ve completo? ¿Lo hice bien?

3 3 ¿Qué es Diseño de Software? Diseño es el proceso creativo de transformar un problema en una solución. La descripción de esa solución es, también, denominada diseño Pfleeger, 1998 El diseño de software es el proceso de concebir (modelar) y especificar los detalles de como el sistema cumplirá las especificaciones de requerimientos establecidas en el análisis En Ingeniería del Software, el diseño es definir como se transformará el que en el como

4 4 ¿Qué es Diseño de Software? Diseño = Proceso Creativo Diseño = Solución No hay UNA única solución No existe una solución completamente óptima Sólo hay soluciones buenas, mediocres, malas... La evaluación y elección depende del cliente, de los requerimientos, del criterio del diseñador, del contexto, etcétera

5 5 ¿Qué es Diseño de Software? Diseño de la Interfaz H/MDiseño de los modelos de datos Diseño de las Interfaces con otros SistemasDiseño de la Arquitectura del Software ¿cómo? Requerimientos del Sistema (¿qué?) Diseño de Procesos / Interacción, etcétera El objetivo del diseño es “implementar” los requerimientos del usuario

6 6 ¿Qué es Diseño de Software? Diseño de la Interfaz H/M Diseño de los modelos de datos Diseño de la Arquitectura del Software (General) Diseño de las Interfaces con otros Sistemas El diseño se hace en función y para cada caso de uso......por medio de un “marco” conceptual preestablecido (Ej: Watch / Diseño Orientado a Objetos) Diseño Detallado de la Arquitectura (Clases / Secuencias)

7 7 Modelo 4+1 de Krutchen Introducido por Philippe Kruchten en 1995 Es un enfoque que permite ver distintas partes (facetas) de la arquitectura de un sistema por separado Usando UML, el sistema también puede ser diseñado en términos de vistas Vista Lógica o Estructural Vista de Implementación Vista de Despliegue Vista de Procesos Vista de Usuarios Una vista captura aspectos del sistema desde una o más perspectivas dadas

8 8 ¿Diseño de Software Conceptual / Técnico? Diseño Diseño Técnico (Interno) Diseño Conceptual (Externo) Orientado al Cliente Orientado a los “Constructores” (Programadores) del sistema Mayor nivel de Abstracción Menor nivel de Abstracción

9 9 ¿Diseño de Software Conceptual / Técnico? Conceptua l Técnic o

10 10 ¿Diseño de Software Conceptual (Externo)? Definir la estructura general del sistema programado Describir las funciones que deberá ejecutar el sistema bajo el ambiente operativo establecido en los requerimientos ¿El “qué”? ¿Casos de Uso? Resulta que desde cierto punto de vista, los casos de uso también forman parte el diseño

11 11 ¿Diseño de Software Conceptual (Externo)? Diseñar la Interfaz Usuario / Sistema, incluyendo la entrada de datos y salida de información Establecer los atributos de calidad de diseño que deberá satisfacer el sistema Describir las fuentes de los datos y sus procesos de transformación

12 12 ¿Diseño de Software Técnico (Interno)? Diseño de la Arquitectura: Usando Estilos Arquitectónicos, Patrones de Diseño, Frameworks (marcos)

13 13 ¿Diseño de Software Técnico (Interno)? Diseño de Archivos o Bases de Datos

14 14 ¿Arquitectura? La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución. IEEE 1471-2000

15 15 ¿Arquitectura? La Arquitectura de Software es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones Paul Clements, 1996

16 16 ¿Arquitectura? La Arquitectura de un sistema define la división y estructura de un sistema en subsistemas y establece un marco de control y comunicación entre los distintos subsistemas

17 17 ¿Arquitectura? Sistema de Visión Sistema de Identificación de Objetos Controlador de la Cinta Transportadora Sistema de Selección de Empaquetado Sistema de Empaquetado Controlador de la Mano Articulada Controlador del Brazo Sistema robótico de control de empaquetado Fuente: Sommerville / Ingeniería del Software

18 18 ¿Arquitectura?

19 19 ¿Arquitectura? Estructura y componentes* del sistema desde el punto de vista del programador Jerarquía y funciones de cada componente* de software Flujos de datos entre los componentes* Estructuras de datos empleadas por cada componente* * También se puede ver desde el punto de vista de Clases / Objetos

20 20 ¿En que afecta una buena / mala arquitectura? Rendimiento: Operaciones críticas en un pequeño número de subsistemas / reducción de comunicación entre subsistemas Protección: Es necesario proteger el acceso a ciertos recursos, se puede usar una arquitectura que esconda y limite el acceso y comunicación con los recursos a proteger Seguridad: Centralizar las operaciones relacionadas con la seguridad en un subsitema (o en un conjunto pequeño de subsistemas) para reducir costos y desarrollar los mecanismos de acceso adecuados Fuente: Sommerville / Ingeniería del Software

21 21 ¿En que afecta una buena / mala arquitectura? Disponibilidad: Incluir componentes redundantes y permitir reemplazar componentes sin necesidad de detener el sistema Mantenibilidad: Utilizar componentes independientes de grano fino que pueden modificarse con facilidad de forma independiente, separar productores de consumidores de información y evitar (o estandarizar) estructuras de datos compartidas Fuente: Sommerville / Ingeniería del Software Otros...

22 22 Arquitectura (Ejemplo) Arquitectura a 3 capas Capa de Presentación (Interfaz Gráfica de Usuario) (HTML, Swing, Qt, GTK, etcétera) Capa de Proceso / Negocio (Lógica / Reglas de Negocio) Capa de Persistencia BD

23 23 Arquitectura (Ejemplo con más detalle) BD Motor de Workflow (CledaFlow, CledaScheduler y CledaBase) Hibernate JDBC Documentos MVC CledaMVC (Struts1) o Echo2 Modelo de Dominio Servlets Navegador WEB CledaTags CledaCore Aplicación Arquitectura a 3 capas bien definida (Cleda)

24 24 Arquitectura (Ejemplo con más detalle) Detalle del Motor de Workflow Cliente Definición de Workflow (XML) Cargador BD Motor de Workflow (CledaFlow) HibernateJDBC Documentos Modelo de Workflow Scheduler (CledaSchedul er) Modelo de Scheduler Usuarios Perfiles Roles (CledaBase) Modelo de Cleda Base Agentes Embebido o Vía Web Services*

25 25 Diseño Arquitectónico Arquitectura del Software Bibliotecas / Componentes Patrones de Diseño Clases / Funciones Frameworks (Marcos) Estilos Arquitectónicos En general, estos elementos se verán mas adelante en clases

26 26 Gracias ¡Gracias!