El siguiente modelo es el proceso de refinamiento gradual (refinamiento) y realización de un proyecto desde el inicio hasta el despliegue final
1. Modelo de caso de uso comercial
Modelo de caso de uso de negocio En la fase de arranque del proyecto, utilizar el modelo de caso de uso de negocio para obtener requisitos es establecer un modelo para el negocio real, y para llegar a un consenso con el cliente, el entorno informático no se considera por el momento. .
Un modelo de caso de uso comercial es opcional, especialmente en proyectos de software más pequeños.
2. Modelo de caso de uso conceptual
El modelo de caso de uso conceptual es un subconjunto del modelo de caso de uso comercial en la etapa de inicio del proyecto y es un proceso comercial clave extraído del caso de uso comercial. En proyectos más pequeños, este modelo no es necesario.
3. Modelo de caso de uso del sistema
El modelo de caso de uso del sistema se encuentra al final de la fase de inicio del proyecto o al principio de la fase de elaboración. El modelado del sistema es la adquisición de requisitos, y los casos de uso del sistema son casos de uso comunes comunes, por lo que el modelo de caso de uso del sistema puede denominarse modelo de caso de uso para abreviar.
El modelo de caso de uso es la salida de la adquisición de requisitos y la entrada del diseño de análisis y el proceso de prueba. Se puede utilizar como anexo al contrato para acordar el alcance del desarrollo del sistema.
4. Modelo de dominio
El modelo de dominio es un mapeo del mundo real, centrándose en el concepto del mundo real en lugar de la descripción del lenguaje informático puro, por lo que el modelo de dominio también se denomina perspectiva conceptual. Dado que el modelo de dominio abstraerá características importantes, es más fácil analizar y dar seguimiento a las ideas. En el proceso de diseño del diagrama de clases subsiguiente, también se hará referencia al modelo de dominio como una de las fuentes importantes de inspiración.
El modelo de dominio es esencialmente una parte del diagrama de clases de UML, pero la mayor diferencia con el diagrama de clases completo es que los nombres de clase utilizados en el modelo de dominio se utilizan completamente en la realidad, y cada clase en el modelo de dominio representa un objeto real. no objetos de software de computadora en el modelo.
5. Modelo de análisis
El modelo de análisis es la transición de la fase de requisitos a la fase de diseño.
El modelo de análisis incluye: vista de arquitectura, vista de casos de uso, vista estática, vista dinámica, vista de componentes, vista de implementación
En el diagrama de secuencia, se agrega una clase de límite entre el protagonista y el sistema como interfaz de operación, y se agrega una clase de control entre la clase de límite y la interacción de la entidad como lógica comercial. La clase de límite no debe interactuar directamente con la clase de entidad .
Relaciones entre clases:
实体类和实体类之间可以有聚合或组合关系，不要有依赖关系，只能通过控制类间接交互；
控制类和控制类之间不要有聚合或组合关系，尽量减少依赖；
边界类依赖于控制类，控制类依赖于实体类。
6. Arquitectura de software y modelo de marco
Arquitectura: es el esqueleto del sistema, es el modelo del sistema, es la definición y descripción de alto nivel del sistema, y es estratégica; el
marco es la solución, es la estructura básica, es el adoptado y reutilizable solución a un determinado problema, táctico
La arquitectura de software se describe a través de dos perspectivas: la perspectiva de amplitud y la perspectiva de profundidad.Estas dos perspectivas constituyen una descripción "tridimensional" de la arquitectura de software.
Perspectiva de amplitud: primero describa las capas de software;
perspectiva de profundidad: luego describa cada capa con más profundidad.
Marco de software: es una solución general a un problema común, como un marco comercial o de código abierto de terceros.
Se ha realizado aquí: diseño del esquema
7. Modelo de diseño
El modelo de diseño, también conocido como diseño detallado, es el último paso del modelado antes de codificar los fenómenos.
El modelo de diseño incluye: vista de arquitectura, vista de casos de uso, vista estática, vista dinámica, vista de componentes y vista de implementación. El modelo de diseño se puede realizar refinando el modelo de análisis.
Diagrama de clase [UML] Diagrama de clase Diagrama
de actividad [UML] Diagrama de actividad, diagrama de máquina de estado Diagrama de máquina de estado, diagrama de secuencia Diagrama de secuencia Diagrama de
caso de uso [UML] Diagrama de caso de uso, diagrama de implementación Diagrama de implementación, diagrama de componente Diagrama de componente
8. Modelo de componentes
Un componente es un subelemento que constituye una arquitectura y, por lo general, se denomina componente de una arquitectura. En los sistemas distribuidos en general, a menudo se hace referencia a los componentes.
En diferentes casos, los componentes tienen diferentes nombres: módulos, subsistemas, bibliotecas de clases, programas ejecutables, paquetes, etc.
9. Modelo de implementación
El modelo de implementación consta de nodos de configuración y componentes. En general, los nodos de configuración se utilizan para describir el hardware y los componentes para describir el software, y normalmente se utilizan en sistemas distribuidos.
