- Álgebra relacional
- Vista lógica
- Diagrama de clase
- Diagrama de objetos
- Diagrama de transición de estado
- Vista de proceso
- Diagrama de secuencia
- Diagrama de comunicación
- Diagrama de actividad
- Diagrama de interacción
- Diagrama de tiempo
- Vista de desarrollo
- Diagrama de componentes
- Diagrama del paquete
- Vista fisica
- Diagrama de implementación
- Vista de caso de uso
Contenido
PalancaAnálisis de software
El principal objetivo del análisis de software es controlar la complejidad. El modelado es una abstracción de la realidad para comprender mejor el sistema que se va a realizar. Para verificar o construir un modelo, este debe estar conectado al mundo real, saber qué existe antes de la obra, qué se hace y qué queda por hacer. Un modelo puede expresarse con diferentes niveles de abstracción / refinamiento, una sola vista del sistema no es suficiente para comprender todo su funcionamiento e interacciones intrínsecas.
El modelado se basa en gráficos de sistemas informáticos. Los gráficos más utilizados forman parte del Lenguaje de modelado unificado (UML). Este último incluye un conjunto de herramientas y reglas para definir diagramas.
Independientemente de la forma que adopte un diagrama de arquitectura, siempre representa solo un punto de vista sobre el sistema considerado, siendo lo más importante las motivaciones. De hecho, ¿de qué sirve producir un diagrama si es inútil (no se utiliza) o si las razones de las elecciones arquitectónicas son vagas e inexplicables? Para evitar formular las motivaciones de cada diagrama, el arquitecto de TI producirá los diferentes diagramas basados en un plantilla de diseño y reutilizará patrones de diseño probados.
4 + 1 vistas de Kruchten
En el análisis de software, el modelo de vista “4 + 1”, conocido como Kruchten, de un sistema informático permite organizar la descripción del sistema en varias vistas complementarias, cada una presentando el sistema desde un punto de vista diferente. El uso de puntos de vista permite que los intereses de varios grupos de partes interesadas se aborden por separado, separando así mejor las preocupaciones funcionales y extra-funcionales.
La figura esquematiza el modelo de vistas “4 + 1”. Este modelo se compone de cinco vistas.
- La vista "lógica" describe los aspectos estáticos y dinámicos de un sistema en términos de clases, objetos, conexiones y comunicaciones. Se centra en la abstracción y la encapsulación.
- La vista “proceso” captura los aspectos de simultaneidad y sincronización, y los desglosa en flujos de ejecución (proceso, subproceso de ejecución, etc.). Se relaciona con objetos e interacciones activos.
- La vista "desarrollo" representa la organización estática de módulos (ejecutables, códigos fuente, paquetes, etc.) en el entorno de desarrollo.
- La vista "física" describe los diversos recursos de hardware y la implementación del software teniendo en cuenta estos recursos. Por lo tanto, se relaciona con los nodos de ejecución física y la ubicación de los objetos en los nodos.
- La vista final, denominada "caso de uso", se centra en la coherencia al presentar casos de uso que implementan elementos de las primeras cuatro vistas. Los escenarios son una abstracción de los requisitos funcionales de la aplicación. Esta última vista valida de alguna manera las otras vistas y garantiza la coherencia general. También es esta última vista la que se construye primero, justo después del establecimiento de las especificaciones, para fijar los contornos del sistema a producir con sus funcionalidades denominadas, en terminología UML, casos de uso.