DAS+Plantilla
-
Upload
victor-alfonso-moran-gil -
Category
Education
-
view
268 -
download
1
Transcript of DAS+Plantilla
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 1 de 19
Nombre Del Proyecto Versión x.y.z
Documento de Arquitectura del Software
Nombre de Gerencia Solicitante
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 2 de 19
Historial de Revisiones
Versión Fecha Autor Descripción
<x.y.z> <dd/mm/aa> <nombre> <especificaciones>
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 3 de 19
Tabla de Contenido
1 INFORMACIÓN GENERAL.................................................................................................................................. 5
1.1. GERENCIAS SOLICITANTES .............................................................................................................................. 5
1.2. CÓDIGO DEL PROYECTO .................................................................................................................................. 5
1.3. NOMBRE DEL PROYECTO ................................................................................................................................. 5
1.4. BENEFICIARIOS ................................................................................................................................................ 5
2. INTRODUCCIÓN .................................................................................................................................................... 6
2.1. PROPÓSITO ....................................................................................................................................................... 6
2.2. ALCANCE .......................................................................................................................................................... 7
2.3. DEFINICIONES, ACRÓNIMO Y ABREVIATURA .................................................................................................. 7
2.4. ESTÁNDARES APLICADOS ................................................................................................................................ 7
2.5. DOCUMENTOS RELACIONADOS ....................................................................................................................... 8
3. RESUMEN ARQUITECTÓNICO .......................................................................................................................... 9
3.1. ESTILO ARQUITECTÓNICO ............................................................................................................................... 9
3.2. OBJETIVO DE LA ARQUITECTURA SELECCIONADA ......................................................................................... 9
4. COMPONENTES SIGNIFICATIVO DE LA ARQUITECTURA DEL SISTEMA ........................................ 11
4.1. PRESENTACIÓN/COMPONENTES DE LA INTERFAZ DE USUARIO ................................................................... 11
4.2. COMPONENTES LÓGICOS DE LA APLICACIÓN ............................................................................................... 11
4.3. COMPONENTES DE ALMACENAMIENTO DE DATO ......................................................................................... 11
5. VISTAS DE CASO DE USO ................................................................................................................................. 12
5.1. MODELADO DE CASO DE USO ........................................................................................................................ 12
6. VISTA LÓGICA ..................................................................................................................................................... 13
6.1. DIAGRAMA DE PAQUETE ................................................................................................................................ 13
6.2. PAQUETES DE DISEÑO SIGNIFICATIVOS ARQUITECTÓNICAMENTE .............................................................. 13
6.3. DIAGRAMA DE CLASES AGRUPADO POR PAQUETE ........................................................................................ 13
6.4. DIAGRAMA WAE (EXTENSIÓN PARA APLICACIONES WEB )....................................................................... 14
6.5. REALIZACIÓN DE LOS CASOS DE USO ............................................................................................................ 14
7. VISTA DE IMPLEMENTACIÓN ........................................................................................................................ 15
7.1. DIAGRAMA DE COMPONENTES DEL SISTEMA ............................................................................................... 15
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 4 de 19
8. VISTA DE DESPLIEGUE ..................................................................................................................................... 16
8.1. DIAGRAMA DE DESPLIEGUE DEL SISTEMA. ................................................................................................... 16
9. MODELO DE DATOS ........................................................................................................................................... 17
9.1. DIAGRAMA DE ENTIDAD-RELACIÓN (“ER”) DE LA BASE DE DATOS ........................................................... 17
9.2. DICCIONARIO DE DATOS ................................................................................................................................ 17
10. VISTA DE PROCESO ........................................................................................................................................... 18
10.1. DIAGRAMA DE ACTIVIDADES ......................................................................................................................... 18
11. ASEGURAMIENTO DE LA CALIDAD ............................................................................................................. 19
11.1. OBJETIVOS DE CALIDAD ................................................................................................................................ 19
11.1.1. Esenciales ............................................................................................................................................. 19
11.1.2. Esperados .............................................................................................................................................. 19
11.1.3. Deseados ............................................................................................................................................... 19
11.1.4. Operatividad .......................................................................................................................................... 19
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 5 de 19
Documento de Arquitectura del Software
1 Información General
1.1. Gerencias Solicitantes
Nombre de la gerencia Solicitante
1.2. Código del Proyecto
Colocar el código del proyecto si este posee
1.3. Nombre del Proyecto
Colocar el nombre del sistema propuesto
1.4. Beneficiarios
Colocar, quienes se Benefician con la elaboración del sistema
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 6 de 19
2. Introducción
La visualización, especificación, construcción y documentación de un sistema debe
realizarse desde varias perspectivas (usuario, analista, desarrollador, entre otras) cada una de
ellas presenta el sistema de forma diferente en diversos momentos a lo largo del proyecto, es
por ello que se plantea en este documento describir el sistema a través de cinco vistas
interrelacionadas (Vista Caso de Uso, Vista Lógica, Vista de Implementación, Vista de
Despliegue y Vista de Proceso).
La arquitectura de software no tiene que ver solamente con la estructura y el
comportamiento, sino también con el uso, la funcionalidad, el rendimiento, la capacidad de
adaptación, la reutilización, la capacidad de ser comprendido y las restricciones tecnológicas,
así como los aspectos estéticos de la aplicación.
Por lo tanto este documento será usado con el propósito de tener una visualización general de
la arquitectura del sistema [“Nombre del sistema. Ejemplo: Sistema de Control de vocales
ABC”], Elaborara con los requisito recogido de los usuario potenciales y comunes de la
[“Nombre de ls gerencia solicitante. Ejemplo: ULA (Universidad de literatura abierta)”]para la
representación gráfica de los mismo, con el fin de realizar un sistema seguro y evolutivo.
2.1. Propósito
El propósito fundamental de este documento consiste en describir textual y gráficamente
la arquitectura del sistema, indicando:
Estilo Arquitectónico y su propósito (objetivo).
Componentes de la arquitectura.
Vista de caso de usos
Vista lógica del sistema (Organización del software en clases, paquetes y
realización de los casos de uso).
Representación de los componentes arquitectónicos.
Distribución de los componentes arquitectónicos a través de los nodos de la
plataforma de operación (Diagrama de Despliegue).
Representación del modelo de datos a través del diagrama Entidad-Relación y el
diccionario de datos.
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 7 de 19
2.2. Alcance
El Sistema de [“Nombre del sistema. Ejemplo: Sistema de Control de vocales ABC”]
provee una interfaz Web fácil de entender y utilizar, con ayudas que facilitan la enseñanza y
aprendizaje del usuario final, soportando una cantidad concurrente de usuarios, permitirá
desarrollar y mantener un control o gestión administrativos realizados por la [“Nombre de
las gerencias solicitantes. Ejemplo: ULA (Universidad de literatura abierta)”] para poder
mejorar dichos procesos administrativos, establece privilegios de acceso diferenciados
dependiendo del tipo de usuario y rol que desempeña dentro de la aplicación, cuenta con
herramientas como [“Describir herramientas o módulo del sistema mas importate (La esencia
del problema a solucionar)”]para el manejo de las mismas, se garantiza un histórico
permanente de cada una de las operaciones manteniendo todos los cambios de estado que se
ejecuten, además de generar reportes y estadísticas parametrizables y dinámicas.
Este documento representa la descripción textual y gráfica de la arquitectura del
sistema, desglosando o descomponiendo solo aquellos componentes, sub-sistemas y procesos
abarcados por las funcionalidades descritas en los términos de referencia refinados de este
proyecto.
2.3. Definiciones, Acrónimo y Abreviatura
Todas las definiciones, acrónimos y abreviaturas necesarias para entender este
documento están especificadas enel Glosario de termino del Sistema.
Términos Descripción
UML Lenguaje unificado de modelado
PHP Lenguaje de programación abierto orientado al
Web
MYSQL Manejador de base de datos abierto.
ER Entidad Relación
2.4. Estándares Aplicados
A continuación se listan los estándares que deben ser aplicados al desarrollar este documento:
UML 2.0
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 8 de 19
Estándar de Codificación del CNTI
Herramienta de modelado [“StarUML, DIa, ETC”]
2.5. Documentos Relacionados
Título Fecha Organización Identificador del
documento
<título> <dd/mm/aa> <nombre> <Id documento>
Glosario_termino_ABC.
ODT
07/07/07 ULA (Universidad de literatura abierta)
ERS_ABC.ODT 07/07/07 ULA (Universidad de
literatura abierta)
Plan_desarrollo_del_Soft
ware.ODT
07/07/07 ULA (Universidad de literatura abierta)
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 9 de 19
3. Resumen Arquitectónico
En esta sección se presenta en función del Modelo de Caso de Uso la Arquitectura del Sistema.
Este es el resultado de ensamblar un cierto número de elementos arquitectónicos de forma adecuada
para satisfacer la mayor funcionalidad y requerimientos de desempeño, así como requerimientos no
funcionales, como la confiabilidad, mantenibilidad, escalabilidad, usabilidad, portabilidad y
disponibilidad.
3.1. Estilo Arquitectónico
En este apartado se debe responder la siguiente pregunta:
¿Qué estilo de arquitectura de software está siendo usado?
Algunos ejemplos de estilos son:
Aplicación de escritorio para proceso simple (con módulos de extensión de
plugins).
Cliente-servidor
Aplicación Web de 2-puertos: servidor Web/servidor de aplicaciones, base de datos.
Aplicación Web de 3-puertos: servidor Web/servidor de aplicaciones, base de datos.
Servicio Web simple: servidor de aplicaciones, base de datos.
Servicios de Red o Web.
Cliente-a-cliente sin servidor central.
Con tuberías y filtros.
Ejemplo:
Para el desarrollo de [“Nombre del sistema. Ejemplo: Sistema de Control de vocales ABC”]
planteamos un patrón de arquitectura de software denominado MVC, el cual separa los datos de la
aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón
MVC se ve frecuentemente en aplicaciones Web, ya que posee una solución de solidez probada,
donde la vista es la página y el código que provee de datos dinámicos a la página, el modelo es el
[“Nombre del sistema. Ejemplo: Sistema de Control de vocales ABC”] y el controlador representa la
Lógica de Control. El elemento de Programación utilizado es Orientada a Objetos.
3.2. Objetivo de la Arquitectura Seleccionada
3.2.1. Alta Disponibilidad
El sistema debe estar disponible 24x7x365 con un mínimo de mantenimiento.
3.2.2. Bajo Acoplamiento (Opcional)
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 10 de 19
Arquitectura que permite el cambio de componentes en cualquier punto del ciclo de
vida de la aplicación sin afectar el funcionamiento de las demás partes involucradas.
3.2.3. Seguridad
Listar las medidas de seguridad que brinda la arquitectura y como la usa el sistema
propuesto.
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 11 de 19
4. Componentes Significativo de la Arquitectura del Sistema
Los componentes de este sistema deben estar definidos claramente en los diagramas de
componentes hechos con UML. Describa brevemente cada componente del sistema que sea
relevante para la arquitectura del sistema. Enfóquese en los detalles arquitectónicos tales
como mecanismos de comunicación, aspectos del entorno que afecten el desarrollo, y
concurrencia. Observe los aspectos claves de cada interfaz, pero evite duplicar los detalles
de las interfaces que se especifican en los diagramas de clase de UML u otros documentos.
Los componentes de este sistema se encuentran listados abajo por tipo:
Nota: Se pueden agregar más componentes si la arquitectura así lo pides…
Ojo Quitar esta nota!.
4.1. Presentación/Componentes de la Interfaz de Usuario
C-00: NOMBRE DEL COMPONENTE
Descripción: Descripción
Requerimientos: Sistema operativo, RAM, etc.
Interfaces Disponibles: Describa brevemente las interfaces
4.2. Componentes Lógicos de la Aplicación
C-10: NOMBRE DEL COMPONENTE
Descripción: Descripción
Requerimientos: Sistema operativo, RAM, etc.
Interfaces Disponibles: Describa brevemente las interfaces
4.3. Componentes de Almacenamiento de Datos
C-20: NOMBRE DEL COMPONENTE
Descripción: Descripción
Requerimientos: Sistema operativo, RAM, etc.
Interfaces Disponibles: Describa brevemente las interfaces
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 12 de 19
5. Vistas de Caso de Uso
La vista de caso de uso comprende los casos de uso que describen el comportamiento del
sistema tal y como es percibido por los usuarios finales, analistas y encargados de las pruebas.
Ésta vista no especifica realmente la organización de un sistema, sólo permite a través de las
funcionalidades definir la arquitectura que soportará el sistema.
5.1. Modelado de Caso de Uso
Un diagrama de caso de uso muestra las distintas operaciones que se espera de una
aplicación o sistema y cómo se relacionan con su entorno (usuarios u otras aplicaciones). Es
muy importante para los analistas y arquitectos del sistema, permite definir el contexto del
desarrollo del software. De acuerdo a la metodología del CNTI, este diagrama debe
corresponder con los casos de uso identificados y validados luego de verificar efectivamente
los casos de uso planteados en el documento inicial de Especificación de Requerimientos
del Sistema (ERS).
A continuación el Modelado de Caso de Uso.
5.1.1. Diagrama General
Loguin
Control de
Vocales
Salir
Sistema
Figura N° 1 Caso de Uso Genral del Sistema Control de Vocales
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 13 de 19
6. Vista Lógica
En esta vista se detallan las partes del modelo de diseño del sistema que son significativas
arquitectónicamente representando los diagramas que permiten tener una visión de los elementos
que conforman el sistema y de la interacción entre ellos. En esta vista se detalla la
descomposición de los sistemas en subsistemas y paquetes; y para cada paquete se presentan sus
clases.
6.1. Diagrama de Paquete
A continuación se muestra el diagrama de paquetes:Diagrama de Paquetes General
Incluir Diagrama de paquete
6.2. Paquetes de Diseño significativos Arquitectónicamente
En esta sección se muestran los paquetes anteriormente representados (Diagrama de Paquetes) y una breve descripción de los mismos y las clases que contiene.
P-01: NOMBRE DEL PAQUETE <Paquete de Páginas Dinámicas>
Descripción:
Este paquete contiene todas las clases que se encargan de la Gestión de las Paginas Dinámicas de la Aplicación ABC. Todas las Clases del Paquete Interfaz y Presentación, que corresponden a la Vista de MVC .La capa vista de PHP es cómo se les habla a los usuarios de ABC.Los
ficheros de vista se almacenan en [Direccion], en una carpeta
nombrada tras el controlador que usa los ficheros, y nombrada tras la acción a la que corresponde.
Clases Disponibles:
Todas las Asociadas a la Vista del Modelo MVC, epecificadas por defecto por Cake Php como:
Controla Vocal.Class DefinirLetra.Class etc
Casos de Uso que lo derivan:
Este paquete es importante porque proporciona las clases que se derivan de los Casos de Usos Gestión de Usuarios, Gestión de Vocale y Gestión de ABCDARIO.
6.3. Diagrama de Clases agrupado por paquete
Incluir diagrama de clase Agrupado por paquete
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 14 de 19
6.4. Diagrama WAE (Extensión para Aplicaciones WEB )
Esta extensión de UML para Web define un conjunto de estereotipos, etiquetas y
restricciones que nos permiten modelar aplicaciones Web. Estos estereotipos y restricciones
son aplicadas a ciertos componentes que son en particulares para las aplicaciones web y nos
permiten representarlos en los mismos modelos y diagramas que el resto del sistema.
A continuación se muestra el diagrama WAE:
6.5. Realización de los Casos de Uso
Se debe ilustrar cómo normalmente el software opera, presentando algunos casos de
uso escogidos, y expone cómo los distintos elementos del modelo de diseño sobrellevan a su
funcionalidad.
Incluir diagrama de Secuencia
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 15 de 19
7. Vista de Implementación
La vista de implementación muestra el empaquetado físico de las partes reutilizables del
sistema en unidades sustituibles, llamadas componentes. Una vista de implementación muestra
los elementos físicos del sistema mediante componentes, así como sus interfaces y dependencias
entre componentes. Los componentes son piezas reutilizables de alto nivel a partir de las cuales
se pueden construir los sistemas.
En esta vista se debe mostrar en general las dependencias y cómo se implementan los
componentes físicos del sistema, agrupándolos en subsistemas organizados en capas y
jerarquías.
7.1. Diagrama de Componentes del Sistema
El diagrama de componentes describe la descomposición física del sistema en
componentes, a efectos de construcción y funcionamiento. La descomposición del diagrama
de componentes se realiza en términos de componentes y de relaciones entre los mismos.
Los componentes identifican objetos físicos que hay en tiempos de ejecución, de
compilación o de desarrollo, y tienen identidad propia y una interfaz bien definida. Cada
componente incorpora la implementación de ciertas clases del diseño del sistema.
En un diagrama de componentes se muestran las diferentes relaciones de dependencia
que se pueden establecer entre componentes. Los componentes bien diseñados no dependen
de otros componentes sino de las interfaces que ofrecen los componentes. En ese caso, un
componente en un sistema puede ser sustituido por otro componente que ofrezca las
interfaces apropiadas.
A continuación se muestra elDiagrama de Componentes:
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 16 de 19
8. Vista de Despliegue
La vista de despliegue muestra la disposición física de los recursos de ejecución
computacionales, tales como computadores y sus interconexiones.
La vista de despliegue puede mostrar cuellos de botella para el rendimiento si las
instancias de los componentes con dependencia se ponen en distintos nodos.
8.1. Diagrama de Despliegue del Sistema.
El diagrama de despliegue permite mostrar la arquitectura en tiempo de ejecución del
sistema respecto al hardware y software. Los nodos representan los objetos físicos
existentes en tiempo de ejecución, sirven para modelar recursos que tienen memoria y
capacidad de proceso, y pueden ser computadores, dispositivos o personas. Los
componentes participan en los procesos mediante los nodos.
A continuación se muestra el Diagrama de Despliegue:
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 17 de 19
9. Modelo de Datos
El Modelo de datos es aquel que describe de forma abstracta cómo se representan los datos
de un sistema. Un modelo de datos consiste en: entidades, atributos y sus relaciones.
9.1. Diagrama de Entidad-Relación (“ER”) de la Base de Datos
El modelado de datos es realizado a través de un modelo entidad-relación. Estos
modelos permiten expresar entidades relevantes para un sistema de información, sus inter-
relaciones y propiedades.
A continuación se muestra el Modelo Entidad-Relación:
9.2. Diccionario de Datos
A continuación se encuentra el Diccionario de datos de la base de datosde [“Nombre del
sistema. Ejemplo: Sistema de Control de vocales ABC”]
DESCRIPCIÓN:
TABLE:
Campos
Nombre Tipo No nulo Único P/K
Índices:
IndiceNombre En Campo Único Full Text
Documento de Arquitectura del Software: Versión:x.y.z
Elaborado por:
Revisado por: Evalado por: Aprobado por:
Dirección:
Teléfono:
Sitio Web:
Pág. 18 de 19
10. Vista de Proceso
Cubre el funcionamiento, capacidad de crecimiento y rendimiento del sistema. Mecanismos de
sincronización y concurrencia del sistema: hilos y procesos. Esta vista puede representarse con los
diagramas de estado y actividades.
En UML un diagrama de actividades se usa para mostrar la secuencia de actividades. Los
diagramas de actividades muestran el flujo de trabajo desde el punto de inicio hasta el punto final
detallando muchas de las rutas de decisiones que existen en el progreso de eventos contenidos en la
actividad. Estos también pueden usarse para detallar situaciones donde el proceso paralelo puede
ocurrir en la ejecución de algunas actividades.Los Diagramas de Actividades son útiles para el
Modelado de Negocios donde se usan para detallar el proceso involucrado en las actividades de
negocio.
10.1. Diagrama de Actividades
Incluir Diagrama de Actividad.
Documento de Arquitectura del Software: Versión<x.y.z> Fecha:
Elaborado por: Revisado por: Aprobado por:
Página 19 de 19
11. Aseguramiento de la Calidad
11.1. Objetivos de Calidad
Añada los objetivos para ajustarlos a su proyecto. Agrúpelos por prioridades de acuerdo
a los lineamientos de su proyecto.
1. Esenciales
Funcionalidad > Corrección
Funcionalidad > Robustez
1.1.1. Esperados
Funcionalidad > Exactitud
Funcionalidad > Compatibilidad
Funcionalidad > Corrección medible
Usabilidad > Comprensibilidad y Legibilidad
Usabilidad > Apoyo para tareas
Usabilidad > Eficiencia
Usabilidad > Seguridad
Usabilidad > Consistencia y Familiaridad
Usabilidad > Satisfacción Subjetiva
1.1.2. Deseados
Confiabilidad > Consistencia en carga
Confiabilidad > Consistencia bajo concurrencia
Confiabilidad > Disponibilidad bajo carga
Confiabilidad > Longevidad
Eficiencia
Escalabilidad
Escalabilidad > Desempeño bajo carga
Escalabilidad > Grandes volúmenes de datos
1.1.3. Operatividad
Capacidad de mantenimiento > Comprensibilidad
Capacidad de mantenimiento > Capacidad de evolución
Capacidad de mantenimiento > Capacidad de prueba