Análisis y Diseño Orientado a Objetos de Sistemas Usando UML resumen

...

Dibujo de un diagrama de clase

Identificación de clases

El diagrama de clases es fundamental para el análisis orientado a objetos. Mediante iteraciones sucesivas, proporciona una base de alto nivel para la arquitectura del sistema y una base de bajo nivel para la adjudicación de datos y comportamiento a clases individuales y ejemplos de objetos y finalmente para el diseño del código del programa que implementa el sistema.

Los nombres de clase se escriben siempre en singular, Aunque sabemos que hay numeroso personal. Esta convención refuerza la visión de una clase como un descriptor de una colección de objetos, más que la colección de objetos en sí misma.

Otra convención es que la mayor parte de los nombres se escriben con letras minúsculas, pero las clases se escriben con letra mayúscula al principio del nombre.

De diagrama de comunicación a diagrama de clase

El paso siguiente en el desarrollo de un modelo de requisitos es generalmente, la generación de un diagrama de clase que corresponde a cada diagrama de comunicación, que a su vez es una realización de un caso de uso.

Ambas muestran símbolos de objetos o clases unidos mediante líneas de conexión.

Un diagrama de clase tiene más o menos la misma estructura que el correspondiente diagrama de comunicación.

La diferencia más evidente es que en un diagrama de comunicación se muestra frecuentemente un actor.

Un diagrama de comunicación contiene solamente ejemplos objeto, mientras que un diagrama de clase generalmente solo contiene clases.

Otra diferencia es que las conexiones entre símbolos de objeto en un diagrama de comunicación simbolizan vínculos, mientras que las conexiones en un diagrama de clase representan asociaciones entre clases.

Finalmente, hay diferencias entre los símbolos de clase y de objeto. Aunque cualquier símbolo estereotipo puede utilizarse en cualquier diagrama, hay algunas diferencias en esta notación. cuando se utiliza la variante de caja rectangular de la notación en un diagrama de comunicación, representa la línea de vida de un ejemplo objeto más que de una clase.

Otra solución para encontrar objetos y clases

Una de ellas consiste en desarrollar primero un modelo dominio, un modelo de case análisis que es independiente de cualquier caso de uso particular.

Merece la pena revisar cualquier documentación preparatoria reunida durante la etapa de búsqueda de hechos. Una segunda lectura, después de un intento inicial de modelado de clase, puede descubrir más clases, como resultado de la mejor comprensión del problema.

Su propia intuición es otra fuente muy útil, junto con la de los colegas. Y puede buscar patrones de análisis.

Algunos consejos para ayudarte a eliminar clases candidato inadecuadas.

- ¿Excede el ámbito del sistema?

- ¿Se refiere al sistema como un todo?

- ¿Duplica a otra clase?

- ¿Es demasiado vago?

- ¿Es demasiado especifico?

- ¿Está demasiado ligado con entradas y salidas físicas?

- ¿Es realmente un atributo?

- ¿Es realmente una operación?

- ¿Es realmente una asociación?

Añadir y localizar atributos

Muchos atributos aparecerán ya en la descripción de caso de uso. Otros surgirán cuando piense en su modelo con mayor detalle. La regla más sencilla es que los atributos deberían situarse en las clases que describen.

Algunas veces es más difícil identificar la clase correcta para un atributo. El atributo puede no pertenecer adecuadamente a ninguna de las clases que ya se han identificado.

Adición de asociaciones

Las asociaciones pueden encontrarse en descripciones de caso de uso y en descripciones de otros textos del dominio aplicación, como verbos estáticos o como acciones que tienen que recordarse por el sistema. Pero esta no es una forma muy confiable de buscar asociaciones.

Solo puede conseguirse un completo conocimiento de las asociaciones en un modelo de clase posteriormente, mediante el análisis de la interacción entre clases diferentes.

Determinación de multiplicidad

Puesto que la multiplicidad de asociación representa una limitación en la forma en que los usuarios pueden realizar sus actividades, es importante comprenderlas perfectamente, y la única manera de conseguirlo es preguntando a los usuarios sobre cada asociación.

Búsqueda de operaciones

Las operaciones son realmente un desglose más detallado de las responsabilidades de alto nivel del sistema modeladas ya como caso de uso.

A veces se encuentran como verbos de acción en descripciones de caso de uso, pero esta imagen es bastante incompleta hasta que se comprenda con mayor detalle la interacción entre clases.

Asignación preliminar de operaciones

Dos consejos ayudan a decidir qué clase situar en cada operación, pero no hay una respuesta sencilla, solo una aproximación satisfactoria.

- Imagine cada clase como un actor independiente, responsable de hacer o de conocer ciertas cosas.

- Localice cada operación en la misma clase como los datos que necesita actualizar o Alos que debe acceder. Sin embargo, muchas veces, esto es problemático, puesto que puede que aún no haya identificado todos los atributos.

Tarjetas CRC (Class Responsibility Callaboration)

Ofrecen una técnica eficaz para explorar las posibles formas de adjudicar responsabilidades a clases y las colaboraciones necesarias para complementar las responsabilidades. Fueron inventadas por Beck y Cunningham(1989).

Las tarjetas CRC son ayuda para agrupar actividades que frecuentemente es divertido hacer.