Creación de diagrama de clases UML

Los diagramas de clases utilizados en diferentes etapas del desarrollo de software tienen diferentes niveles de abstracción, es decir, nivel conceptual, nivel de descripción y nivel de implementación. El modelado de aplicaciones utilizando UML también debería ser un proceso iterativo, por lo que deberíamos establecer un concepto de jerarquía de diagrama de clases.

Los diagramas de clases a nivel de concepto describen conceptos en el dominio de la aplicación y estos conceptos están relacionados con las clases que los implementan. Generalmente no existe un mapeo directo. Los problemas de implementación rara vez o no se consideran al dibujar diagramas de clases conceptuales, por lo que los diagramas de clases conceptuales deben ser independientes de los lenguajes de programación específicos. A continuación se muestra una representación de una clase de nivel conceptual.

Describe el diagrama de clases. En este punto estamos examinando la parte de interfaz de la clase, no la parte de implementación. Esta interfaz puede tener muchas implementaciones diferentes debido al entorno de implementación, las características operativas, etc. A continuación se muestra una representación de una clase de capa de descripción.

El diagrama de clases de la capa de implementación realmente considera los problemas de implementación de la clase y proporciona detalles de implementación. En este momento, el concepto de clase debería ser una verdadera clase en sentido estricto. Revela la composición de las entidades de software. Las clases de capa de implementación son las más utilizadas. En muchos casos, las clases de capa de descripción son más útiles para que las personas comprendan el software.

El objetivo final de UML es identificar todas las clases necesarias y analizar la relación entre estas clases. La identificación de clases se realiza durante todo el proceso de modelado. La fase de análisis identifica principalmente las clases relacionadas con el dominio del problema. En esta etapa, debe agregar algunas clases que reflejen ideas y métodos de diseño, así como las clases necesarias para implementar el dominio del problema. En la etapa de codificación e implementación, debido a las características del lenguaje, es posible que deba agregar algunas otras. clases.

Pasos para establecer un diagrama de clases:

(1) Investigar y analizar el área del problema para determinar los requisitos del sistema.

(2) Determinar la clase, aclarar el significado y las responsabilidades de la clase y determinar los atributos y operaciones.

(3) Determinar la relación entre clases.

La identificación de clases es un trabajo que requiere muchas habilidades. Algunas técnicas para encontrar clases incluyen: identificación de sustantivos; determinación de clases basándose en descripciones de casos de uso utilizando análisis CRC; y clases de entidad. Dividir para ayudar a analizar las clases en el sistema; consultar patrones de diseño para determinar las clases; o utilizar los resultados del análisis de dominios existentes para obtener clases;

1. Método de identificación sustantivo:

La clave de este método es identificar entidades en el dominio del problema del sistema. Para describir el sistema, la descripción debe utilizar conceptos y denominaciones en el dominio del problema, e identificar sustantivos y frases nominales de la descripción del sistema. Los sustantivos a menudo pueden identificarse como objetos y los sustantivos en plural a menudo pueden identificarse como clases.

2. Identificar clases a partir de casos de uso:

Los diagramas de casos de uso son esencialmente una forma de descripción del sistema y las clases se pueden identificar naturalmente en función de las descripciones de casos de uso. Para cada caso de uso, puede hacer las siguientes preguntas para ayudar en la identificación:

¿Qué entidades aparecen en la descripción del caso de uso?

¿Qué entidades necesitan cooperar para completar el caso de uso?

¿Qué información se generará y almacenará durante la ejecución del caso de uso?

¿Qué aportación requiere el caso de uso de cada rol asociado a él?

¿Cuál es el resultado de cada rol al que está asociado el feedback del caso de uso?

¿Qué equipo de hardware necesita el caso de uso para funcionar?

En aplicaciones orientadas a objetos, los datos de información pasados ​​entre clases pueden asignarse a ciertos atributos del remitente o los datos de información en sí son un objeto. Al combinar diferentes resultados de identificación de casos de uso, podemos obtener las clases de todo el sistema. En función de las clases, podemos analizar las características dinámicas de los casos de uso para modelar el comportamiento dinámico de los casos de uso.

3. Utilice el método de análisis CRC:

El mayor valor de las tarjetas CRC (Clase, Responsabilidades, Colaboración) es alejar a las personas del modo de proceso de pensamiento y centrarse más plenamente en el tecnología de objetos. Las tarjetas CRC permiten que todo el equipo del proyecto contribuya al diseño. Cuanta más gente participe en el diseño del sistema, más buenas ideas se podrán reunir. Debido a que todos asisten a las reuniones del CRC, generalmente solo se requieren unas pocas tarjetas con los nombres de las clases y en realidad no se escriben tarjetas completas. Mientras se desarrolla la reunión del CRC, algunas personas simulan el sistema y se comunican con objetos y pasan mensajes a otros objetos. Si lo sigue paso a paso, el problema se puede resolver fácilmente. Consta de tres partes: Clase, Responsabilidad y Colaborador.

Aquí hay un ejemplo de una tarjeta CRC: Nombre de la clase Responsabilidad 1 Colaboración de responsabilidad 1 Responsabilidad 2 Colaboración de responsabilidad 2... Una responsabilidad es cualquier cosa que la clase necesita saber o hacer. Estas responsabilidades son conocimientos conocidos por la propia clase o conocimientos requeridos por la clase al ejecutar. La colaboración se refiere a otras clases que obtienen información o ayudan en la realización de actividades. La creación de un modelo CRC requiere los siguientes pasos.

1) Forme un equipo que incluya clientes, diseñadores, analistas y un facilitador. Si no hay tanta gente, pueden ser sólo dos personas, el cliente y usted.

2) Encuentra los sustantivos y sintagmas nominales que existen en los requisitos, prestando especial atención al plural (normalmente conjuntos), y sus correspondientes singulares. Anota en una pizarra o papel todos los conceptos que te vengan por primera vez. Por ridículos que parezcan estos conceptos, escríbelos.

3) Filtrar. Divida los objetos en tres categorías: objetos principales (deben implementarse primero), opcionales (no se pueden determinar en este momento) y objetos innecesarios. Es mejor determinar el alcance de su proyecto antes de hacer esto. Algunos objetos que no están dentro del alcance de este proyecto se pueden implementar utilizando adaptadores ligeros o servidores proxy. Aquí se puede agregar la consideración y aplicación de patrones de análisis y diseño.

4) Crea una tarjeta. Saque las tarjetas CRC y escriba las clases principales en cada tarjeta, y escriba las clases opcionales y las clases excluidas en hojas de papel separadas.

5) Juego de roles. Lo mejor es hacerlo en equipo, es difícil hacerlo solo. Cada persona es responsable de varias categorías. Para cada escenario de caso de uso. El facilitador designa la clase de una determinada persona para comenzar, y una determinada persona verá si puede completarla de forma independiente. Si no puede completarla, todos mirarán la clase que tienen en sus manos. Quien pueda completarla se levantará y declarará. él puede completarlo, para poder continuar. Durante este proceso, todos se sientan después de completar sus deberes. Durante este proceso modifica constantemente las responsabilidades de la clase y anota los nombres de los colaboradores.

4. Ayude a analizar las clases en el sistema en función de clases de límite, clases de control y clases de entidad.

Hay tres tipos principales de clases en UML: clases de límite, clases de control, y clases de entidad. La introducción de los conceptos de clases de límites, clases de control y clases de entidades ayuda a los analistas y diseñadores a determinar las clases en el sistema.

Las clases de límite están ubicadas en la interfaz entre el sistema y el mundo exterior. Formularios, informes y clases que representan protocolos de comunicación, clases que interactúan directamente con dispositivos externos y clases que interactúan directamente con sistemas externos. clases de frontera. Las clases de límite requeridas se pueden determinar mediante el diagrama de casos de uso. Cada par Actor/Caso de uso requiere al menos una clase de límite, pero no todos los pares Actor/Caso de uso requieren una clase de límite única.

Las clases de entidad almacenan información para colocarla en un almacenamiento persistente. El almacenamiento persistente son medios como bases de datos y archivos que pueden almacenar datos de forma permanente. Las clases de entidades se pueden descubrir a través de flujos de eventos y diagramas de interacción. Por lo general, cada clase de entidad tiene una tabla correspondiente en la base de datos y los atributos de la clase de entidad corresponden a los campos de la tabla de la base de datos.

Las clases de control son clases que controlan el trabajo de otras clases. Cada caso de uso generalmente tiene una clase de control que controla la secuencia de eventos en el caso de uso. Las clases de control también se pueden usar en múltiples casos de uso. Otras clases no envían muchos mensajes a la clase de control, pero la clase de control envía muchos mensajes.

5. Análisis del dominio

El proceso de establecimiento de un diagrama de clases es el proceso de análisis y diseño del dominio y sus soluciones. Obtener clases es un proceso que depende de la creatividad personal. A veces es necesario cooperar con expertos en el campo para analizar cuidadosamente el campo de investigación, abstraer los conceptos en el campo, definir su significado y sus interrelaciones, analizar las clases del sistema y utilizar la terminología. el campo. Dale un nombre a la clase. El análisis de dominio es el proceso de identificar, recopilar, organizar, analizar y representar modelos de dominio y arquitectura de software a través de la investigación de sistemas de aplicaciones, teorías, tecnologías, historias de desarrollo, etc. existentes en un campo determinado, y obtener los resultados.