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