Este artículo introduce principalmente el concepto de arquitectura y amplía la importancia del análisis de la demanda.
Planeo hacer una serie en el seguimiento, e introducir regularmente algunos casos de realización de requisitos desde mi trabajo.
Nota: Debido a que el contenido de la arquitectura es relativamente extenso, cada punto puede expandirse en una serie de artículos.
Por lo tanto, este artículo es solo una charla incoherente y la mayor parte del contenido es solo una introducción. Consideraré escribirlo. más tarde cuando tenga tiempo.
Introducción a la arquitectura
1. Malentendidos
Cuando se trata de arquitectura, muchos desarrolladores, especialmente el desarrollo de back-end, estarán asociados con un montón de contenido técnico:
- Sub-biblioteca y sub-tabla
- balanceo de carga
- diseño de microservicios
- Principio CAP distribuido
- Límite de corriente de degradación del fusible
- descubrimiento de registro
- Malla de servicio
De hecho, estos no son el contenido principal de la arquitectura, son solo una pequeña parte de las soluciones a algunos requisitos o problemas, e
incluso estas soluciones tienen un ámbito de aplicación muy reducido, se utilizan principalmente para proyectos de Internet (alta concurrencia). , alto rendimiento, grandes requisitos de datos)
La gran mayoría de los proyectos, especialmente los proyectos de puesta en marcha, no utilizan estas soluciones en absoluto, porque durante un período de tiempo considerable al principio, no hay una gran cantidad de datos, usuarios o concurrencia.
2. Concepto
En diferentes plataformas, hay diferentes interpretaciones de la arquitectura:
- Wikipedia: la arquitectura del software es una descripción abstracta de la estructura general y los componentes del software, que se utiliza para guiar el diseño de todos los aspectos de los grandes sistemas de software.
- ISO/IEC: El enfoque estructural básico del sistema, incluidos los elementos del sistema, la relación entre estos elementos y los principios que guían el diseño y la implementación del sistema.
- IEEE: La arquitectura es la estructura organizativa básica de un sistema a nivel de sus componentes, incluida la relación entre los componentes internos del sistema, la relación entre los componentes y el exterior, y los principios que determinan su diseño y evolución.
- Enciclopedia de Baidu: Arquitectura es una descripción abstracta de la estructura general y los componentes del software, que se utiliza para guiar el diseño de todos los aspectos de los sistemas de software a gran escala.
Yo mismo encontré uno en Internet, creo que es más apropiado y más fácil de entender.La definición de arquitectura:
- Defina el límite del sistema de destino de acuerdo con el problema a resolver .
- Y segmente el sistema de destino de acuerdo con cierto principio . El principio de la segmentación es facilitar que diferentes roles trabajen en las partes divididas en paralelo o en serie. Generalmente, el paralelismo puede reducir el tiempo.
- Para estas partes divididas, establecer un mecanismo de comunicación .
- De acuerdo con el mecanismo de comunicación del paso anterior, estas partes se pueden conectar orgánicamente, fusionar y ensamblar en un todo, y completar todo el trabajo del sistema de destino.
Nota: La segmentación no significa dividir los microservicios, y también se pueden implementar varios módulos como una sola unidad. Sin embargo, después de la segmentación, es más conveniente implementar más adelante de acuerdo con los microservicios.
3. ¿Por qué necesitamos arquitectura?
Mira una foto:
Esta foto muestra que la era que vivimos es una era cambiante, esta foto también es aplicable a muchos productos/demandas, hay un dicho que dice: la mayor certeza de la demanda es la Incertidumbre
en la demanda.
Significa [demanda variable], esta característica es estable y sin cambios.
Extracto de Internet:
- El objetivo principal del diseño de la arquitectura: resolver los problemas causados por la complejidad del sistema bajo la premisa de realizar la función objetivo del sistema.
Fuentes de complejidad del sistema:- Los requisitos complican la tecnología
- La gente complica la tecnología.
- la complejidad de la tecnología en sí
- La complejidad del funcionamiento estable del sistema.
Para hacer frente a la complejidad del sistema y la variabilidad de los requisitos, la planificación y el diseño de la arquitectura deben llevarse a cabo con anticipación.Creo que los pasos generales del diseño de la arquitectura son los siguientes:
- Recopilar requisitos y comprenderlos
, incluidos, entre otros, comunicarse y alinearse con los especialistas en marketing, gerentes de productos, usuarios finales y realizar análisis de factibilidad; - Análisis de requisitos
Aclarar los objetivos que debe lograr el sistema, incluidos los requisitos funcionales, los requisitos no funcionales (incluidos los requisitos de seguridad) y las limitaciones de tiempo; este paso generalmente requiere clasificar
algunos diagramas de casos de uso, diagramas de secuencia y diagramas de estado para prepararse para describir requisitos y comunicar; - Selección de tecnología/diseño técnico
En este paso, es necesario aclarar el lenguaje de desarrollo, las herramientas de desarrollo, el marco técnico, la base de datos, el middleware, etc. utilizados, así como realizar el diseño del esquema y el diseño detallado; - División del equipo/programación técnica
- Desarrollo iterativo/Entrega continua
- Implementación/Monitoreo de O&M
Cada paso del diseño de la arquitectura requiere que los arquitectos elaboren un plan relativamente equilibrado basado en los antecedentes actuales. Si los
requisitos se pueden cumplir es el criterio más importante, o incluso el único criterio,
y no existe una corrección única para ningún requisito. arquitectura o único implementación.
Los factores de fondo de los arquitectos generalmente incluyen:
- La experiencia técnica personal del arquitecto, que afectará principalmente la selección técnica.Por
ejemplo, elegiré MySQL para la base de datos, no PostgreSQL o MongoDB, porque tengo una experiencia relativamente rica en el manejo de problemas de MySQL, mientras que otras bases de datos tienen menos experiencia; - La experiencia del proyecto del arquitecto, que afectará principalmente a la cognición de límites y la división de módulos.
Por ejemplo, he trabajado en un sistema SaaS y consideraré la transmisión del SaaS-ID global y futuras versiones en escala de grises con anticipación al diseñar,
pero nunca he ha estado involucrado en el negocio de seguros, si hace un proyecto de seguros, debe gastar mucha energía para comprender el negocio de seguros antes de poder diseñarlo;
Los requisitos del sistema, incluidas las funciones y las expectativas futuras que el sistema puede lograr, incluidos los requisitos no funcionales;- Requisitos de duración, tiempo de entrega requerido por el sistema, si se puede entregar por etapas
- Capacidades del equipo, que afectarán la selección de tecnología, la división del trabajo y la gestión de proyectos
Por ejemplo, si hay expertos en C++ en el equipo, puede considerar usar C++ para implementar la compresión de imágenes del lado del cliente o alguna compresión de imágenes del lado del servidor. - Las limitaciones del software afectan la selección de tecnología.
Por ejemplo, solo podemos usar Centos para la implementación, por lo que no podemos elegir el desarrollo de .Net Framework. - Las limitaciones de hardware afectan la selección de tecnología y las consideraciones de costos.
Por ejemplo, cooperamos con xx cloud, pero no tienen soporte para RabbitMQ, por lo que nuestra cola de mensajes debe reemplazarse con otros tipos disponibles.
análisis de la demanda
1. Encontrar problemas es más importante que resolverlos
En los pasos del diseño de la arquitectura, el paso más importante es el paso del análisis de requisitos , porque:
【Encontrar problemas es más importante que resolverlos】
Si entiende mal el problema, entonces la inversión en resolver el problema puede ser desperdiciada, o incluso no resuelven el problema en el momento correcto, lo que lleva a consecuencias impredecibles.
Mire una imagen, alguien está haciendo sopa de tomate y huevo:
quiero ilustrar una verdad a través de esta imagen:
la experiencia y el conocimiento de todos son diferentes, lo que conducirá a diferentes resultados cognitivos. Algunas cosas que usted piensa son de sentido común, pero otra persona no. No lo entiendo en absoluto
Es necesario comprender correctamente las necesidades/problemas a través de una comunicación/recuento continuo, para que los próximos pasos se puedan llevar a cabo correctamente.
Publique otra imagen para ilustrar que si se implementa un requisito incorrecto, la diferencia de costos será diferente en las diferentes etapas de realización. Se puede ver que el desperdicio de costos en la etapa de análisis de requisitos es el más bajo, y la diferencia ya es 10 veces mayor en la etapa de codificación. , sin mencionar la fase de mantenimiento en línea:
2. Cómo hacer un análisis de necesidades
La función más importante del análisis de requisitos es identificar los requisitos efectivos. Por lo general, existen tres niveles de requisitos:
-
Requisito comercial ( Requisito comercial ) representa los objetivos de alto nivel de la organización o el cliente. Los requisitos comerciales generalmente provienen de los inversores del proyecto, los clientes que compran productos, los gerentes de los usuarios reales, los departamentos de marketing o los departamentos de planificación de productos. Los requisitos comerciales describen por qué una organización debe desarrollar un sistema, es decir, lo que la organización quiere lograr.
Comprensión: quien quiera construir este sistema también puede entenderse como demanda del mercado, qué problemas del mercado o puntos débiles se resuelven,
como la demanda de los desarrolladores inmobiliarios para construir una casa. -
Los requisitos del usuario (requisito del usuario) describen el objetivo del usuario o las tareas que el usuario requiere que el sistema pueda completar. Los casos de uso, las descripciones de escenarios y las tablas de respuesta a eventos son formas efectivas de expresar las necesidades del usuario. En otras palabras, los requisitos del usuario describen lo que los usuarios pueden hacer con el sistema.
Entender: Quién está usando el sistema. Por ejemplo, la demanda de viviendas planteada por los usuarios que compran viviendas. -
El requisito funcional (requisito funcional) estipula las funciones de software que los desarrolladores deben implementar en el producto. Los usuarios utilizan estas funciones para completar tareas y satisfacer las necesidades comerciales. Comprensión: qué funciones debe implementar el propio sistema para cumplir con los dos tipos de requisitos anteriores,
como la casa en sí debe qué capacidades
Daremos salida a diferentes niveles de requisitos en diferentes etapas.Durante el desarrollo comercial, debemos comprender los requisitos de los tres niveles y considerar y cumplir los requisitos de cada nivel a su vez.
Los pasos generales del análisis de requisitos son los siguientes, y generalmente hay documentos de requisitos correspondientes y varias salidas de leyenda UML:
3. Diagramas UML comunes:
Este artículo solo presenta 5 diagramas UML de uso común.
Diagrama de contexto del sistema
Defina los límites y las interfaces entre el sistema que se va a construir y las entidades externas (personas, equipos, otros sistemas). Solo concéntrese en las entidades que
están directamente relacionadas con el sistema actual y no considere las dependencias
de las dependencias Use, primero determine el contexto del sistema y luego use el modelado de casos. 2. ¿Ayudar a los participantes del sistema a comprender intuitivamente quiénes son los usuarios del sistema que se construirá en un nivel superior? ¿Para qué puedo usar el sistema? ¿Qué no puedes hacer? ¿De quién depende el sistema? 3. Ayudar a los creadores del sistema a aclarar los límites y el alcance del sistema antes del inicio oficial, lo que facilita la discusión y mejora del alcance del sistema con las partes relevantes;
use el diagrama del caso
Define los participantes del sistema, los casos de uso contenidos en el sistema y la relación entre ellos.
El siguiente es el diagrama de casos de uso del sistema expreso intraurbano:
el papel del diagrama de casos de uso:
el diagrama de casos de uso es el producto del análisis de requisitos, la función principal es describir la relación entre los participantes y los casos de uso y ayudar a los desarrolladores a visualizar las funciones del sistema. Con la ayuda de los diagramas de casos de uso, los usuarios del sistema, los analistas del sistema, los diseñadores del sistema y los expertos en el dominio pueden analizar los problemas de manera visual, lo que reduce muchas barreras de comunicación y facilita el consenso sobre los problemas.
El diagrama de casos de uso expresa visualmente los requisitos del sistema, tiene las ventajas de la intuición y la estandarización y supera las deficiencias de la descripción de texto puro.
El método de caso de uso es definir la función del sistema completamente desde el exterior, lo que separa completamente los requisitos y el diseño. No necesitamos preocuparnos por cómo se completan las diversas funciones dentro del sistema, el sistema es una caja negra para nosotros.
Diagrama de estado
Describir el comportamiento dinámico o la transición de estado de una entidad en el sistema en función de las respuestas de eventos.
El siguiente es el diagrama de estado de orden del sistema expreso intraurbano:
El papel del diagrama de estado:
el diagrama de estado describe claramente la secuencia de transición entre estados, y la secuencia de ejecución de eventos se puede ver claramente a través de la secuencia de transición de estado.
Sin diagramas de estado inevitablemente tendríamos que usar muchas palabras para describir la secuencia legal de eventos externos.
Una secuencia clara de eventos ayuda a los programadores a evitar errores en la secuencia de eventos al desarrollar programas.
Diagrama de secuencia del sistema
Se utiliza para describir la secuencia cronológica de mensajes enviados entre objetos, mostrando una colaboración dinámica entre varios objetos.
El siguiente es el diagrama de secuencia del acaparamiento de pedidos en el sistema expreso intraurbano:
Función del diagrama de secuencia:
El diagrama de secuencia se utiliza para mostrar la interacción y la transmisión de mensajes entre objetos dentro de un rango de tiempo específico. Los diagramas de secuencia nos ayudan a visualizar y comprender el comportamiento de un sistema y cómo los diversos objetos cooperan para realizar una función específica. Esto es invaluable para analizar, diseñar y comprender los sistemas de software.
Diagrama de actividad del sistema (diagrama de flujo)
Se utiliza para describir las actividades, los puntos de decisión y las sucursales del sistema, etc.
El siguiente es el diagrama de actividad empresarial del sistema expreso intraurbano para la toma de pedidos:
Función del diagrama de actividad:
el diagrama de actividad se utiliza principalmente para describir el negocio lógica, flujo de trabajo y secuencia de operaciones en el sistema. El diagrama de actividades muestra gráficamente la relación dinámica y el control de procesos entre diferentes actividades en un contexto específico. Puede ayudarnos a analizar profundamente el comportamiento y la secuencia de operación del sistema, para que los requisitos y la lógica puedan aclararse en la etapa de diseño.
Nota: Los diagramas de actividades se utilizan con mayor frecuencia en las actividades de desarrollo reales. Generalmente, dibujar un diagrama de actividades equivale a haber desarrollado mentalmente un programa.
4. Requisitos no funcionales
Durante el análisis de requisitos, los requisitos no funcionales del sistema también deben confirmarse y generarse en la salida del análisis de requisitos.
Consideraciones comunes para requisitos no funcionales:
- velocidad de finalización de la tarea
- La precisión del resultado.
- seguridad operativa
- capacidad del producto
- rango de valores permitidos
- Rendimiento, como tps
- eficiencia en el uso de recursos
- fiabilidad
- Tolerancia a fallas y robustez
- Escalabilidad
- escalabilidad
En el siguiente artículo, presentaremos el proceso de recopilación y generación de requisitos no funcionales.