El análisis de requisitos de software resuelve el problema de "qué hacer", mientras que el proceso de diseño de software resuelve el problema de "cómo hacerlo".

El diseño de software es el proceso de transformar los requisitos del software en representación del software. Consta principalmente de dos etapas: etapa de diseño de la arquitectura del software y diseño a nivel de componentes.

Utilizando un enfoque de diseño, la información sobre los requisitos de software representados por datos, modelos funcionales y de comportamiento en el modelo de análisis de software se pasa a la fase de diseño, lo que da como resultado el diseño de datos/clases, el diseño de arquitectura, el diseño de interfaces y el diseño a nivel de componentes.

Diseño de datos/clases: transforme el modelo de clases de análisis en implementación de clases y estructuras de datos necesarias para la implementación del software.

Diseño arquitectónico: el diseño arquitectónico define la estructura general del software.

Diseño de interfaz: El diseño de interfaz describe cómo comunicarse dentro del software, entre el software y los sistemas colaborativos, y entre colegas del software.

Diseño a nivel de componente: El diseño a nivel de componente transforma los elementos estructurales de la arquitectura del software en una descripción procesal de los componentes del software.

En el proceso de diseño de software, debemos prestar mucha atención a los factores de calidad del software.

Los objetivos del proceso de diseño de software McGlanghlin son:

1) La estructura diseñada debe ser una estructura jerárquica para establecer el control entre los componentes del software.

2) El diseño debe ser modular, dividiendo lógicamente el software en componentes que completen funciones o subfunciones específicas.

3) El diseño debe incluir tanto la abstracción de datos como la abstracción de procesos.

4) El diseño deberá establecer módulos con características funcionales independientes.

5) El diseño debe establecer interfaces que reduzcan las conexiones complejas entre el módulo y el entorno externo.

6) El diseño debe poder establecer un método manejable y repetible basado en la información obtenida del análisis de requisitos de software.

1) Desarrollar especificaciones

2) Arquitectura y diseño de interfaz.

3) Diseño de datos/clase

4) Diseño a nivel de componente (proceso)

5) Escribir documentos de diseño.

6) Revisión del diseño

La abstracción es una estrategia básica para controlar la complejidad a medida que aumenta gradualmente la escala del diseño de software.

Poco a poco busca el refinamiento.

La modularización, es decir, dividir el software en componentes más pequeños, independientes pero interrelacionados según principios prescritos, es en realidad un proceso de descomposición y abstracción del sistema.

Un módulo es una colección de objetos de programa, como descripciones de datos y declaraciones ejecutables. Tiene un nombre individual y se puede acceder a él por su nombre.

Por ejemplo, proceso. Funciones, subrutinas, macros, etc.

Los detalles de implementación de cada módulo deben estar ocultos a otros módulos.

La información (incluidos datos y procedimientos) contenida en el bloque no puede ser utilizada por otros módulos que no necesiten esta información.

Mediante la ocultación de información, se pueden definir y aplicar restricciones de acceso a los detalles del proceso y a las estructuras de datos locales del módulo.

Independencia funcional: la independencia funcional es un resultado directo de conceptos como modularidad, abstracción, ocultación de información y localización. La independencia funcional se puede lograr desarrollando módulos que sean funcionalmente específicos y eviten interacciones excesivas con otros módulos.

La importancia de la independencia funcional

La independencia funcional se puede medir mediante dos indicadores: cohesión y acoplamiento.

① Facilitar la comunicación entre las partes interesadas

②Conducente a la toma temprana de decisiones en el diseño del sistema.

③Abstracción a nivel de sistema transmisible

Arquitectura de software común

La gran mayoría puede clasificarse como uno de un número relativamente pequeño de estilos arquitectónicos.

Cada estilo describe una categoría de sistema, que incluye:

Algunos datos (como un archivo o una base de datos) se almacenan en el centro de la estructura y otros componentes los utilizan, agregan, eliminan o modifican con frecuencia.

Esta estructura es adecuada para que los datos de entrada se transformen en datos de salida mediante una serie de componentes de cálculo o procesamiento.

Este estilo permite al diseñador de software diseñar una arquitectura que sea muy fácil de modificar y ampliar.

Contiene: arquitectura de estilo de programa/subprograma principal y arquitectura de estilo de llamada a procedimiento remoto

Hay algunos conceptos que debe comprender aquí:

Métodos para que los componentes del sistema encapsulen datos y manipulen datos.

La interacción y coordinación entre componentes se transmiten a través de mensajes.

En esta estructura, se definen diferentes niveles y cada nivel completa operaciones más cercanas a las instrucciones de la máquina que el nivel exterior.

Para el mismo requisito de software, se derivarán diferentes estructuras de software debido a diferentes principios de diversos métodos de diseño.

Diferentes estructuras de software para el mismo problema

1) Definir escenarios de aplicación (escenarios): expresar el sistema desde la perspectiva del usuario a través de diagramas de casos de uso

2) Derivar requisitos, restricciones y descripción del entorno: esto es parte de la ingeniería de requisitos para garantizar que se enumeren todas las inquietudes del cliente.

3) Describa el estilo arquitectónico que puede manejar las situaciones y requisitos anteriores.

4) Evaluar cada desempeño del sistema individualmente. El rendimiento para el diseño de arquitectura incluye: confiabilidad, rendimiento, seguridad, mantenibilidad, flexibilidad, capacidad de prueba, portabilidad, reutilización e interoperabilidad, etc.

5) Para diferentes formas arquitectónicas, evalúe la sensibilidad de estas actuaciones mencionadas en el paso 4. Se puede evaluar de esta manera: realice algunos pequeños cambios en toda la arquitectura, analice y determine si hay cambios sensibles en el rendimiento de la apelación. Aquellos rendimientos que se ven muy afectados por los cambios arquitectónicos se denominan puntos sensibles.

6) Evaluar aquellas arquitecturas propuestas en el paso 3 a través del análisis de sensibilidad en el paso 5. El método descrito por SEI es el siguiente: cuando se determinan los puntos sensibles de una arquitectura, necesitamos encontrar los factores que requieren la mayor cantidad de puntos de compensación en el sistema (puntos de compensación). El factor de compensación significa que cambiar este contenido en la arquitectura provocará cambios sensibles en el rendimiento del sistema. Por ejemplo, el rendimiento de un sistema con una estructura cliente-servidor está estrechamente relacionado con la cantidad de servidores en el sistema (por ejemplo, aumentar la cantidad de servidores mejorará el rendimiento del sistema hasta cierto punto)... En En este caso, la cantidad de servidores es este punto de equilibrio en la arquitectura.

(1) Mejorar la estructura del software y mejorar la independencia del módulo.

(2) Profundidad, ancho, distribución en abanico y entrada en abanico adecuados del módulo

(3) El alcance de juicio del módulo debe estar dentro de su alcance de control.

(4) Esforzarse por reducir la complejidad de las interfaces de los módulos.

(5) Diseñar un módulo con entrada única y salida única

(6) La funcionalidad del módulo debe ser predecible y el tamaño del módulo debe ser moderado

(7) Generalmente, es mejor que un módulo contenga entre 30 y 50 declaraciones.

(8) Una estructura de software bien diseñada generalmente tiene una mayor distribución en la capa superior, menos distribución en la capa intermedia y una alta distribución en la capa inferior.

Determine el algoritmo utilizado para cada componente, seleccione una herramienta adecuada para expresar el proceso del algoritmo y escriba una descripción detallada del procedimiento del componente.

Determinar las estructuras de datos utilizadas internamente por cada componente.

Al final del diseño a nivel de componente, los resultados anteriores deben escribirse en la especificación de diseño a nivel de componente y formarse en un documento formal mediante revisión, que servirá como base para la siguiente etapa (etapa de codificación).

Una definición más popular es: "Si los bloques de código de un programa están conectados sólo a través de las tres estructuras de control básicas de secuencia, selección y bucle, y cada bloque de código tiene sólo una entrada y una salida, entonces se dice que el programa está estructurado". . de"

Con el desarrollo de nuevos métodos y tecnologías de desarrollo de software, como la orientación a objetos y la reutilización de software, un enfoque de desarrollo más realista y eficaz puede ser una combinación orgánica de métodos de arriba hacia abajo y de abajo hacia arriba.

Diagrama de flujo del programa

diagrama NS

ALMOHADILLA

Cuando el algoritmo contiene múltiples selecciones de condiciones anidadas, es difícil describirlo claramente utilizando diagramas de flujo del programa, diagramas N-S o PAD.

Sin embargo, las tablas de decisiones pueden expresar claramente la correspondencia entre combinaciones complejas de condiciones y las acciones que deben tomarse.

La ventaja de la tabla de decisiones es que puede describir todas las reglas de procesamiento de manera concisa e inequívoca.

Sin embargo, la tabla de decisiones representa lógica estática, que es el posible resultado bajo una determinada combinación de valores de condición. No puede expresar la secuencia de procesamiento ni la estructura del bucle.

PDL (Program Design Language) es un lenguaje utilizado para describir el diseño del algoritmo y los detalles de procesamiento de componentes funcionales, llamado lenguaje de diseño.

Es una especie de pseudocódigo. En términos generales, las reglas gramaticales del pseudocódigo se dividen en "gramática externa" y "gramática interna".

Ejemplos de uso de PDL

Funciones de PDL

El objetivo final del diseño de software es obtener la mejor solución.

"Mejor" significa que entre todas las soluciones candidatas, la solución que puede lograr mayor productividad, mayor confiabilidad y mantenibilidad se selecciona en función de las condiciones de ahorrar costos de desarrollo, reducir el consumo de recursos y acortar el tiempo de desarrollo.

Contenido de la revisión del diseño.

Hay dos tipos de revisión: revisión formal y revisión informal.