Resumen del tema

El modelo de análisis es la primera representación técnica de un sistema. Utiliza una mezcla de formatos en texto y diagramas para representar los requisitos del software, las funciones y el comportamiento. De esta manera se hace mucho más fácil de comprender dicha representación, ya que es posible examinar los requisitos desde diferentes puntos de vista aumentando la probabilidad de encontrar errores, de que surjan debilidades y de que se descubran descuidos.

El modelo de análisis debe cumplir tres objetivos primarios:

Describir los que requiere el cliente. Establecer una base para la creación de un diseño de software. Definir un conjunto de requisitos que pueda validarse una vez construido el software.

El modelo de análisis se complementa de cuatro elementos fundamentales. Estos elementos sirven para clasificar principalmente los diferentes diagramas y otros derivados conocidos en plataformas como sistemas de información e ingeniería de software entre otros. Además estos con clasificados en elementos de escenario, elementos de flujo, elementos de clases y elementos de comportamiento.

Este modelo en simples palabras sirve para una interacción más amena entre el sistema y el usuario, por lo tanto el modelo de análisis con UML comienza con la creación de escenarios en la forma de “los casos de uso, diagrama de actividad y diagrama de carril”.

Caso de uso: Describe un escenario de un caso específico en un lenguaje directo desde el punto de vista de un actor definido.

Diagrama de actividad: es un modelo muy parecido al caso de uso pero mucho mejor complementado y proporciona una representación del flujo de interacción dentro de un escenario específico.

Diagrama de carril: Consiste en tomar el diagrama actividad y situarlo en filas o en carriles. En este modelo los actores son fundamentales ya que en el diagrama de carril se especifica claramente, con un carril, la responsabilidad a cada actor.

Tiene una visión del sistema del tipo entrada proceso-salida. Los objetos de datos fluyen hacia el interior del software, se transforman mediante elementos de procesamiento y los objetos de datos resultantes fluyen al exterior del software.

Propiedades del DFD:

El nivel 0 del diagrama del flujo debe representar al software. La entrada y la salida primaria se deben establecer con cuidado. La refinación debe comenzar por el aislamiento de procesos, objetos de datos y almacenamiento de datos candidatos a ser representados en el siguiente nivel. Toda las flechas y burbujas se deben rotular con el nombre. Se debe tener la continuidad de flujo al cambiar el nivel. La refinación de burbujas debe hacerse una por una.

Una clase orientada a objetos encapsula atributos de los datos pero también incorpora las operaciones que manipulan los datos implicados por dichos atributos. Las clases se manifiestan en la siguiente forma: entidades externas, sucesos o eventos, cosas, papeles o roles, unidades organizacionales, sitios y estructuras.

El modelado de Clase-Responsabilidad Colaborador (CRC) proporciona un medio simple para identificar y organizar las clases relevantes para los requisitos del sistema o producto. Un modelo CRC es una colección de tarjetas índices estándar que representan clases. El objeto es desarrollar una representación organizada de las clases.

El modelo de comportamiento indica la forma en que el software responderá a los eventos o estímulos externos.

5.2 Diagramas de Secuencia

El diagrama de secuencia es un tipo de diagrama de interacción cuyo objetivo es describir el comportamiento dinámico del sistema de información haciendo énfasis en la secuencia de los mensajes intercambiados por los objetos.

Un diagrama de secuencia tiene dos dimensiones, el eje vertical representa el tiempo y el eje horizontal los diferentes objetos. El tiempo avanza desde la parte superior del diagrama hacia la inferior. Normalmente, en relación al tiempo sólo es importante la secuencia de los mensajes, sin embargo, en aplicaciones de tiempo real se podría introducir una escala en el eje vertical. Respecto a los objetos, es irrelevante el orden en que se representan, aunque su colocación debería poseer la mayor claridad posible.

Cada objeto tiene asociados una línea de vida y focos de control. La línea de vida indica el intervalo de tiempo durante e que existe ese objeto. Un foco de control o activación muestra el periodo de tiempo en el cual el objeto se encuentra ejecutando alguna operación, ya sea directamente o mediante un procedimiento concurrente.

Objeto y línea de vida: Un objeto se representa como una línea vertical discontinua, llamada línea de vida, con un rectángulo de encabezado con el nombre del objeto en su interior. También se puede incluir a continuación el nombre de la clase, separando ambos por dos puntos. Si el objeto es creado en el intervalo de tiempo representado en el diagrama, la línea comienza en el punto que representa ese instante y encima se coloca el objeto. Si el objeto es destruido durante la interacción que muestra el diagrama, la línea de vida termina en ese punto y se señala con un aspa de ancho equivalente al del foco de control. Foco de control o activación: Se representa como un rectángulo delgado superpuesto a la línea de vida del objeto. Su largo dependerá de la duración de la acción. La parte superior del rectángulo indica el inicio de una acción ejecutada por el objeto y la parte inferior su finalización. Mensaje: Un mensaje se representa como una flecha horizontal entre las líneas de vida de los objetos que intercambian el mensaje. La flecha va desde el objeto que envía el mensaje al que lo recibe. Además, un objeto puede mandarse un mensaje a sí mismo, en este caso la flecha comienza y termina en su línea de vida. 5.3 Diagrama De Clases Conceptuales

El propósito de un diagrama de clase es describir las clases que conforman el modelo de un determinado sistema. Dado el carácter de refinamiento iterativo que caracteriza un desarrollo orientado a objetos, el diagrama de clase va a ser creado y refinado durante las fases de análisis y diseño, estando presente como guía en la implementación del sistema. Según Fowler, perpectiva a tener en cuenta a la hora de dibujar los diagramas de clases (o cualquier otro tipo de diagrama, pero es más evidente en los diagramas de clases):

Conceptual: Estamos dibujando un diagrama que representa los conceptos del dominio del sistema. Estos conceptos se relacionarán de forma natural con las clases que los implementen, pero a menudo no hay una aplicación directa. Es decir, el modelo se dibuja sin tener en cuenta el software que lo implementa y generalmente es independiente del lenguaje de programación.

Un Modelo Conceptual /Dominio es el conjunto de diagramas de estructura estático con clases, atributos y asociaciones, pero no operaciones.

1. 2.

3.

4. 5.

6.

Construcción del Modelo Conceptual / Dominio. Representa un aspecto de la realidad. Ayuda a los Ingenieros de Software a gestionar la complejidad. Es más simple que la realidad. Un Modelo Conceptual / Dominio debe: Organizar Datos dentro de Objetos y Clases Estructurar Datos vía herencia y asociaciones Especificar comportamiento e interfaces públicas 7.Describir el comportamiento global 8.Describir Restricciones El modelo de dominio muestra las clases conceptuales o vocabulario del dominio.

Informalmente una clase conceptual es una idea, cosa u objeto. Formalmente, una clase conceptual puede considerarse en términos de su símbolo, intensión y extensión (Martin y Odell, 1995). Símbolo: palabras o imágenes que representan una clase conceptual. Intensión: la definición de una clase conceptual. Extensión: el conjunto de ejemplos a los que se aplica la clase conceptual.

Los casos de uso son un fenómeno interesante, durante mucho tiempo, tanto en el desarrollo orientado a objeto como en el tradicional, las personas se auxiliaban de escenarios típicos que le ayudaban a entender los requerimientos. Sin embargo, estos, se trataban de modo muy informal; siempre se construían, pero pocas veces se documentaban. Cada Caso de Uso puede estar definido por:

Texto que lo describe. Secuencia de pasos ejecutados dentro del escenario. Condiciones pre-post para que el escenario comience o termine mezclando las anteriores.

Un actor es un agente, alguien o algo que solicita un servicio al sistema o actúa como catalizador para que ocurra algo. Un caso de uso ofrece una vista estática de las relaciones entre diferentes casos de uso y actores. Un caso de uso se representa en UML como un óvalo:

En UML, cada caso de uso debe tener al menos un actor. Esta forma de ver el sistema nos ayuda a concebirlo como un todo. En UML, un actor se representa con:

Categorías de actores: Principales: personas que usan el sistema. Secundarios: personas que mantienen o administran el sistema. Material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la aplicación y deben ser utilizados. Otros sistemas: sistemas con los que el sistema interactúa.

La Generalización: Es como una generalización entre clases. El caso hijo hereda el comportamiento y significado de caso de uso padre. El hijo puede añadir o redefinir el comportamiento del padre.

inclusión: Un caso base de uso base incorpora explícitamente el comportamiento de otro caso de uso en el lugar especificado en el caso base.

Extensión: Significa que un caso de uso base incorpora implícitamente el comportamiento de otro caso de uso en el lugar especificado indirectamente por el caso de uso que extiende al base. Se usa esta relación cuando se tiene un caso de uso que es similar a otro, pero que hace un poco más. <>

5.5 Presentación del proyecto final.

Fases de un proyecto de desarrollo de software:

Fase de planificación. Fase de análisis. Fase de Diseño. Fase de Desarrollo. Fase de integración. Fase de implementación. Fase de mantenimiento. Documentación