Dra. Marcela Capobianco Licenciatura en Ciencias de la Computación UNS

Transcripción

1 Modulo 4: Conceptos básicos Diseño y Desarrollo de Software Dra. Marcela Capobianco Licenciatura en Ciencias de la Computación UNS

2 Licencia Copyright 2015 Marcela Capobianco Se asegura la libertad para copiar, distribuir y modificar este documento de acuerdo a los términos de la GNU Free Documentation License, Version 1.2 o cualquiera posterior publicada por la Free Software Foundation, sin secciones invariantes ni textos de cubierta delantera o trasera. Una copia de esta licencia está siempre disponible en la página

3 Qué es una arquitectura de SW Definición: Es el conjunto de todas las principales decisiones de diseño sobre el sistema La arquitectura es el plano para la construcción y evolución del sistema Las decisiones de diseño abarcan: Estructura Comportamiento Interacción Propiedades no-funcionales 3

4 Qué significa principal? Principal implica un grado de importancia que le da a la decisión de diseño un estado arquitectónico No todas lo son Esto es, no todas impactan en la arquitectura del sistema Esto depende de lo que los participantes definan como objetivos del sistema 4

5 Otras definiciones Shaw and Garlan: Software architecture [is a level of design that] involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. Kruchten: Software architecture deals with the design and implementation of the high-level structure of software. Architecture deals with abstraction, decomposition, composition, style, and aesthetics.

6 En conclusión La arquitectura de software es un modelo Simplificación de la realidad Abstracción Cerrada: tiene cierta independencia Modelado puede ser: Informal, semi formal, formal En academia suele ser formal y en la industria semi formal o informal

7 Componentes y conectores Garlan 1993 intenta definir la arquitectura como una tupla: SA={componentes, connectors, constrains} Componentes y conectores son elementos en un nivel arquitectónico Los componentes no son clases de sistemas OO Los componentes y conectores reflejan estado en tiempo de ejecución no son estáticos como una clase

8 Vistas Componentes definen protocolos de comunicación y estrategias Las restricciones definen las reglas a las que el sistema debe respetar Es esto suficiente? Qué falta? Se necesitan varias vistas diferentes: estática, dinámica, etc

9 Word Counter Programa que toma un archivo de texto y devuelve pares de (palabra, frecuencia) para cada palabra en orden de frecuencia

10 Word Counter

11 Word Counter

12 Aspectos temporales Las decisiones de diseño pueden hacerse y deshacerse durante la vida del sistema La arquitectura tiene un aspecto temporal En un punto en el tiempo el sistema tiene una sola arquitectura Pero si cambia en el tiempo se puede pensar que ha tenido una familia de arquitecturas 12

13 Prescriptive vs. Descriptive Architecture La arquitectura prescriptiva del sistema captura las decisiones de diseño hechas previamente a la construcción del sistema Es como fue concebido el sistema La arquitectura descriptiva describe como el sistema ha sido construido Es la arquitectura de acuerdo a como fue implementado 13

14 Evolución arquitectonica Cuando un sistema evoluciona idealmente se modifica primero su arquitectura prescriptiva En la práctica el sistema y entonces su aruitectura descriptiva es frecuentemente modificado directamente por: Pereza de los desarrolladores Deadlines demasiado estrictos Falta de documentación prescriptiva Técnicas o herramientas inadecuadas 14

15 Degradación Arquitectónica Architectural drift es la introducción de las principales decisiones de diseño en la arquitectura descriptiva del sistema Que no están incluidas en o implicadas por la arquitectura prescriptiva Pero no violan las decisiones de diseño de la arqutiectura prescriptiva Architectural erosion es la introducción de las decisiones de diseño arquitectónicas en la arquitectura descriptiva que violan su 15

16 Recuperación arquitectónica Si se permite la degradación, tarde o temprano tendrá que hacerse una recuperación Es el proceso de determinar la arquitectura de un sistema desde sus artefactos a nivel de implementación Los artefactos pueden ser: Código fuente Archivos ejecutables Java.class 16

17 IEEE 1471 (año 2000) Esfuerzo por crear un estándar en el campo de la arquitectura de software Se resaltan varios aspectos clave

18 IEEE 1471 (año 2000) Every system has its own architecture, but they are not identical El sistema es un producto concreto mientras que la arquitectura es una abstracción dependiente del sistema Software architecture and its description are different La arquitectura existe cuando existe el software. Qué es lo que hacemos antes?

19 IEEE 1471 (año 2000) SA: la organización del sistema personificada en sus componentes, las relaciones entre estos, la relación con el ambiente y los principios que guiaron su diseño y evolución Descripción: una colección de productos para documentar la arquitectura Técnicas para documentar: varios diagramas en UML, usar un ADL, diagramas simples de cajas y líneas. Importante: convención No todos los sistemas cuentas con una descripción, ej: sistemas legacy

20 IEEE 1471 (año 2000) Software architecture, architectural description and development process are separated, both in research and in application El uso de un modelo de proceso no implica que deba usarse un tipo particular de descripción Space should be leaven facilitating the customization of detailed architectural models for researches and practices Sólo se definen principios rectores

21 ISO/IEC/IEEE Evolución de la anterior norma Especifica la manera en que se organizan y expresan las descripciones arquitectónicas de un sistema Especifica los conceptos de architecture viewpoints, architecture frameworks y define nuevamente SA También define el concepto de description languages para usar en las descripciones

22 Conceptos Architecting: es el proceso de concebir, definir, comunicar, certificar la implementación adecuada y mejorar una arquitectura a través de su ciclo de vida System Architecture: conceptos fundamentales o propiedades de un sistema corporizado en sus elementos, relaciones y los principios de su diseño y evolución. Importante

23 Conceptos Architecture description (AD): producto usado para expresar una arquitectura Architecture framework: convenciones, principios y prácticas para la descripción de arquitecturas que están establecidas en un dominio específico. Architecture view: producto que expresa la arquitectura de un sistema desde la perspectiva de un concern específico del mismo

24 Conceptos Architecture viewpoint: wproducto que establece las convenciones para la construcción, interpretación y uso de las vistas arquitectónicas para enmarcar un concern específico Concern: interés en un sistema que es relevante a uno o mas de los particpantes (stakeholders) Environment: contexto que determina las circunstancias de todas las influencias sobre un sistema A view is what you see. A viewpoint is where you are looking from the vantage point or perspective that determines what you see.

25 Concerns The following are concerns in the terms of this International Standard: functionality, feasibility, usage, system purposes, system features, system properties, known limitations, structure, behavior, performance, resource,...

26 Contexto de la DA

27 Descripciones SA contiene lo que es esencial para el sistema considerando su entorno Esto puede contener alguno o todos de los siguientes elementos: Constituyentes del sistema o elementos Como se relacionan estos elementos y/u organizan Principios de organización y diseño del sistema

28 Descripción arquitectónica

29 Importante No se especifica: Formatos o medios para almacenar las descripciones Procesos o métodos usados para producirlas. Modelos notaciones o técnicas

30 Views y Viewpoints Un architecture view (vista) expresa la arquitectura del sistema de acuerdo con un architecture viewpoint (punto de vista). Aspectos de un viewpoint: los concerns que enmarca para los participantes (stakeholders) y las convenciones sobre las cuales establece las vistas. Un architecture viewpoint enmarca uno o mas concerns y un concern puede ser enmarcado por mas de un viewpoint.

31 Views y Viewpoints Una vista es governada por su viewpoint asociado el cual establece las convenciones para construir, interpretar y analizar la vista para asi abordar los concerns enmarcados Las convenciones de un Viewpoint pueden incluir lenguajes, notaciones, clases de modelos, etc.

32 Ejemplo views y viewpoints Deployment view of a 3-tier application Deployment view of a Lunar Lander system Both instances of the deployment viewpoint

33 Observación importante This International Standard does not use phrases such as business architecture, physical architecture, and technical architecture. The arquitecture of a system is a holistic conception of that system s fundamental properties, best understood via multiple views of that architecture. Equivalents of the above phrases are business view, physical view, and technical view, respectively.

34 Modelos arquitectónicos Un architecture view se compone de uno o mas modelos arquitectónicos (architecture models). Un modelo usa convenciones de modelado apropiadas a los concerns que se quieren abordar Esas conveciones se especifican por el tipo de modelo que lo gobierna

35 AD Elements y Correspondencias Correspondencias: capturan las relaciones entre elementos de AD Las correspondencias y las reglas de correspondencias se usan para expresar y forzar relaciones arquitectónicas como: composición, refinamiento, consistencia, trazabilidad

36 AD Elements and Correspondences AD Element: cada item en una DA (descripción arquitectónica o en inglés AD) se considera un elemento (Stakeholder, Concern, Viewpoint, View, Model Kind) Correspondencia: expresa una relación entre elementos de DA Son usadas para expresar relaciones arquitectónicas de interés dentro de una DA o entre DAs

37 AD Elements and Correspondences Las correspondences pueden ser governadas por reglas de correspondencia. Regla de correspondencia: fuerza relaciones dentro de una DA o entre DAs

38 Ejemplo de correspondencia Hardware view, HW(S), software component view, SC(S). SC(S) includes software elements, e1,... e6, and HW(S) includes hardware platforms, p1,... p4

39 Decisiones arquitectónicas

40 Decisiones arquitectónicas Una Decisión Arquitectónica afecta los elmentos de DA y se relaciona con uno o mas Concerns. Al realizar una decisión pueden aparecer nuevos concerns. Architecture Rationale: registra la explicación o justificación sobre decisiones arquitectónicas que se realizaron y las alternativas que no se eligieron

41 Arquitecture Framework

42 Arquitecture Framework Un architecture framework establece una práctica común para crear, interpretar analizar y usar una DA dentro de un dominio particular o comunidad de stakeholders Nos ayuda a elegir que viewpoints y vistas usar en un dado caso

43 Qué hace un framework Describir una metodología para la definición de un sistema de información en términos de un conjunto de bloques constituitivos Contener un conjunto de herramientas. Proveer un vocabulario común. Incluir una lista de estándares recomendados.

44 Algunos ejemplos de frameworks Zachman s information systems architecture framework [44] UK Ministry of Defence Architecture Framework [27], The Open Group s Architecture Framework (TOGAF) [41], Kruchten s 4+1 view model [23], Siemens 4 views method [10], Las referencias están en la definición de la norma Reference Model for Open Distributed Processing (RMODP), [ISO/IEC 10746] and Generalized Enterprise Reference Architecture (GERA)[ISO 15704].

45 TOGAF (ejemplo de framework) Proporciona un enfoque para el diseño, planificación, implementación y gobierno de una arquitectura empresarial de información. Está modelada en cuatro niveles o dimensiones: Negocios, Tecnología, Datos y Aplicaciones.

46 TOGAF Arquitectura de Negocios: define la estrategia de negocios, la gobernabilidad, la estructura y los procesos clave de la organización. Arquitectura de Aplicaciones: provee un plano para cada uno de los sistemas de aplicación que se requiere implantar, las interacciones entre estos sistemas y sus relaciones con los procesos de negocio centrales de la organización. Arquitectura de Datos, la cual describe la estructura de los datos físicos y lógicos de la organización, y los recursos de gestión de estos datos. Arquitectura Tecnológica, la cual describe la estructura de hardware, software y redes requerida

47 Architecture Description Language (ADL)

48 ADLs Un ADL es una forma de expresión para ser usada en DA. Un ADL puede incluir un tipo de modelo, un viewpoint o varios Ejemplos: Rapide, SysML, ArchiMate, ACME, xadl.

49 Elementos de la arquitectura de Software La arquitectura de un sistema debería ser una composición de diferentes elementos: Procesamiento Datos, también llamados información o estados Interacción 49

50 Resumiendo

51 Resumiendo A viewpoint is a way of looking at a system, a view is what you can see Un viewpoint define las convenciones (notaciones, lenguajes y tipos de modelos) que van a ser usados en una vista Una vista es el resultado de aplicar un viewpoint a un sistema de interés particular ISO/IEC/IEEE 42010

52 Resumiendo Architecture viewpoints: definen los contenidos de cada vista Architecture frameworks: conjunto coordinado de viewpoints para usar en un dominio en particular ALDs: cualquier modo de expresión usado en una descripción arquitectónica

53 Componentes y conectores Es la vista más importante y usual Muchos autores (en el pasado sobre todo) sólo usan este tipo de vista para sus descripciones arquitectónicas Es fácil deducir atributos de calidad en esta vista en fases tempranas del desarrollo Esto disminuye los riesgos de desarrollo

54 Ejemplo de sistema de gestión de versiones

55 Vista de componentes y conectores Abstrae la esencia de la ejecución del sistema Cada elemento tiene un significado en tiempo de ejecución Por ejemplo el code repository server puede ser implementado por varias clases OO Cada elemento debe tener un significado claro y bien definido (notación) Es historicamente importante, se la pensó como la arquitectura inicialmente.

56 Componentes Elementos que encapsulan procesamiento y datos en la arquitectura del sistema Un componente de software es una entidad que: Encapsula un subconjunto de funcionalidad y/o datos del sistema Restringe acceso a ese conjunto via una interfaces definida en forma explícita Posee dependencias explicitamente definidas en su contexto requerido de ejecución Típicamiento proveen servicios específicos de la aplicación 56

57 Connectors En sistemas complejos la interacción puede ser más importante que la funcionalidad de los componentes Un conector es un bloque de construcción arquitectónico al que se le asigna la tarea de realizar y regular la interacción entre componentes En muchos casos son procedure calls o accesos de datos compartidos, otras veces son más complejos 57

58 Ejemplos de Conectores Procedure call connectors Shared memory connectors Message passing connectors Streaming connectors Distribution connectors Wrapper/adaptor connectors 58

59 Viewpoints comunes

60 Vista de descomposición Brinda información más estática Se puede usar en primer lugar para definir el vocabulario del sistema y construir su modelo lógico Descomponemos el sistema completo en varios conceptos lógicos con un estilo topdown

61 Vista de descomposición El proceso puede continuar hasta cumplir con el objetivo de los desarrolladores Los conceptos y sus asociaciones construyen el modelo lógico del sistema El modelo lógico sirve en domain software development porque se pueden reusar bloques del sistema Permite dividir el trabajo entre los desarrolladores

62 Vista de implementación Implementation view, o artifact view, se concentra en que archivos fuente se usan para implementar las unidades lógicas. También refleja la relación entre los archivos de código fuente Se debe agregar información de versiones Sirve para los desarrolladores y lideres de proyecto

63 Vista de Implementación

64 Vista de Deployment Llena el gap entre SW y HW Los elmentos de SW incluyen modules, objects, procesos. Los de HW se llaman nodos y pueden ser un workstation, un mainframe, un server, un router u otro dispositivo móvil Se expresan en varios grados de formalidad.

65 Vista de deployment

66 Vista de deployment Through analyzing information brought by nodes' properties, such as CPU features, memory capability, network' s bandwidth and so on, many of the problems with current design in architectural level will be exposed. For example, we can calculate and track which part of the whole system slow down the overall performance due to the hardware reason, and then simplify the algorithm implemented there.

67

68

69

70

71

72

73 Vista de comportamiento Especificar el comportamiento dinámico Centrada en mensajes De actividad general De un sólo elemento

74 Estilos arquitectónicos Algunas decisiones de diseño resultan regularmente en soluciones con propiedades superiores Comparado con otras alternativas posibles, estas soluciones son más elegantes, eficientes, efectivas, escalables, etc

75 Estilos arquitectónicos Un estilo arquitectónico es una colección de decisiones de diseño con un nombre determinado que Son aplicables en un contexto determinado Restringen las decisiones de diseño arquitectónicas que son específicas a un sistema particular dentro de ese contexto Elicitan cualidades beneficiosas en el sistema resultante

76 Patrones arquitectónicos Un patrón arquitectónico es un conjunto de decisiones de diseño arquitectónicas que son aplicables a un problema reurrente de diseño y parametrizados para ser usados en distintos contextos Un patrón muy usando es los sistemas distribuidos es el three-tiered system pattern Science Banking E-commerce Reservation systems 76

77 Three-Tiered Pattern Front Tier Middle Tier Contains the user interface functionality to access the system s services Contains the application s major functionality Back Tier Contains the application s data access and storage functionality 77 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.

78 Modelos, Vistas y Visualizaciones Architecture Model Un artefacto documentando algunas de las decisiones de diseño del sistema Architecture Visualization Una forma de describir algunas de las decisiones de diseño sobre un sistema a un participante Architecture View Un subconjunto de decisiones de diseño 78 relacionadas

79 Procesos arquitectónicos Architectural design Architecture modeling and visualization Architecture-driven system analysis Architecture-driven system implementation Architecture-driven system deployment, runtime redeployment, and mobility Architecture-based design for non-functional properties, including security and trust architectural adaptation 79

80 Participantes en la arquitectura del sistema Arquitectos Desarrolladores Testers Managers Clientes Usuarios Vendedores 80

81 Arquitecturas comunes Cloud Computing Architectures Dataflow architecture Layered architecture Middleware architecture n-tier architecture Rich client architecture Service Oriented Architectures Thin client architecture

82 Bibliografía Taylor, Medividovic, Dashofy. Software Architecture: foundations, theory, and practice ISO/IEC/IEEE 42010:2011. Systems and software engineering Architecture description Qin, Xing, Zheng. Software Architecture