Arquitecturas de software - Parte 1

Arquitecturas de Software
Parte 1
- Definiciones básicas
- Beneficios de una Arquitectura de SW
- Arquitectura 4+1 vista

Material académico preparado por:
Ph.D Marta Silvia Tabares B.
Fecha última actualización 4-Sep-2011

Ingeniería de Software II
(mapa conceptual de tópicos de conocimiento)

Material Preparado por MARTA SILVIA TABARES B. UdeM

Bibliografía
Los conceptos utilizados en esta presentación fueron estudiados y tomados en su mayoría
de las siguientes referencias bibliográficas.

1. Arlow, J., and Neustad, I. UML 2 and the Unified Process: Practical Object-Oriented Analysis
and Design (2nd Edition). Addison-Wesley Object Technology Series. 2005.
2. OMG-UML. Unified Modeling Language: Superstructure. Version 2.0, formal/05-07-04. 2005.
3. Jacobson, I., Booch, G., Rumbaugh, J. El Proceso Unificado de Desarrollo de Software.
Addison Wesley. 2000.
4. Alan Dennis, Barbara Haley Wixom and David Tegarden. Systems Analysis and Design with
UML Version 2.0 - An Object Oriented Approach, Second Edition. John Wiley & Sons © 2005.
5. Simon Bennett, Stee McRobb, y Ray Farmer. Análisis y Diseño Orientado a Objetos del
Sistema, Usando UML. McGraw-Hill, 2006.
6. Bass, L., Clements, P., Kazman, R. Software Architecture in Practice Second Edition.
7. Pressman, R. Ingeniería del Software un Enfoque Práctico.
8. Camacho, E.; Cardeso, F.; Nuñez, G. ARQUITECTURAS DE SOFTWARE - GUÍA DE ESTUDIO. (Abril, 2004).
9. www.sei.cmu.edu.co
10. http://www.iso.org/iso/home.html
11. http://iso25000.com/index.php/iso-iec-9126.html
3
Material académico preparado por Marta Silvia Tabares B. UdeM

Arquitectura de Software
“If a project has not achieved a system
architecture, including its rationale, the
project should not proceed to full-scale
system development. Specifying the
architecture as a deliverable enables its use
throughout the development and maintenance
process.”
--- Barry Boehm 1995

Tomado del Libro Software Architecture in Practice – Second Edition

Material académico preparado por Marta
4
Silvia Tabares B. UdeM

Definición básica:

La arquitectura de software de un
programa o sistema de computación es la
estructura o estructuras del sistema, las
cuales comprometen elementos de
software, las propiedades externamente
visibles de esos elementos y las relaciones
entre ellos.
(Arlow and Neustad, 2005)
5

Definición básica:

Toda la arquitectura es diseño, pero no todo el
diseño es arquitectura. La arquitectura representa
las decisiones de diseño significativas que le dan
forma a un sistema. Donde lo significativo puede ser
medido por el costo del cambio.
Booch)
(Grady Booch)

6

Otras Definiciones (1/4)
1. Es la organización de un sistema en términos de sus componentes de
software, incluyendo los subsistemas y las relaciones e interacciones entre
ellos, y los principios que guían el diseño de ese sistema de software.

2. Es una forma coherente de establecer los patrones y abstracciones para
que los analistas y desarrolladores trabajen en una línea común hacia la
implementación del sistema de información.

3. Una arquitectura sigue un patrón o un conjunto de patrones que
proporcionan un marco de referencia para lograr la funcional requerida
por el cliente, y otros objetivos como la mantenibilidad, auditabilidad,
flexibilidad e interacción con otros sistemas de información.

7

• Es un esquema de trabajo que determina la interacción de diferentes
componentes del sistema.

• Emerge como una parte crucial del proceso de análisis diseño
(Diseño de alto nivel (decisiones tempranas de diseño)

• Es el resultado de un conjunto de decisiones técnicas y de negocio.

• Es la estructura general del sistema.

• Es un conjunto de componentes, conectores y restricciones de un
programa o sistema, sus interrelaciones, y los principios que gobiernan
su diseño.
8

• La arquitectura de software es una forma de representar sistemas
complejos mediante el uso de la abstracción.

• Es la estructura de sistemas o sistema de estructuras que consisten en
elementos, sus propiedades externamente visibles y la relación entre
ellos"

– «Propiedades externamente visibles: qué es lo que debe saber/suponer un
componente sobre otro»

• Es la organización fundamental de un sistema incorporada en sus
componentes, en sus relaciones mutuas y el entorno, y los principios
que guían su diseño y evolución (IEEE Standard 1471-2000).

9

Arquitecturas de software
• La arquitectura de software es importante como disciplina
debido a que los sistemas de software crecen de forma tal
que resulta muy complicado que sean diseñados,
especificados y entendidos por un solo individuo.

• Uno de los aspectos que motivan el estudio en este campo
es el factor humano, en términos de aspectos como
inspecciones de diseño, comunicación a alto nivel entre los
miembros del equipo de desarrollo, reutilización de
componentes y comparación a alto nivel de diseños
alternativos (Kazman, 1996).


Terminología:
• Sistema: conjunto de componentes que cumplen una función o un
conjunto de funciones específicas.

• Descripción de la arquitectura: es un conjunto de productos que
documentan la arquitectura.

• Perspectiva de la arquitectura: es una representación desde una
perspectiva específica de un determinado sistema o de una parte del
mismo.

• Punto de vista arquitectónico: es una plantilla que describe la forma
de crear y utilizar una perspectiva de la arquitectura. Un punto de
vista incluye un nombre, socios, problemas más abordados por el
punto de vista y el modelado y las convenciones analíticas.
11

Beneficios de una Arquitectura de
Software
1. Proporciona la comunicación entre
Stakeholders (participantes del proyecto)

Director de la Mercadeo Usuario Final Organización del Cliente
organización Mantenimiento
de desarrollo Características Comportamiento,
o rasgos, rendimiento,
corto tiempo seguridad,
para el confiabilidad, Modificabilida
mercadeo, usabilidad d
bajos costos
Bajos Costos,
Bajos
tiempo de
Costos,
entrega,
Mantener
Ohhhh… pocos cambios
la gente
en corto
empleada
tiempo
Arquitecto
12

Software
Influencias en la Arquitectura

Stakeholders
Requisitos de Arquitectura
Calidad
Organizaciones
de
Desarrollo
Sistema
Ambiente Técnico
Arquitecto
Experiencia del Arquitecto

13

Software
2. Manifiesta las decisiones de diseño
tempranamente
– Define restricciones de implementación
– Soporta la estructura organizacional
– Inhibe o activa los atributos de calidad del sistema
– Exhibe los atributos de calidad requeridos
– Facilita el razonar acerca del manejo del cambio
– Ayuda en la evolución del prototipado
– Alcanza más exactitud en estimación de costos y
agenda del proyecto
14

Software
3. Las arquitecturas como un modelo reusable y
transferible
– Las líneas de productos de software comparten una
arquitectura en común
– Los sistemas se pueden construir usando grandes y
extensos elementos de desarrollo
– Menos es más: vocabulario restringido de alternativas de
diseño
– Una arquitectura permite desarrollo basado en plantillas
(templates)
– Una arquitectura puede ser la base para el entrenamiento
de nuevos miembros del equipo de desarrollo
15

Arquitectura 4+1 Vistas

Pilippe (Philipe) Kruchten define: “Una vista es una
presentación de un modelo, la cual es una descripción
completa de un sistema desde una perspectiva particular”.


Vista Lógica
Requisitos funcionales del sistema y de lo que el sistema debe de hacer, las funciones y
servicios que se han definido.

Enfocada a lo definido como dominio de la aplicación, lo que son las clases y
objetos principales que formaran el corazón o "core" de la aplicación.

Esta vista se complementa con los diagramas UML:
• Diagrama de Clases
• Diagrama de Paquetes


Vista de Despliegue o Vista de Desarrollo
Mostrar básicamente como está dividido nuestro sistema de software en componentes, y
muestra las dependencias entre estos componentes.

Muestra los componentes físicos incluyen archivos, cabeceras, bibliotecas
compartidas, módulos, ejecutables, o paquetes. Organización y las dependencias entre
el conjunto de componentes, y como se comunican entre ellos.

Esta vista la vamos a complementar con los diagramas UML:
• Diagrama de Componentes
• Diagrama de Paquetes


Vista de Procesos
Representa los flujos de trabajo paso a paso de negocio y operacionales de los
componentes que conforman el sistema. También va a mostrar algunos de los
requisitos no funciónales, como son ejecución, disponibilidad, tolerancia a fallas,
integridad, seguridad, confiabilidad entre otros.

• Diagrama de Actividad



Vista Física
Representa cómo están distribuidos los componentes entre los distintos equipos que
conforman la solución incluyendo los servicios.

Los elementos definidos en la vista lógica se mapean a componentes de software
o de hardware.

• Diagrama de Deployment



Vista +1 o Vista de Escenarios,
Esta vista va a ser representada por los casos de uso, que ayudarán a unir las otras cuatro
vistas.

Desde un caso de uso podemos ver cómo se van ligando las otras cuatro vistas, con esto
tenemos una trazabilidad de componentes, clases, equipo, paquetes, etc., para
realización cada caso de uso.

• Diagrama de Casos de Uso


Arquitecturas de software - Parte 1

Más contenido relacionado

La actualidad más candente (20)

Similar a Arquitecturas de software - Parte 1 (20)

Más de Marta Silvia Tabares (20)

Último (20)

Arquitecturas de software - Parte 1