2.1. Metas y Restricciones de la Arquitectura

Instituto Nacional
de Tecnologías
de la Comunicación
DISEÑO DE ALTO NIVEL
Departamento/Proyecto/ Subtítulo
Mes 2008
Instituto Nacional
de Tecnologías
de la Comunicación
HISTÓRICO DE CAMBIOS
Fecha
Versión
Descripción
Autor
Departamento/Proyecto/ Subtítulo
2
Instituto Nacional
de Tecnologías
de la Comunicación
Departamento/Proyecto/ Subtítulo
3
Instituto Nacional
de Tecnologías
de la Comunicación
ÍNDICE
1.
2.
3.
VISIÓN GENERAL DEL PROYECTO
6
1.1.
Introducción
6
1.2.
Propósito
6
1.3.
Alcance
6
1.4.
Definiciones y Abreviaturas
6
1.5.
Listado de Referencias
6
1.6.
Notación
6
REPRESENTACIÓN DE LA ARQUITECTURA
7
2.1.
Metas y Restricciones de la Arquitectura
7
2.2.
Desarrollar diseños alternativos de la arquitectura
7
2.2.1.
Solución A
7
2.2.2.
Solución B
7
2.3.
Requisitos y Visión de la Arquitectura
7
2.4.
Conformidad con Estándares Abiertos
7
2.5.
Soluciones Específicas de Vendedores
8
2.6.
Reutilización
8
2.7.
Componentes y frameworks reutilizados por el proyecto
8
2.8.
Mecanismos para la Evaluación de Componentes Reutilizables
8
2.9.
Componentes y Frameworks Reutilizables
8
VISTA DE CASOS DE USO
10
3.1.
10
Comprensión de los Casos de Uso
4.
VISTA LÓGICA
11
5.
VISTA DE INTERACCIÓN
12
5.1.
Interfaces de Usuario
12
5.2.
Interfaces Software
12
5.3.
Interfaces hardware
12
6.
VISTA DE SEGURIDAD
13
7.
VISTA DEL PROCESO
14
Departamento/Proyecto/ Subtítulo
4
Instituto Nacional
de Tecnologías
de la Comunicación
8.
VISTA DEL DESPLIEGUE
15
9.
VISTA DE IMPLEMENTACIÓN
16
9.1.
Vista General de las Capas
16
9.2.
Paquetes/Componentes
16
9.3.
Interfaz
16
9.4.
Criterios para la interfaz
16
10.
VISTA DE DATOS
17
11.
VISTA DE ADMINISTRACIÓN
18
12.
CARACTERÍSTICAS GENERALES DE CALIDAD
19
12.1.
Fiabilidad
19
12.2.
Usabilidad
19
12.3.
Portabilidad, mantenibilidad
19
12.4.
Rendimiento
19
12.5.
Seguridad
19
12.6.
Capacidad de Prueba
19
12.7.
Disponibilidad y Escalabilidad
19
Departamento/Proyecto/ Subtítulo
5
Instituto Nacional
de Tecnologías
de la Comunicación
1.
VISIÓN GENERAL DEL PROYECTO
1.1.
INTRODUCCIÓN
La introducción proporciona una visión general que incluye los propósitos, definiciones,
acrónimos, abreviaturas, referencias…
1.2.
PROPÓSITO
Esta sección define el rol o propósito del documento, y describe brevemente la estructura
del documento. Se identifican las audiencias específicas para el documento con una
descripción de cómo se espera que se usen.
1.3.
ALCANCE
Se describe el alcance general del esfuerzo del diseño. Mucha información se obtiene del
documento de especificación de requisitos software e incluye los objetivos del sistema y los
requerimientos principales del software, restricciones y limitaciones del diseño.
1.4.
DEFINICIONES Y ABREVIATURAS
Se describe cualquier término, acrónimo y abreviatura requerido para entender este
documento.
1.5.
LISTADO DE REFERENCIAS
Proporcionar una lista completa de documentos a los que se hace referencia en el diseño de
alto nivel. Se pueden incluir tanto documentos internos como proporcionados por el cliente.
Por ejemplo:
-
1.6.
Plan de gestión del proyecto
Especificación de requisitos
Informes de investigación
NOTACIÓN
Describe el tipo de notación para los diagramas que se ha utilizado para representar las
vistas de la arquitectura. Se recomienda el uso del lenguaje de modelado unificado (UML).
Si no se utiliza UML, entonces se debe proporcionar una leyenda detallada en esta sección
para todos los símbolos y semántica utilizada.
Departamento/Proyecto/ Subtítulo
6
Instituto Nacional
de Tecnologías
de la Comunicación
2.
REPRESENTACIÓN DE LA ARQUITECTURA
Describa de forma genérica la arquitectura del software para el sistema.
2.1.
METAS Y RESTRICCIONES DE LA ARQUITECTURA
Describir los requerimientos y objetivos del software que tienen un impacto significativo
sobre la arquitectura; por ejemplo, seguridad, privacidad, portabilidad, distribución,
rendimiento, escalabilidad, reutilización. Esta sección debería también capturar restricciones
especiales que se debieran aplicar: estrategias de diseño e implementación, herramientas
de desarrollo, estructura del equipo, planificación, etc.
2.2.
DESARROLLAR
ARQUITECTURA
DISEÑOS
ALTERNATIVOS
DE
LA
Desarrollar otros diseños que puedan satisfacer los requisitos del cliente y puedan obtener
buen rendimiento, seguridad, privacidad, portabilidad, distribución, escalabilidad,
reutilización y una tasa baja de errores en el desarrollo de la aplicación.
Se debe crear una nueva sección para cada solución alternativa desarrollada y proporcionar
la suficiente información para ser capaz de aplicar criterios de selección para elegir la más
apropiada. Este proceso debe estar documentado y se deben incluir los componentes del
producto desarrollados, comprados o reutilizados según criterios establecidos. Si aplica, se
debe proporcionar un enlace a las recomendaciones de los documentos de análisis y
resolución de decisiones (DAR) utilizados para identificar la solución.
2.2.1.
2.2.2.
2.3.
Solución A
Solución B
REQUISITOS Y VISIÓN DE LA ARQUITECTURA
Se debe representar una visión de por qué se ha escogido una arquitectura en particular y
cómo se alinea con los requisitos del software especificados además de cumplir con la
estrategia y metas corporativas. Esta visión debe explicar cómo la arquitectura permite
futuras integraciones con otras aplicaciones y cómo se adapta a posibles cambios en la
tecnología.
2.4.
CONFORMIDAD CON ESTÁNDARES ABIERTOS
Listado de todos los estándares abiertos y los números de las versiones que la arquitectura
cumple.
Departamento/Proyecto/ Subtítulo
7
Instituto Nacional
de Tecnologías
de la Comunicación
2.5.
SOLUCIONES ESPECÍFICAS DE VENDEDORES
Listado de vendedores específicos, protocolos propietarios y APIs utilizados en esta
arquitectura.
2.6.
REUTILIZACIÓN
Si se utiliza programación orientada a objetos (OO), se debe proporcionar una ligera visión
de cómo puede beneficiar al proyecto la incorporación de componentes reutilizables,
frameworks y patrones de diseño. Identificar las áreas funcionales o componentes de
negocio para los que la reutilización de componentes debe ser utilizada o adquirida.
Identificar el lugar donde se deben aplicar los patrones de diseño. A la hora de reutilizar un
componente se deben analizar aquellos que mejor se adapten a nuestras necesidades y que
estarán en muchos casos en la base de datos del histórico de nuestra organización.
2.7.
COMPONENTES Y FRAMEWORKS REUTILIZADOS POR EL
PROYECTO
Listado de los componentes del producto y frameworks a ser reutilizados por el proyecto
incluyendo el nombre de vendedor y nombre del producto. Detallar cualquier beneficio
tangible o intangible para el proyecto causado por la reutilización de los componentes y
frameworks.
Framework
componente
reutilizable
Nombre y versión
2.8.
o Proveedor
Lista
beneficios
de Repositorio donde se
ubican
Vendedor,
otro Beneficios para el URL donde encontrar
proyecto,
código proyecto.
información sobre los
abierto, etc.
componentes/frameworks
a reutilizar.
MECANISMOS PARA LA EVALUACIÓN DE COMPONENTES
REUTILIZABLES
Describir el mecanismo de evaluación para los componentes reutilizables existentes.
2.9.
COMPONENTES Y FRAMEWORKS REUTILIZABLES
Identificar los componentes del negocio funcionales que son candidatos para la
generalización. Proporcionar detalles (ej: JAVADOC, modelo UML, etc) sobre esos
componentes y resumir las tareas requeridas para generalizarlos y que pueden ser
Departamento/Proyecto/ Subtítulo
8
Instituto Nacional
de Tecnologías
de la Comunicación
reutilizados. Indicar la razón para crear un componente nuevo y la librería de componentes
que lo contiene.
Componentes
candidatos
Función de negocio Generalización
o
servicio
que
presta
Localización
Nombre
Nombre
identificación
URL
donde
encontrar
información sobre el
componente
existente.
y/o Vistazo general de
las extensiones que
se necesitan para
activar
la
reutilización general
y el modelo del
componente actual.
Departamento/Proyecto/ Subtítulo
9
Instituto Nacional
de Tecnologías
de la Comunicación
3.
VISTA DE CASOS DE USO
Listar aquellos casos de uso o escenarios procedentes del modelo de casos de uso (creado
como parte de la especificación de requisitos del sistema) que representan una
funcionalidad significativa o principal del sistema final, o bien aquellos que cubren gran parte
de la arquitectura. Incluir los casos de uso que utilizan elementos de la arquitectura o bien si
sobrecargan o muestran un punto delicado de la arquitectura. La lista de casos de uso debe
ser considerada para una arquitectura ejecutable. La notación preferida para la vista de los
casos de uso es UML.
3.1.
COMPRENSIÓN DE LOS CASOS DE USO
Mostrar cómo funciona el software para un determinado caso de uso (o escenario). Explicar
cómo se configura la arquitectura para que permita que los casos de uso se cumplan.
Departamento/Proyecto/ Subtítulo
10
Instituto Nacional
de Tecnologías
de la Comunicación
4.
VISTA LÓGICA
Describe la descomposición funcional de la aplicación basándose en una ordenación lógica
de los requisitos de la aplicación. Los aspectos de la aplicación con una funcionalidad similar
se deben agrupar en un subsistema. Se deben representar las dependencias entre los
subsistemas.
Si se incluye desarrollo orientado a objetos (OO), entonces se deben describir las partes
significativas de la arquitectura del modelo de diseño, como su descomposición en
subsistemas y paquetes. Para cada paquete significativo, mostrar su descomposición en
clases o interfaces. Presentar las clases significativas de la arquitectura y describir sus
responsabilidades, así como las relaciones importantes basadas en la arquitectura,
operaciones y atributos. La notación preferida para la vista lógica es UML.
Departamento/Proyecto/ Subtítulo
11
Instituto Nacional
de Tecnologías
de la Comunicación
5.
VISTA DE INTERACCIÓN
5.1.
INTERFACES DE USUARIO
5.2.
INTERFACES SOFTWARE
5.3.
INTERFACES HARDWARE
Departamento/Proyecto/ Subtítulo
12
Instituto Nacional
de Tecnologías
de la Comunicación
6.
VISTA DE SEGURIDAD
Departamento/Proyecto/ Subtítulo
13
Instituto Nacional
de Tecnologías
de la Comunicación
7.
VISTA DEL PROCESO
Describir la descomposición del sistema en procesos más ligeros (hilos individuales de
control) y procesos más pesados (grupos de procesos ligeros). Organizar la sección por
grupos de procesos de negocio que se comunican o interactúan.
Si se incluye el desarrollo orientado a objetos (OO), entonces se debe representar la
información solicitada utilizando diagramas de secuencia específicos del proyecto
(diagramas de interacción de objetos), preferiblemente utilizando la notación UML. Donde
sea posible, los diagramas explican el proceso de interacción requerido por los casos de uso
principales.
Departamento/Proyecto/ Subtítulo
14
Instituto Nacional
de Tecnologías
de la Comunicación
8.
VISTA DEL DESPLIEGUE
Describir la configuración de la plataforma física (procesador/almacenamiento) en la que el
software va a ser desplegado. Si el sistema se va a desplegar en varios sitios, proporcionar
una vista de despliegue para cada sitio diferente. Como mínimo, para cada configuración, se
deben indicar los nodos físicos (ej: ordenadores, CPUs, memorias) que ejecutan el software
y sus interconexiones (ej: bus, topología LAN, punto a punto, WAN).
Incluir un mapeo entre los procesos de la vista de proceso y los nodos físicos. La notación
preferida es UML para la vista de despliegue.
Departamento/Proyecto/ Subtítulo
15
Instituto Nacional
de Tecnologías
de la Comunicación
9.
VISTA DE IMPLEMENTACIÓN
Describe la estructura general del modelo de implementación y la descomposición del
sistema en capas y subsistemas como vimos en la perspectiva de desarrollo del software.
Indicar cómo se ensamblarán los subsistemas a medida que aumenta el progreso de
implementación del proyecto. Esta sección también proporciona una vista de los paquetes/
componentes que guía en el desarrollo del software y el ensamblado del sistema de acuerdo
al plan de proyecto.
9.1.
VISTA GENERAL DE LAS CAPAS
Nombrar y definir las distintas capas y su contenido, las reglas que gobiernan una
determinada capa, y los límites entre las mismas. Incluir un diagrama de componentes que
muestre la relación entre las capas.
9.2.
PAQUETES/COMPONENTES
Describir el modo principal de comunicación entre los procesos del sistema operativo, como
el paso de mensajes, interrupciones, colas y protocolos. Indicar cómo se gestiona la
concurrencia y la sincronización. Indicar cómo se optimizará el rendimiento (ej: qué
parámetros se deben modificar para que impacten en las operaciones (procesos/hilos)).
Si se incluye el desarrollo orientado a objetos, entonces, para cada implementación de un
paquete/componente, incluir una subsección con su nombre, descripción y diagrama.
9.3.
INTERFAZ
El diseñador identifica las interfaces internas principales y todas las interfaces externas del
sistema/software. Describa de forma breve la especificación de las interfaces de los
componentes, la descripción de los componentes que forman las interfaces y las guías que
se han seguido. Hacer referencia a guías de diseño de interfaces.
9.4.
CRITERIOS PARA LA INTERFAZ
Identificar los criterios de la interfaz de los componentes, funciones o aplicaciones.
Departamento/Proyecto/ Subtítulo
16
Instituto Nacional
de Tecnologías
de la Comunicación
10. VISTA DE DATOS
Describir el modelo lógico de los datos.
Departamento/Proyecto/ Subtítulo
17
Instituto Nacional
de Tecnologías
de la Comunicación
11. VISTA DE ADMINISTRACIÓN
Departamento/Proyecto/ Subtítulo
18
Instituto Nacional
de Tecnologías
de la Comunicación
12. CARACTERÍSTICAS GENERALES DE CALIDAD
12.1.
FIABILIDAD
Describir las características/elementos de diseño relativos a la fiabilidad. Ej: Medidas para
asegurar una buena operatividad, mejorar la tasa de errores/tiempo, etc.
12.2.
USABILIDAD
Describir los elementos de usabilidad del diseño que añadan facilidades y funciones
estándar. Ej: Estándares GUI, tolerancia a errores del operador, etc.
12.3.
PORTABILIDAD, MANTENIBILIDAD
Describir los elementos de portabilidad y mantenibilidad del diseño que añaden
independencia al sistema operativo y al hardware, permiten la planificación de la frecuencia
de mantenimiento y duración, modularidad del diseño, etc.
12.4.
RENDIMIENTO
Describir los elementos del diseño que impactan en las características de rendimiento. Ej:
medidas para mejorar la potencia de la CPU, tasa de transacciones a disco, etc.
12.5.
SEGURIDAD
Describir las medidas de diseño tomadas para mejorar e incorporar los requisitos de
seguridad. Ej: Protección de datos y control de acceso, controles de seguridad relativos a
políticas de sistemas, etc.
12.6.
CAPACIDAD DE PRUEBA
Describir las medidas de diseño identificadas que mejoren la capacidad de prueba del
sistema.
12.7.
DISPONIBILIDAD Y ESCALABILIDAD
Describir el “clustering”, la tolerancia a los fallos y los mecanismos de redundancia utilizados
para alcanzar la disponibilidad y escalabilidad necesarios en el sistema. Se incluyen
concesiones entre el rendimiento y la escalabilidad.
Departamento/Proyecto/ Subtítulo
19