construccion

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

construccion [2012/06/06 12:15] (current)
Line 1: Line 1:
 +====== Diseño de alto nivel ======
 +
 +En la fase de Diseño de Alto Nivel de un ciclo de desarrollo se investiga sobre el problema, intentando diseñar lo que va a ser la interacción del sistema con el exterior.
 +
 +===== Actividades =====
 +
 +  - Definir Casos de Uso Esenciales en formato expandido. (si no están definidos)
 +  - Refinar los Diagramas de Casos de Uso.
 +  - Definir los Diagramas de Secuencia del Sistema.
 +  - Refinar el Modelo Conceptual.
 +  - Refinar el Glosario. (continuado en posteriores fases)
 +  - Definir Contratos de Operación.
 +  - Definir Diagramas de Estado. (opcional)
 +
 +===== Diagramas de secuencia del sistema =====
 +
 +Para comenzar a modelar el comportamiento del sistema tal y como los actores lo necesitan vamos a partir de los casos de uso. Para cada caso de uso se va a construir una serie de Diagramas de Secuencia que muestren los eventos que llegan al sistema para cada escenario del caso de uso.
 +
 +En cada caso de uso se muestra una interacción de actores con el sistema. En esta interacción los actores generan eventos, solicitando al sistema operaciones.
 +
 +Los casos de uso representan una interacción genérica. Una instancia de un caso de uso se denomina **escenario**, y muestra una ejecución real del caso de uso, con las posibles bifurcaciones y alternativas resueltas de forma particular.
 +
 +Un Diagrama de Secuencia de Sistema se representa usando la notación para **diagramas de secuencia de UML**.
 +
 +==== Construcción de un diagrama de secuencias ====
 +
 +  - Representar el sistema como un objeto con una línea debajo.
 +  - Identificar los actores que directamente operan con el sistema, y dibujar una línea para cada uno de ellos.
 +  - Partiendo del texto del curso típico de eventos del caso de uso, identificar los eventos (externos) del sistema que cada actor genera y representarlos en el diagrama.
 +  - Opcionalmente, incluir el texto del caso de uso en el margen del diagrama.
 +
 +Con el Diagrama de Secuencia identificamos las Operaciones del Sistema. Cada Operación del Sistema va a definirse en cuanto a qué se espera de ella mediante un contrato. Tal definición se va a basar en los cambios que sufren los elementos del Modelo Conceptual. Los Contratos de las Operaciones del Sistema y el Modelo Conceptual van a ir desarrollándose en paralelo: en cada definición de un contrato se va hacer referencia a cambios en el modelo conceptual.
 +
 +===== Modelo conceptual =====
 +
 +Una parte de la investigación sobre el dominio del problema consiste en identificar los conceptos que lo conforman. Para representar estos conceptos se va a usar un **Diagrama de Estructura Estática de UML**, al que se va a llamar Modelo Conceptual.
 +
 +En el Modelo Conceptual se tiene una representación de conceptos del mundo real, no de componentes software.
 +
 +==== Identificación de conceptos ====
 +
 +Para identificar conceptos hay que basarse en los requisitos, en la descripción de los casos de uso y en el conocimiento general acerca del dominio del problema.
 +
 +Otro consejo para identificar conceptos consiste en buscar sustantivos en los documentos de requisitos o, más concretamente, en la descripción de los casos de uso. No es un método infalible, pero puede servir de guía para empezar.
 +
 +==== Creación del modelo conceptual ====
 +
 +  - Hacer una lista de conceptos candidato usando la Lista de Categorías de Conceptos y la búsqueda de sustantivos relacionados con los requisitos en consideración en este ciclo.
 +  - Representarlos en un diagrama.
 +  - Añadir las asociaciones necesarias para ilustrar las relaciones entre conceptos que es necesario conocer.
 +  - Añadir los atributos necesarios para contener toda la información que se necesite conocer de cada concepto.
 +
 +==== Identificación de asociaciones ====
 +
 +Una asociación es una relación entre conceptos que indica una conexión con sentido y que es de interés en el conjunto de casos de uso que se está tratando.
 +
 +Se incluyen en el modelo las asociaciones siguientes:
 +
 +  - Asociaciones para las que el conocimiento de la relación necesita mantenerse por un cierto período de tiempo (asociaciones “necesita-conocer”).
 +  - Asociaciones derivadas de la Lista de Asociaciones Típicas que se muestra en la siguiente tabla:
 +
 +{{ uml:tipus-associacions.png }}
 +
 +==== Identificación de atributos ====
 +
 +Es necesario incorporar al Modelo Conceptual los atributos necesarios para satisfacer las necesidades de información de los casos de uso que se estén desarrollando en ese momento. Los atributos deben tomar valor en tipos simples (número, texto, etc.), pues los tipos complejos deberían ser modelados como conceptos y ser relacionados mediante asociaciones.
 +
 +
 +
 +===== Glosario =====
 +
 +En el glosario debe aparecer una descripción textual de cualquier elemento de cualquier modelo, para eliminar toda posible ambigüedad.
 +
 +===== Contratos de operaciones =====
 +
 +Un Contrato es un documento que describe qué es lo que se espera de una operación. Tiene una redacción en estilo declarativo, enfatizando en el qué más que en el cómo. Lo más común es expresar los contratos en forma de pre- y post-condiciones en torno a cambios de estado. Se puede escribir un contrato para un método individual de una clase software, o para una operación del sistema completa. Un Contrato de Operación del Sistema describe cambios en el estado del sistema cuando una operación del sistema es invocada.
 +
 +{{ uml:contrato-operacion.png }}
 +
 +
 +==== Construcción de un contrato ====
 +
 +  - Identificar las operaciones del sistema a partir de los Diagramas de Secuencia del Sistema.
 +  - Para cada operación del sistema construir un contrato.
 +  - Empezar escribiendo el apartado de Responsabilidades, describiendo informalmente el propósito de la operación.
 +  - A continuación rellenar el apartado de Post-condiciones, describiendo declarativamente los cambios de estado que sufren los objetos en el Modelo Conceptual.
 +  - Para describir las post-condiciones, usar las siguientes categorías:
 +    - Creación y borrado de instancias.
 +    - Modificación de atributos.
 +    - Asociaciones formadas y retiradas.
 +  - Completar el resto de apartados en su caso.
 +
 +
 +==== Construcción de un contrato ====
 +
 +Éstas se basan en el Modelo Conceptual, en los cambios que sufren los elementos del mismo una vez se ha realizado la operación. Es mejor usar el tiempo pasado o el pretérito perfecto al redactar una post-condición, para enfatizar que se trata de declaraciones sobre un cambio en el estado que ya ha pasado. Por ejemplo es mejor decir “se ha creado una Sesión” que decir “crear una Sesión”.
 +
 +Cuando se ha creado un objeto, lo normal es que se haya asociado a algún otro objeto ya existente, porque si no queda aislado del resto del sistema. Por tanto, al escribir las postcondiciones hay que acordarse de añadir asociaciones a los objetos creados. Olvidar incluir estas asociaciones es el fallo más común cometido al escribir las post-condiciones de un contrato.
 +
 +
 +===== Diagramas de estados =====
 +
 +Para modelar el comportamiento del sistema pueden usarse los **Diagramas de Estados que define UML**. Se puede aplicar un Diagrama de Estados al comportamiento de los siguientes elementos:
 +
 +  - Una clase software.
 +  - Un concepto.
 +  - Un caso de uso.
 +
 +En la fase de Diseño de Alto Nivel sólo se haría para los dos últimos tipos de elemento, pues una clase software pertenece al Diagrama de Clases de Diseño. Puesto que el sistema entero puede ser representado por un concepto, también se puede modelar el comportamiento del sistema completo mediante un Diagrama de Estados.
 +
 +La utilidad de un Diagrama de Estados en el Diseño de Alto Nivel reside en mostrar la secuencia permitida de eventos externos que pueden ser reconocidos y tratados por el sistema.
 +
 +
 +====== Diseño de bajo nivel ======
 +
 +En la fase de Diseño de Bajo Nivel se crea una solución a nivel lógico para satisfacer los requisitos, basándose en lo diseñado en la fase de Diseño de Alto Nivel.
 +
 +===== Actividades =====
 +
 +  - Definir los Casos de Uso Reales.
 +  - Definir Informes e Interfaz de Usuario.
 +  - Refinar la Arquitectura del Sistema.
 +  - Definir los Diagramas de Interacción.
 +  - Definir el Diagrama de Clases de Diseño. (en paralelo con los Diagramas de Interacción)
 +  - Definir el Esquema de Base de Datos.
 +
 +
 +===== Casos de uso reales =====
 +
 +Un Caso de Uso Real describe el diseño real del caso de uso según una tecnología concreta de entrada y de salida y su implementación. Si el caso de uso implica una interfaz de usuario, el caso de uso real incluirá bocetos de las ventanas y detalles de la interacción a bajo nivel con los widgets de la ventana.
 +
 +Como alternativa a la creación de los Casos de Uso Reales, el desarrollador puede crear bocetos de la interfaz en papel, y dejar los detalles para la fase de implementación.
 +
 +
 +===== Diagramas de colaboración =====
 +
 +Los Diagramas de Interacción muestran el intercambio de mensajes entre instancias del modelo de clases para cumplir las post-condiciones establecidas en un contrato.
 +
 +Hay dos clases de Diagramas de Interacción:
 +
 +  - Diagramas de Colaboración.
 +  - Diagramas de Secuencia.
 +
 +De entre ambos tipos se prefieren los Diagramas de Colaboración por su expresividad y por su economía espacial (una interacción compleja puede ser muy larga en un Diagrama de Secuencia).
 +
 +La creación de los Diagramas de Colaboración de un sistema es una de las actividades más importantes en el desarrollo orientado a objetos, pues al construirlos se toman unas decisiones clave acerca del funcionamiento del futuro sistema. La creación de estos diagramas, por tanto, debería ocupar un porcentaje significativo en el esfuerzo dedicado al proyecto entero.
 +
 +  - Crear un diagrama separado para cada operación del sistema en desarrollo en el ciclo de desarrollo actual.
 +  - Para cada evento del sistema, hacer un diagrama con él como mensaje inicial.
 +  - Si el diagrama se complica, dividirlo en diagramas más pequeños.
 +  - Usando los apartados de responsabilidades y de post-condiciones del contrato de operación, y la descripción del caso de uso como punto de partida, diseñar un sistema de objetos que interaccionan para llevar a cabo las tareas requeridas.
 +
 +Las responsabilidades de una clase están ligadas a las obligaciones de un objeto en cuanto a su comportamiento. Básicamente, estas responsabilidades son de los dos siguientes tipos:
 +
 +  - Conocer:
 +    - Conocer datos privados encapsulados.
 +    - Conocer los objetos relacionados.
 +    - Conocer las cosas que puede calcular o derivar.
 +  - Hacer:
 +    - Hacer algo él mismo.
 +    - Iniciar una acción en otros objetos.
 +    - Controlar y coordinar actividades en otros objetos.
 +
 +
 +===== Diagramas de clases de diseño =====
 +
 +Al construir los Diagramas de Colaboración se van usando clases procedentes del Modelo Conceptual, junto con otras creadas para encargarse de responsabilidades específicas. El conjunto de todas las clases usadas, junto con sus relaciones, forma el Diagrama de Clases de Diseño.
 +
 +Un Diagrama de Clases de Diseño muestra la especificación para las clases software de una aplicación. Incluye la siguiente información:
 +
 +  - Clases, asociaciones y atributos.
 +  - Interfaces, con sus operaciones y constantes.
 +  - Métodos.
 +  - Navegabilidad.
 +  - Dependencias.
 +
 +==== Construcción de un diagrama de clases de diseño ====
 +
 +  - Identificar todas las clases participantes en la solución software. Esto se lleva a cabo analizando los Diagramas de Interacción.
 +  - Representarlas en un diagrama de clases.
 +  - Duplicar los atributos que aparezcan en los conceptos asociados del Modelo Conceptual.
 +  - Añadir los métodos, según aparecen en los Diagramas de Interacción.
 +  - Añadir información de tipo a los atributos y métodos.
 +  - Añadir las asociaciones necesarias para soportar la visibilidad de atributos requerida.
 +  - Añadir flechas de navegabilidad a las asociaciones para indicar la dirección de visibilidad de los atributos.
 +  - Añadir relaciones de dependencia para indicar visibilidad no correspondiente a atributos.
 +
 +No todas las clases que aparecían en el Modelo Conceptual tienen por qué aparecer en el Diagrama de Clases de Diseño. De hecho, tan solo se incluirán aquellas clases que tengan interés en cuanto a que se les ha asignado algún tipo de responsabilidad en el diseño de la interacción del sistema. No hay, por tanto, un transición directa entre el Modelo Conceptual y el Diagrama de Clases de Diseño, debido a que ambos se basan en enfoques completamente distintos: el primero en comprensión de un dominio, y el segundo en una solución software.
 +
 +En la fase de Diseño se añaden los detalles referentes al lenguaje de programación que se vaya a usar. Por ejemplo, los tipos de los atributos y parámetros se expresarán según la sintaxis del lenguaje de implementación escogido.
 +
 +
 +==== Navegabilidad ====
 +
 +La navegabilidad es una propiedad de un rol (un extremo de una asociación) que indica que es posible “navegar” unidireccionalmente a través de la asociación, desde objetos de la clase origen a objetos de la clase destino.
 +
 +La navegabilidad implica visibilidad, normalmente visibilidad por medio de un atributo en la clase origen. En la implementación se traducirá en la clase origen como un atributo que sea una referencia a la clase destino.
 +
 +Las asociaciones que aparezcan en el Diagrama de Clases deben cumplir una función, deben ser necesarias, si no es así deben eliminarse.
 +
 +Las situaciones más comunes en las que parece que se necesita definir una asociación con navegabilidad de A a B son:
 +
 +  - A envía un mensaje a B.
 +  - A crea una instancia B.
 +  - A necesita mantener una conexión con B.
 +
 +
 +==== Visibilidad ====
 +
 +Los atributos y los métodos deben tener una visibilidad asignada, que puede ser:
 +
 +  - + Visibilidad pública.
 +  - # Visibilidad protegida.
 +  - - Visibilidad privada.
 +
 +También puede ser necesario incluir valores por defecto, y todos los detalles ya cercanos a la implementación que sean necesarios para completar el Diagrama de Clases.
 +
 +
 +===== Ostros aspectos en el diseño del sistema =====
 +
 +En los puntos anteriores se ha hablado de decisiones de diseño a un nivel de granularidad fina, con las clases y objetos como unidades de decisión. En el diseño de un sistema es necesario también tomar decisiones a un nivel más alto sobre la descomposición de un sistema en subsistemas y sobre la arquitectura del sistema. Esta parte del Diseño es lo que se denomina Diseño del Sistema.
 +
 +Sí hay que tener en cuenta que las posibles divisiones en subsistemas tienen que hacerse en base a las clases definidas en el Diagrama de Clases del Diseño. Para realizar una división en módulos o paquetes del sistema, se empleará **la notación para paquetes que define UML**.
 +
 +
 +====== Implantación y pruebas ======
 +
 +Una vez se tiene completo el Diagrama de Clases de Diseño, se pasa a la implementación en el lenguaje de programación elegido.
 +
 +El programa obtenido se depura y prueba, y ya se tiene una parte del sistema funcionando que se puede probar con los futuros usuarios, e incluso poner en producción si se ha planeado una instalación gradual.
 +
 +Una vez se tiene una versión estable se pasa al siguiente ciclo de desarrollo para incrementar el sistema con los casos de uso asignados a tal ciclo.
 +
  
  • construccion.txt
  • Last modified: 2012/06/06 12:15
  • (external edit)