Академический Документы
Профессиональный Документы
Культура Документы
Diseo
Definicin
El proceso de definicin de la arquitectura, componente, interfaces y otras caractersticas de un sistema o de un componente. El resultado de este proceso.
IEEE std. 610.12-1990 Glossary of software engineering terminology
El diseo del software comprende la descripcin de la arquitectura del sistema con el nivel de detalle suficiente para guiar su construccin. Descomposicin del sistema Organizacin entre los componentes del sistema Interfaces entre los componentes
Diseo
Diseo es la actividad del ciclo de vida en la que se analizan los requisitos del software para desarrollar una descripcin de la estructura interna y la organizacin del sistema que servir de base para su construccin.
Requisitos
Diseo
Construccin
Diseo
Diseo detallado
del software
Definicin y estructura de los componentes y datos. Definicin de los interfaces Elaboracin de las estimaciones de tiempo y tamao.
Considerando que la descripcin del sistema (ConOps) dibuja una primera aproximacin del sistema en su conjunto, algunos autores diferencian entre: Diseo del sistema (la visin del documento de descripcin del sistema). Diseo de la arquitectura Diseo del detallado del software
5
Por qu?
El resumen de las razones expuestas que hacen necesarias las tareas de diseo antes de comenzar la construccin de un sistema son:
Permite la descomposicin del problema en partes y vistas de menor tamao, ms manejables para el trabajo intelectual del diseo de la solucin. Permite el desarrollo de modelos que se pueden analizar para determinar si cumplen los distintos requisitos. Permite examinar soluciones alternativas. Los modelos se pueden utilizar para planificar el desarrollo de las actividades, y son el punto de partida para empezar las actividades de codificacin y pruebas.
Descomposicin
de la complejidad
Requisitos
Etc.
8
y del desarrollo
Los borradores de manuales para mantenimiento y administracin Se ha realizado la trazabilidad del diseo Se ha revisado el diseo de la arquitectura Se ha verificado el diseo de la arquitectura Se ha escrito la planificacin de la integracin del software. Se ha establecido la lnea base del producto
10
11
Notacin empleada
Si bien el concepto y la finalidad del diseo o modelado de un sistema de software es siempre el mismo, las notaciones pueden variar en funcin de las caractersticas de cada proyecto o de los conocimientos o preferencias de las personas u organizacin que lo realice. A travs del lenguaje de modelado empleado (UML, IDEF, Diagramas de flujo, etc.) se consiguen realizar dos tipo de descripciones:
Descripciones estructurales
Las notaciones para descripciones estructurales suelen ser grficas y representan los diferentes componentes y sus relaciones. Lenguajes de descripcin de arquitecturas (ADL): AADL, AESOP, CODE, MetaH, Gestalt, Modechart, UML, Unicon, Modechart, etc. Diagramas de clases y objetos Diagramas de componentes Diagramas entidad-relacin Lenguajes de descripcin de interfaz Etc.
Descripciones de comportamiento
Diagramas de actividad Diagramas de colaboracin Diagramas de flujo de datos Diagramas de flujo Pseudo-cdigo y lenguajes de diseo (PDL) Diagramas de secuencia Etc.
12
Diseo estructurado
Esta es la aproximacin clsica y se centra en la identificacin y descomposicin de las principales funciones del sistema hacia niveles ms detallados.
Para cada estrategia hay numerosos mtodos (notaciones, lenguajes de modelado, tcnicas).
13
Estrategias
Las estrategias OO cubren tanto los requisitos como el anlisis, diseo y programacin. Anlisis Orientado a Objetos (OOA) Diseo Orientado a Objetos (OOD) Programacin Orientada a Objetos (OOP)
Mtodos
Las metodologas ms importantes de anlisis y diseo de sistemas, orientado a objetos, han terminado confluyendo en lo que es el UML (www.uml.org), bajo el respaldo del Object Management Group (www.omg.org).
Algunas de las principales metodologas, pioneras que han terminado confluyendo en el UML son: Object-Oriented Design (OOD), Booch. Object Modeling Technique (OMT), Rumbaugh. Object Oriented Analysis (OOA), Coad/Yourdon. Hierarchical Object Oriented Design (HOOD), ESA. Object Oriented Structured Design (OOSD), Wasserman. Object Oriented Systems Analysis (OOSA), Shaler y Mellor. Responsibility Driven Design (RDD), Wirfs-Brock, entre otros.
14
Enfoque OO
Este paradigma centra su foco en el concepto Objeto.
Objeto es aquello que tiene estado (propiedades ms valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los dems objetos). La estructura y comportamiento de objetos similares estn definidos en su clase comn; los trminos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento comn. La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstraccin, la "esencia" de un objeto, tal como son. De aqu que un objeto no es una clase, sin embargo, una clase puede ser un objeto.
Beneficios
del enfoque OO
Potencia, el uso del modelo OO ayuda a explotar el poder expresivo de los lenguajes de programacin basados u orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada, Java, C#
Reutilizacin, el uso del modelo OO favorece la reutilizacin, no solo del software, sino de diseos completos. Mantenibilidad, produce sistemas que estn construidos en formas intermedias estables y por ello son ms resistentes al cambio en especificaciones y tecnologa.
15
Abstraccin. Simplificacin en la descripcin o especificacin de un sistema consistente en enfatizar algunos detalles o propiedades del sistema, con detrimento o supresin de otros. Encapsulacin. Ocultacin de los detalles de un objeto que no contribuyen a sus caractersticas esenciales. Modularidad. Propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos coherentes e independientes. Jerarqua o herencia. Orden de las abstracciones organizado por niveles. Tipificacin. Definicin precisa de un objeto de forma tal que objetos de diferentes tipos no puedan ser intercambiados o, a lo sumo, pueden intercambiarse de manera muy restringida. Concurrencia . Propiedad que distingue un objeto que est activo de uno que no lo est. Persistencia. Propiedad de un objeto por la cual su existencia trasciende al tiempo (es decir, el objeto continua existiendo despus de que su creador ha dejado de existir) y/o al espacio (es decir, la localizacin del objeto se mueve del espacio de direccin en que fue creado).
16
UML
UML es un lenguaje de modelado que permite especificar, visualizar y documentar modelos de sistemas de software. Desde sus inicios fue concebido para ayudar a las tareas de anlisis de los sistemas de software, y este es sin duda el mbito de mayor utilizacin, si bien es cierto que en la actualidad tambin se emplea en el modelado y diseo de otros tipos de sistemas (modelos de negocio, producciones cinematogrficas, etc.)
Diagrama de casos de uso Diagrama de secuencia Diagrama de colaboracin Diagrama de actividad Diagrama de colaboracin Diagrama de estados
17
18
1.- Introduccin 1.1 Propsito 1.2 Alcance 1.3 Definiciones y acrnimos 2.- Referencias 3.- Descomposicin de la informacin 3.1 Descomposicin modular 3.1.1. Descripcin del mdulo 1 3.1.2. Descripcin del mdulo 2 3.2 Descomposicin de los proceesos 3.2.1. Descomposicin del proceso 1 3.2.2. Descomposicin del proceso 2 3.3 Descomposicin de los datos 3.3.1. Descripcin de la entidad 1 3.3.2. Descripcin de la entidad 2
4.- Descripcin de las dependencias 4.1 Dependencias intermolulares 4.2 Dependencias inter-procesos 4.3 Dependencias de los datos 5.- Descripcin de interfaces 5.1 Interfaces entre mdulos 5.1.1 Interfaz del mdulo 1 5.1.2 Interfaz del mdulo 2 5.2 Interfaces entre procesos 5.2.1 Interfaz del proceso 1 5.2.2 Interfaz del proceso 2 6.- Diseo detallado 6.1 Diseo detallado de los mdulos 6.1.1 Detalle del mdulo 1 6.1.2 Detalle del mdulo 2 6.2 Diseo detallado de los datos 6.1.1 Detalle de la entidad 1 6.1.2 Detalle de la entidad 2
19
Prcticas recomendadas
Trazabilidad
del diseo
Comprobacin de que el diseo incluye todos lols requisitos Comprobacin de que el diseo no incluye funciones adicionales no especificadas en el SRS. Los resultados de la trazabiliad del diseo deben estar documentados para la reunin de revisin del diseo
QU
CMO
20
21
Ingeniero de Software decide: Qu tareas hay que realizar Orden y Dependencias de tareas Tamao (Esfuerzo en horas) Solucin tcnica para la resolucin del problema Qu herramientas de anlisis y diseo hay que utilizar Riesgos tcnicos El modelo de procesos (Tcnicas) Actualizar la planificacin cuando los requisitos o el entorno cambian.
Gestor de Proyecto decide: Las habilidades necesarias para realizar las tareas La agenda para terminar el proyecto El coste de esfuerzo Metodologa para evaluar el estatus del proyecto Qu herramientas de planificacin hay que utilizar Gestin de riesgos El modelo de procesos (Gestin) Actualizar la planificacin cuando condiciones de gestin y entorno cambian. 22
Consideraciones
El diseo es la estrategia de solucin. Las tareas de codificacin, integracin y mantenimiento del sistema son la tctica. La estrategia debe ser adecuada a las necesidades de los usuarios (requisitos y atributos de calidad esperados). No surge de procesos, herramientas o lenguajes de modelado. Surge del talento de su creador. Los procesos, las herramientas y los lenguajes de modelado pueden resultar tiles como ayuda para descomponer la complejidad, y para comunicar el diseo a los participantes del proyecto. El talento de algunos profesionales les puede permitir manejar niveles de complejidad elevados sin necesitar apoyo de procesos, herramientas o lenguajes de modelado. A travs del cdigo es posible ver el diseo y la arquitectura del sistema. La documentacin del cdigo resulta til para comunicar su diseo a travs del espacio en sistemas en los que intervienen muchos desarrolladores, y del tiempo para facilitar su mantenimiento. Al emplear documentacin para la comunicacin del diseo es necesario trabajar con procesos suficientes para garantizar su integridad y actualidad a travs de los cambios. El diseo no cumple su finalidad hasta que no queda plasmado en el cdigo. El resultado del diseo puede fallar tanto errores en su estrategia como por distorsiones introducidas en la codificacin, integracin y mantenimiento.
23