Diseo Arquitectnico

1
Diseño Arquitectónico

• Felipe Guerrero V.

2
Qué es la arquitectura de software?

• Bases de la Ingeniería de software
• La ingeniería en general física y matemáticas.
• Ingeniería de software
• Matemáticas. Turing, Kleene.
• Arquitectura. Dijkstra, Parnas.
• Ingeniería. Naur 1968
• Estructura de los componentes de un sistema, sus
  interrelaciones, y principios y directivas que
  gobiernan su diseño y evolución en el tiempo.
• David Garlan and Dewayne Perry, 1995

3
Evolución

• Detalles estructurales del software
• Abstracción Formalismo, lenguajes de
  arquitectura.

4
Enfoquémonos

• Propósito de la arquitectura en construcción
  Belleza, utilidad, durabilidad.
• En los ochentas los objetos capturan el mundo
  real.
• Lo importante de la arquitectura las personas.
  Al código no le interesa cuán cohesivo o acoplado
  está.
• Lo último patrones.

5
Relación con otras áreas

• Desarrollo internacional de software
  particionamiento.
• Complejidad creciente del software.
• Administración del proceso de desarrollo
  alienación de los desarrolladores.
• El software está en todas partes somos
  arquitectos de nuestro ambiente.

6
Problemas a resolver

• Creación/selección Cómo seleccionar o crear una
  arquitectura, dado un conjunto de requerimientos.
• Representación Cómo comunicar una arquitectura.
  Lenguaje y selección de la información a
  comunicar.
• Análisis Cómo analizar una arquitectura para
  predecir la calidad de los sistemas. Cómo
  comparar arquitecturas entre sí.

7
Problemas a resolver

• Desarrollo Cómo construir un sistema dada la
  representación de una arquitectura.
• Evolución Cómo ajustar un sistema legado cuando
  los cambion pueden afectar su arquitectura.
  Arqueología arquitectónica, si el sistema no
  tiene documentación.

8
Una visión novedosa

• Primero diseño, luego construyo. O no?
• Me siento culpable por no seguir las buenas
  prácticas.
• Perrochon y Mann Hagámoslo al revés!, cuando la
  tecnología cambia rápidamente y no podamos
  anticipar las propiedades del sistema.

9
Diséños deducidos

• Diseño basado en implementaciones.
• Tradicionalmente Desarrólleme un sistema que
  haga A. Espiral y cascada funcionan
  correctamente.
• Qué pasa si el pedido es Cambie el sistema para
  que también haga B ?
• No puedo reemplazar completamente el sistema

10
Arquitecturas de software dinámicas

• Las arquitecturas tradicionales no permiten
  cambios dinámicos.
• Las herramientas CASE no apoyan si hago un
  cambio tardío, se refleja en las etapas previas
  automáticamente?
• Y si el sistema existe, CASE no me sirve
  ingeniería inversa.
• Para los sistemas de sistemas diseño deducido.

11
Modelo de diseño deducido

• Monitoreo. Extracción de la información útil de
  un sistema.
• Abstracción. Se intenta entender el sistema, se
  buscan patrones.
• Modelado. En base a los patrones se construye un
  diseño deducido.
• Supervisión. Se compara el diseño con el sistema
  en operación.
• Adaptación. Se cambia el sistema el diseño
  deducido se actualiza automáticamente.

12
Diseño en condiciones especiales

• Proyecto Mars Pathfinder poca plata, poco
  tiempo, mismos requerimientos de otras misiones.
• Normal ocho a diez años, más de mil millones de
  dólares.
• Ahora tres años y 150 millones de dólares.
• Con metodologías formales no se iba a lograr.

13
Importancia de la metodología

• Qué problemas resolver
• En qué orden
• Cómo capturar y organizar las soluciones.
• Pathfinder Diseño autónomo, confiable, flexible,
  de alto desempeño

14
Partida falsa del proyecto

• Orientación a objetos reducir costos y acelerar
  desarrollo.
• Apoyo en libros de texto y material publicado
  realidad ! ejemplos.
• Primero encontrar objetos (no clases).
• Idea conectarlos y encontrar subsistemas.
• Problema muchos objetos. Escalabilidad de las
  metodologías.

15
Encontrémonos al medio

• Combinar lo mejor de descomposición funcional
  top-down y diseño OO bottom-up.
• Descomposición funcional fijar fronteras.
• Orientación a objetos modularizar.
• Se obtuvo interfaces compactas.

16
La metodología

• Identificar los componentes funcionales del
  software identificación y agrupación de
  conductas del software.
• Se representa con un DFD.
• Miembros del equipo identifican requerimientos
  funcionales. Para reducir documentación, cada uno
  los identifica y los documenta.

17
Documentación

• Responder las preguntas
• Cómo se ajusta el subsistema?
• Cuáles son las piezas?
• Cómo se ajustan las piezas?
• Dónde está la lógica?
• Cuál es el contexto de tarea?
• Informalidad del desarrollo.

18
Bibliografía

• Artículos de la revista Software de la IEEE,
  Sep/Oct 1999
• Reevaluating the architectural metaphor toward
  piecemeal growth. James O. Coplien.
• Inferrer designs. Louis Perrochon, Walter Mann.
• Streamlined design approach lands Mars
  Pathfinder. Steven A. Stolper.
• Software Architecture An Executive Overview. Paul
  C. Clements, Linda M. Northrop, Technical Report
  CMU/SEI-96-TR-003 ESC-TR-96-003, feb 1996