Ar Quite Ctu Rade Software

SISTEMA-MARITZA
Arquitectura del Software (SRS)
Versin 2.0
Huacho, 2016
SISTEMA-MARITZA Versin: 2.0
Arquitectura de software -Maritza Fecha: 01/0452016
Tabla de contenido
1. Introduccin
1.1. Propsito
1.2. Alcance
1.3. Definiciones, Acrnimos y abreviaturas
1.4. Referencias
1.5. Generalidades
2. Representacin de la Arquitectura
3. Metas y Restricciones Arquitectnicas
3.1. Requerimientos no funcionales
3.2. Riesgos
3.3. Restricciones Especiales.
4. Vista de Casos de Uso
4.1. Diagrama de Caso de Uso
4.2. Casos de Uso Significativos de la Arquitectura
5. Vista Lgica
5.1. Generalidades
5.2. Paquetes de Diseo Arquitectnicamente Significativos
5.2.1. Capas
6. Vista de Procesos
7. Tamao y desempeo
8. Calidad
1. Introduccin
Este documento provee informacin detallada de la arquitectura, necesaria para el
desarrollo y diseo de la aplicacin Web segn lo acordado en los requerimientos
especificados en el documento de SRS, el cual tiene como objetivo establecer las
necesidades de los actores y las diferentes vistas temticas que intervienen en la
administracin de la Panadera Maritza.
1.1.Propsito
Se describe detalladamente la visin completa de la arquitectura del software, usando
diferentes vistas arquitectnicas: lgica, procesos, implementacin, distribucin y datos,
con la intencin de reflejar las decisiones arquitectnicas ms relevantes que se tomaron
para hacer la definicin del software.
1.2.Alcance
El sistema gestin de panadera Maritza, mantenimiento de usuarios (Clientes,
administrador, cajero, proveedor), control de insumos, ingreso de pedidos, generar ticket
(boleta, factura) validacin de usuarios y entre otros.
1.3. Definiciones, Acrnimos y abreviaturas
Arquitectura de software
Conjunto de elementos estticos, propios del diseo intelectual del sistema, que definen y
dan forma tanto al cdigo fuente, como al comportamiento del software en tiempo de
ejecucin. Naturalmente este diseo arquitectnico ha de ajustarse a las necesidades y
requisitos del proyecto.
C#.Net
Lenguaje de programacin interpretado, diseado para la construccin de pginas web
dinmicas.
Requerimiento funcional
Define el comportamiento interno del software: clculos, detalles tcnicos, manipulacin
de datos y otras funcionalidades que definen como los casos de uso sern satisfechos.
Requerimiento no funcional
Un requerimiento que especifica criterios que pueden usarse para juzgar la operacin de
un sistema en lugar de sus comportamientos especficos.
1.4. Referencias
Los siguientes documentos referenciados han sido usados como base para elaborar el
presente documento.
Especificaciones de Casos de Uso
Especificacin de Requerimientos del Software
1.5. Generalidades
Este documento cuenta con una breve descripcin de las funciones con los que cuenta la
aplicacin web, describiendo los diferentes diagramas utilizando para el modelado de este
sistema.
2. Representacin de la Arquitectura
Para describir y estructurar el modelo de arquitectura escogido por el equipo se usa la vista
de modelos arquitectnicos llamada 4+1 de Philippe Kruchten que se ilustra en la
siguiente figura
Figura N1
El documento se ha estructurado empleando la representacin de la arquitectura de acuerdo
con la arquitectura de 4 + 1 vistas propuestas por IBM Rational.
Y que el propsito de cada una de ellas dentro del desarrollo del proyecto es:
Vista Lgica
Describe las partes arquitectnicamente significativas del modelo de diseo, como son la
descripcin y modelado de los requerimientos funcionales. Para este caso, se representarn
por medio de la especificacin de diagramas de clases y como soporte, con diagramas de
secuencia para definir las interacciones realizadas por el sistema para cumplir con cada uno de
estos requerimientos. Adems, como complemento se mostrar el diagrama de entidad relacin
del sistema.
Vista de Procesos
Describe la descomposicin del sistema en hilos y procesos en tiempo de ejecucin.
Indica qu procesos o grupos de procesos se comunican o interactan entre s y los modos
en que estos se comunican. Para este caso, esta vista se representar en diagramas de
secuencia y de entidad relacin.
Vista de Desarrollo
Muestra la comunicacin entre los diferentes mdulos que componen los escenarios,
as como la organizacin de estos en capas. Estos mdulos pueden ser mostrados en
componentes o subsistemas, y estos son organizados jerrquicamente en las capas
mencionadas. Toma en cuenta principalmente requerimientos internos relacionados con la
facilidad de desarrollo, la gestin del software, reutilizacin, y las restricciones impuestas
por la herramienta o el lenguaje de programacin. Para esta vista, se representar con el
diagrama de componentes.
Vista de Escenarios
Lista los casos de uso que representen funcionalidades centrales del sistema, que requieran
una gran cobertura arquitectnica o aquellos que impliquen algn punto especialmente
delicado de la arquitectura. Para esta vista, se realizar por medio del diagrama de casos
de uso y del diagrama de actividad.
Vista Fsica
Describe la estructura fsica del sistema, los modos de comunicacin y los nodos existentes
en l, mostrando la ejecucin del software en el hardware. Se toma en cuenta
primordialmente los requerimientos no funcionales del sistema como la disponibilidad, la
confiabilidad, el desempeo y la escalabilidad, otros.
La representacin arquitectnica del sistema web se encuentra basada bajo el estilo cliente
servidor, basada en el paso de mensajes entre una mquina (cliente) que solicita
peticiones de servicio a otra en la que residen los datos y los programas de aplicacin
(servidor).
En esta arquitectura la capacidad de proceso est repartida entre el servidor y los clientes.
Se pueden distinguir 3 capas o niveles:
Interface del usuario (Nivel de presentacin).
Presenta el sistema al usuario. Captura y comunica la informacin al usuario. GUI
(Interfaz grfica de usuario) el cual es amigable, entendible y usable.
Procesador de aplicaciones o reglas del negocio (Nivel lgico).

Es donde residen las funciones que se ejecutan. Se reciben las peticiones del usuario.
Se procesa la informacin y se envan las respuestas tras el proceso
Gestor de Base de Datos (Nivel de almacenamiento).
Es donde residen los datos. Es el encargado de gestionar los datos. Est formado por
uno o ms DBMS: Definir y almacenar, consultar, manipular y controlar.
3. Metas y Restricciones Arquitectnicas
Se han identificado los requerimientos no funcionales y riesgos que impactan sobre la
arquitectura del sistema.
3.1. Requerimientos no funcionales
3.1 .1 Requisitos de rendimiento
i. Requisito de respuesta
El sistema ofrecer respuesta al usuario en tiempo real.
3.1.2 Seguridad
i. Requisito de autenticacin:
El sistema requerir de un usuario y contrasea vlidos para poder permitir el acceso.
ii. Requisito de divisin de mdulos:

El sistema tendr separados los mdulos a los que puede acceder un usuario
convencional de los mdulos a los que puede acceder el usuario administrador.
iii. Requisito de conexin:
El sistema slo tendr abierta la conexin a la base de datos mientras se ejecuta la
transaccin.
iv. Requisito de copia de seguridad:
El sistema realizar una copia de seguridad peridicamente siempre y cuando encuentre
la conexin cerrada, de lo contrario lo intentar ms tarde.
3.1.3 Fiabilidad
i. Requisito conexin:
El sistema cerrar las conexiones inmediatamente terminando el turno en ejecucin
para evitar prdida de datos o cualquier percance inesperado.
3.1.4 Disponibilidad
En funcionamiento normal el sistema estar disponible el 90% del tiempo.
3.1.5 Mantenibilidad
i. Requisito de mantenimiento:
El sistema recibir mantenimiento una vez por semana los primeros 6 meses.
ii. Requisito de depuracin de respaldos de bases de datos:

Se revisarn los respaldos de la base de datos para decidir si es necesaria una
depuracin.
iii. Requisito de actualizacin de estadsticas:
Se actualizarn las estadsticas manualmente para no perjudicar el rendimiento con una
actualizacin automtica.
iv. Requisito de comprobacin de integridad de datos:
Se comprobar la integridad y asignacin estructural de objetos e ndices de la base de
datos.
vii. Factibilidad Operacional
Dentro de ese punto debemos considerar que los mismos usuarios del sistema actual
(trabajadores de la empresa), estn de acuerdo y motivados con el cambio, esto en un
punto positivo para nosotros, ya eso nos da a entender que la resistencia al cambio
entre el sistema actual y el sistema nuevo no debera a (nivel de usuario) tener
mayores complicaciones
viii. Desempeo:
Tiempo de Respuesta: se ansa obtener una respuesta con mayor fluidez posible cuando se
consultan los datos o se solicita algn registro de datos, respecto a las respuestas sern
considerados cada uno de ellos de acuerdo al rango de tiempo que se establece a
continuacin:
Medio: 3 a 5 segundos
Ideal: 0 a 2 segundos
Mximo: 6 a 60 segundos
Intolerable: ms de 60 segundos
3.2 Riesgos
Detallados 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 definicin de la arquitectura son:
Todas las funciones deben estar disponibles para cualquiera de los ordenadores
comercialmente disponibles.
Toda la interpretacin 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 Tecnologa
Base de datos SQL Server
Lenguaje de programacin ASP.net
Framework de diseo .NET Framework 4.5

Editor de texto Visual Studio 2013
Administrador de BD Microsoft SQL Server 2012
4. Vista de Casos de Uso
A travs de la vista de los casos de uso se realizar una definicin del alcance funcional del
producto software en cada uno de los subsistemas funcionales que lo constituyen.
4.1 Diagrama de Caso de Uso
A continuacin, se describen los casos de uso dentro del contexto en que se desempean, y
asociado a uno o varios actores que ejecutan la accin. En la siguiente tabla se resumen las
interacciones de los usuarios y las funcionalidades.

<<include>> <<extend>>
Registrar cliente Informe Maestro Informe de Embolsador
<<extend>>
Registro de Orden Produccin

<<extend>>
Anular venta Genera venta Ingreso Productos Comprados
<<include>>
Generar Pedidos Almacenero

Vendedor
Imprimir Comprobante <<include>>
<<include>>
Imprimir Guia de Despacho

Administrar Producto
<<include>>
Tiempo de espera generar contrato

supervisor
Egresos de la Almacen Administrar Recetas
Registrar Trabajador
Gestion de Pedidos
Registrar Cliente
Generar Venta
Anular Venta
<<include>>
Consultar producto
<<include>>
Vendedor Generar Pedidos
Anular venta
supervisor
<<include>>
Verifica N de serie
Imprimir Guia de Despacho
Generar Pedidos
Generar contrato
Caracteristicas del producto

<<extend>>
Vendedor generar contrato <<include>>

Tiempo de espera
supervisor
Gestin de Pedidos
supervisor
Gestion de Pedidos
Ingresar Productos Comprados
Informe de Embolsador
Informe Maestro
Registro de Orden Produccin

Salida Regular de Almacn
Administrar Recetas de Producto Terminado
supervisor
Administrar Recetas
Actores
Los siguientes son los actores que interactan con el sistema:

ACTORES DESCRIPCIN
Tiene prioridad de registrar y administrar usuarios,

Supervisor
productos
Es el encargado de la venta, generar pedidos al almacenero y

Vendedor
generar contrato.
Recibe los pedidos del vendedor, registrar los ingresos de
Almacenero productos comprados Registra el informe maestro de la
orden de produccin.
CASOS DE USO DESCRIPCIN
El vendedor registra el nuevo cliente ingresando sus datos

Registrar Cliente
completos en la base de datos.
El vendedor atender al cliente pidindole la lista de los

Generar Venta
productos que desea comprar.
El Supervisor ingresa el nmero de serie de la venta para
buscarlo en la base de datos y as poder anularlo por motivo

Anular Venta
de cambio de producto, por falta de producto en stock o por
error al digitar el pedido.
El vendedor atender al cliente pidindole la lista de los
Generar Pedidos productos que desea comprar y el da en el que los recoger,
tambin se puede separar el pedido via web previo pago.
El generar contrato se refiere a cuando un cliente no quiere

Generar contrato
un producto estndar de nuestra panadera si no que quiere
un producto con cosas especiales, como tortas
personalizadas, de varios pisos, etc. Debe realizar el pago y
acercarse para generar el contrato.
Registrar Trabajador El supervisor Registrar al nuevo trabajador.
El Supervisor podr editar, actualizar y registrar un nuevo

Gestin de Pedidos
pedido.
El supervisor puede alterar las caractersticas de los

productos.
Ingresar Productos Registrar los productos recin llegados.
Comprados
Si por algn motivo el Embolsador encuentra desperfectos
Informe de Embolsador en los tems producidos por Maritza el almacenero debe
informarlo.
Informe Maestro Informe de la produccin de este periodo.
Registro de Orden Registra el informe maestro de la orden de produccin.
Produccin
Este caso se refiere al momento donde se tiene dar salidas
Salida Regular de Almacn de almacn por motivos de Merma, Ajuste de inventario,
Prstamo, Consumo interno y Regalo.
Este caso est relacionado a la creacin, modificacin y

Administrar Recetas de
activacin y desactivacin de una receta que fue creada para
Producto Terminado
un producto que es fabricado en la empresa y tambin poder
saber el costo de los insumos de forma total de la produccin
e individual.
5. Vista Lgica
5.1 Generalidades
En esta seccin se describe la parte significativa de la arquitectura del modelo de diseo. Los
aspectos relevantes incluyen: descomposicin del sistema en subsistema y paquetes. De
aplicarse algn estilo arquitectnico, se debe definir cul o cules estilos son y la estructura de
la vista lgica estar determinada por dichos estilos aplicables. Para las clases
arquitectnicamente importantes se deber describir sus operaciones, atributos y relaciones con
otras clases. La vista lgica se concentra en las funcionalidades que el sistema provee a los
usuarios finales, por lo que para representarla, se tendrn en cuenta el diagrama de clases, el
diagrama de secuencias y el diagrama de entidad-relacin que pretende visualizar las
distribuciones de los datos y sus relaciones, soportando as los dos diagramas anteriores.
5.2 Paquete de Diseo Arquitectnicamente Significativos
5.2.1 Capas
El software presenta 4 capas.
Capa de aplicacin
Capa de Negocio
Capa lgica
Capa de datos
6. Vista de Procesos
La vista de procesos es aquella donde muestra cmo es que se lleva a cabo cada uno de los
procesos. De esta manera y mediante la utilizacin de diagramas de actividad se logra
plasmar el flujo de cada una de las actividades que se realizan dentro del sistema.
DIAGRAMA DE ACTIVIDAD -VENDEDOR

DIAGRAMA DE ACTIVIDAD -ALMACENERO

DIAGRAMA DE ACTIVIDAD SUPERVISOR

7. Tamao y desempeo
Adems de los requerimientos no funcionales con los que debe cumplir el sistema web,
existen algunos otros como que el sistema debe ser escalable de forma horizontal para dar
garanta de escalabilidad y disponibilidad tanto a los usuarios como a los stakeholders. El
sistema debe responder en un tiempo no mximo a 6 segundos y dando una respuesta en
tiempo real al usuario, como se menciona en la seccin de requerimientos No Funcionales.
En cuanto a otras mtricas de desempeo es tambin importante que el sistema sea robusto
y que adems sea tolerante a fallos de manera que cualquier falla pueda ser corregida a la
mayor brevedad. Dado a esto, se identific y dise la arquitectura planteada durante todo
este documento.
8. Calidad
En esta seccin, se tendr en cuenta la contribucin que har la arquitectura durante el
desarrollo del sistema. A continuacin se mostrar las metas de calidad fijadas para
cumplir con los requerimientos no funcionales del sistema propuestos.
Factibilidad Operacional
Dentro de ese punto debemos considerar que los mismos usuarios del sistema actual
(trabajadores de la empresa), estn de acuerdo y motivados con el cambio, esto en un punto
positivo para nosotros, ya eso nos da a entender que la resistencia al cambio entre el sistema
actual y el sistema nuevo no debera a (nivel de usuario) tener mayores complicaciones.

Desempeo
Garantizar el desempeo del sistema a los diferentes usuarios.
El sistema debe estar en capacidad de dar respuesta en un tiempo aceptable.
Tiempo de Respuesta: se ansia obtener una respuesta con mayor fluidez posible cuando se
consultan los datos o se solicita algn registro de datos, respecto a las respuestas sern
considerados cada uno de ellos de acuerdo al rango de tiempo que se establece a
continuacin:
Medio: 3 a 5 segundos
Ideal: 0 a 2 segundos
Mximo: 6 a 60 segundos
Intolerable: ms de 60 segundos
Usabilidad
- La plataforma no puede ser accedida directamente, sino a travs de una interfaz
diseada para estos propsitos.

- Los mensajes de error deben ser reportados por la propia aplicacin en la medida de
las posibilidades y no por el sistema operativo. Los mensajes del sistema deben estar
en el idioma apropiado.
- Facilidad de aprendizaje: A medida que los usuarios usen el sistema se familiarizaran
y entendern mejor su manejo.
Flexibilidad
El sistema debe ser diseado y construido sobre la base de una construccin
parametrizable de manera que si existen nuevas funcionalidades o requerimientos
relacionados stos no afecten al sistema.
Escalabilidad
El sistema debe evitar el mantenimiento excesivo si es que existen nuevos
requerimientos, por esto los componentes que deben ser reutilizables y en efecto
incorporar nuevos cdigos o modificar sobre los ya existentes
Facilidad de uso
El sistema debe ser de fcil uso por parte de los usuarios.
El sistema debe presentar mensajes de error que permita al usuario identificar el tipo de
error y as comunicarse con el equipo de trabajo.
La estabilidad de la red debe de ir de la mano con el ingreso de datos y as tener
transacciones adecuadas.
Instalacin
El sistema tiene que ser fcil de instalar.
Mantenibilidad
Todo el sistema debe ser documentado tanto como los manuales de usuario y cdigos.
El sistema debe tener una interfaz para la administracin de usuarios, mdulos (de
ventas, reportes, otros).
El sistema debe permitir su fcil mantenimiento.
Operatividad
El sistema ser de fcil operacin por el dueo del Gimnasio.
Seguridad
La seguridad del sistema debe estar regida por las polticas de seguridad.
El acceso al sistema debe estar restringido por el uso de claves asignadas a cada usuario,
siendo los usuarios personas registradas que tendrn diferentes roles.
El sistema debe llevar un registro de las actividades de los usuarios que accedieron.
Validacin de informacin
El sistema debe validar la informacin en el formulario de ingreso.
El sistema debe contar con la obligacin de campos, la longitud de caracteres, manejo
de tipo de datos, etc.
Arquitectura
La solucin debe operar de manera independiente del navegador que se utilice.
La solucin debe tener interfaces grficas en idioma espaol.
Back-ups
El sistema debe proveer mecanismos para generar back-ups peridicamente siendo esto
responsabilidad del equipo de trabajo.
Historia de las Revisiones
Fecha Versin Descripcin Autor
27/04/2016 1.0 Creacin del
documento
01/05/2016 2.0 Modificacin del
documento

Ar Quite Ctu Rade Software

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Ar Quite Ctu Rade Software

Diunggah oleh

Hak Cipta:

Format Tersedia

SISTEMA-MARITZA

Arquitectura del Software (SRS)

Arquitectura de software -Maritza Fecha: 01/0452016

Arquitectura de software -Maritza Fecha: 01/0452016

Este documento provee informacin detallada de la arquitectura, necesaria para el

desarrollo y diseo de la aplicacin Web segn lo acordado en los requerimientos

especificados en el documento de SRS, el cual tiene como objetivo establecer las

necesidades de los actores y las diferentes vistas temticas que intervienen en la

administracin de la Panadera Maritza.

Se describe detalladamente la visin completa de la arquitectura del software, usando

diferentes vistas arquitectnicas: lgica, procesos, implementacin, distribucin y datos,

con la intencin de reflejar las decisiones arquitectnicas ms relevantes que se tomaron

para hacer la definicin del software.

El sistema gestin de panadera Maritza, mantenimiento de usuarios (Clientes,

administrador, cajero, proveedor), control de insumos, ingreso de pedidos, generar ticket

(boleta, factura) validacin de usuarios y entre otros.

1.3. Definiciones, Acrnimos y abreviaturas

ejecucin. Naturalmente este diseo arquitectnico ha de ajustarse a las necesidades y

requisitos del proyecto.

Lenguaje de programacin interpretado, diseado para la construccin de pginas web

Arquitectura de software -Maritza Fecha: 01/0452016

Define el comportamiento interno del software: clculos, detalles tcnicos, manipulacin

un sistema en lugar de sus comportamientos especficos.

Especificaciones de Casos de Uso

Especificacin de Requerimientos del Software

Arquitectura de software -Maritza Fecha: 01/0452016

de modelos arquitectnicos llamada 4+1 de Philippe Kruchten que se ilustra en la

El documento se ha estructurado empleando la representacin de la arquitectura de acuerdo

con la arquitectura de 4 + 1 vistas propuestas por IBM Rational.

descripcin y modelado de los requerimientos funcionales. Para este caso, se representarn

por medio de la especificacin de diagramas de clases y como soporte, con diagramas de

estos requerimientos. Adems, como complemento se mostrar el diagrama de entidad relacin

Arquitectura de software -Maritza Fecha: 01/0452016

Describe la descomposicin del sistema en hilos y procesos en tiempo de ejecucin.

Indica qu procesos o grupos de procesos se comunican o interactan entre s y los modos

secuencia y de entidad relacin.

as como la organizacin de estos en capas. Estos mdulos pueden ser mostrados en

componentes o subsistemas, y estos son organizados jerrquicamente en las capas

mencionadas. Toma en cuenta principalmente requerimientos internos relacionados con la

facilidad de desarrollo, la gestin del software, reutilizacin, y las restricciones impuestas

por la herramienta o el lenguaje de programacin. Para esta vista, se representar con el

Arquitectura de software -Maritza Fecha: 01/0452016

de uso y del diagrama de actividad.

en l, mostrando la ejecucin del software en el hardware. Se toma en cuenta

primordialmente los requerimientos no funcionales del sistema como la disponibilidad, la

confiabilidad, el desempeo y la escalabilidad, otros.

Se pueden distinguir 3 capas o niveles:

Interface del usuario (Nivel de presentacin).

Presenta el sistema al usuario. Captura y comunica la informacin al usuario. GUI

(Interfaz grfica de usuario) el cual es amigable, entendible y usable.

Procesador de aplicaciones o reglas del negocio (Nivel lgico).

Arquitectura de software -Maritza Fecha: 01/0452016

Se procesa la informacin y se envan las respuestas tras el proceso

Gestor de Base de Datos (Nivel de almacenamiento).

uno o ms DBMS: Definir y almacenar, consultar, manipular y controlar.

3. Metas y Restricciones Arquitectnicas

Se han identificado los requerimientos no funcionales y riesgos que impactan sobre la

arquitectura del sistema.

3.1. Requerimientos no funcionales

3.1 .1 Requisitos de rendimiento

El sistema ofrecer respuesta al usuario en tiempo real.

El sistema requerir de un usuario y contrasea vlidos para poder permitir el acceso.

ii. Requisito de divisin de mdulos:

Arquitectura de software -Maritza Fecha: 01/0452016