Definición Arquitectura de sistemas

[pic 1]

CARRERA:

ASIGNATURA:

PROFESOR:

ALUMNO:

Contenido

1. Definición Arquitectura de sistemas.        3

2. Tipos de estructuras de los sistemas        3

3. ¿Cuáles son las propiedades visibles externas del sistema?        3

4. Elementos de una Arquitectura de Software y sus atributos.        3

5. Definición de un STAKEHOLDERS        3

6. Importancia de los STAKEHOLDERS.        3

7. Descripción arquitectónica del sistema.        3

8. Vista arquitectónica del sistema.        3

9. Beneficios de usar vistas y puntos de vistas.        3

10. Errores errores en los puntos de vista.        4

11. Principales puntos  de vista fundamentales para la información arquitectura de sistemas.        4

12. Perspectivas arquitectónicas.        4

13. Consecuencias de aplicar una perspectiva        4

14. Beneficios de usar perspectivas.        4

15 Definición del proceso de la arquitectura.        4

16. Roles de un arquitecto de Software.        4

17. Especializaciones de los arquitectos de software.        4

18. Responsabilidades de los Arquitectos de software        4

Introducción

Actualmente, la sociedad y el mundo en su conjunto se encuentran subdesarrollados en el campo de las tecnologías de la información, lo que significa innovación desde el propio sector, lo que lleva a la adherencia a estándares y metodologías de calidad, así como al trabajo en nuevos productos y proyectos de software, con una estructura especializada en este tipo de producto o proyecto, para asegurar la eficiencia, eficacia y calidad del producto o proyecto que se rige por este tipo de norma. La arquitectura de software, en un sentido estricto, se define como el conjunto de estructuras que componen el sistema, lo que incluye elementos de software, las relaciones entre los mismos, y las propiedades tanto de los elementos como de sus relaciones (SWEBOK, 2014). En otras palabras, la arquitectura de software define el conjunto de componentes de un sistema, las interfaces de comunicación de los mismos, y la manera como estos componentes se comunican entre ellos usando estas interfaces. Las organizaciones dependen de los sistemas de software que soportan su operación, y el buen funcionamiento de estos depende de sus arquitecturas. La arquitectura de un sistema de software se diseña para satisfacer los requerimientos funcionales y no funcionales establecidos por los interesados en el sistema (ej.: usuarios, clientes, proveedores).

1. Definición Arquitectura de sistemas.

La mejor definición de arquitectura que hemos leído, y la más aceptada en la comunidad arquitectónica, proviene del trabajo realizado en el grupo de Arquitectura de Software del Instituto de Ingeniería de Software (SEI) de la Universidad Carnegie-Mellon de Pittsburgh. Es la estructura o estructuras del sistema, incluidos los elementos del programa, las propiedades visibles externamente de estos elementos y la relación entre ellos. La arquitectura del sistema es una característica inherente y fundamental que existe tanto si está documentada como si no, y si se comprende. De ello se deduce que cada sistema tiene exactamente una estructura. La arquitectura de un sistema intensivo en software es la estructura o estructuras del sistema, que comprenden elementos de software, el exterior propiedades normalmente visibles de esos elementos, y las relaciones entre ellos.

1. Tipos de estructuras de los sistemas.

1. Las estructuras estáticas de un sistema le indican cuál es la forma en tiempo de diseño de un sistema, es decir, cuáles son sus elementos y cómo encajan entre sí. Los elementos de software internos en tiempo de diseño pueden ser módulos, clases o paquetes orientados a objetos, procedimientos almacenados en bases de datos, servicios o cualquier otra unidad de código independiente. Los elementos de datos internos incluyen clases, entidades/tablas de bases de datos relacionales y archivos de datos. Los elementos de hardware interno incluyen computadoras o sus partes constituyentes, como discos o CPU, y elementos de red, como cables, enrutadores o concentradores. La disposición estática de estos elementos define, según el contexto, las asociaciones, relaciones o conectividad entre estos elementos. Para los módulos de software, por ejemplo, puede haber relaciones estáticas como una jerarquía de elementos (el módulo A se construye a partir de los módulos B y C) o dependencias entre elementos (el módulo A se basa en los servicios del módulo B). Para clases, entidades relacionales u otros elementos de datos, las relaciones definen cómo se vincula un elemento de datos con otro. Para el hardware, las relaciones definen las interconexiones físicas requeridas entre los diversos elementos de hardware del sistema.
2. Las propiedades de calidad le indican cómo se comporta un sistema desde el punto de vista de un observador externo (a menudo denominadas características no funcionales). Hay toda una gama de características arquitectónicas externas que pueden ser de interés: ¿Cómo funciona el sistema bajo carga? ¿Cuál es el rendimiento máximo dado cierto hardware? ¿Cómo se protege la información en el sistema del uso malicioso? ¿Con qué frecuencia es probable que se rompa? ¿Qué tan fácil es administrar, mantener y mejorar? ¿Con qué facilidad puede ser utilizado por personas discapacitadas? Cuáles de estas características son relevantes depende de sus circunstancias y de las preocupaciones y prioridades de sus partes interesadas.

3. ¿Cuáles son las propiedades visibles externas del sistema?

Podemos capturar la relación entre las propiedades visibles externamente de un sistema y su estructura y organización internas de la siguiente manera:

El comportamiento visible externamente de un sistema (lo que hace) está determinado por el comportamiento funcional combinado de sus elementos internos.

Las propiedades de calidad de un sistema como el rendimiento, la escalabilidad y la resiliencia (cómo lo hace) surgen de las propiedades de calidad de sus elementos internos. (Por lo general, la propiedad de calidad general de un sistema es tan buena como la propiedad de su elemento interno más débil o de peor comportamiento).

4. Elementos de una Arquitectura de Software y sus atributos.

A lo largo de este libro, estandarizamos el término elemento arquitectónico para referirnos a las piezas a partir de las cuales se construyen los sistemas. La naturaleza de un elemento arquitectónico depende mucho del tipo de sistema que esté considerando y del contexto dentro del cual esté considerando sus elementos. Las bibliotecas de programación, los subsistemas, las unidades de software implementables (p. ej., Enterprise Java Beans y controles Active X), los productos de software reutilizables (p. ej., sistemas de administración de bases de datos) o las aplicaciones completas pueden formar elementos arquitectónicos en un sistema de información, según el sistema que se construya. Un elemento arquitectónico debe poseer los siguientes atributos clave:

• Un conjunto claramente definido de responsabilidades
• Un límite claramente definido
• Un conjunto de interfaces claramente definidas, que definen los servicios que el elemento brinda a los otros elementos arquitectónicos.

Los elementos arquitectónicos a menudo se conocen informalmente como componentes o módulos, pero estos términos ya se usan ampliamente con un significado específico establecido. En particular, el término componente tiende a sugerir el uso de un modelo de componente de nivel de programación (como J2EE o .NET), mientras que módulo tiende a sugerir una construcción de lenguaje de programación. Aunque estos son elementos arquitectónicos válidos en algunos contextos, no serán el tipo de elemento fundamental del sistema utilizado en otros.

Por este motivo, deliberadamente no utilizaremos estos términos a partir de ahora. En su lugar, usamos el término elemento a lo largo del libro para evitar confusiones (siguiendo el ejemplo de otros, incluidos Perry y Wolf [PERR92] y Bass, Clements y Kazman [BASS03]; consulte la sección Lecturas adicionales al final de este capítulo para obtener más información). más detalles).

5. Definición de un STAKEHOLDERS.

El desarrollo de software tradicional ha sido impulsado por la necesidad del software entregado para cumplir con los requisitos de los usuarios. Aunque la definición del término usuario varía, todos los métodos de desarrollo de software se basan en este principio de una forma u otra. Sin embargo, las personas afectadas por un sistema de software no se limitan a quienes lo utilizan. Los sistemas de software no solo se usan: tienen que construirse

...