Documento que describe la arquitectura en desarrollo de Software según en autor Ian Sommerville

1. Arquitectura en el desarrollo
de software
Integrantes: Jorge Pereira
Wladimir Tapia

2. Arquitectura de software
El diseño del sistema se centra en proporcionar la funcionalidad del sistema a
través de sus diferentes componentes. Las actividades que se realizan en este
proceso son:
1. Dividir requerimientos. Analice los requerimientos y organícense en
grupos afines. Normalmente existen varias opciones posibles de división,
y puede sugerir varias alternativas en esta etapa del proceso.
2. Identificar subsistemas. Debe identificar los diferentes subsistemas que
pueden, individual o colectivamente, cumplir los requerimientos. Los
grupos de requerimientos están normalmente relacionados con los
subsistemas, de tal forma que esta actividad y la de división de
requerimientos se pueden fusionar. Sin embargo, la identificación de
subsistemas se puede ver influenciada por otros factores
organizacionales y del entorno.
3. Asignar requerimientos a los subsistemas. Asigne los requerimientos a
los subsistemas. En principio, esto debe ser sencillo si la división de
requerimientos se utiliza para la identificación de subsistemas. En la
práctica, no existe igualdad entre las divisiones de requerimientos y la
identificación de subsistemas. Las limitaciones de los subsistemas
comerciales pueden significar que tenga que cambiar los requerimientos
para acomodarlos a estas restricciones.
4. Especificar la funcionalidad de los subsistemas. Debe enumerar las
funciones específicas asignadas a cada subsistema. Esto puede verse
como parte de la fase de diseño del sistema o, si el subsistema es un
sistema de software, como parte de la actividad de especificación de
requerimientos para ese sistema. También debe intentar especificar las
relaciones entre los subsistemas en esta etapa.
5. Definir las interfaces del subsistema. Defina las interfaces necesarias y
requeridas por cada subsistema. Una vez que estas interfaces se han
acordado, es posible desarrollar estos subsistemas en paralelo.

3. En este proceso de diseño existe mucha realimentación e iteración de una
etapa a la otra. Cuando surgen problemas y preguntas, a menudo tiene que
rehacer el trabajo hecho en etapas anteriores. Aunque se han separado los
procesos de ingeniería de requerimientos y de diseño en este análisis, en la
práctica están inextricablemente relacionados. Restricciones planteadas por
sistemas existentes pueden limitar elecciones de diseño, y estas elecciones
pueden ser especificadas en los requerimientos. Puede tener que hacer algún
diseño inicial para estructurar y organizar el proceso de la ingeniería de
requerimientos. A medida que el proceso de diseño continúa, puede descubrir
problemas con los requerimientos existentes y pueden surgir nuevos
requerimientos. Por consiguiente, una manera de representar estos procesos
relacionados es en forma de espiral. El proceso en espiral refleja la realidad de
que los requerimientos afectan a las decisiones de diseño y viceversa, y de esta
forma tiene sentido entrelazar estos procesos. Comenzando en el centro, cada
vuelta de la espiral añade algún detalle a los requerimientos y al diseño.
Algunas vueltas se centran en los requerimientos; otras, en el diseño. A veces,
nuevo conocimiento recopilado durante los procesos de requerimientos y
diseño significa que la declaración del problema en sí misma tiene que ser
cambiada. Para la mayoría de los sistemas, existen muchos diseños posibles
que cumplen los requerimientos. Estos comprenden una amplia gama de
soluciones que combinan hardware, software y operaciones humanas. La
solución que elija para el desarrollo futuro deberá ser la solución técnica más
apropiada que cumpla los requerimientos. Sin embargo, las intervenciones
organizacionales y políticas pueden influir en la elección de la solución. Por
ejemplo, un cliente del gobierno puede preferir usar proveedores nacionales
antes que los extranjeros para su sistema, aun cuando el producto nacional sea
técnicamente inferior. Estas influencias normalmente tienen efecto en la fase
de revisión y valoración en el modelo en espiral, donde los diseños y
requerimientos pueden ser aceptados o rechazados. El proceso finaliza cuando
la revisión y evaluación muestra que los requerimientos y el diseño de alto
nivel son suficientemente detallados para permitir empezar la siguiente fase
del proceso.

4. Arquitecturas más comunes
Generalmente, no es necesario inventar una nueva arquitectura de software
para cada sistema de información. Lo habitual es adoptar una arquitectura
conocida en función de sus ventajas e inconvenientes para cada caso en
concreto. Así, las arquitecturas más universales son:
❏ Descomposición Modular. Donde el software se estructura en grupos
funcionales muy acoplados.
❏ Cliente-servidor. Donde el software reparte su carga de cómputo en
dos partes independientes pero sin reparto claro de funciones.
❏ Arquitectura de tres niveles. Especialización de la arquitectura
cliente-servidor donde la carga se divide en tres partes (o capas) con
un reparto claro de funciones: una capa para la presentación (interfaz
de usuario), otra para el cálculo (donde se encuentra modelado el
negocio) y otra para el almacenamiento (persistencia). Una capa
solamente tiene relación con la siguiente.
Otras arquitecturas menos conocidas son:
❏ Modelo Vista Controlador.
❏ En ​pipeline​.
❏ Entre pares​.
❏ En pizarra.
❏ Orientada a servicios (SOA del inglés ​Service-Oriented Architecture​).
❏ Arquitectura de microservicios (MSA del inglés ​MicroServices
Architecture​). Algunos consideran que es una especialización de una
forma de implementar SOA.
❏ Dirigida por eventos.
❏ Máquinas virtuales

5. ejemplo
aquí se puede apreciar una arquitectura simple de un sistema de alarma contra
ladrones.
Artefactos que se generan en la arquitectura
Se generan 13 artefactos que los nombraremos y definiremos:
● Modelo de Desarrollo: ​Muestra la configuración de nodos de proceso en
tiempo de ejecución, los enlaces de comunicación entre ellos y las
instancias de componentes y objetos que residen en ellos.
Su objetivo es capturar la configuración de elementos de proceso y la
conexión entre ellos en el sistema.
Consiste en uno o más nodos (los cuales son elementos de proceso con
al menos un procesador, memoria y posiblemente otros dispositivos)
dispositivos (nodos estereotipados sin posibilidad de procesamiento en
el nivel de modelado de abstracción), y conectores entre nodos, y entre
nodos y dispositivos. El modelo de desarrollo también muestra procesos

6. en sus elementos de proceso, permitiendo la distribución del
comportamiento a través de nodos para ser representados.
Esperemos que quede más claro con la siguiente imagen:
● Modelo de Análisis​: Contiene los resultados del análisis de los casos de
uso. Este artefacto es opcional. El modelo de análisis puede ser un
artefacto temporal, como lo es en el caso de que evolucione para
convertirse en un modelo de diseño, o puede seguir viviendo a través de
algunos o todos los proyectos, y tal vez más que eso, sirviendo como una
visión general conceptual del sistema.
● Modelo de Diseño​: Es un objeto de modelado que describe la realización
de los Casos de Uso y sirve como una abstracción del modelo de
implementación y su código fuente.
❏ Es usado como entrada esencial a las actividades de la
implementación y las pruebas.
❏ Es una abstracción de la implementación de un sistema; es
utilizado para crear y documentar el diseño del sistema de
Software.
❏ Se trata de un artefacto compuesto que abarca todas las clases de
diseño, subsistemas, paquetes, colaboraciones, y las relaciones
entre ellos.

7. Contiene los siguientes Artefactos:
❏ Protocolo: ​Es una especificación del comportamiento deseado que
puede tener lugar a través de una conexión (una especificación explícita
del acuerdo contractual entre los participantes en el protocolo. Es puro
comportamiento y no se especifica ningún elemento estructural. Un
protocolo comprende un conjunto de los participantes, cada uno de los
cuales desempeña un papel específico en el protocolo. Los protocolos
permiten la especificación de un conjunto de Cápsulas (una Cápsula es
otro artefacto) para ser definidas y usadas. El protocolo define un
conjunto de tipos de mensajes entrantes y salientes (como lo pueden ser
operaciones y señales) y opcionalmente una colaboración (por lo
regular, consiste en un conjunto de diagramas de secuencia) la cual
define los pedidos de los mensajes y una "máquina de estados" (descrita
por un conjunto de diagramas de estado), que especifica el
comportamiento abstracto que los participantes en un protocolo deben
proveer.
❏ Interfaz: ​Es un artefacto que define un conjunto de comportamientos,
propuesto por un modelo clasificador. Un clasificador puede realizar una
o más interfaces y una interfaz puede ser realizada por uno o más
clasificadores. Cualquier clasificador que realice las mismas interfaces
puede ser sustituido por otro en el sistema. Cada interfaz, debería
ofrecer un único y bien definido conjunto de operaciones. Declara un
conjunto de operaciones, incluyendo sus firmas y parámetros, que son

8. usados para especificar los servicios ofrecidos por un modelo
clasificador. (Por ejemplo una clase, componente o subsistema).
❏ Evento: ​Es la especificación de una ocurrencia en el espacio y tiempo; o
en el buen español: un suceso o algo que a lo que el sistema debe
responder.Identifica y captura información sobre eventos externos de
que el sistema es consciente, y para la que debe responder. Los eventos
pueden también ser usados para modelar eventos internos,
especialmente excepciones.
❏ Señal: ​Es una entidad de comunicación asíncrona que puede ocasionar
un estado transitorio en la máquina de estados de un objeto que recibe
dicha señal.Provee una comunicación asíncrona de un solo sentido de un
objeto a otro.
❏ Cápsula: ​ "Una cápsula es un patrón de diseño, lo que representa un
encapsulado hilo de control en el sistema. Las cápsulas tienen puertos, a
través de los cuales se comunican con otras cápsulas". Se representa
como una clase, con el estereotipo <<capsule>>. Está compuesta por Sub
cápsulas, Clases Pasivas, Conectores, Puertos, Especificación de
Colaboración y Estado de Máquina. En RUP se representa de la siguiente
forma:

9. ● Documento de Arquitectura de Software:​ Es un documento que provee
una visión amplia arquitectónica del sistema, usando diferentes vistas
arquitectónicas para representar diferentes aspectos del sistema. Sirve
como un medio de comunicación entre el Arquitecto de Software y los
demás miembro del proyecto respecto a decisiones importantes sobre la
arquitectura que se han estado haciendo en el proyecto.
● Arquitectura de Referencia: ​Es en esencia un patrón arquitectónico
pre-definido o conjunto de patrones, posiblemente parcial o
completamente instanciado, diseñado y probado para su uso en
negocios particulares y contextos técnicos​.​ Frecuentemente, estos
artefactos son cosecha de proyectos anteriores. Crea un punto de
comienzo para el desarrollo arquitectónico. Su gama puede estar desde
pautas de arquitectura preestablecidas, arquitectura de mecanismos y
marcos, hasta sistemas completos, con características conocidas
demostradas en uso. La utilización de arquitecturas de referencia
probadas es una forma eficaz para hacer frente a muchos no los
requisitos funcionales, en particular los requisitos de calidad, por la
elección de las arquitecturas de referencia, que son conocidas a través
de uso para satisfacer esos requisitos. La arquitectura de referencia,
puede existir o ser usada en diferentes niveles de abstracción y desde
distintos puntos de vista.
● Directrices de Diseño​: Es un producto de la definición de arquitectura.
Muchas personas necesitarán este documento, puesto que describe las
directrices para ser seguidas durante el diseño e implementación.
○ Es un artefacto creado y actualizado por el arquitecto de Software,
y sirve como un medio de comunicación entre el arquitecto de
software y otros desarrolladores.
○ Los diseñadores lo utilizarán como referencia la hora de definir las
operaciones de diseño en las clases y la hora de adaptar las clases
de diseño al ambiente de implementación.
○ Los dueños de lo paquetes, lo usarán como referencia cuando
describen dependencias entre paquetes.

10. ○ Los "implementadores" la usarán como referencia en la
implementación del modelado de las clases.
○ Los "revisadores" lo usarán como referencia al momento de
revisar la arquitectura del Software, el diseño del modelo y la
implementación del mismo.
○ Los recién llegados al proyecto lo usarán para entender qué es lo
que se está produciendo.
● Modelo de implementación: ​El modelo de implantación es una colección
de componentes y subsistemas de la aplicación que los contengan. Los
componentes incluyen tanto a entregar los componentes, tales como
ejecutables, y los componentes de los productos que se producen, tales
como archivos de código fuente.
● Prueba-de-Concepto arquitectónico: ​Es una solución que simplemente
puede ser conceptual, para los requerimientos de significado
arquitectónico que son identificados en la concepción.Determina donde
pueda existir, una solución para satisfacer los requerimientos de
significado arquitectónico.
● Directrices de Programación: ​Describe los convenios a ser usados cuando
se trabaje con el lenguaje de programación. Describe los lineamientos de
cómo se debe de escribir el código fuente.

11. bibliografía
libro guia de ​Ian Sommerville - Ingeniería de software
http://clases3gingsof.wikifoundry.com/page/Artefactos+Arquitectura+de+Soft
ware
https://es.wikipedia.org/wiki/Arquitectura_de_software