Procedimiento para la Generación

Universidad Nacional del Documento de Arquitectura

Escuela de Informática de Software.

IS-008-V02

Fecha de Primera Versión: 03-Nov-2007

Fecha última actualización: 30-agosto-2012

Autorizado por:

Cátedra de Ingeniería de Sistemas II

Cátedra de
Ingeniería de Sistemas

Tabla de Contenidos.
1. Introducción.......................................................................................................................................9
1.1 Propósito......................................................................................................................................9
1.2 Alcance........................................................................................................................................9
1.3 Definiciones, acrónimos y abreviaciones....................................................................................9
1.4 Referencias...................................................................................................................................9
2. Representación de la arquitectura....................................................................................................10
2.1 Metas y limitaciones..................................................................................................................10
2.1.1 Plataforma técnica...................................................................................................................10
2.1.2 Portabilidad.............................................................................................................................10
2.1.3 Seguridad................................................................................................................................10
2.1.4 Persistencia.............................................................................................................................10
2.1.5 Confiabilidad/Disponibilidad (failover)..................................................................................10
2.1.6 Desempeño..............................................................................................................................11
2.2 Vistas de la Arquitectura del Sistema........................................................................................11
2.2.1 Vista de Escenarios..........................................................................................................11
2.2.1.1 Diagrama de Casos de Uso............................................................................11
2.2.1.2 Realización de casos de Uso-Diseño.............................................................12
2.2.2 Vista lógica.......................................................................................................................12
2.2.3 Vista Desarrollo................................................................................................................15
2.2.4 Vista Física.......................................................................................................................16
2.2.5 Vista de Procesos..............................................................................................................17
2.2.6 Vista de Datos..................................................................................................................17
3. Definición de estándares..................................................................................................................18
----------------------------------------------------------------------------------------------------------------------------------------------------------------------

1
1. Propósito.
Este procedimiento establece el formato del documento Arquitectura de Software.

2. Alcance.
Este procedimiento se aplica a los proyectos de software desarrollados utilizando el Proceso Unificado.

3. Políticas.

3.1 Utilización de este procedimiento.

Todo documento de arquitectura de software debe ser desarrollado utilizando el formato establecido en
este documento.

4. Responsables.

4.1 PROFESOR TITULAR. Responsable del curso.

4.2 ESTUDIANTE PROPIO. Estudiante matriculado en el curso y grupo asignado al Profesor Titular.
Estudiante que desarrolla un proyecto.

4.3 ESTUDIANTE INVITADO. Estudiante matriculado en otro curso y grupo asignado al Profesor de
Registro. Estudiante que desarrolla un proyecto.

4.4 DOCUMENTADOR. Estudiante(s) encargado(s) de la generación del documento de Arquitectura de

Software. Es el responsable de la utilización adecuada de este procedimiento.

4.5 PROVEEDOR DE INSUMOS. Estudiante encargado por el Documentador(es) de aportar algún

elemento del análisis o diseño para ser incorporaros en el documento de Arquitectura de Software. Es
el responsable de proveer los elementos en las fechas especificadas.

5. Definiciones.

5.1 Arquitectura de Software: Arquitectura es la estructura de los componentes más significativos de un

sistema interactuando a través de interfaces con otros componentes conformados por componentes
sucesivamente pequeños e interfaces”.

5.2 Modularidad en el Software: Técnica de separación de sistemas computacionales en partes

manejables e interconectadas. En las metodologías orientadas a objetos, se busca la modularidad
para, entre otras cosas, lograr la reutilización del software, mostrar abstracciones para una mejor
comunicación, facilitar el mantenimiento futuro, buscar el encapsulamiento.

5.3 Subsistema: Parte de un producto de software o sistema computacional.

2
5.4 Paquete o módulo: Mecanismo de propósito general para organizar elementos en grupos que permite
dividir un modelo en partes manejables mediante la agrupación de clases u otros paquetes. Es un
concepto puramente conceptual (sólo existe en tiempo de desarrollo). Gráficamente se representa como
una carpeta conteniendo normalmente su nombre y, a veces, su contenido. Se puede conceptualizar
como un grupo de elementos del modelo. Los elementos estructurales, los elementos de
comportamiento, incluso los propios elementos de agrupación se pueden incluir en un paquete. Los
paquetes pueden tener anidados otros paquetes, así como paquetes subordinados. Algunos paquetes
pueden ser Subsistemas o modelos

5.5 Vista Conceptual. Vista usada para definir los requerimientos funcionales y la visión que los usuarios
del negocio tienen de la aplicación. Describe el modelo de negocio que la arquitectura debe cubrir.
Muestra los subsistemas y módulos en los que se divide la aplicación y la funcionalidad que brinda
dentro de cada uno de ellos.

5.6 Vista Lógica. Vista usada para describir las partes de la arquitectura más significativas del modelo de
diseño, tal como su descomposición en paquetes y subsistemas y cada paquete en su descomposición
en clases.

5.7 Vista Física. Vista usada para ilustrar la distribución del procesamiento entre los distintos equipos que
conforman la solución, incluyendo los servicios y procesos de base.

5.8 Vista de implementación. Vista usada para describir cómo se implementan los componentes físicos.
Describe el mapeo desde los paquetes y clases del modelo de diseño a subsistemas y componentes
físicos.

6. Documentos relacionados.

Código Descripción Anexo

IS-008-V##-R01 Origen de insumos para la Arquitectura de Software 9.1
IS-008-V##-R02 Arquitectura de Software 9.2
IS-008-V##-R03 Planeación de la Integración (Descripción de Arquitectura de Software) 9.3

7. Procedimiento.

7.1 El Profesor Titular explica a los estudiantes, el uso del Procedimiento.

7.2 Los estudiantes nombran uno o varios Documentadores.

7.3 El Documentador(es) determina(n) los diferentes elementos del análisis y diseño del software, que
serán necesarios para el documento de la Arquitectura de Software. Para esto utilizará el registro
Origen de insumos para la Arquitectura de Software (IS-008-V##-R01) y lo archivará y distribuirá de
acuerdo a lo establecido en el apartado 8 de este procedimiento.

7.4 Los Estudiantes procederán a aportar los elementos detallados en el Origen de insumos para la
Arquitectura de Software (IS-008-V##-R01) en las fechas establecidas en ese registro.

7.5 El Documentador(es) procederá (ran) a generar el documento de Arquitectura de Software (IS-008-V##-

R02) de acuerdo a lo establecido en ese registro.

7.6 Una vez concluido este documento, todos los estudiantes lo revisarán para corregir eventuales
inconsistencias o errores que se pudieran haber presentado.

7.7 FIN.

3
8. Control de Registros de Calidad.

Código Descripción Anexo Modo de archivo Caducidad

IS-008-V##-R01 Origen de insumos para la 9.1 El Documentador(es) Hasta el
Arquitectura de Software conservará el original y final de la
distribuirá una copia a cada fase.
Proveedor de Insumos.
IS-008-V##-R02 Arquitectura de Software 9.2 Los estudiantes Hasta el
conservaran el original. final de la
fase.
IS-008-V##-R03 Planeación de la 9.3 Los estudiantes Hasta el
Integración (Descripción conservaran el original. final de la
de Arquitectura de Una copia se debe entregar fase.
Software) al profesor de acuerdo a
como se indique en su
oportunidad.
IS-008-V##-R04 Estructuración de la Los estudiantes Hasta el
arquitectura según modelo conservaran el original. final de la
4+1 capas de Kruchten fase

4
9. Anexos.

9.1 Origen de insumos para la Arquitectura de Software (IS-008-V##-R01)

Vista Capa Elemento Proveedor de Insumos Fecha

límite
Vista Escenarios Diagrama(s) de Casos de Uso
Realización de casos de Uso
Diseño
Vista Lógica Descomposición en Capas
Descomposición en
Subsistemas
Diagrama de Clases
(“completo”)
Clases por subsistema
Vista Desarrollo Distribución del Hardware
Distribución del software
Vista Física Componentes de hardware
involucrados
Vista de Manejo de hilos y procesos por
procesos parte del sistema
Vista de datos Modelo Relacional

5
 9.2 Arquitectura de Software (IS-008-V##-R02)

<Nombre del Proyecto>

Plantilla Documento de Arquitectura de Software
 
Version <1.0>
 
 
 

Historial de Revisiones
Date Version Description Autor
<dd/mmm/yy> <x.x> <details> <name>
       
       
       
 

6
 Tabla de contenidos
Documento de arquitectura
               
1. Introducción.......................................................................................................................................8
1.1 Propósito......................................................................................................................................8
1.2 Alcance........................................................................................................................................8
1.3 Definiciones, acrónimos y abreviaciones....................................................................................8
1.4 Referencias...................................................................................................................................8
2. Representación de la arquitectura......................................................................................................9
2.1 Metas y limitaciones....................................................................................................................9
2.1.1 Plataforma técnica.....................................................................................................................9
2.1.2 Portabilidad...............................................................................................................................9
2.1.3 Seguridad..................................................................................................................................9
2.1.4 Persistencia...............................................................................................................................9
2.1.5 Confiabilidad/Disponibilidad (failover)....................................................................................9
2.1.6 Desempeño..............................................................................................................................10
2.2 Vistas de la Arquitectura del Sistema........................................................................................10
2.2.1 Vista de Escenarios..........................................................................................................10
2.2.2 Vista lógica.......................................................................................................................11
2.2.3 Vista Desarrollo (implementación)..................................................................................14
2.2.4 Vista Física.......................................................................................................................15
2.2.5 Vista de Procesos..............................................................................................................16
2.2.6 Vista de Datos..................................................................................................................16
3. Definición de estándares..................................................................................................................16

7
1. Introducción
1.1 Propósito

El propósito de este documento es resumir la arquitectura del sistema.

1.2 Alcance

Esta versión del documento de arquitectura cubre los aspectos generales del sistema
<<nombre del sistema>> con relación a la arquitectura del software cubriendo los siguientes
aspectos:

 Vista de Escenarios: Esta vista va a ser representada por los casos de uso software y va a
tener la función de unir y relacionar las otras vistas, esto quiere decir que desde un caso de
uso podemos ver cómo se van ligando las otras vistas, con lo que tendremos una
trazabilidad de componentes, clases, equipos, paquetes, etc., para realizar cada caso de
uso. Para completar la documentación de esta vista se pueden incluir el diagrama de casos
de uso de UML.
 Vista lógica: En esta vista se representa la funcionalidad que el sistema proporcionara a los
usuarios finales. Es decir, se ha de representar lo que el sistema debe hacer, y las
funciones y servicios que ofrece. Para completar la documentación de esta vista se pueden
incluir los diagramas de clases, paquetes y componentes, incluso si se desea se pueden
incorporar los diagramas de colaboración y secuencia para brindar un panorama dinámico
de la interacción entre objetos.
 Vista de desarrollo: Esta vista se ocupa de la gestión del software; se va a mostrar cómo
está dividido el sistema software en componentes y las dependencias que hay entre esos
componentes. Para completar la documentación de esta vista se pueden incluir los
diagramas de componentes, de paquetes, y de despliegue.
 Vista física: La vista física se centra en los requisitos no funcionales, tales como la
disponibilidad del sistema, la fiabilidad (tolerancia a fallos), ejecución y escalabilidad. Y
también presenta cómo los procesos, objetos, etc., corresponden a nodos de proceso:
Componentes ( nodos de proceso), Conectores( LAN, WAN, bus), Contenedores
(subsistemas físico).
 Vista de procesos: Se tratan algunos requisitos no funcionales. Ejecución, disponibilidad,
tolerancia a fallos, integridad, etc. Esta vista también especifica que hilo de control ejecuta
cada operación identificada en cada clase identificada en la vista lógica. La vista se centra
por tanto en la concurrencia y distribución de procesos.

1.3 Definiciones, acrónimos y abreviaciones

RUP: Rational Unified Process

UML: Unified Modeling Language

8
1.4 Referencias

[KRU41]: The “4+1” view model of software architecture, Philippe Kruchten, November
1995,http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/bk
4p1.pdf

[RSA]: IBM Rational Software Architect

http://www-306.ibm.com/software/awdtools/architect/swarchitect/index.html

[RUP]: The IBM Rational Unified Process : http://www-

306.ibm.com/software/awdtools/rup/index.html

2. Representación de la arquitectura
[En esta sección se describe cual es la arquitectura de software para el sistema y como se representa.
Su organización por capas, o bien patrones de arquitectura utilizados (SOA, BPM, etc. Se debe de
especificar que en orden de detallar el software de la manera más precisa posible, la estructura del
documento sigue el modelo “4+1” vistas de Kruchten]

2.1 Metas y limitaciones

[En esta sección se describe los objetivos y requerimientos del software que impactan la arquitectura,
por ejemplo seguridad, portabilidad, distribución, persistencia, disponibilidad y desempeño. También
incluye las restricciones puedan aplicar como estrategia de implementación o de diseño, herramientas
de desarrollo, como software libre, estructura del equipo de trabajo, cronograma, sistemas legados,
etc.]

2.1.1 Plataforma técnica

[Conjunto de plataformas y tecnologías en las cuales correrá el producto terminado]

2.1.2 Portabilidad
[Describir la capacidad de que posee un software para ejecutarse en diferentes plataformas]

2.1.3 Seguridad
[Describir los mecanismos de seguridad que manejará el software]

2.1.4 Persistencia
[Describir el mecanismo de persistencia de datos utilizado por el software]

9
2.1.5 Confiabilidad/Disponibilidad (failover)
[Describir el nivel de exigencia en términos de disponibilidad y como la arquitectura los garantiza]

2.1.6 Desempeño
[Describir los requisitos de desempeño del software, tales como duración por transacción, cantidad de
usuarios concurrentes soportados, entre otros]

2.2 Vistas de la Arquitectura del Sistema

[Esta sección consiste en la especificación de la representación de la arquitectura]

2.2.1 Vista de Escenarios

La vista de escenarios es usada para vincular las otras vistas, es una vista integradora de la
funcionalidad a la que responde la arquitectura para dar trazabilidad a los componentes; es
un punto de partida desde la perspectiva del usuario final donde se plasma la visión que
estos tienen del negocio y de la aplicación para así describir el modelo de negocio que la
arquitectura debe cubrir.

Esta vista estará descripta en términos de Casos de Uso y muestra los subsistemas y
módulos en los que se divide la aplicación y la funcionalidad que brinda dentro de cada uno
de ellos.

2.2.1.1 Diagrama de Casos de Uso

[Esta sección se debe copiar el diagrama de casos de uso. Se recomienda subdividir los casos de uso
según la estructura de subsistemas del software tal y como se muestra en la figura 1]

10
 Figura 1. Vista de Escenarios: CU de los módulos del sistema

Fuente: US National Institute of Health

2.2.1.2 Realización de casos de Uso-Diseño

[En esta sección se puede hacer referencia a la vista lógica, en la sección del diagrama de clases, o
bien detallar las clases que implementan los casos de uso más representativos]

2.2.2 Vista lógica

11
Esta sección describe las partes de la arquitectura más significativas del modelo de diseño
desde la perspectiva de diseño del desarrollador, tal como su descomposición en paquetes y
subsistemas, y su subsecuente descomposición en clases.

2.2.2.1 Descomposición en Capas

[En esta sección se deben de representar las distintas capas en las que es desarrollado el software así
como las relaciones entre estas. En la figura 2 se muestra un ejemplo. Para realizar esta
representación se puede utilizar un diagrama de componentes en UML donde cada componente
presenta una capa. Se debe detallar el contenido y la funciona de cada capa.]

Figura 2. Dependencias entre capas

Fuente: www.cse.hcmut.edu.vn

2.2.2.2 Descomposición en Subsistemas

[Esta sección describe los distintos subsistemas en los que se divide el software. Además de describir
el contenido y funcionalidad de cada subsistema, se debe representar mediante un diagrama de
paquetes de UML como se muestra en la figura 3]

Subsistema A:
[Detallar el contenido y funcionalidad del subsistema A]
.

12
.
.

Subsistema N:
[Detallar el contenido y funcionalidad del subsistema N]

Figura 3. Descomposición en subsistemas

Fuente: elaboración propia

2.2.2.3 Diagrama general de clases diseño

[Esta sección se presenta el diagrama general de clases diseño del sistema como se muestra en la
figura 4]

Figura 4. Diagrama general de clase

13
 Fuente: elaboración propia

2.2.2.4 Diagrama de clases pos subsistema

[Esta sección se presentan diversos diagramas (uno por subsistema) que detallan las clases que
realizan cada subsistema, organizadas por capas tal y como se presenta en la figura 5]

Figura 5. Especificación de un subsistema

Fuente: elaboración propia

14
2.2.3 Vista Desarrollo (implementación)

[Muestra los componentes de software que se planean utilizar para la implementación del sistema, a
nivel de software y de hardware; y la manera en que estos estarán relacionados]

Figura 6. Diagrama de componentes

Fuente: elaboración propia

2.2.4 Vista Física

[Muestra los componentes de infraestructura física involucrados en el funcionamiento del software,

tal y como se aprecia en la figura 7]

Figura 7. Diagrama de componentes físicos

15
 Fuente: www.cse.hcmut.edu.vn

2.2.5 Vista de Procesos

[Describe las tareas (procesos e hilos) involucrados en la ejecución del Sistema, sus interacciones y
configuraciones. Además describe la asignación de objetivos y clases a las tareas del sistema]

2.2.6 Vista de Datos

[Describe las relaciones entre las entidades de persistencia del software representadas mediante un
modelo relacional del sistema, o bien un modelo de entidades de objetivos en caso de que se utilicen
bases de datos orientadas a objetos]

Figura 8. Ejemplo de Modelo Relacional

16
 Fuente: http://basesdedatosbydante.blogspot.com/

3. Definición de estándares

Código Descripción
E01 Estándar bd.

Nota: Adjuntar los Registros de Estándares individuales. Se deben adjuntar todos los registros detallados en
esta definición de estándares (Registro IS-011-V##-R01)

17