dms_t1_analisis_diseño_des_arqui

Análisis y Diseño: Descripción Arquitectónica
Architecture Business Cycle – ABC
Los requisitos no determinan del todo la arquitectura, más bien está es además
resultado de influencias en los ambientes técnicos, sociales y del negocio.
Llamaremos a este ciclo de influencias, del ambiente a la arquitectura y de la
arquitectura al ambiente como “El Ciclo de la Arquitectura de Negocios
(Architecture Business Cycle - ABC)”.
¿Por qué es importante la Arquitectura de un sistema?
La arquitectura afecta los aspectos técnicos y de negocio de una organización.
Estas son influenciadas por:



Stakeholders de un sistema
Factores técnicos y organizacionales
Experiencia y conocimiento del arquitecto
Accionistas (Stakelholders) de un sistema
Muchas personas y organizaciones están interesadas en la construcción de un
sistema de software. Llamamos a estos stakeholders: el cliente, los usuarios
finales, los desarrolladores, el administrador del proyecto, etc. Losstakeholders
tienen diferentes preocupaciones que desean que el sistema garantice,
El problema de fondo, por supuesto, es que cada stakeholder tiene diferentes
preocupaciones y objetivos, algunos de los cuales pueden ser contradictorias.
Estas pueden ser enumeradas y discutidas, por supuesto, en un artefacto como un
documento de requisitos.
La realidad es que el arquitecto a menudo tiene que llenarlos espacios en blanco y
mediar los conflictos entre ellos.

Factores técnicos y organizacionales
Factores técnicos
Un caso en particular de los antecedentes del arquitecto y la experiencia se refleja
en el entorno técnico. La arquitectura será influenciada por el ambiente actual
tecnológico de la organización. Puede incluir prácticas estándar de la industria o
las técnicas de ingeniería de software común en la comunidad profesional del
arquitecto.
Factores organizacionales


Problemas del negocio a corto plazo
o Amortizar la infraestructura
o Mantener bajos los costos de instalación
Problemas del negocio a largo plazo
o Invertir en una infraestructura para metas estratégicas
o Invertir en personal
Experiencia y conocimiento del arquitecto
Los arquitectos desarrollan su criterio de sus experiencias pasadas:
 Anteriores experiencias exitosas conducirán a volver a ser aplicadas.
 Anteriores experiencias negativas serán excluidas en nuevos diseños.
Factores influenciados por una arquitectura

Estructura de la organización de desarrollo
o Corto plazo: Unidades de trabajo son organizadas alrededor de
unidades arquitectónicas para un sistema particular en construcción
o Largo plazo: Cuando la empresa construye una colección de
sistemas similares, unidades organizacionales reflejan componentes
comunes

Metas empresariales
o El desarrollo de un sistema puede establecer una huella en un nicho
de mercado
o Ser conocidos por desarrollar particulares tipos de sistemas llega a
ser un arma de mercadotecnia
o La arquitectura llega a ser una ventaja para nuevas oportunidades en
el mercado

Requisitos de clientes
 Conocimiento de sistemas similares conducen a los clientes a
pedir características particulares
 Los clientes alterarán los requisitos sobre la disponibilidad de
sistemas existentes

Experiencia del arquitecto
 La creación de nuevos sistemas afecta la experiencia del
arquitecto
Importancia de una Arquitectura
Una arquitectura es importante por al menos tres razones:
 Provee un vehículo para comunicación entre los stakeholders
 Es la manifestación de las decisiones de diseño tempranas acerca del
sistema
 Es una abstracción transferible y reutilizable de un sistema
¿Qué hace buena a una arquitectura?
Una arquitectura debería...




ser producto de un arquitecto o un pequeño grupo de arquitectos con un
líder definido.
estar bien documentada, con al menos una vista dinámica y una vista
estática, utilizando una notación que los stakeholders puedan entender
fácilmente.
presentarse como una implementación incremental, para poder diseñar un
esqueleto del sistema, mostrando primero la mínima funcionalidad y
después como puede ir creciendo.
ser diseñada por arquitectos que cuentan con los requisitos funcionales y
no funcionales del sistema.
EJEMPLO
Representación de una Arquitectura de Software poco informativa.
Figura 6 Ejemplo Representación de una Arquitectura de Software poco
informativa.
¿Qué está mal en el diagrama?


Muchas cosas no están especificadas:
o ¿Qué tipo de componentes son?
o ¿Qué tipo de conectores son?
o ¿Qué significan los círculos y las flechas?
o ¿Cuál es el significado del “layout” (jerárquico)?
o ¿Por qué está el proceso de control al nivel más alto?
o
Figuras y flechas dibujadas solitas no son una arquitectura; sin embargo
son un punto de partida

¿Cuál estructura? El software se compone de muchas estructuras:
o Módulos
o Tareas
o Funciones
o Hardware
o Clases

De esta manera, al ver figuras y líneas debemos preguntar:
o ¿Qué representan las figuras?
o ¿Qué significan las flechas/líneas?
Lenguajes para documentar arquitecturas


Para documentar una arquitectura se pueden utilizar ADLs (Architecture
DescriptionLanguages)
También, una arquitectura puede ser modelada con UML.
Documentación de la Arquitectura
En una casa hay planos para cuartos, cableado eléctrico, plomería, ventilación,
etc. Cada una de estos planos constituye una “vista” de la casa. Estas vistas son:



Usadas por diferentes personas
Usadas para conseguir diferentes cualidades en la casa
Usadas como una descripción y prescripción
Entonces, lo mismo es con una arquitectura de software
Las 4+1 vistas de Kruchten
El enfoque 4+1 vistas fue desarrollado originalmente por PhilippeKruchten en
1995. Las distintas vistas del enfoque responden a las necesidades de las
distintas partes interesadas: clientes, programadores, administradores, etc.
La vista de desarrollo le dice al programador como iniciar y organizar su código; la
vista física ayuda a los administradores de sistemas a decidir la infraestructura que
se ha de dedicar al sistema; la vista de procesos es útil para realizar análisis de
integridad y tomar decisiones de integración con otros sistemas; finalmente, la
vista lógica le sirve a los usuarios y clientes a visualizar la funcionalidad que el
sistema les provee.
(Planos Arquitect´onicos: El Modelo de “4+1” Vistas de laArquitectura del
Software¤, PhilippeKruchten)
Figura 7 Vistas de Kruchten
Vista Lógica
La arquitectura lógica apoya principalmente los requisitos funcionales –lo que el
sistema debe brindar en términos de servicios a sus usuarios. El sistema se
descompone en una serie de abstracciones clave, tomadas (principalmente) del
dominio del problema en la forma de objetos o clases de objetos. Aquí se aplican
los principios de abstracción, encapsulamiento y herencia. Esta descomposición
no sólo se hace para potenciar el análisis funcional, sino también sirve para
identificar mecanismos y elementos de diseño comunes a diversas partes del
sistema.
Figura 8 Ejemplo de Vista lógica
Vista de Desarrollo
Es usada para describir los módulos del sistema. Los módulos son bloques de
construcción más grandes que las clases y los objetos y varía acorde al entorno
de desarrollo. Paquetes, subsistemas y librerías de clases son considerados
módulos.
También se puede utilizar para estudiar el alojamiento de los archivos en el
sistema y el entorno de desarrollo. Alternativamente, es una buena manera para
ver las capas del sistema en una arquitectura en capas. Una arquitectura en capas
típica podría contener la capa de Interfaz de Usuario, una capa de lógica del
negocio y una capa de persistencia.
Figura 9 Ejemplo de vista de Desarrollo
El ejemplo es un diagrama de paquetes mostrando cómo los paquetes están
anidados en el sistema.
Vista Física
Describe cómo la aplicación es instalada y cómo se ejecuta en una red de
computadoras. Esta vista toma en cuenta los requisitos no funcionales como
disponibilidad, confiabilidad, rendimiento y escalabilidad.
Figura 10 ejemplo de Vista Física
Vista de Escenarios


Esta vista consiste de casos de usos y escenarios que describen o
consolidan las otras vistas.
La vista de casos de uso consiste de diagramas de casos de uso detallando
las acciones y condiciones dentro de cada caso de uso.
Figura 11 Ejemplo de Vista de Escenarios
Vista de Procesos



Se refiere más al control de la concurrencia.
A cómo los procesos interactuarán entre sí (protocolos de concurrencia)
No muy tomada en cuenta en el desarrollo de sistemas de información.
Resumiendo:
 Vista lógica nos permitirá alcanzar los requerimientos funcionales. ¿Cuáles
partes van juntas? ¿Cuáles son las clases y sus relaciones?
 Vista de proceso ayuda a lograr los requerimientos no-funcionales, como el
desempeño y la disponibilidad. ¿Cuáles necesidades de control hay? ¿Qué
actividades pueden ser concurrentes? ¿Qué sincronización debe haber?
 Vista de desarrollo ayuda a administrar el proyecto. ¿Cuál parte hará cada
elemento del equipo de gente? ¿Qué partes pueden reusarse?
 Vista física ayuda a alcanzar los requerimientos no-funcionales, haciendo
una vista más concreta que la de proceso. ¿Cuales partes correrán en la
misma computadora?
 Vista Escenarios nos permite representar la parte funcional de un sistema.