009.1. Documento Arquitectura de Software

E.A.P. Ingeniería de Sistemas – Calidad de SoftwareUniversidad Nacional José Faustino Sánchez Carrión

DA002 - Maritza: Order & DeliveryDocumento de Arquitectura del Software (SAD)

Versión <0.5>

Equipo de Desarrollo:- BERNABE GAVINO, Olga Lucero- DIAZ LOZANO, Andreí Rossana.

- MARTÍNEZ GUARDALES, Dalia Lucero.- MATOS LORENZO, Allison Milagros.- ROJAS MEDINA, Luis Enrique.- ROBLES MEJÍA, Zakery Steven.

Ingeniería de Sistemas

VII Ciclo - 2015

Página 2 de 8

Tabla de Contenidos1. Introducción 3

1.1 Propósito 31.2 Alcance 31.3 Definiciones, Acrónimos y abreviaturas 31.4 Referencias 31.5 Generalidades 3

2. Representación de la Arquitectura 3

3. Metas y Restricciones Arquitectónicas 43.1 Requerimientos no funcionales 43.2 Riesgos 43.3 Restricciones Especiales. 4

3.3.1 [Requerimiento Especial 1]. 4

4. Vista de Casos de Uso 54.1 Diagrama de Caso de Uso 54.2 Casos de Uso Significat ivos de la Arquitectura 5

5. Vista Lógica 55.1 Generalidades 5

5.1.1 Vista de Capas y Subsistemas 55.2 Paquetes de Diseño Arquitectónicamente Significativos 5

5.2.1 <Capa/Paquete Uno> 55.3 Interpretaciones de los Casos de Uso 6

5.3.1 <Caso de Uso Uno> 6

6. Vista de Procesos 6

7. Vista de Despliegue 67.1 <Componente Uno> 6

8. Vista de Implementación 68.1 Generalidades 68.2 Capas 6

8.2.1 <Capa Uno> 7

9. Vista de Datos 7

10. Tamaño y desempeño 7

11. Calidad 7

DA002 –Maritza: Order & Delivery Ve rsión: <0.5>Documento de Arquitectura del Software (SAD) Fecha: 04/05/2015

Página 3 de 8

Documento de Arquitectura del Software (SAD)

1. IntroducciónEl presente documento provee una visión general de la arquitectura del DA002 - Maritza: Order & Delivery, usando diferentes vistas para apreciar los diferentes aspectos del Sistema, las cuales están basados en los estándares del Proceso Unificado de Desarrollo de Software (RUP) y utilizando el Lenguaje de programación C# ASP.NET.

1.1 PropósitoEl presente documento tiene como objetivo: Plasmar mediante diagramas, modelos y artefactos del RUP, las

consideraciones técnicas y tecnológicas (plataforma) en la que será implementada la solución.

Bosquejar los aspectos funcionales de la aplicación. Definir los mecanismos de despliegue y distribución del sistema. Esbozar el modelo entidad – relación de la cardinalidad de la arquitectura de

datos a desarrollar.

1.2 AlcanceDetalla la arquitectura propuesta por el equipo de desarrollo y contempla la interrelación con otros sistemas internos y externos a la Panadería y Pastelería “Maritza”, modelos de dominio y datos, además de los diagramas de diseño necesarios para comprender el comportamiento de los componentes.

1.3 Definiciones, Acrónimos y abreviaturasToda definición, acrónimo y abreviatura requerida para entender este documento se encuentra en el Glosario de Términos del Proyecto DA002 - Maritza: Order & Delivery.

1.4 ReferenciasLos siguientes documentos referenciados han sido usados como base para elaborar el presente documento.

Especificaciones de Casos de Uso

Especificación de Requerimientos del Software

1.5 GeneralidadesDefine las consideraciones de infraestructura para el sistema, así como los diagramas que permiten entender las dependencias entre artefactos y/o componentes en la arquitectura de la solución.


Página 4 de 8

2. Representación de la Arquitectura

A continuación se muestra la arquitectura del Sistema D A 0 0 2 – Maritza: Order & Delivery, la cual está dividida en 4 capas:

Capa Entidad Capa Vista Capa Lógica Capa Datos

Así mismo la aplicación se ha di vi dido en 3 subsistemas por criterio de:

Clases (Métodos)

Formularios

Cálculos (de pedidos online)

El documento se ha estructurado empleando la representación de la arquitectura de acuerdo con la arquitectura de 4 + “1” vistas propuestas por IBM Rational. La representación se realizará a fin de mostrar diferentes perspectivas del producto software, empleando las vistas siguientes:

1. Perspectiva Funcional – Vista de Casos de Usos:

Presenta la arquitectura desde la perspectiva del usuario final. Esta vista se desarrolla a través del Modelo de Casos de Usos (usando Diagramas de Casos de Uso de UML).

2. Perspectiva Estructural – Vista Lógica:

Presenta la arquitectura desde la perspectiva del desarrollador. Permite mostrar la organización de las piezas fundamentales de la arquitectura, organizando los elementos de diseño (clases, tablas, etc.).

3. Perspectiva de Construcción – Vista de Implementación:

Presenta la arquitectura desde la perspectiva del programador, definiendo los componentes software a ser desarrollados, la distribución de las clases, tablas y demás.

4. Perspectiva Dinámica – Vista de los Procesos / Tareas:

Presenta la arquitectura desde la perspectiva del desarrollador a fin de definir aspectos de concurrencia, comunicación interprocesos, sincronizaciones, etc.

5. Perspectiva de los Datos – Vista de Datos:

Presenta la arquitectura de datos que soportará los requerimientos de información del sistema software. Se emplea el Modelo Entidad Relación.

6. Perspectiva del Despliegue – Vista de Despliegue:

Presenta la arquitectura desde la perspectiva del implantador de la solución. Define como los componentes de la arquitectura serán desplegados sobre la infraestructura de TI definida.


Página 5 de 8

3. Metas y Restricciones Arquitectónicas

Se han identificado los requerimientos no funcionales y riesgos que impactan sobre la arquitectura del sistema.

3.1 Requerimientos no funcionalesEstos se detallan en el documento de Especificación de Requerimientos del Software.

3.2 RiesgosDetallados en el documento de Lista de Riesgos y que afectan la arquitectura del sistema.

3.3 Restricciones Especiales

Restricciones de relevancia a considerar para la definición de la arquitectura son: Todas las funciones deben estar disponibles para cualquiera de los ordenadores

comercialmente disponibles. Toda la interpretación y exigencias recopiladas en los documentos que se han

realizado deben ser tenidas en cuenta cuando la arquitectura está siendo desarrollada.

Siendo las restricciones del sistema:

Elementos TecnologíaBase de datos SQL Server 2012Lenguaje de programación Visual Studio 2013 – C#

Framework de diseño .NET Framework 4

Editor de texto Visual Studio 2013

Administrador de BD SQLServer 2012

4. Vista de Casos de Uso

Casos de Uso

1° etapa de desarrollo

- Registrar Nuevo cliente

- Registrar pedidos

- Modificar orden

- Enviar comentario

- Generar número de ticket

2° etapa de desarrollo

- Crear Nuevo usuario

- Administrar usuarios

- Asignar roles


Página 6 de 8

- Asignación de privilegios

- Registrar_productos

- Administrar_productos

- Administrar pedidos

- Generar reportes

- Valorizar_pedidos

- Generar comprobante de pago

- Registrar pago

- Monitoriar estado de pedido

Escenario (1era etapa):

- Login (Acceso al Sistema)


Página 7 de 8

4.1. Diagrama de Caso de Uso


Página 8 de 8

Diagrama de despliegue

Despliegues Registra pedidos

2° Etapa de Desarrollo


Página 9 de 8

Diagrama de paquete


Página 10 de 8

4.1 Casos de Uso Significativos de la ArquitecturaLos casos de uso significati vos de arquitectura son aquellos que tienen restricciones es decir están vinculados a requerimientos no funcionales y/o riesgos.

Caso de Uso Significativo

Requerimientos No Funcionales y/o Riesgos

Registrar Pedidos El Sistema debe ser operable en diversos ordenadores.

Generar Restricciones El Sistema debe mostrar las actividades que pueda realizer un usuario y el cliente.

5. Vista LógicaEn esta sección se describe la parte significativa de la arquitectura del modelo de diseño. Los aspectos relevantes incluyen: descomposición del sistema en subsistema y paquetes. De aplicarse algún estilo arquitectónico, se debe definir cuál o cuáles estilos son y la estructura de la vista lógica estará determinada por dichos estilos aplicables. Para las clases arquitectónicamente importantes se deberá describir sus operaciones, atributos y relaciones con otras clases.

5.1 Generalidades

[Esta parte del documento describe la descomposición completa del modelo de diseño en término de la jerarquía de sus paquetes y las capas.]

5.1.1 Vista de Capas y Subsistemas[Insertar el diagrama de subsistemas contenidos en capas]

5.2 Paquetes de Diseño Arquitectónicamente Significativos[Para cada paquete significativo, se deberá colocar una subsección con el nombre del paquete y su descripción, y uno o varios diagramas con todas las clases y paquetes significativos contenidos dentro del paquete. Para cada clase significativa en el paquete, incluir el nombre, descripción y opcionalmente, una descripción de sus principales responsabilidades, operaciones y atributos.]

5.2.1 <Capa/Paquete Uno>[Colocar la descripción, y uno o varios diagramas con todas las clases y paquetes significativos contenidos dentro del paquete. Para cada clase significativa en el paquete, incluir el nombre, descripción y opcionalmente, una descripción de sus principales responsabilidades, operaciones y atributos.]

5.2.1.1 <Subsistema Uno>Está formado por las siguientes clases de interfase:

[Insertar el diagrama de clases del subsistema]


Página 11 de 8

<Código del Proyecto> - <Nombre del Proyecto> Ve rsión: <X.Y>Documento de Arquitectura del Software (SAD) Fecha: dd/mm/yyyyDES-DSW-01

5.3 Interpretaciones de los Ca sos de Uso[Ilustrar como el software operará, proporcionando un conjunto selecto de interpretaciones de los casos de uso (escenarios) a través de Diagramas de Secuencias y/o Diagramas de Colaboración. Explicar como los diferentes elementos del modelo de diseño aporta a la funcionalidad descrita.

Los escenarios relevantes a incluir son aquellos asociados con los principales riesgos o desafías técnicos a ser cubiertos por el producto. Los patrones de interacción que marcan el comportamiento de la arquitectura y que ejercitan la mayor parte de los elementos de la arquitectura. Se debería organizar esta sección colocando una subsección por cada caso de uso o escenario, donde la especificación de los escenarios puede apoyarse con diagramas de clases que incluyan los elementos participantes del escenario o caso de uso. ]

5.3.1 <Caso de Uso Uno>

5.3.1.1 <Escenario Uno>[Colocar el diagrama de secuencias que describe el comportamiento del sistema apoyado con el diagrama de clases con los elementos de diseño que participan. ]

6. Vista de Procesos[Se debe de describir la descomposición del sistema en procesos ligeros o hilos de control, y procesos pesados (agrupamiento de procesos ligeros).

La sección deberá ser organizada por grupos de procesos que se comunican o interactúan. Definir los métodos principales de comunicación entre procesos, como pueden ser: paso de mensajes, interrupciones, colas de mensajes, etc.]

7. Vista de Despliegue[Describir una o varias configuraciones físicas de red – infraestructura de la red o arquitectura de TI – sobre las que el software deberá ser desplegado. Para cada elemento de hardware definir las características requeridas para el correcto funcionamiento de los componentes software (memoria, CPU, HDD, etc.), las interconexiones entre dichos elementos (LAN, punto a punto, etc.). Realiza el planteamiento del despliegue de los procesos de la Vista de Procesos sobre la infraestructura de TI cubierta en esta sección.

Se ubicará aquí el Modelo de Despliegue expresado a través del Diagrama de Despliegue de UML o variante más sofisticado.]

7.1 <Componente Uno>[Descripción del componente]

8. Vista de Implementación[En esta sección se describe la estructura completa del Modelo de Implementación, la descomposición del software en capas y subsistemas en el Modelo de Implementación, y cualquier componente arquitectónicamente significativo .]

8.1 Generalidades[Nombre y defina las diferentes capas y sus contenidos, las reglas que definen la inclusión de una capa dada y la fronteras entre las diferentes capas (interfaces de integración) entre componentes de capas adyacentes. Esta información será cubierta a través del Diagrama de Componentes. ]

[Colocar el Modelo de Implementación (Diagrama de componentes en capas) en este lugar.]

8.2 Capas[Se deberá proveer para cada capa una sección con su nombre y la enumeración de los subsistemas asignados a la capa, así como un diagrama de componentes donde se muestren los componentes


Página 12 de 8

que conforman la capa, las dependencias entre ellos. Las interfaces requeridas y proporcionadas


Página 13 de 8

<Código del Proyecto> - <Nombre del Proyecto> Ve rsión: <X.Y>Documento de Arquitectura del Software (SAD) Fecha: dd/mm/yyyyDES-DSW-01

por cada componente, a fin de describir con suma precisión la integración .]

8.2.1 <Capa Uno>[Indicar la enumeración de los subsistemas asignados a la capa, así como un diagrama de componentes donde se muestren los componentes que conforman la capa, las dependencias entre ellos. Las interfaces requeridas y proporcionadas por cada componente, a fin de describir con suma precisión la integración.]

[Colocar el Diagrama de componentes de la capa en este lugar.]

8.2.1.1 <Componente Uno>

9. Vista de Datos[Incorporar la perspectiva del almacenamiento de datos del sistema para soportar los requerimientos de persistencia de la información en el tiempo. Puede incluirse referencia al Documento de Diseño Detallado.]

[Colocar el Diagrama Entidad-Relación en este lugar.]

10. Tamaño y desempeño[Aspectos relacionados a requerimientos no funcionales tales como desempeño, tiempos de respuestas, entre otros.]

11. Calidad[Definir como la arquitectura del software contribuye con las capacidades del sistema: extensibilidad, confiabilidad, portabilidad, entre otros. Definir los principales conflictos de diseño que son cubiertos y resueltos con la propuesta arquitectónica que se define a través de este documento. Considerar además, aspectos tales como seguridad y privacidad, como son resueltos a través de la arquitectura.]


Página 14 de 8


Página 15 de 8


Historia de las RevisionesFecha Versión Descripción Autor

<04/05/2015> <0.5> Creación del esquema general del documento Matos Lorenzo, Allison


Documents

009.1. Documento Arquitectura de Software