Un proceso conducido por casos de Uso

1. El Modelo de Caso de Usos representa los requisitos funcionales.

1.1. La primera disciplina que se desarrolla dentro de cada iteración es la de requerimientos (posiblemente luego de realizar un modelado del dominio o del negocio). El objetivo de esta fase es determinar los requerimientos del sistema. Los requerimientos funcionales son plasmados a través de casos de uso en un Modelo de Casos de Uso.

1.2. El modelo de casos de uso ayuda al cliente, a los usuarios, y a los desarrolladores a llegar a un acuerdo sobre cómo utilizar el sistema.

1.3. Cada tipo de usuario del sistema se representa mediante un actor que define un rol de utilización del sistema.

1.4. Los actores modelan el entorno del sistema, y los casos de uso especifican el sistema.

1.5. Un diagrama de casos de uso describe parte del modelo de casos de uso y muestra un conjunto de casos de uso y actores asociados.

2. Creación del modelo de diseño a partir del modelo de análisis

2.1. El modelo de diseño se crea tomando el modelo de análisis como entrada principal (cuando este fue creado), y se lo adapta a un entorno de implementación particular.

2.2. Esta adaptación incluye considerar por Ej. adecuaciones a un framework de construcción de GUI particular, uso de un ORB, frameworks, sistemas heredados, etc.

2.3. El modelo de diseño es similar al modelo de análisis ya que incluye clasificadores, relaciones, y realizaciones de casos de uso, y existe una relación de traza entre los artefactos del diseño y los del análisis, pero mientras estos últimos son conceptuales, los del diseño deben adecuarse al entorno de implementación específico.

3. Agrupación de clases en subsistemas.

3.1. Es imposible utilizar sólo clases para realizar los casos de uso en un sistema grande con cientos o miles de clases. Es imposible comprender el sistema sin una organización de más alto nivel. Las clases se agrupan en subsistemas.

3.2. Un subsistema es un agrupamiento semánticamente útil de clases o de otros subsistemas.

3.3. Los subsistemas de bajo nivel se denominan subsistemas de servicio. Los subsistemas de servicio constituyen una unidad manejable de funcionalidad opcional.

3.4. Los subsistemas pueden diseñarse en forma descendente o ascendente.

3.5. El diseño ascendente se realiza a partir de la agrupación de clases ya identificadas. Se proponen subsistemas que empaquetan clases en unidades claramente definidas.

3.6. El diseño descendente, implica la definición previa por parte del arquitecto de los subsistemas de más alto nivel y las interfaces entre ellos, antes de que se hayan identificado las clases.

4. Introducción

4.1. Veamos una visión general de cómo se desarrolla el trabajo a través de todos los flujos en un proceso dirigido por casos de uso. Tomaremos como ejemplo una versión simplificada de un sistema para un Cajero Automático (CA).

5. Creación del modelo de análisis a partir de los casos de uso.

5.1. El modelo del análisis es opcional. En él, se describen un conjunto de Clases del Análisis que se utilizan para realizar una descripción abstracta de la realización de los casos de uso del modelo de casos de uso.

5.2. Las clases del análisis luego evolucionan hacia otras clases más detalladas en el Modelo del Diseño. El modelo de análisis crece incrementalmente a medida que se analizan más y más casos de uso.

5.3. En cada iteración elegimos un conjunto de casos de uso y los reflejamos en el modelo de análisis. Construimos el sistema como una estructura de clasificadores (clases del análisis) y relaciones entre ellas.

5.4. También describimos las colaboraciones que llevan a cabo los casos de uso, es decir las realizaciones de los casos de uso.

6. Creación del modelo de implementación a partir del modelo de diseño

6.1. El modelo de implementación está formado por componentes, que incluyen todos los ejecutables (Ej. ActiveX, JavaBeans, .exe), y otro tipo de componentes como ser componentes de fichero (código fuente, shell scripts, etc.), componentes de tabla (elementos de base de datos), etc.

6.2. Un componente es una parte física y reemplazable del sistema que cumple y proporciona la realización de un conjunto de interfaces.