Trata sobre CONSIDERACIONES PARA EL DESARROLLO DE INFORMES DE ANALISIS Y DISEñO DE PROYECTOS
Hace más de un año que prometi publicar información sobre OO y sobre UML y que mejor que hacerlo con un documento hecho por mi mismo, jejeje.
Definición de casos de uso
Los casos de uso describen, bajo la forma de acciones y reacciones, el comportamiento de un sistema, desde el punto de vista del usuario, permitiendo definir los límites del sistema y las relaciones entre el sistema y el entorno. Esta práctica permite que el analista y el usuario participante puedan comunicarse de una forma en común, permitiéndole al usuario visualizar la funcionalidad desde su perspectiva.
Si comparamos el uso de casos de uso con la metodología de análisis de Ingeniería de Software, se puede decir que un caso de uso es comparable con los diagramas de flujo de datos (DFD), del enfoque estructurado.
Los casos de uso son descripciones de la funcionalidad del proceso que se analiza, independiente de la implementación. Estos cubren la carencia existente, en cuanto a la determinación de requisitos.
Al utilizar casos de uso, se puede particionar el conjunto de necesidades, atendiendo a la categoría de usuarios que participan en el mismo.
Los casos de uso están compuestos por tres objetos específicos, los cuales son:
• Actores
• Casos de uso
• Relaciones
Actores
Un actor es un rol que un usuario juega con respecto al sistema. Se debe destacar el uso de la palabra rol, pues con esto se especifica que un actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema, dentro de esta especificación, se puede observar que un actor puede ser del tipo:
• Principal: Personas que usan el sistema.
• Secundario: 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.
El actor de un caso de uso se simboliza de la siguiente forma:
Definición de casos de uso
Los casos de uso describen, bajo la forma de acciones y reacciones, el comportamiento de un sistema, desde el punto de vista del usuario, permitiendo definir los límites del sistema y las relaciones entre el sistema y el entorno. Esta práctica permite que el analista y el usuario participante puedan comunicarse de una forma en común, permitiéndole al usuario visualizar la funcionalidad desde su perspectiva.
Si comparamos el uso de casos de uso con la metodología de análisis de Ingeniería de Software, se puede decir que un caso de uso es comparable con los diagramas de flujo de datos (DFD), del enfoque estructurado.
Los casos de uso son descripciones de la funcionalidad del proceso que se analiza, independiente de la implementación. Estos cubren la carencia existente, en cuanto a la determinación de requisitos.
Al utilizar casos de uso, se puede particionar el conjunto de necesidades, atendiendo a la categoría de usuarios que participan en el mismo.
Los casos de uso están compuestos por tres objetos específicos, los cuales son:
• Actores
• Casos de uso
• Relaciones
Actores
Un actor es un rol que un usuario juega con respecto al sistema. Se debe destacar el uso de la palabra rol, pues con esto se especifica que un actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema, dentro de esta especificación, se puede observar que un actor puede ser del tipo:
• Principal: Personas que usan el sistema.
• Secundario: 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.
El actor de un caso de uso se simboliza de la siguiente forma:
Caso de uso
Un caso de uso es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.
Un caso de uso debe ser simple, inteligible, claro y conciso. Generalmente hay pocos actores asociados a cada caso de uso. Para identificar y definir un caso de uso, se deben realizar las siguientes preguntas:
• ¿Cuáles son las tareas del actor?
• ¿Qué información crea, guarda, modifica, destruye o lee el actor?
• ¿Debe el actor notificar al sistema los cambios externos?
• ¿Debe el sistema informar al actor de los cambios internos?
• ¿Qué transformación de información se realiza dentro del caso de uso?
• ¿Qué función o funciones se realizan dentro del caso de uso?
Una vez que se han realizado las consultas descritas, se debe especificar la funcionalidad del caso de uso, definiendo los siguientes puntos:
• Que actor utiliza el caso de uso.
• Tipo de caso uso: Nivel e importancia, ejemplo simple y esencial.
• Objetivo del caso de uso.
• Descripción general.
• Descripción de la interacción actor - caso de uso: qué mensajes intercambian ambos.
• Cronología y origen de las interacciones.
• Repeticiones de comportamiento: qué operaciones son iteradas.
• Situaciones opcionales: qué ejecuciones alternativas se presentan en el caso de uso, es decir, si una acción de un caso de uso utiliza otro caso de uso para terminar la operación.
El caso de uso se simboliza de la siguiente forma:
Relaciones
UML define 2 tipos relevantes de relación en los diagramas de casos de uso, estas son:
• Inclusión (Uses). Una instancia del caso de uso origen incluye también el comportamiento descrito por el caso de uso de destino.
• Extensión (Extend). El caso de uso origen extiende el comportamiento del caso de uso destino.
Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).
Se recomienda utilizar uses cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica
En este ejemplo el caso de uso “Validar Usuario”, puede ser utilizado en muchas partes del sistema, lo cual hace que se convierta en un solo caso de uso que permite la validación y acceso al sistema al personal registrado. Este caso de uso va a ser utilizado por distintos casos de uso.
Se recomienda utilizar extend, cuando un caso de uso es similar a otro o cuando permiten cumplir características que son propias de ese caso de uso.
En el siguiente ejemplo se observa que el caso de uso “Administrar RR.HH.”, extiende sus funciones a los casos de uso “Crear, Modificar y Eliminar RR.HH.”, estos casos de uso son extensiones del caso de uso principal y pueden ser ejecutados solo cuando se administra la información del RR.HH.
Existen otros 2 tipos de relaciones que reflejan la relación entre los actores y el o los casos de uso y la relación de herencia que existe entre actores.
Asociación. Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (Caso de uso). Dicha relación se denota con una flecha simple.
Herencia. Es el tipo de relación que existe entre actores o casos de uso. Los actores indican su relación y herencia de privilegios, en el los casos de uso la herencia es definida por extend, asignado privilegios a los casos de uso desde un caso de uso superior.
En la presente figura se observa que el actor B tiene más privilegios que el actor A. El actor A hereda ciertos privilegios del actor B, estos privilegios deben ser detallados.
Definición de un diagrama de contexto
Para la definición de un diagrama de contexto, se deben realizar los siguientes pasos:
• Definir el nombre del sistema.
• Identificar los actores, siendo estos personas o sistemas externos que interactúan de una u otra forma con el sistema.
• Definir las relaciones que existirán entre el sistema y los actores.
Para ello, se debe utilizar la práctica asociada a los casos de uso, la cual permite reflejar de una forma generalizada y entendible, tanto para los usuarios como para el analista, la interacción que tendrán los actores con el sistema.
Como ejemplo, en la siguiente imagen se puede observar como se ha definido el diagrama de contexto del sistema “Gestión y Control de Proyectos”.
En este diagrama de contexto se observa la interacción que tendrán los actores con el sistema desde un punto de vista general, este diagrama puede ser desagregado según su complejidad a medida que se van analizando en detalle cada caso de uso, como se observa en la figura 22.
Al desagregar, se puede observar la interacción desde un punto de vista modular que tendrá cada actor con los diversos casos de uso, esta visión permite observar el diagrama de contexto general desagregado.
El diagrama de casos de uso que representa cada módulo, se debe describir de forma funcional explicando los procesos que se realizan en cada módulo.
Esta metodología permite definir y analizar la funcionalidad del proceso que debe ser absorbida por el sistema a desarrollar, en la medida que se van descomponiendo los niveles de cada caso de uso, desde el nivel general hasta el nivel detallado. El nivel general permite definir los lineamientos y objetivos que persigue el sistema.
Definición del modelo conceptual
La definición del modelo conceptual está orientado a identificar los conceptos (objetos) y sus relaciones dentro de una organización. Este modelo también es conocido como BCM (Business Conceptual Model).
El modelo conceptual y sus relaciones deben ser trabajados entre el analista y los usuarios que utilizarán el sistema a desarrollar. Esta práctica está orientada a definir un lenguaje de conceptos y sus relaciones únicas entre los participantes que analizan el sistema.
La importancia de definir el modelo conceptual radica en la oportunidad que este presenta para definir del modelo conceptual de datos y el modelo de clases u objetos.
En resumen se puede decir que el modelo conceptual busca representar los conceptos en el dominio del problema, es decir, de los objetos del mundo real, y no componentes de software y sus asociaciones y atributos.
Algunas de las fortalezas que presenta la definición del modelo conceptual se detallan a continuación:
• Permitir descomponer el espacio del problema en unidades comprensibles (conceptos), disminuyendo la complejidad del mismo.
• Clarifica terminología y vocabulario del espacio del problema.
• Representa una importante herramienta de comunicación.
Un modelo conceptual esta constituido por dos aspectos:
• El concepto.
• Las asociaciones que existen entre conceptos.
Conceptos
Los conceptos son clasificados de dos formas, formales e informales.
Los conceptos formales, pertenecen al dominio del problema y son identificados dentro de este.
Los conceptos informales representan ideas, cosas u objetos, que pueden estar fuera del dominio del problema. Un concepto formal es un subconjunto de un concepto informal.
Al definir un concepto se debe considerar:
• Símbolo. Palabra o imagen que representa el concepto.
• Intención. Definición del concepto y objetivo de éste.
• Extensión. Se debe definir un conjunto de ejemplos a los que aplica el concepto.
En la siguiente imagen se observa como debe ser definido un concepto, si se observa éste parece una entidad de un modelo conceptual de datos, pero la diferencia radica en que este representa los datos relevantes del concepto.
Nombre de Concepto
Atributo 1
Abtributo 2
.. Atributo n
Si se observa, un concepto puede representar, al momento de definirse un modelo conceptual de datos. Como ejemplo podemos definir el concepto empleado, en el modelo de datos representa más de una entidad. El empleado tiene datos asociados a dirección, cargas familiares u otro y tipo de entidad. Adicionalmente un concepto no tiene clave primaria, una entidad sí.
Asociaciones
Son relaciones entre conceptos, las cuales representan una conexión útil y de interés, que mejoran la comprensión del concepto.
Se debe tener en mente que:
• Durante la construcción del modelo conceptual, identificar los conceptos es más importante que identificar asociaciones
• Un modelo sobrecargado de asociaciones tiende más a dificultar su entendimiento, que a clarificarlo.
Se debe tener en mente que el modelo conceptual debe ser entendido por cualquier persona que lo analice, incluyendo a los usuarios que participan en la definición del modelo conceptual y que a la pos serán los que utilizarán el sistema. No se debe olvidar que el modelo conceptual representa el entendimiento entre los usuarios de la organización y el analista. Al definir una relación entre conceptos se recomienda identificar que representa esa relación, ejemplo:
Descripción de asociaciones.
Tipos de relaciones comunes entre conceptos
Existe otro tipo de relaciones entre conceptos, las cuales son: composición, necesidad de saber y relaciones de comprensión.
• Un proyecto administra una cierta cantidad de Recursos Humanos.
• Un proyecto tiene informes.
• Un proyecto arroja alarmas de estado. Al igual que en un modelo conceptual de datos, en el modelo conceptual se debe definir la cardinalidad de las relaciones.
Asociaciones de composición y de agregación
Un concepto se encuentra definido por otros conceptos.
. Asociación de composición (Conjunto “Y”).
Asociación de agregación
(Conjunto “0”).
(Conjunto “0”).
Cuando el conector se encuentra destacado en color negro (composición), se interpreta que el concepto Solicitud está constituido por los conceptos Datos personales y Datos comerciales.
Cuando el conector se encuentra en color blanco (agregación), se interpreta que el concepto Solicitud está constituido por Datos personales o Datos comerciales.
Bajo este tipo de relaciones se recomienda concentrarse en aquellas asociaciones para las que se requiere mantener conocimiento, de acuerdo a los requerimientos, de los conceptos que relaciona.
Asociaciones derivadas (Discriminación)
Estas representan el tipo de concepto de un concepto superior, es decir, Humano - Hombre, Humano – Mujer, pero entre los conceptos inferiores existe una diferencia.
Asociaciones derivadas (Discriminación).
Bajo este esquema se recomienda evitar definir asociaciones redundantes o derivadas, solo se recomienda definirlas cuando sea estrictamente necesario.
Estas asociaciones se incluyen cuando se desea aclarar el comportamiento de una relación que se encuentra poco clara en el modelo conceptual. Ver figura.
Asociación de comprensión.
Se recomienda incluir asociaciones, cuyo conocimiento no se necesita mantener acorde a los requerimientos, pero que mejoran el entendimiento del problema.
Consideraciones para la construcción de modelos conceptuales
Las consideraciones más importantes son las siguientes:
• Listar los conceptos candidatos relacionados a los requerimientos bajo consideración.
• Dibujarlos en un modelo conceptual.
• Agregar las asociaciones necesarias para registrar las relaciones entre conceptos para las que se requiere preservar conocimiento, y aquellas que clarifican el dominio del problema.
• Una vez definido el modelo conceptual y sus asociaciones se deben especificar los atributos necesarios de cada concepto definido.
Definición del modelo conceptual de datos
Para este cometido, se debe tener claro que un modelo conceptual de datos representa la información de negocios que es relevante en el alcance del sistema que se está especificando.
Para definir el modelo conceptual de datos se debe:
• Hacer una copia del modelo conceptual, se debe considerar que el modelo conceptual tiene definido conceptos generales y sus atributos.
• Eliminar aquellos conceptos para los cuales no es relevante mantener información.
• Eliminar aquellos conceptos cuya extensión es única.
• Transformar los conceptos restantes en tipos o entidades.
• Eliminar aquellas asociaciones que solo sirven para clarificar el dominio del problema (relaciones de comprensión).
• Crear las entidades necesarias para hacer que el modelo conceptual de datos sea consistente con sus relaciones.
• Adecuar las asociaciones de composición y derivadas a las necesidades de información de los requerimientos.
• Completar los tipos con los atributos que se estimen convenientes.
• Definir las claves primarias de las entidades.
Definición del modelo de clases y métodos
Análisis y diseño con el diagrama de clase
El Diagrama de Clase es el diagrama principal de diseño y análisis para un sistema. En él, la estructura de clases del sistema se especifica con relaciones entre clases y estructuras de herencia. Durante el análisis del sistema, el diagrama se desarrolla buscando una solución ideal. Durante el diseño, se usa el mismo diagrama, y se modifica para satisfacer los detalles de las implementaciones. Bajo este esquema se recomienda, en la fase de diseño, tomar el modelo conceptual (objetos) como base para realizar el desarrollo de los diagramas de clases y definición de métodos.
Desarrollo del modelo conceptual en la fase de análisis
El diagrama de clases se desarrolla a través de información obtenida en los Casos de uso y diagramas de actividades. Ver figura.
Consideraciones para la construcción de modelos conceptuales
Las consideraciones más importantes son las siguientes:
• Listar los conceptos candidatos relacionados a los requerimientos bajo consideración.
• Dibujarlos en un modelo conceptual.
• Agregar las asociaciones necesarias para registrar las relaciones entre conceptos para las que se requiere preservar conocimiento, y aquellas que clarifican el dominio del problema.
• Una vez definido el modelo conceptual y sus asociaciones se deben especificar los atributos necesarios de cada concepto definido.
Definición del modelo conceptual de datos
Para este cometido, se debe tener claro que un modelo conceptual de datos representa la información de negocios que es relevante en el alcance del sistema que se está especificando.
Para definir el modelo conceptual de datos se debe:
• Hacer una copia del modelo conceptual, se debe considerar que el modelo conceptual tiene definido conceptos generales y sus atributos.
• Eliminar aquellos conceptos para los cuales no es relevante mantener información.
• Eliminar aquellos conceptos cuya extensión es única.
• Transformar los conceptos restantes en tipos o entidades.
• Eliminar aquellas asociaciones que solo sirven para clarificar el dominio del problema (relaciones de comprensión).
• Crear las entidades necesarias para hacer que el modelo conceptual de datos sea consistente con sus relaciones.
• Adecuar las asociaciones de composición y derivadas a las necesidades de información de los requerimientos.
• Completar los tipos con los atributos que se estimen convenientes.
• Definir las claves primarias de las entidades.
Definición del modelo de clases y métodos
Análisis y diseño con el diagrama de clase
El Diagrama de Clase es el diagrama principal de diseño y análisis para un sistema. En él, la estructura de clases del sistema se especifica con relaciones entre clases y estructuras de herencia. Durante el análisis del sistema, el diagrama se desarrolla buscando una solución ideal. Durante el diseño, se usa el mismo diagrama, y se modifica para satisfacer los detalles de las implementaciones. Bajo este esquema se recomienda, en la fase de diseño, tomar el modelo conceptual (objetos) como base para realizar el desarrollo de los diagramas de clases y definición de métodos.
Desarrollo del modelo conceptual en la fase de análisis
El diagrama de clases se desarrolla a través de información obtenida en los Casos de uso y diagramas de actividades. Ver figura.
Modelo conceptual “Diagrama de Clase” durante la fase de análisis
Los objetos encontrados durante el análisis son modelados en términos de la clase a la que instancian, y las interacciones entre objetos son referenciados a relaciones entre las clases instanciadas
Diseño del sistema con diagramas de clase
Durante el diseño, el modelo conceptual diagrama de Clase se elabora para tener en cuenta los detalles concretos de la implementación del sistema. Bajo este esquema el modelo conceptual debe ser refinado, indicando clases, relaciones, colaboraciones, métodos específicos, valores de entrada y valores de salida de cada método definido.
Arquitecturas multicapas
Una vez iniciada la fase de diseño, se debe establecer la arquitectura del sistema. Esto incluye establecer si será un sistema simple diseñado para correr en una sola máquina, un sistema “two-tiered” consistente en un cliente y un servidor, o un sistema “multi-tiered” con objetos interfaz de usuario separados de los objetos “business”, separado de la base de datos, cada uno corriendo en plataformas distintas.
Se puede separar el diagrama en secciones que muestren la lógica de la aplicación, el diseño de la interfaz de usuario y las clases implicadas con el almacenamiento de los datos. Esto se puede hacer físicamente segmentando el diagrama de clase, usando diagramas separados para cada sección, o simplemente añadiendo una propiedad a cada clase.
Definición de métodos
La definición de los métodos en un modelo de clases en la fase de diseño, representa el conjunto de funciones, procedimientos u operatoria que este presentará una vez que se encuentre construido.
Los métodos representan la interacción entre las distintas capas, existiendo métodos de interfaz, de negocio y de base de datos.
Al definir por primera vez el modelo de clases, se debe pensar en una serie de métodos que apoyarán la ejecución de operaciones precisas que deben atender los requerimientos planteados por el usuario. Estos métodos deben especificar las variables de entrada, operaciones, entidades con que interactúan (dependiendo de la capa en la que se encuentren), algoritmo de operación y las variables de salida.
Análisis y diseño iterativo
El diagrama de clase se puede desarrollar en una “iterative fashion”, a través de un ciclo repetido de análisis, diseño e implementación, y después vuelta al análisis, para empezar el ciclo de nuevo. Este proceso se suele llamar “round-trip engineering”.
Definición del diagrama de secuencias
El diagrama de secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos y/o clases en un sistema, la utilización de sus métodos, mensajes y la colaboración de objetos mediante los métodos definidos. Un diagrama de secuencia se modela para cada caso de uso, mientras que el diagrama de caso de uso permite el modelado de una vista “business” del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos, mediante sus métodos.
Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se tiene modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces se pueden seguir esos pasos para descubrir qué objetos son necesarios.
Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales y los mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria.
El diagrama de secuencias puede ser definido indistintamente en la fase de análisis como en la fase de diseño. En la fase de análisis permite definir los métodos que deben ser definidos en el modelo de clases para la fase de diseño. En la fase de diseño muestra la secuencia que se debe seguir para ejecutar un caso de uso, esta práctica puede depurar el modelo de clases, así como también identificar casos de uso que no fueron definidos en la fase de análisis.
Durante la fase de análisis inicial, el modelador típicamente coloca el nombre “business” de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre “business” es reemplazado con el nombre del método que está siendo llamado por un objeto (Clase). El método llamado, o invocado, pertenece a la definición de la clase instanciada por el objeto en la recepción final del mensaje.
El diagrama de secuencia en la fase de diseño representa las operaciones que deben ser realizadas por una solicitud de un actor definido y las respuestas que el sistema puede arrojar, interactuando con distintos métodos que pertenecen a un mismo o distinto objeto en una distinta capa de servicio.
En la siguiente figura se observa las operaciones que se realizan con sus respectivos mensajes entre métodos de distintos objetos, para atender una solicitud de un actor.
Bueno , lo dejo hasta aqui, ya que lo que sigue lo desarrolle e implante especificamente para una organización, la otra información la pueden encontrar en libros o en otras Web, pero creo que como la he explicado se puede usar de mejor forma.
Por cierto, si trabajan con una herramienta de 4 generacion para modelamiento ya sea de datos o de diagramas conceptuales, despues existe la posibilidad de transformar los modemos lógicos a modelos físicos en una base de datos o para un lenguaje en particular.
Espero que les sirva esto
Diseño del sistema con diagramas de clase
Durante el diseño, el modelo conceptual diagrama de Clase se elabora para tener en cuenta los detalles concretos de la implementación del sistema. Bajo este esquema el modelo conceptual debe ser refinado, indicando clases, relaciones, colaboraciones, métodos específicos, valores de entrada y valores de salida de cada método definido.
Arquitecturas multicapas
Una vez iniciada la fase de diseño, se debe establecer la arquitectura del sistema. Esto incluye establecer si será un sistema simple diseñado para correr en una sola máquina, un sistema “two-tiered” consistente en un cliente y un servidor, o un sistema “multi-tiered” con objetos interfaz de usuario separados de los objetos “business”, separado de la base de datos, cada uno corriendo en plataformas distintas.
Se puede separar el diagrama en secciones que muestren la lógica de la aplicación, el diseño de la interfaz de usuario y las clases implicadas con el almacenamiento de los datos. Esto se puede hacer físicamente segmentando el diagrama de clase, usando diagramas separados para cada sección, o simplemente añadiendo una propiedad a cada clase.
Definición de métodos
La definición de los métodos en un modelo de clases en la fase de diseño, representa el conjunto de funciones, procedimientos u operatoria que este presentará una vez que se encuentre construido.
Los métodos representan la interacción entre las distintas capas, existiendo métodos de interfaz, de negocio y de base de datos.
Al definir por primera vez el modelo de clases, se debe pensar en una serie de métodos que apoyarán la ejecución de operaciones precisas que deben atender los requerimientos planteados por el usuario. Estos métodos deben especificar las variables de entrada, operaciones, entidades con que interactúan (dependiendo de la capa en la que se encuentren), algoritmo de operación y las variables de salida.
Análisis y diseño iterativo
El diagrama de clase se puede desarrollar en una “iterative fashion”, a través de un ciclo repetido de análisis, diseño e implementación, y después vuelta al análisis, para empezar el ciclo de nuevo. Este proceso se suele llamar “round-trip engineering”.
Definición del diagrama de secuencias
El diagrama de secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos y/o clases en un sistema, la utilización de sus métodos, mensajes y la colaboración de objetos mediante los métodos definidos. Un diagrama de secuencia se modela para cada caso de uso, mientras que el diagrama de caso de uso permite el modelado de una vista “business” del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos, mediante sus métodos.
Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se tiene modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces se pueden seguir esos pasos para descubrir qué objetos son necesarios.
Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales y los mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria.
El diagrama de secuencias puede ser definido indistintamente en la fase de análisis como en la fase de diseño. En la fase de análisis permite definir los métodos que deben ser definidos en el modelo de clases para la fase de diseño. En la fase de diseño muestra la secuencia que se debe seguir para ejecutar un caso de uso, esta práctica puede depurar el modelo de clases, así como también identificar casos de uso que no fueron definidos en la fase de análisis.
Durante la fase de análisis inicial, el modelador típicamente coloca el nombre “business” de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre “business” es reemplazado con el nombre del método que está siendo llamado por un objeto (Clase). El método llamado, o invocado, pertenece a la definición de la clase instanciada por el objeto en la recepción final del mensaje.
El diagrama de secuencia en la fase de diseño representa las operaciones que deben ser realizadas por una solicitud de un actor definido y las respuestas que el sistema puede arrojar, interactuando con distintos métodos que pertenecen a un mismo o distinto objeto en una distinta capa de servicio.
En la siguiente figura se observa las operaciones que se realizan con sus respectivos mensajes entre métodos de distintos objetos, para atender una solicitud de un actor.
Diagrama de secuencias
Bueno , lo dejo hasta aqui, ya que lo que sigue lo desarrolle e implante especificamente para una organización, la otra información la pueden encontrar en libros o en otras Web, pero creo que como la he explicado se puede usar de mejor forma.
Por cierto, si trabajan con una herramienta de 4 generacion para modelamiento ya sea de datos o de diagramas conceptuales, despues existe la posibilidad de transformar los modemos lógicos a modelos físicos en una base de datos o para un lenguaje en particular.
Espero que les sirva esto
No hay comentarios:
Publicar un comentario