Cómo hacer un buen trabajo en el diseño arquitectónico de sistemas de softwarePara proyectos de tipo empresarial de subcontratación, el propósito del diseño de arquitectura de software es diferente de los proyectos de tipo de producto. Aquí analizamos principalmente el propósito del diseño de la arquitectura de software para proyectos de tipo empresarial de subcontratación. 1. Proporcionar las bases y especificaciones para el desarrollo a gran escala y proporcionar activos reutilizables. El desarrollo a gran escala de sistemas de software debe tener una base determinada y seguir determinadas especificaciones. Esto no es sólo un requisito de la ingeniería de software en sí, sino también un requisito de los clientes. Durante el proceso de diseño arquitectónico, algunas partes públicas se pueden abstraer para formar clases públicas y clases de herramientas para lograr el propósito de reutilización. 2. Para acortar el ciclo del proyecto hasta cierto punto, utilice el marco o los componentes reutilizables proporcionados por la arquitectura del software para acortar el ciclo de desarrollo del proyecto. 3. Reducir el costo de desarrollo y mantenimiento Una gran cantidad de reutilización y abstracción puede extraer algunas partes comunes que los desarrolladores no necesitan preocuparse, de modo que los desarrolladores solo puedan concentrarse en la implementación de la lógica empresarial, reduciendo así una gran cantidad de carga de trabajo y mejorar la eficiencia del desarrollo. 4. Mejorar la calidad del producto. Un buen diseño de la arquitectura de software es la garantía de la calidad del producto, especialmente la satisfacción de los requisitos no funcionales que suelen plantear los clientes. Principios del diseño de la arquitectura de software El diseño de la arquitectura de software debe seguir los siguientes principios: 1. Cumplir con los requisitos funcionales y los requisitos no funcionales. Este es el requisito más básico para un sistema de software y el principio más básico que debe seguir el diseño de arquitectura. 2. Principio de practicidad, así como cada sistema de software debe ser práctico cuando se entrega a los usuarios para resolver sus problemas, el diseño arquitectónico también debe ser práctico, de lo contrario será "demasiado" o "sobrediseñado". 3. Cumplir con los requisitos de reutilización y maximizar la eficiencia laboral de los desarrolladores. Varias perspectivas sobre el diseño de la arquitectura de software Cuando discutimos qué debe hacer el diseño de la arquitectura, o en las reuniones de revisión del diseño de la arquitectura, a menudo hacemos varias preguntas, como cómo los desarrolladores deben registrar los registros y cómo controlar las transacciones. ¿Cómo podemos mejorar la eficiencia del trabajo de nuestros desarrolladores, es decir, completar más funciones con mejor calidad por unidad de tiempo? ¿Cómo satisfacer las necesidades no funcionales de los clientes? ¿Cómo permitir que los administradores de plataformas en el entorno de producción mantengan mejor el sistema? En realidad, las cuestiones anteriores las plantean diferentes partes interesadas en el sistema de software desde diferentes perspectivas. Para responder a estas preguntas, debemos mirar el trabajo de diseño de arquitectura de software desde una perspectiva diferente. 1. Desde la perspectiva de la arquitectura lógica, considere los problemas desde la perspectiva de los usuarios del sistema y diseñe una arquitectura de software que pueda satisfacer las necesidades de la lógica empresarial y manejar necesidades de lógica empresarial cada vez más complejas. 2. Desde la perspectiva de la arquitectura de desarrollo, considere el problema desde la perspectiva de un desarrollador de sistemas. La arquitectura diseñada debe ser fácil de entender, desarrollar y probar unitariamente, y lo ideal es que los desarrolladores utilicen la menor cantidad de líneas de código para completar el desarrollo funcional. 3. Desde la perspectiva de la arquitectura operativa, teniendo en cuenta los requisitos de calidad del sistema durante la operación, centrándose especialmente en los requisitos no funcionales del sistema, los clientes a menudo requieren que el tiempo máximo de respuesta de la pantalla funcional de nuestro sistema no excede los 4 segundos y puede satisfacer a 2000 usuarios al mismo tiempo. Para uso en línea, control de seguridad basado en roles de los recursos del sistema. 4. Desde la perspectiva de la arquitectura física, preste atención al entorno de instalación e implementación del sistema, como IBM HTTP Server WebSphere Application Server DB2, WebLogic Oracle, estas son las soluciones de servicios de aplicaciones empresariales más populares. 5. Desde la perspectiva de la arquitectura de datos, los diversos sistemas que desarrollamos hoy, como MIS, ERP y SAP, básicamente operan con varios datos, presentan una gran cantidad de datos que los usuarios no comprenden bien y procesan automáticamente varios datos. Es un tipo de operación de datos, por lo que la persistencia de los datos es muy importante. 1. Analizar los requisitos, comprender el modelo de negocio (o modelado de dominio) y seleccionar casos de uso clave. Los requisitos de software se pueden dividir en perspectivas del usuario y perspectivas del desarrollador. Desde la perspectiva del usuario, también se pueden dividir en requisitos funcionales y requisitos no funcionales. Debemos comprender y analizar de manera integral los requisitos y comprender el modelo de negocio desde diferentes ángulos y niveles. La práctica demuestra que los requisitos no funcionales que a menudo ignoramos conducen al fracaso de todo el proyecto. La mejor manera de comprender los requisitos comerciales es el modelado de dominios. El modelado de dominio y el análisis de requisitos a menudo se realizan de manera intercambiable. El modelado de dominio tiene principalmente las siguientes tres funciones: ◆ Explorar problemas complejos y aclarar el conocimiento del dominio.
Martin Fowler dijo una vez que la mayor ventaja de su enfoque orientado a objetos es que ayuda a resolver problemas más complejos. El modelado de dominio en sí mismo sirve como una herramienta para ayudar a pensar, ayudándonos a mantener siempre nuestra atención en los conceptos comerciales más importantes y sus relaciones, para que podamos continuar analizando y comprendiendo los requisitos de manera profunda y sistemática. El modelado de dominios suele ser un proceso que va de lo confuso a lo claro, de los fragmentos a los sistemas. ◆Determinar el alcance de las funciones y afectar la escalabilidad. Cualquier modelo es una abstracción de un programa del mundo real. Este tipo de abstracción ignorará algunas cosas, como las propiedades de los objetos y las relaciones entre objetos, y estas omisiones suelen tener un propósito y determinar el alcance de la función. El modelo revela la estructura detrás de varias funciones. Si definir funciones equivale a "tomar fotografías", entonces el modelado de dominios equivale a "hacer perspectiva", prestando más atención a la estructura interna del dominio del problema, lo que equivale a abstraer el dominio del problema hasta cierto punto. Un buen modelo de dominio no solo puede soportar bien las funciones existentes, sino que también puede soportar hasta cierto punto nuevos requisitos que puedan surgir en el futuro, lo que demuestra una buena escalabilidad. ◆Proporcionar bases de comunicación y promover una comunicación efectiva. El modelado de dominio suele utilizar diagramas UML como método de representación, lo que facilita nuestra comunicación. Por supuesto, a veces las palabras pueden ser más apropiadas y flexibles para describir problemas en determinadas áreas. En el proceso real de desarrollo de software de nuestra empresa, el modelado de dominios a menudo carece de este vínculo, lo que puede ser un área que necesite mejoras adicionales en trabajos futuros. Aunque siempre esperamos que los arquitectos comprendan plenamente los requisitos, debido a limitaciones de tiempo y energía, la realidad que tenemos ante nosotros es que los arquitectos no tienen tiempo para analizar todos los requisitos en profundidad, por lo que nuestra estrategia es "utilizar buen acero en la hoja". , es decir, dedique la mayor parte de su tiempo y energía a determinar los requisitos clave más importantes de la arquitectura. Al seleccionar los requisitos clave, se debe tener en cuenta que los requisitos de alta prioridad a menudo se ven desde la perspectiva del usuario y pueden no ser requisitos verdaderamente críticos. En el libro "Guía para profesionales de RUP", nos dice cómo identificar los requisitos funcionales clave. a. Como núcleo de la aplicación o para implementar la función de la interfaz principal del sistema b. Funciones que deben implementarse, es decir, si no se implementan estas funciones, el software desarrollado pierde valor c. arquitectura del sistema pero no está cubierta por otras funcionalidades importantes cubiertas por casos de uso. 2. Considere todos los aspectos de la arquitectura de software desde diferentes perspectivas. El diseño de la arquitectura de software debe considerar todos los aspectos, el diseño basado en el modelo de dominio, los requisitos clave y las restricciones del sistema establecidos en trabajos anteriores, y analizar y resolver problemas desde las perspectivas de los usuarios del sistema, desarrolladores, administradores de sistemas, administradores de implementación y administradores de datos. Por ejemplo, si nuestra arquitectura operativa está agrupada, debemos tener cuidado con el almacenamiento en caché y el uso de sesiones. Si nuestra lógica empresarial requiere que operemos varias bases de datos, deberíamos considerar admitir la confirmación de transacciones en dos fases. Un diseño arquitectónico de este tipo está completo sólo si se tienen en cuenta todos estos aspectos. En cuanto a los detalles que debemos diseñar en cada vista, en realidad están relacionados con la definición del proceso de todo el proyecto. Por ejemplo, tenemos una actividad especial para organizar el diseño del esquema de la base de datos. Durante el proceso de diseño de la arquitectura, solo podemos centrarnos en las características de la base de datos de nivel superior y las relaciones entre las bases de datos. En actividades relacionadas posteriores, podemos diseñar el diccionario de datos de cada tabla. , pero si Sin esta actividad, refinaríamos cada campo de cada tabla y las relaciones entre las tablas. 3. Resolver confusiones y problemas técnicos clave En el proceso de diseño de la arquitectura de software, a menudo necesitamos superar algunas confusiones y problemas técnicos clave. Este es un trabajo que requiere conocimientos teóricos sólidos y una rica experiencia práctica. Por ejemplo, ¿cómo mejorar el rendimiento de todo el sistema? ¿Cómo exportar "informes al estilo chino" extremadamente complejos (generalmente mucho más complejos que los producidos por los países occidentales y muchos marcos de BI de código abierto no pueden resolver completamente el problema)? Cuando se encuentre con un problema realmente difícil, puede acudir a Baidu o Google para consultar con los técnicos o expertos superiores de la empresa, o realizar un seminario técnico a pequeña escala e intentar encontrar respuestas mediante una lluvia de ideas para mejorar la eficiencia del trabajo. 4. Convocar una reunión de revisión del diseño arquitectónico y aceptar la revisión por pares. La revisión del diseño arquitectónico es una parte sumamente importante.