1. Notaciones para las vistas de módulos
1.1. Pueden ser diagramas de caja si se desea representar los módulos y submódulos.
1.2. UML donde se pueden representar capas, subsistema.
2. Estilo de generalización
2.1. Nos ayuda a apoyar la extensión y evolución de la arquitectura, cuando los módulos tienen relación de generalización , el módulo padre es más general mientras que los hijos heredan de el.
2.1.1. Elementos, relaciones y propiedades:
2.1.1.1. El elemento de este estilo es el módulo, la relación es generalización que es IS-A (Un módulo es padre de otros módulos hijo), y por último la herencia indica un módulo hereda comportamiento..
2.2. Uso:
2.2.1. Diseño orientado a objetos
2.2.2. Predominante para expresar una herencia
2.2.3. Proporcionar una estructura global estable
2.2.4. Reutilización es decir; encontrar módulos que puedan ser reutilizables.
2.3. Notaciones:
2.3.1. Se representan mediante UML, los módulos son representados mediante el uso de clases.
3. Estilo de capas
3.1. Es similar al estilo por descomposición, pero en este caso se hace uso de capas.
3.2. Elementos, relaciones y propiedades
3.2.1. Los elementos de una vista de capas son capas, un requisito es que los módulos tengan una interfaz de comunicación para la conexión de sus servicios, sus propiedades van desde su contenido que son capas.
3.3. Uso
3.3.1. Las capas nos ayudan a atraer atributos de calidad
3.3.2. En un sistema grande el número de módulos y dependencias de expanden rápidamente.
3.3.3. Agrupan en capas módulos con la misma tecnología
3.3.4. Apoyan al análisis de impacto de cambios
3.4. Notaciones:
3.4.1. Se dibujan como pilas de cajas
3.4.2. Conexión entre los componentes se muestran por adyacencia geométrica.
4. Estilo de aspectos
4.1. Propone módulos responsables de la funcionalidad, estos deben colocarse en uno o más vistas de aspecto
4.2. Usos
4.2.1. Para moldear la implementación de preocupaciones transversales
4.2.2. Modificabilidad aumentando la modularidad y evitando el enredo de la funcionalidad del dominio empresarial.
4.3. Notaciones
4.3.1. UML sin símbolos incorporados para representar vistas es una opción común usar diagrama de clases.
5. Estilo de modelo de datos
5.1. El modelado de datos es una actividad común en el desarrollo del software, el resultado esta actividad es el modelo de datos
5.2. Elementos, propuedades y relaciones:
5.2.1. Se denominan entidades de datos o simplemente entidades,
5.2.2. Nombre de la entidad, Descripción del significado e importancia, Atributo y restricciones
5.2.3. Relación, generalización y agregación
5.3. Usos:
5.3.1. Facilita la relación entre stakeholders y mejora el rendimiento del sistema eliminando cuellos de botella.
5.4. Notación
5.4.1. Puede describirse gráficamente utilizando notaciones visuales como: Diagrama de entidad de relación y de clases.
6. Se captura :
6.1. La descomposición funcional y las capas del sistema. El sistema es descompuesto lógicamente en subsistemas, módulos, y unidades abstractas. Cada capa representa las distintas interfaces de comunicación permitidas entre los módulos.
7. Vistas de módulo
7.1. Análisis
7.1.1. Debe describir la manera en cómo los módulos responden a las funciones que son involucradas por el módulo principal.
7.2. Construcción
7.2.1. Debe contener el código fuente
7.3. Comunicación
7.3.1. Interfaz para explicar la funcionalidad del módulo, explican la estructura del código a un nuevo desarrollador en el equipo.
8. Elementos
8.1. Se refieren a las características y responsabilidades de una unidad de software, los módulos se pueden agregar, descomponer, basados en alguna similitud.
9. Relaciones
9.1. Es parte de:
9.1.1. Indica parte- todo. El submódulo es la parte y em módulo el todo.
9.2. Depende de:
9.2.1. Define una relación de dependencia entre módulos A y B
9.3. Es a
9.3.1. Define una relación de generalización.
10. Propiedades
10.1. Nombre
10.1.1. Debe guardar algún tipo de relación directa con la función del elemento en el sistema.
10.2. Responsabilidad
10.2.1. Módulo debe detallar la función que cumple el elemento , describe al lector que hace cada módulo.
10.3. Visibilidad de interfaces
10.3.1. Las conocidas como interfaces son únicamente visibles dentro de los submódulos, no son visibles fuera y tampoco tienen relación directa con la interfaz padre que encapsula las subinterfaces.
10.4. Información de la implementación
10.4.1. Información sobre la administración y desarrollo del módulo, conocida también como información de prueba de gestión y limitaciones de la gestión.