Opciones de representación |
Representación UML: Modelo, estereotipado como <<modelo de análisis>>.
El modelo de análisis puede tener las siguientes propiedades:
-
Introducción: Una descripción textual que sirve como breve introducción al modelo.
-
Paquetes de análisis: Los paquetes del modelo, que representan una jerarquía.
-
Clases: Las clases del modelo, propiedad de los paquetes.
-
Relaciones: Las relaciones del modelo, propiedad de los paquetes.
-
Realizaciones de guión de uso: las realizaciones de guión de uso del modelo, propiedad de los
paquetes.
-
Diagramas : Los diagramas del modelo, propiedad de los paquetes.
Normalmente, las "clases de análisis" evolucionarán directamente en elementos en el modelo de diseño: algunos se
convierten en clases de diseño, otros se convierten en subsistemas de diseño. El objetivo de un análisis es identificar
una correlación preliminar de comportamiento necesario en elementos de modelado del sistema. El objetivo del diseño es
transformar esta correlación preliminar (y algo idealizada) en un conjunto de elementos de modelo que se pueden
implementar. Como resultado, existe un perfeccionamiento en el detalle y la precisión como uno de los movimientos de
análisis a través de diseño. Como resultado, las "clases de análisis" suelen ser bastante fluidas, cambiables y
evolucionan rápidamente antes de solidificarse en las actividades de diseño.
Los puntos que hay que tener en cuenta al decidir si es necesario un modelo de análisis separado:
-
Un modelo de análisis puede resultar útil cuando el sistema debe diseñarse para múltiples entornos de destino, con
arquitecturas de diseño separadas. El modelo de análisis es una abstracción, o una generalización, del modelo de
diseño. Omite la mayoría de detalles del diseño para proporcionar una visión general de la funcionalidad del
sistema.
-
El diseño es complejo, así que es necesario un diseño simplificado, abstraído, para presentar el diseño a nuevos
miembros del equipo. Una vez más, una arquitectura bien definida puede servir para el mismo objetivo.
-
El trabajo extra necesario para garantizar que los modelos de diseño de & análisis mantienen la coherencia se
debe equilibrar con el beneficio de tener una vista del sistema que representa sólo los detalles más importantes
sobre cómo el funcionamiento del sistema. Puede resultar muy costoso mantener un nivel elevado de fidelidad entre
el modelo de análisis y el modelo de diseño. Un enfoque menos ambicioso puede ser mantener el modelo de análisis
con sólo las clases de dominio más importantes y las abstracciones clave en el diseño. A medida que la complejidad
del modelo de análisis aumenta, también lo hace el coste para mantenerlo.
-
Cuando el modelo de análisis ya no se mantiene, su valor decae rápidamente. En algún momento, si no se mantiene,
dejará de ser útil ya que no reflejará con precisión el diseño actual del sistema. No mantener el modelo de
análisis puede resultar adecuado (puede haber servido para su objetivo), pero la decisión debería ser consciente.
En algunas empresas, donde los sistemas duran décadas, o donde existen diferentes variantes del sistema, un modelo de
análisis separado resulta muy útil.
|