1 Descripción general
1.1 Introducción al sistema
Una breve introducción al contenido del sistema, los usuarios a los que se enfrenta y los entorno en el que se ejecuta el sistema La descripción proviene principalmente del comienzo de la especificación de requisitos.
1.2 Objetivos de diseño de software
Esta sección analiza los objetivos de diseño de todo el sistema, indicando claramente qué funciones el sistema decide implementar y qué funciones no pretende implementar. También deben mencionarse los requisitos no funcionales como el rendimiento y la usabilidad. La especificación de requisitos es una referencia importante para esta parte. Mire los requisitos funcionales y no funcionales definidos en él.
Esta sección debe describir claramente el diseño general y garantizar que el lector sepa qué características y funciones tendrá el sistema después de leerla. En la sección de documentación a continuación, explicamos cómo el diseño implementa esto.
1.3 Citas
Enumere las referencias citadas en este documento. (Al menos cite la especificación de requisitos)
1.4 Historial de revisiones
Enumere el historial de modificaciones de este documento. Deberá especificarse el contenido, fecha y autor de la modificación.
2 Glosario
Explica los diversos términos utilizados en este documento. Si algunos términos ya se han explicado en la especificación de requisitos, no es necesario repetirlos aquí y se puede indicar a los lectores que consulten la especificación de requisitos.
3 casos de uso
Aquí se requiere que el sistema esté representado mediante un diagrama de casos de uso (UML), y cada caso de uso (situación de procesamiento normal) debe describirse en chino.
4 Descripción general del diseño
4.1 Introducción
Esta parte requiere resaltar los métodos utilizados en todo el diseño (diseño orientado a objetos o diseño estructurado), arquitectura del sistema ( como la arquitectura cliente/servidor) y las correspondientes tecnologías y herramientas utilizadas (como OMT y Ross).
4.2 Diseño de la estructura del sistema
Esta parte requiere describir la estructura del sistema de alto nivel y utilizar diagramas de bloques para mostrar los componentes principales y las interacciones entre los componentes. Es mejor separar la estructura lógica de la estructura física y describir la primera. No olvides explicar los modismos y símbolos utilizados en la imagen.
4.2.1 Estructura del sistema de nivel superior
4.2.2 Estructura del subsistema 1
Estructura del subsistema 2
4.3 Interfaz del sistema
p>
Aquí se describen las diversas interfaces proporcionadas a los usuarios y sistemas externos. Si la interfaz de usuario ya se describió en la especificación de requisitos, no es necesario repetirla aquí y el lector puede ser dirigido a la especificación de requisitos. Si el sistema proporciona interfaces con otros sistemas, como importar/exportar datos de otros sistemas de software, esto debe indicarse aquí.
4.4 Restricciones y supuestos
Describa las restricciones más importantes en el diseño del sistema, que son impuestas por el cliente y establecidas en la especificación de requisitos. Explique cómo se adapta el sistema a estas restricciones.
Además, el sistema puede estar sujeto a otras limitaciones si interactúa con otros sistemas externos o depende de otros sistemas externos para proporcionar alguna asistencia funcional. En este caso, es necesario que haya una descripción clara de los tipos de software que interactúan con el sistema (como el software de base de datos XXX y el software de correo XXX) y las restricciones resultantes (como que solo se permite el correo de texto sin formato).
El lenguaje y la plataforma implementados también tendrán restricciones en el sistema, que también se explican aquí.
En cuanto a las restricciones impuestas al sistema al elegir una implementación de diseño específica, describa brevemente sus pensamientos, qué tipo de compensaciones, por qué debería adoptar dicho diseño, etc.
Modelo de objetos 5
Modelo de objetos del sistema 5.1
Proporciona el modelo de objetos de todo el sistema. Si el modelo es demasiado grande, divídalo en pedazos más pequeños tanto como sea posible. Por ejemplo, los modelos de objetos de cliente y servidor se pueden dividir en dos diagramas.
¿Qué debe contener un diagrama de objetos?
Debe contener todos los objetos del sistema. Estos objetos surgen de la comprensión de los requisitos. Sea claro acerca de lo que debe incluirse en el cuadro y lo que no debe incluirse en el cuadro.
Se debe determinar la asociación entre todos los objetos y se debe especificar la cardinalidad de la asociación (uno a uno, uno a muchos o muchos a muchos, 0...1). , *, 1...*). La relación entre agregación y herencia debe estar claramente definida. Cada número debe ir acompañado de una explicación sencilla.
Es posible que se requieran varias iteraciones para obtener el modelo de objetos del sistema correcto.
6 Descripción del Objeto
En esta sección se describen los detalles, propiedades y métodos de cada objeto. Antes de que esto pueda suceder, los objetos deben organizarse lógicamente. Es posible que desee utilizar un diagrama de estructura para separar objetos en subsistemas.
Crea una entrada para cada objeto. Describa brevemente su propósito y restricciones (como solo una instancia) en el modelo de objetos del sistema y enumere sus propiedades y métodos. Si el objeto está almacenado en un contenedor de datos persistentes, indica que es un objeto persistente; en caso contrario, indica que es un objeto temporal;
Explique detalladamente cada atributo de cada objeto: nombre, tipo, si el atributo no es muy intuitivo o tiene restricciones (por ejemplo, los atributos de cada objeto deben tener un valor único o el rango de valores es un entero positivo limitado, etc.).
Una descripción detallada de cada método de cada objeto: nombre del método, tipo de retorno, valor de retorno, parámetros, propósito y una descripción breve (si no particularmente simple). del algoritmo utilizado. Si se suponen variables o valores de retorno, aquí se deben indicar condiciones previas y posteriores. Enumera las propiedades a las que él o los métodos que llama necesitan acceder o modificar. Finalmente, el método de implementación se verifica mediante un caso de prueba.
Objetos en 6.1 Subsistema 1
6.1.1 Objeto: Objeto 1
Uso:
Restricciones:
Persistencia:
6.1.1.1 Descripción de propiedad:
1. Propiedad: Propiedad 1
Tipo:
Descripción:
Restricciones:
2. Atributo: Atributo 2
6.1.1.2 Descripción del método:
1.
Tipo de retorno:
Parámetros:
Valor de retorno:
Requisitos previos:
Postcondiciones:
Atributos leídos/modificados:
Método llamado:
Lógica de procesamiento:
Caso de prueba: qué parámetros usar ¿Cuál es el resultado esperado al llamar? este método...
7 Modelo Dinámico
La función de esta parte es describir cómo responde el sistema a varios eventos. Por ejemplo, se puede construir un modelo de comportamiento del sistema. Generalmente se utilizan diagramas de secuencia y diagramas de estado.
Identificar diferentes escenarios es el primer paso. No es necesario identificar todos los escenarios posibles, pero se deben cubrir al menos los casos de uso típicos del sistema. No lo des por sentado y crea tus propias escenas. Una estrategia común es describir escenarios con los que los clientes puedan identificarse.
7.1 Escenas
Cree una entrada para cada escena, incluyendo lo siguiente:
Nombre de la escena: asígnele un nombre significativo.
Descripción de la escena: Describe brevemente qué hace la escena y la secuencia de acciones.
Diagrama de secuencia: describe varios eventos y su tiempo relativo.
7.1.1 Escenario: Escenario 1
Descripción:
Acción 1
Acción 2
7.2 Estado Diagrama
Esta sección contiene diagramas de estado de partes importantes del modelo dinámico del sistema. Tal vez quieras dibujar un diagrama de estado para cada objeto, pero eso en realidad genera demasiados detalles inesperados. Sólo necesita identificar algunos objetos importantes en el sistema y proporcionarles diagramas de estado.
7.2.1 Diagrama de estado 1:
8 Requisitos no funcionales
En esta sección es necesario explicar cómo tratar los requisitos no funcionales. especificado en el documento de requisitos. Evaluar la capacidad del sistema para manejar cada requisito no funcional de la manera más objetiva posible. Si algunos requisitos no funcionales no se implementan completamente en el sistema diseñado, asegúrese de indicarlos aquí. Además, deberá estimar la evolución futura del sistema y describir cómo este diseño permitirá que el sistema se adapte a estos cambios previsibles.
9 Documentos Auxiliares
Aportar documentos relevantes que ayuden a comprender el diseño.
Índice de 10 vocabulario
Entradas de artículos