Directorio de artículos
1. El ciclo de vida del diseño de la arquitectura de software
¿Qué es la arquitectura? Si le preguntas a diez personas , es posible obtener once respuestas diferentes; si vas a los libros relevantes, cada uno puede dar una definición diferente.
Por lo tanto, no necesitamos enredarnos en esos conceptos, siempre y cuando el método sea el correcto y la tarea del proyecto se pueda completar, no importa el gato negro o el gato blanco, el gato que puede atrapar al ratón es un buen gato. !
1. Proceso de desarrollo de software
Un proyecto de software ha pasado por muchos enlaces desde el inicio del proyecto hasta la entrega final . Específicamente para el ciclo de vida del diseño de software, puede incluir estas etapas: investigación de requisitos-análisis de requisitos-esquema de diseño-diseño detallado-verificación de arquitectura-desarrollo-prueba de unidad-prueba de integración .
Los pasos anteriores siguen siendo conceptos muy aproximados . En el funcionamiento real, cada uno de estos pasos se puede subdividir en muchos enlaces de ejecución específicos.
P.ej:
- Investigación de la demanda: ¿qué se debe hacer? ¿Qué método se utiliza? ¿Cuál es la ideología rectora? ¿Cuáles son algunas buenas herramientas?
- Análisis de la demanda: ¿cómo analizarlo? ¿Deben analizarse todos los requisitos? ¿Cómo encontrar los requisitos clave?
- Diseño detallado: ¿Cuáles son los mejores métodos prácticos en ingeniería de software? ¿Cómo superponer? ¿Cómo dividir módulos?
Todos estos son problemas que deben estar involucrados en el proceso de diseño de software. Entonces, ¿ cuál es el objetivo final del diseño de software ? Son los siguientes documentos:
- Arquitectura lógica
- Estructura física
- Arquitectura operativa
- Arquitectura de desarrollo;
2. Acerca de Taolu
Creo que en este mundo todo tiene una rutina , incluso cualquier cosa, cualquier campo y cualquier industria.
Cuando ingresamos a un nuevo campo, por ejemplo, le permitimos diseñar un sistema de despacho de vehículos, un sistema de control de robot o diseñar un walkie-talkie, una puerta de enlace de IoT, si es un recién llegado en este campo , entonces debe tener un ojo morado. : No entiendo este campo en absoluto, ¿cómo diseño?
Esto me recuerda una pequeña historia:
Una vez me incorporé a una nueva empresa y me hice cargo del trabajo de un antiguo colega. En ese momento, se realizó la evaluación de KPI y la tasa de error directo (es decir, la proporción de errores resueltos a la vez, y el personal de control de calidad no volverá a eliminarlos), que es un indicador importante. Ante tantos errores en el sistema, el líder me preguntó: ¿Cuánto tiempo te llevará resolver estos problemas? Dije: nunca antes había estado en contacto con este aspecto del trabajo y no puedo dar una hora exacta. El líder dijo: No importa, solo necesitas darme un tiempo específico. Me quedé estupefacto en ese momento.
En este momento, lo más importante es comprender y dominar rápidamente los conocimientos básicos básicos e importantes en este campo . ¿Entonces qué debería ser hecho? ¡Encuentra una rutina !
No seas codicioso por todo, no esperes dominar todo el contenido relevante, esto es imposible, especialmente en un corto período de tiempo. Nuestro objetivo es hacer un buen trabajo y completar el proyecto .
En este momento, mi enfoque general es: ¡ encuentre una rutina!
Puede ser un poco ilusorio decir eso, así que tomemos como ejemplo el diseño arquitectónico en el desarrollo de software . Encuentre el siguiente contenido relacionado en los libros y materiales de ingeniería de software o gestión de proyectos:
- ¿Cómo diseñaron otros la arquitectura?
- ¿Qué pasos se necesitan en el proceso de diseño?
- ¿Cuál es la entrada en cada paso? ¿Cuál es la salida?
- ¿Cuáles son los puntos a considerar en cada paso?
- ¿Cuáles son algunas buenas herramientas de software?
- ¿Cómo comunicarse con las personas relevantes del proyecto (jefe de proyecto, desarrollador, tester, cliente de la Parte A)?
Cuanto más peine de las experiencias de estas personas , resuma un conjunto para su propia "Metodología" , luego vaya paso a paso de acuerdo con esta rutina particular cuando se ejecute, de acuerdo con la situación real , ajuste dinámico oportuno , en general, podemos sin problemas Avanza un proyecto.
3. Primero rígido, luego optimizado, luego solidificado
Estos nueve personajes fueron propuestos por Ren Zhengfei, el director de Huawei, cuando presentó el sistema de gestión, un método muy práctico.
- Rigidez: pararse sobre los hombros de gigantes: "cortar pies y calzar zapatos" en las primeras etapas del aprendizaje;
- Optimización: dominar el arma de la autocrítica: absorber, mejorar e innovar continuamente en la práctica para optimizarse;
- Solidificación: La innovación se organiza y se restringe. Si no hay restricciones, la innovación es una innovación caótica y desordenada. Necesita ser apisonada capa por capa como tierra apisonada, paso a paso para solidificar los resultados de la optimización por fases;
Para el diseño de la arquitectura de software, también podemos seguir estos pasos.
El primer paso es la rigidez , que es seguir una rutina fija . Aunque pueda "caer en la sabiduría convencional " , al menos puede asegurar que va por el camino correcto y no se desviará . ¡Esto es lo más importante!
¿Qué significa si otros lo consideran un "legado"? Explique que otros piensan que su enfoque está en línea con el proceso de trabajo más "general" en este campo, lo que equivale a reconocer que realmente ha entrado en este campo. ¡Esto es algo bueno!
Como principiante, ¿no debería estar orgulloso de ser evaluado así ? Después de todo, sabemos en nuestro corazón: solo soy un Xiaobai que acaba de entrar en este campo.
4. El Buda dijo: "Saber lo que digo es como un hombre que entiende lo que digo".
El propósito de escribir este artículo es principalmente hablar sobre cómo "rígido" el diseño de la arquitectura del software.
Cuando entramos por primera vez en la industria del desarrollo de software, nuestro trabajo diario consistía principalmente en codificar , y tal vez no estábamos lo suficientemente calificados para diseñar la arquitectura de todo el sistema. Pero esto no nos impide tomar la iniciativa para aprender . Las oportunidades están reservadas para los que están preparados. Si un día aparece el pozo del diseño arquitectónico en el equipo de proyecto, ¿qué zanahoria encontrará el líder para llenar el pozo?
Por lo tanto, este artículo presenta principalmente los pasos de diseño de software más básicos y básicos , así como las ideas de orientación y las herramientas útiles que se utilizan en cada paso .
Si ya eres ingeniero senior de diseño de software, puedes ir a tomar un café y disfrutar de tu vida. Por supuesto, también puedes compartir tu metodología. ¡Aprendemos los unos de los otros!
Estos contenidos no los descubrí yo mismo, sino que los obtuve leyendo libros, buscando materiales y resumiendo durante el proceso de desarrollo del proyecto, son más adecuados para el proyecto que estoy afrontando y yo solo soy un portador de conocimiento .
Antes, me refería principalmente a varios libros sobre diseño de arquitectura de software , aprendí unos de otros y resumí un conjunto de métodos que me convenían. La última vez que me mudé, perdí muchos libros, dejando solo las notas fragmentarias en la computadora . La fuente del material para este artículo son estas notas. Por supuesto, la mayor parte del contenido proviene de libros. Solo hice algunas concesiones y recortes .
En el sexto artículo del "Sutra del diamante", Tathagata a menudo dice: "Esperas a los monjes, sabes lo que digo, como una metáfora; la ley debería ser abandonada, y mucho menos ilegal".
Dharma es como una balsa para que la gente cruce un río . Una vez que lo cruzas y llegas a la orilla, debes tirar la balsa y dejar de pensar en la balsa en tu corazón. La balsa es como el Dharma, y el Dharma debe descartarse, y mucho menos algo que no es Dharma, ¿por qué todavía estás enredado con él?
Por lo tanto, la rutina de diseño de la que estoy hablando aquí también es similar a una balsa, que es un andamio para ayudarlo cuando ingresa por primera vez al diseño de la arquitectura del software . Cuando ingresa a la "optimización" del segundo nivel, puede tirar el andamio.
En ese momento, puede decir con seguridad: "Lo que escribe el hermano Dao tiene que ver con la escritura, la pediatría, necesito explorar rangos más avanzados". ¡En este momento, me gustaría felicitarte desde el fondo de mi corazón!
2. Investigación de la demanda y análisis de la demanda
La mayoría de la gente está de acuerdo en que "la demanda determina la arquitectura" , pero ¿cómo determinan los requisitos la arquitectura? Hablemos de mi comprensión en esta parte.
En la etapa de aprobación del proyecto, si tiene suerte, puede obtener un documento "Especificación de requisitos de funciones de software" (para las especificaciones de requisitos de algunas empresas japonesas, son realmente pervertidas y detalladas). Si no tiene suerte, no tiene ningún documento y todos los requisitos deben ser recopilados y ordenados por usted mismo.
En un sentido estricto, la demanda es una función ; en un sentido amplio, también incluye requisitos no funcionales como atributos de calidad y restricciones condicionales .
1. Requisitos funcionales
La parte de requisitos funcionales es la más intuitiva, que es lo que debe lograr el software que diseñamos . En un sistema, no puede haber límites claros entre varias funciones. A través de ciertas interacciones entre cada módulo pequeño , se forma una "cadena de cooperación" para completar la función designada.
Por ejemplo, la siguiente imagen es un artículo que escribí antes: Desarrollo de puerta de enlace de IoT: proceso de diseño basado en bus de mensajes MQTT (activado) , el modelo de interacción entre diferentes módulos, las partes roja y azul son dos cadenas de colaboración diferentes.
Por supuesto, esta imagen es la arquitectura del sistema diseñada final (en capas, submódulo), antes de obtener esta imagen, primero debemos recopilar y organizar todos los requisitos funcionales .
En esta etapa, lo más importante es qué hacer , no cómo hacerlo . Además, como diseñador, debes hacerte una pregunta con frecuencia: ¿estás incompleto? ¿Hay alguna omisión?
2. Atributos de calidad
Podemos clasificar los requisitos de calidad según diferentes etapas :
etapa de desarrollo
- Reutilización, no realice trabajos repetitivos;
- Flexible y fácil de expandir (piense en las actividades psicológicas de los desarrolladores cuando cambian los requisitos);
- Fácil de entender (piense en cuándo se hace cargo de los proyectos de otras personas);
- Pruebas convenientes (pruebas unitarias, pruebas de integración);
- Portátil (especialmente proyectos integrados, deben ejecutarse en diferentes plataformas);
Fase operativa
- El sistema debe ser confiable;
- El rendimiento debe cumplir con ciertos requisitos (rendimiento, tiempo de respuesta, etc.);
- Sin lagunas, seguridad del sistema;
- La escalabilidad debería ser buena para facilitar la expansión y la implementación;
3. Restricciones
Las restricciones se refieren principalmente a algunas condiciones restrictivas , como:
- La pila técnica de los miembros del equipo (si todos usan C, no debe elegir C ++);
- Cuáles son los recursos dados por el líder;
- Si usa algún software de código abierto, ¿hay algún error? ¿Es conveniente para el desarrollo secundario?
- ¿Cuánto dura el ciclo de desarrollo del proyecto?
- ¿Cuáles son las plataformas operativas del software? Cuales son las restricciones?
4. Dibuja un diagrama de casos de uso.
Con respecto al concepto de diagrama de casos de uso, no puedo resumirlo bien, por lo que citaré directamente la definición en Baidu Zhili:
El diagrama de casos de uso se refiere a una vista compuesta por actores (Actores), casos de uso (Casos de uso), límites y las relaciones entre ellos para describir las funciones del sistema .
Un diagrama de caso de uso (caso de usuario) es un diagrama modelo de funciones del sistema que los usuarios externos (llamados participantes) pueden observar. El diagrama de casos de uso es el modelo del sistema . El diagrama de casos de uso presenta algunos participantes, algunos casos de uso y las relaciones entre ellos. Se utilizan principalmente para modelar el comportamiento funcional de sistemas, subsistemas o clases.
Hay varios conceptos :
- Participante: No se refiere específicamente a las personas, sino que se refiere al papel que desempeñan las personas ajenas al sistema al utilizar el sistema o interactuar con él.
- Caso de uso: Es la descripción de un conjunto de secuencias de acciones que incluyen variables, el sistema ejecuta estas acciones y produce resultados observables que transmiten el valor de participantes específicos.
- Límite del sistema: se utiliza para representar el límite del sistema que se está modelando. El interior del límite representa los componentes del sistema y el exterior del límite representa el exterior del sistema.
- Flechas: se utilizan para indicar la relación entre los participantes y el sistema para interactuar enviándose señales o mensajes entre sí.
- Rol: (1) Obtención de requisitos; (2) Pruebas de orientación; (3) También puede desempeñar un papel de orientación en otros flujos de trabajo a lo largo del proceso.
Encontré algunos diagramas de casos de uso en línea, cada uno un círculo , representa una función.
A través del diagrama de casos de uso, puede ver todas las funciones proporcionadas por el sistema de un vistazo.
5. Escriba la descripción del caso de uso
Pero el diagrama de casos de uso no describe el proceso de ejecución de cada caso de uso en detalle , es decir: el diagrama de casos de uso describe los requisitos del sistema en su conjunto, pero no describe el proceso de comportamiento .
Por lo tanto, podemos adjuntar una descripción simple o detallada del caso de uso a cada caso de uso, para confirmar el proceso de comportamiento de este caso de uso de manera más específica .
Los siguientes son también dos ejemplos de descripción de casos de uso que se encuentran en Internet. Se puede ver que no existe un formato uniforme, y es necesario aumentarlo o disminuirlo según la naturaleza del proyecto.
6. Identificar los requisitos clave
Supongamos que enumeramos todos los requisitos (requisitos funcionales, atributos de calidad, restricciones condicionales) tanto como sea posible en la recopilación y el análisis continuos , ¿qué se debe hacer a continuación? Con tantas demandas, ¿con cuál deberíamos empezar?
Requisito clave = función clave + calidad clave. Determina la dirección general de la arquitectura.
Lo primero que hay que tener claro es que es imposible que todas las necesidades sean iguales . Tenemos que encontrar los siguientes tres tipos de requisitos de numerosos casos de uso:
- Requisitos funcionales clave: aquellos que involucran la mayoría de los módulos y los métodos más representativos de colaboración entre módulos, filtran un subconjunto de funciones clave;
- Atributos de calidad clave: En las etapas de desarrollo y operación, ¿qué atributos de calidad tienen un mayor impacto en la arquitectura del software, si existen conflictos entre los atributos de calidad, a cuál se le debe dar prioridad?
- Parte de alto riesgo: desde la perspectiva de la dificultad técnica, ¿qué funciones son riesgosas en la implementación técnica y necesitan experimentar la verificación técnica de antemano?
Estos tres tipos de requisitos son los requisitos en los que debemos centrarnos y también son los materiales de entrada para el siguiente paso (modelado de dominio) .
Debido a la extensión del espacio, con respecto al contenido de la parte de diseño (modelado de dominio, diseño de esquema y diseño detallado), continuaremos con el próximo artículo, ¡espero que pueda serle útil!
[Lenguaje C]
Puntero del lenguaje C: desde los principios subyacentes hasta habilidades sofisticadas, use gráficos y código para ayudarlo a explicar
los principios de depuración subyacentes del gdb original, tan simple
análisis paso a paso, cómo usar C para implementar programación orientada a objetos para
mejorar el la poderosa herramienta del código: definición de macros: desde la entrada hasta el abandono,
use setjmp y longjmp en el lenguaje C para implementar la captura de excepciones y las corrutinas
【Diseño de aplicaciones】
Desarrollo de puerta de enlace de Internet de las cosas: proceso de diseño
basado en el bus de mensajes MQTT (parte 1) Desarrollo de la puerta de enlace de Internet de las cosas: proceso de diseño basado en el bus de mensajes MQTT (parte 2)
Mi método favorito de comunicación entre procesos: bus de mensajes
【Internet de las Cosas】
Los aspectos relacionados con el cifrado y los certificados
profundizan en el lenguaje de secuencias de comandos LUA, lo que le permite comprender completamente el principio de depuración.
[Tonterías] Basado
en mi experiencia laboral fallida: algunos consejos para técnicos que son nuevos en el lugar de trabajo