Trabajo de Análisis y Diseño de Sistemas de Información

Traducción Capitulo 2

Diseño de Software

SWEBOK

Presentado por:

Jorge Fabián Munevar Hernández

Docente:

Olvanny Torres

Universidad De Pamplona

Departamento De Ciencias Económicas Y Empresariales

Facultad Administración De Empresas

Villa Del Rosario

2016

INTRODUCCIÓN

El diseño se define como tanto "el proceso de definición la arquitectura,

componentes, interfaces y otras características de un sistema o componente " y

"el resultado del proceso [que]". Visto como un proceso, diseño de software es la

ingeniería del software la actividad del ciclo de vida en el que los requisitos de

software se analizan con el fin de producir una descripción de la estructura interna

del software que lo hará servir de base para su construcción. Un software diseño

(el resultado) describe la arquitectura-software es decir, cómo se descompone

software y organizada en componentes-y las interfaces entre esos componentes.

También debe describir los componentes en un nivel de detalle que permite su

construcción.

El diseño de software juega un papel importante en el desarrollo de software:

durante el diseño de software, ingenieros de software producen varios modelos

que forma una especie de anteproyecto de la solución hasta ponerse en práctica.

Podemos analizar y evaluar estos modelos para determinar si son o no nos

permitirá cumplir con los diversos requisitos.

También podemos examinar y evaluar alternativas soluciones y compensaciones.

Por último, podemos utilizar el dando como resultado modelos para planificar el

desarrollo subsecuente actividades, tales como la verificación y validación del

sistema, Además de su uso como entradas y como el punto de construcción y

ensayo de partida. En una lista estándar de los procesos del ciclo de vida del

software, como el de la norma ISO / IEC / IEEE Std. 12207, Procesos del ciclo de

vida del software, el diseño de software consta de dos actividades que se ajustan

entre el software análisis de requisitos y la construcción de software:

• Diseño de la arquitectura del software (a veces diseño llamado de alto nivel): se

desarrolla a nivel superior la estructura y la organización del software e identifica

los diversos componentes.

• Diseño detallado del programa: especifica cada uno componente con suficiente

detalle para facilitar su construcción.

Esta área de conocimiento Diseño de Software (KA) no discutir todos los temas

que incluye el palabra "diseño". En la terminología de Tom Demarco, los temas

discutidos en este acuerdo KA principalmente con D-diseño (diseño

descomposición), el objetivo de los cuales es el mapeo de software en el

componente piezas. Sin embargo, debido a su importancia en el campo de la

arquitectura de software, nosotros también abordar FP-diseño (diseño del patrón

de la familia), la objetivo de que es establecer comunes explotables en una familia

de productos de software.

Fig. 2.1

Esta KA no se ocupa de la I-diseño (diseño invención), que por lo general se lleva

a cabo durante el software los requisitos del proceso con el objetivo de

conceptualizar y el software para satisfacer la especificación descubierto

necesidades y requerimientos, ya que este tema es considerado como parte del

proceso de requisitos (Ver los requisitos de software KA). Construcción, Ingeniería

de Software de Gestión, Modelos de Ingeniería de Software y Métodos, Calidad

del Software, y Fundamentos de Informática Kas.

DISTRIBUCIÓN DE TEMAS PARA

DISEÑO DE SOFTWARE

El desglose de temas para el Software de Diseño KA se muestra en la Figura 2.1.

Fundamentos del Diseño de Software La conceptos, nociones y terminología

introducida aquí constituyen una base fundamental para el conocimiento de la

función y el alcance del diseño de software.

1.1. Conceptos generales de diseño

En sentido general, el diseño puede ser visto como una forma de resolución de

problemas. Por ejemplo, el concepto de una solución de un problema complejo,

sin definitiva solución es interesante en términos de la comprensión de los límites

del diseño. Un numero de otras nociones y conceptos son también de interés en

entender el diseño en su sentido general: objetivos, limitaciones, las alternativas,

las representaciones, y soluciones (véase la resolución de problemas en el

Técnicas Fundamentos de computación KA).

1.2. Contexto de Diseño de Software

El diseño de software es una parte importante del software proceso de desarrollo.

Para entender el papel de diseño de software, tenemos que ver cómo encaja en el

ciclo de vida del software de desarrollo. Por lo tanto, es importante comprender las

características principales de los requisitos de software de análisis, software el

diseño, la construcción de software, pruebas de software, y mantenimiento de

software.

1.3. Software de Diseño de Procesos

El diseño del software se considera generalmente en dos etapas de proceso:

El diseño arquitectónico (también denominado como de alto nivel diseño y

diseño de nivel superior) describe cómo el software está organizado en

componentes.

• Diseño detallado se describe el comportamiento deseado de estos componentes.

La salida de estos dos procesos es un conjunto de modelos y artefactos que

registran las principales decisiones que se han adoptado, junto con una

explicación de los fundamentos de cada decisión no trivial. Mediante el registro de

la razón de ser, capacidad de mantenimiento a largo plazo del producto de

software se ha mejorado.

1.4. Principios de Diseño de Software

Un principio es "una amplia y fundamental ley, doctrina o suposición”. Software

principios de diseño son conceptos clave que proporcionan la base para el diseño

de muchos diferentes programas informáticos enfoques y conceptos. Principios de

diseño de software incluya la captación; acoplamiento y cohesión; descomposición

y la modularización; encapsulación / ocultación de información; separación de

interfaz e implementación; suficiencia, integridad, y primitivo; y la separación de

las capas.

• La abstracción es "una visión de un objeto que se centra en la información

relevante para una propósito particular e ignora el resto de la información "(véase

la abstracción en los Fundamentos de computación KA). En el contexto del diseño

de software, dos abstracciones clave mecanismos son parametrización y

especificación. Abstracción de parametrización resúmenes de los detalles de las

representaciones de datos mediante la representación de los datos como el

nombre parámetros. Abstracción por la especificación da lugar a tres tipos

principales de la abstracción: abstracción de procedimientos, la abstracción de

datos, y control (iteración) abstracción.

• Acoplamiento y cohesión. El acoplamiento se define como "una medida de la

interdependencia entre las módulos en un programa de ordenador ", mientras

cohesión se define como "una medida de la fuerza de la asociación de los

elementos dentro de un módulo”.

• Descomposición y modularización. La descomposición y la modularización

significan que tan grande software se divide en una serie de pequeños

componentes nombrados habiendo bien definidos interfaces que describen

interacciones de los componentes. Por lo general, el objetivo es colocar diferentes

funcionalidades y responsabilidades en diferentes componentes.

• Medios de encapsulación y ocultación de la información agrupar y empaquetar

los detalles internos de una abstracción y hacer que esos detalles inaccesible a

entidades externas.

• Separación de la interfaz y la implementación. La separación de interfaz y la

implementación implica la definición de un componente especificando una interfaz

pública (conocido por los clientes) que es independiente de los detalles de cómo la

componente se realiza (ver encapsulación y ocultación de la información anterior).

• La suficiencia, integridad y primitivismo. El logro de la suficiencia e integridad

significa la garantía de un componente de software capta todas las características

importantes de una abstracción y nada más. Carácter primitivo significa que el

diseño debe basarse en patrones que son fáciles de implementar.

• Separación de intereses. Una preocupación es una "Área de interés con respecto

a un software diseño”. Una preocupación diseño es un área de diseño que es

relevante para uno o más de sus las partes interesadas. Cada vista de la

arquitectura marcos uno o más preocupaciones. La separación de las

preocupaciones por las vistas permite a las partes interesadas centrarse en

algunas cosas a la vez y ofrece una los medios de gestión de la complejidad

2. Cuestiones clave en el diseño de software

Una serie de cuestiones clave debe ser tratado cuando el diseño de software.

Algunos son problemas de calidad que todo el software debe abordar, por

ejemplo, rendimiento, seguridad, fiabilidad, facilidad de uso, etc. Otra cuestión

importante es cómo se descomponen, organizar y componentes de software

paquete. Esto es tan fundamental que todos los enfoques de diseño abordarlo de

una manera u otra (véase la sección 1.4, Principios de diseño de software, y el

tema 7, Software Estrategias de diseño y Métodos). A diferencia de, otras

cuestiones "trato con algún aspecto del software de comportamiento que no está

en el dominio de aplicación, pero que aborda algunas de las apoyo .dominios”.

Estas cuestiones, que a menudo cruzan corte la funcionalidad del sistema, se han

contemplado como aspectos, que "tienden a no ser unidades de software

descomposición funcional, sino más bien para ser propiedades que afectan al

rendimiento o la semántica de los componentes en formas sistémicas ". Algunas

de estas claves, son temas transversales se discute en las siguientes secciones

(presentada en orden alfabético).

2.1. Concurrencia

Diseño para la concurrencia se ocupa de descomposición de software en

procesos, tareas y discusiones y hacer frente a cuestiones relacionadas con la

eficiencia, atomicidad, sincronización y programación.

2.2. Control y Manejo de Eventos

Este problema de diseño se ocupa de cómo organizar los datos y el flujo de

control, así como la forma para controlar los eventos reactivos y temporales a

través diversos mecanismos tales como la invocación implícita y devoluciones de

llamadas.

2.3. Persistencia de datos

Este problema de diseño se ocupa de cómo manejar los datos de larga vida.

2.4. Distribución de Componentes

Este problema de diseño se ocupa de cómo distribuir el software en el hardware

(incluyendo hardware de ordenador y hardware de red), cómo los componentes se

comunican, y cómo Artículos de medio se puede utilizar para hacer frente a

heterogéneo software.

2.5. Error y el control de excepciones y el de fallos Tolerancia

Este problema de diseño se ocupa de cómo prevenir, tolerar, y los errores de

proceso y tratar con condiciones excepcionales.

2.6. Interacción y Presentación

Este problema de diseño se ocupa de cómo estructurar y organizar las

interacciones con los usuarios, así como la presentación de información (por

ejemplo, separación de la presentación y de la lógica de negocio utilizando el

enfoque del Modelo-Vista-Controlador).Tenga en cuenta que este tema no

especifica la interfaz de usuario detalles, que es la tarea de diseño de la interfaz

de usuario

(Véase el tema 4, diseño de interfaz de usuario).

2.7. Seguridad

Diseño para la seguridad tiene que ver con la forma de prevenir divulgación no

autorizada, creación, cambio, eliminación, o la denegación de acceso a la

información y otros recursos. También se ocupa de cómo tolerar ataques o

violaciones relacionadas con la seguridad de daños limitante, servicio continuado,

el exceso de velocidad reparación y recuperación, y en su defecto y recuperar

segura. El control de acceso es un concepto fundamental de la seguridad, y de

también hay que asegurar la el uso adecuado de la criptología.

3. Estructura del software y Arquitectura

En su sentido más estricto, es una arquitectura de software "El conjunto de las

estructuras necesarias para razonar acerca el sistema, que comprenden

elementos de software, las relaciones entre ellos, y las propiedades de ambos

".Durante la década de 1990, sin embargo, el software arquitectura comenzó a

surgir como una más amplia disciplina que implicaba el estudio de software

estructuras y arquitecturas de una forma más genérica camino. Esto dio lugar a

una serie de interesantes conceptos sobre el diseño de software en los diferentes

niveles de abstracción. Algunos de estos conceptos pueden ser útil durante el

diseño arquitectónico (por ejemplo, estilos arquitectónicos), así como durante el

diseño detallado (por ejemplo, patrones de diseño). Estos conceptos de diseño

también se pueden utilizar para diseñar familias de programas (también conocido

como líneas de productos). Curiosamente, la mayoría de estos conceptos puede

verse como intentos de describir, y de por tanto, la reutilización, el conocimiento

de diseño.

3.1. Las estructuras arquitectónicas y puntos de vista

Las diferentes facetas de alto nivel de un diseño de software pueden ser descritas

y documentado. estas facetas son a menudo llamados puntos de vista: "Una vista

parcial representa una aspecto de una arquitectura de software que muestra

específica propiedades de un sistema de software ".Views pertenecer a cuestiones

diferentes asociados con el software diseño, por ejemplo, la vista lógica

(satisfaciendo los requisitos funcionales) frente a la vista de procesos (problemas

de concurrencia) frente a la vista física (distribución temas) frente a la vista de

desarrollo (como el diseño se divide en unidades de ejecución con la

representación explícita de las dependencias entre las unidades). Varios autores

utilizan diferentes terminologías similares vs funcional del comportamiento

estructural vs. Vistas de modelado de datos. En resumen, una diseño de software

se produce un artefacto multifacético por el proceso de diseño y generalmente

compuesta de vistas relativamente independientes y de ortogonales.

3.2. Estilos arquitectónicos

Un estilo arquitectónico es "una especialización de elemento y tipos de relación,

junto con un conjunto de restricciones sobre la forma en que se pueden utilizar”.

Un estilo arquitectónico de este modo puede ser visto como proporcionar

organización de alto nivel de software. Varios autores han identificado una serie de

importantes arquitectónica estilos:

• Las estructuras generales (por ejemplo, capas, tuberías y los filtros, pizarra)

• Los sistemas distribuidos (por ejemplo, ClientServer, tres niveles, agente)

• Los sistemas interactivos (por ejemplo, Modelo-Vista- Controlador, Presentación-

Abstracción-Control)

• Sistemas Adaptables (por ejemplo, microkernel, reflexión)

• Otros (por ejemplo, por lotes, intérpretes, proceso de control, basado en normas).

3.3. Patrones de diseño

Sucintamente descrito, es un patrón "un común solución a un problema común en

un contexto dado”. Mientras que los estilos arquitectónicos se pueden ver como

patrones que describen la organización de alto nivel de software, otros patrones

de diseño se pueden utilizar para describir los detalles en un nivel inferior. Estos

menores patrones de diseño de nivel son las siguientes:

• Patrones de creación (por ejemplo, constructor, fábrica, prototipo, Singleton)

• Los patrones estructurales (por ejemplo, un adaptador, puente, compuesto,

decorador, fachada, peso mosca, apoderado)

• Los patrones de comportamiento (por ejemplo, comandos, intérprete, iterador,

mediador, recuerdo, observador, estado, estrategia, plantilla, visitante).

3.4. Las decisiones de Arquitectura del diseño

El diseño arquitectónico es un proceso creativo. Durante el proceso de diseño, los

diseñadores de software tienen para hacer una serie de decisiones fundamentales

que afectar profundamente el software y el desarrollo proceso. Es útil pensar en la

arquitectura proceso de diseño de una toma de decisiones perspectiva en lugar de

desde una perspectiva actividad.

A menudo, el impacto sobre los atributos de calidad y compensaciones entre los

atributos de calidad de la competencia son la base para las decisiones de diseño.

3.5. Familias de programas y marcos

Un enfoque para proporcionar la reutilización de software diseños y componentes

es diseñar familias de programas, también conocidas como líneas de productos de

software. Esto se puede hacer mediante la identificación de los elementos

comunes entre los miembros de estas familias y mediante el diseño componentes

reutilizables y adaptables a la cuenta para la variabilidad entre los miembros de la

familia. En la programación orientada a objetos (OO), una tecla noción relacionada

es la de un marco: a parcialmente sistema de software completado que puede ser

extendido por apropiadamente crear instancias de extensiones específicas (Tales

como plug-ins).

4. Diseño de Interfaz de Usuario

Diseño de interfaz de usuario es una parte esencial de la proceso de diseño de

software. Diseño de interfaz de usuario debe asegurarse de que la interacción

entre el ser humano y la máquina proporciona un funcionamiento eficaz y el

control de la máquina. Para que el software alcanzar su pleno potencial, la interfaz

de usuario debe ser diseñado para que coincida con las habilidades, experiencia y

expectativas de sus usuarios previstos.

4.1. Principios generales para el usuario de diseño de interfaces

• Facilidad de aprendizaje. El software debe ser fácil de aprender de manera que

el usuario puede empezar a trabajar rápidamente con el software.

• Familiaridad del usuario. La interfaz debe utilizar términos y conceptos extraídos

de las experiencias de las personas que vayan a utilizar el software.

• La consistencia. La interfaz debe ser coherente para que las operaciones

comparables se activan del mismo modo.

• Mínimo sorpresa. El comportamiento de software No debe sorprender a los

usuarios.

• La recuperabilidad. La interfaz debe proporcionar mecanismos que permiten a

los usuarios recuperar a partir errores.

• Guía para el usuario. La interfaz debe dar retroalimentación significativa cuando

se producen errores y proporcionar ayuda relacionada con el contexto a los

usuarios.

• La diversidad de usuario. La interfaz debe proporcionar mecanismos de

interacción adecuados para diversos tipos de usuarios y para los usuarios con

diferentes capacidades (ciegos, problemas de visión, sordo, daltónico, etc.).

4.2. Cuestiones del diseño de Interfaz de Usuario

Diseño de interfaz de usuario debe resolver dos cuestiones clave:

• ¿Cómo debería el usuario interactuar con el software?

• ¿Cómo debe la información desde el software se presentará al usuario?

Diseño de interfaz de usuario debe integrar usuario la interacción y la presentación

de la información. Usuario diseño de la interfaz debe considerar un compromiso

entre los estilos más apropiados de interacción y la presentación del software, el

fondo y la experiencia de los usuarios de software, y el dispositivos disponibles.

4.3. El diseño de las modalidades de interacción del usuario

La interacción del usuario implica dando órdenes y proporcionando datos

asociados al software. Usuario estilos de interacción se pueden clasificar en los

siguientes estilos principales:

• Pregunta respuesta. La interacción es esencialmente restringida a una sola

pregunta-respuesta intercambio entre el usuario y el software. El usuario envía

una pregunta al software, y el software devuelve la respuesta a la pregunta.

• Manipulación directa. Los usuarios interactúan con objetos en la pantalla del

ordenador. Directo manipulación a menudo incluye un señalador dispositivo (tal

como un ratón, bola de seguimiento, o un dedo en las pantallas táctiles) que

manipula una de objetos y acciones que especifican lo invoca se debe hacer con

ese objeto.

• Selección de menú. El usuario selecciona un comando a partir de una lista de

menú de comandos.

• Forma de relleno. El usuario rellena los campos de una formar. A veces campos

incluyen menús, en cuyo caso la forma tiene botones de acción para al usuario

iniciar la acción.

• El lenguaje de comandos. El usuario emite un comando y proporciona los

parámetros relacionados con dirigir el software qué hacer.

• Lenguaje natural. El usuario emite un comando en lenguaje natural. Es decir, lo

natural el lenguaje es una interfaz a un lenguaje de comandos y es interpretada y

traducida en el software comandos.

4.4. El Diseño de la Información de presentación

Presentación de la información puede ser textual o gráfica en naturaleza. Un buen

diseño mantiene la información la presentación por separado de la información en

sí misma.

El enfoque MVC (Modelo-Vista-Controlador) es una forma efectiva de mantener la

presentación de información la separación de la información que se presenta.

Los ingenieros de software también consideran el software tiempo de respuesta y

la retroalimentación en el diseño de la información presentación. El tiempo de

respuesta es por lo general medida desde el punto en el que se ejecuta un usuario

una cierta acción de control hasta que el software responde con una respuesta.

Una indicación del progreso es deseable mientras que el software se está

preparando la respuesta. La retroalimentación puede ser proporcionada mediante

la reformulación del usuario de entrada mientras se completa el procesamiento.

Abstracto visualizaciones pueden ser utilizados cuando son grandes cantidades de

información se han de presentar. De acuerdo con el estilo de presentación de la

información, Los diseñadores también pueden utilizar el color para mejorar la

interfaz. Existen varias pautas importantes:

• Limite el número de colores utilizados.

• Use cambio de color para mostrar el cambio de software estado.

• Use códigos de colores para apoyar la tarea del usuario.

• Use códigos de colores en un reflexivo y coherente camino.

• Use colores para facilitar el acceso de las personas con ceguera o deficiencia

cromática de color (Por ejemplo, utilizar el cambio de color y la saturación el brillo

del color, trate de evitar azul y rojo combinaciones).

• No se confíe sólo en el color para transmitir Información importante para los

usuarios con diferentes capacidades (ceguera, problemas de visión, ceguera al

color, etc.).

4.5. Proceso de Interfaz de usuario Diseño

Diseño de la interfaz de usuario es un proceso iterativo; prototipos de interfaz se

utilizan a menudo para determinar las características, la organización, y el aspecto

del software interfaz de usuario. Este proceso incluye tres

Actividades centrales Actividades principales:

• Análisis del usuario. En esta fase, el diseñador analiza tareas de los usuarios, el

medio ambiente de trabajo, otro software, y cómo interactúan los usuarios con

otras personas.

• La creación de prototipos de software. El desarrollo de prototipos ayuda a los

usuarios de software para guiar la evolución de La interfaz.

• Evaluación de la interfaz. Los diseñadores pueden observar experiencias de los

usuarios con la interfaz en evolución.

4.6. Localización e internacionalización

Diseño de interfaz de usuario a menudo necesita considerar la internacionalización

y la localización, que son medios de adaptar el software a los diferentes idiomas,

las diferencias regionales, y los requisitos técnicos de un mercado objetivo. La

internacionalización es el proceso de diseño de una aplicación de software de

manera que se puede adaptar a varios idiomas y regiones sin grandes cambios de

ingeniería. Localización es el proceso de adaptación de software

internacionalizado para una región o idioma mediante la incorporación

componentes de la configuración regional específica y la traducción del texto.

Localización e internacionalización debe considerar factores tales como símbolos,

números, moneda, tiempo, y unidades de medición.

4.7. Metáforas y modelos conceptuales

los diseñadores de interfaces de usuario pueden utilizar metáforas y modelos

conceptuales para establecer correspondencias entre el software y algún sistema

de referencia conocida a la usuarios en el mundo real, que pueden ayudar a los

usuarios más fácilmente aprender y utilizar la interfaz. Por ejemplo, la operación

de "borrar archivo" se puede convertir en una metáfora con el icono de un cubo de

basura. En el diseño de una interfaz de usuario, los ingenieros de software debe

tener cuidado de no usar más de una metáfora para cada concepto. Metáforas

también presentes problemas potenciales con respecto a la internacionalización,

ya que no todas las metáforas son significativos o se aplican de la misma manera

en todas las culturas.

5. Diseño de Software de Análisis de Calidad y Evaluación

En esta sección se incluye una serie de análisis de la calidad y temas de

evaluación que son específicamente en relación con el diseño de software. (Véase

también el Software KA calidad.)

5.1. Los atributos de calidad

Diversos atributos contribuyen a la calidad de un diseño de software, incluyendo

varios "-ilities" (Mantenibilidad, portabilidad, capacidad de prueba, la facilidad de

uso) y "-nesses" (exactitud, robustez). Ahí está una interesante distinción entre los

atributos de calidad discernible en tiempo de ejecución (por ejemplo, rendimiento,

seguridad, disponibilidad, funcionalidad, usabilidad), los que no discernibles en

tiempo de ejecución (por ejemplo, modificabilidad, portabilidad, reutilización, la

capacidad de prueba), y los relacionados con la arquitectura de cualidades

intrínsecas (por ejemplo, la integridad conceptual, corrección, integridad). (Véase

también la Software de Calidad KA).

5.2. Análisis de calidad y técnicas de evaluación

Varias herramientas y técnicas pueden ayudar en el análisis y la evaluación de la

calidad del diseño de software.

• Software: revisiones del diseño estructurado y formalizado técnicas para

determinar la calidad de artefactos de diseño (por ejemplo, la arquitectura los

comentarios, revisiones de diseño, e inspecciones; técnicas basadas en

escenarios; requisitos rastreo). Las revisiones de diseño de software pueden

también evaluar la seguridad. Ayudas para la instalación, operación, y el uso (por

ejemplo, manuales y archivos de ayuda) se pueden revisar.

• Análisis estático: estática formal o semiformal (No ejecutable) análisis que puede

ser utilizado para evaluar un diseño (por ejemplo, faulttree análisis o comparación

automatizada). Análisis de vulnerabilidad de diseño (por ejemplo, el análisis

estático de las debilidades de seguridad) puede llevarse a cabo si la seguridad es

una preocupación. Formal análisis de diseño utiliza modelos matemáticos que

permiten a los diseñadores de predicado el comportamiento y validar el

rendimiento del software en vez de tener que depender totalmente de la prueba.

Análisis de diseño formal puede ser utilizado para detectar especificación residual

y errores de diseño (tal vez causado por la imprecisión, ambigüedad y algunas

veces otros tipos de errores). (Ver También los modelos de ingeniería de software

y Métodos KA).

• La simulación y prototipo: técnicas de dinámica para evaluar un diseño (por

ejemplo, simulación de rendimiento o viabilidad prototipos).

5.3. Medidas

Las medidas se pueden utilizar para evaluar o cuantitativamente estimar diversos

aspectos de un software diseño; por ejemplo, el tamaño, estructura y calidad. La

mayoría de las medidas que se han propuesto dependen en el enfoque utilizado

para producir el diseño. Estas medidas se clasifican en dos grandes categorías:

• basado en las funciones medidas (estructurada) de diseño: medidas obtenidos

mediante el análisis funcional descomposición; generalmente representado el uso

de un diagrama de estructura (a veces llamada diagrama jerárquico) en el que

diversas medidas puede ser calculado.

• Medidas orientadas a objetos de diseño: el diseño estructura se representa

típicamente como una clase diagrama, en el que diversas medidas pueden ser

computado. Medidas sobre las propiedades de la contenido interno de cada clase

puede ser también computado.

6. Diseño de Software notaciones

Existen muchas notaciones para representar el diseño de software artefactos.

Algunos se utilizan para describir la estructura organización de un diseño, para

representar otro software comportamiento. Ciertas notaciones se utilizan sobre

todo durante el diseño arquitectónico y los demás principalmente durante el diseño

detallado, aunque algunas notaciones se pueden utilizar para ambos propósitos.

En adición, algunas anotaciones se utilizan sobre todo en el contexto de métodos

de diseño específico (Véase el apartado 7, Software Estrategias de diseño y

Métodos). Tenga en cuenta que diseño de software a menudo se logra utilizando

múltiples notaciones. A continuación, se clasifican en notaciones para describir la

estructura (estática) ver frente a la vista del comportamiento (dinámica).

6.1. Las descripciones estructurales (estático Vista)

Las siguientes anotaciones, en su mayoría, pero no siempre gráfica, describir y

representar el estructural los aspectos de un programa de diseño, es decir, que

son se usa para describir los componentes principales y cómo que están

interconectados (visión estática):

• Lenguajes de descripción de Arquitectura (AVD): textual, a menudos formales,

lenguas utilizan para describir la arquitectura de software en términos de

componentes y conectores.

• Clase y objeto: diagramas utilizados para representar un conjunto de clases (y

objetos) y sus interrelaciones.

• Diagramas de componentes: se utiliza para representar una un conjunto de

componentes (“física y reemplazable parte [s] de un sistema que [se ajuste] para y

[dar] la realización de un conjunto de interfaces "[18]) y sus interrelaciones.

• Tarjetas colaborador de responsabilidad Clase (CRC): utilizado para indicar los

nombres de los componentes (Clase), sus responsabilidades y su colaborar

nombre de los componentes.

• Los diagramas de despliegue: se utiliza para representar una un conjunto de

nodos (físicas) y sus interrelaciones, y, por lo tanto, para modelar la física

aspectos del software.

• Diagramas de entidad-relación (ERD): se utilizan para representar los modelos

conceptuales de datos almacenados en los depósitos de información.

• Lenguajes de descripción de interfaz (IDL): lenguajes de programación que se

usa para definir las interfaces (nombres y tipos de exportada operaciones) de los

componentes de software.

• Gráficos de Estructura: se utiliza para describir el llamado estructura de los

programas (que módulos llamada, y son llamados por, qué otros módulos).

6.2. Las descripciones de comportamiento (vista dinámica)

Las siguientes notaciones y lenguajes, alguna gráfica y algún textual, se utilizan

para describir el comportamiento dinámico de los sistemas de software y

componentes. Muchas de estas notaciones son útiles sobre todo, pero no

exclusivamente, durante detallado diseño. Por otra parte, las descripciones de

comportamiento pueden incluir una justificación de la decisión de diseño tales

como cómo un diseño cumplirá con los requisitos de seguridad.

• Diagramas de actividad: se utiliza para mostrar el flujo de control de una

actividad a otra. Puede ser utilizado para representar actividades concurrentes.

• Diagramas de comunicación: se utilizan para mostrar las interacciones que se

producen entre un grupo de los objetos; se hace hincapié en los objetos, sus

enlaces, y los mensajes que intercambian en esos enlaces.

• Diagramas de flujo de datos (DFDs): Se utiliza para mostrar el flujo de datos

entre los elementos. Un diagrama de flujo de datos proporciona "una descripción

basada en el modelado el flujo de información en torno a una red de elementos

operativos, con cada elemento haciendo uso de o la modificación de la

información que fluye en ese elemento "[4 *]. Los flujos de datos (Y por lo tanto los

diagramas de flujo de datos) puede ser utilizado para el análisis de la seguridad,

ya que ofrecen la identificación de caminos posibles para el ataque y la

divulgación información de carácter confidencial.

• Las tablas de decisión y diagramas: usan para representar complejas

combinaciones de condiciones y acciones.

• Diagramas de flujo: Se utiliza para representar el flujo de control y las acciones

asociadas sean realizado.

• Los diagramas de secuencia: se utiliza para mostrar las interacciones entre un

grupo de objetos, con énfasis en el orden de tiempo de mensajes pasó entre

objetos.

• Transición de estado y tabla de estado de los diagramas: se utiliza para mostrar

el flujo de control de un estado a estado y cómo el comportamiento de un

componente cambios en función de su estado actual en un estado máquina.

• Lenguajes de especificación formal: lenguajes textuales que utilizan conceptos

básicos de las matemáticas (Por ejemplo, la lógica, conjunto, secuencia) para

definir con rigor y de forma abstracta de software interfaces de componentes y el

comportamiento, a menudo en términos de condiciones previas y posteriores. (Ver

también los modelos de ingeniería de software y métodosKA).

• Pseudo código del programa y lenguajes de diseño (PDL): lenguajes de

programación estructurados similar se usa para describir, en general, en el etapa

de diseño detallado, el comportamiento de un procedimiento de o método.

7. Diseño de Software estrategias y métodos

Existen varias estrategias generales para ayudar guiar el proceso de diseño. En

contraste con el general estrategias, los métodos son más específicos en cuanto a

que generalmente proporcionar un conjunto de anotaciones para ser utilizado con

el método, una descripción del proceso para ser utilizado cuando se sigue el

método, y un conjunto de directrices para el uso del método. Tales métodos son

útiles como un marco común para los equipos de ingenieros de software. (Véase

también la Ingeniería de Software Modelos y Métodos KA).

7.1. Las estrategias generales

Algunos ejemplos citados con frecuencia de las estrategias generales útil en el

proceso de diseño incluyen la dividendo- conquistar y estrategias de refinamiento

paso a paso, de arriba hacia abajo frente a las estrategias de abajo hacia arriba, y

las estrategias haciendo uso de la heurística, el uso de patrones y el patrón

idiomas, y el uso de un iterativo e incremental enfoque.

7.2. Función-Oriented (Estructurado) Diseño

Este es uno de los métodos clásicos de software diseño, donde los centros de

descomposición en la identificación de las principales funciones del software y

luego elaborar y el perfeccionamiento de ellos en una de arriba abajo jerárquica

manera. Diseño estructurado se utiliza generalmente después de un análisis

estructurado, produciendo de este modo (entre otras cosas) y diagramas de flujo

de datos asociados descripciones de procesos. Los investigadores han propuesto

diversas estrategias (por ejemplo, la transformación análisis, análisis de las

transacciones) y la heurística (por ejemplo, fan-in / abanico de salida, el alcance

del efecto vs. Alcance de control) para transformar un DFD en un software

arquitectura representa generalmente como una estructura gráfico.

7.3. Diseño Orientado a Objetos

Numerosos métodos de diseño de software basadas en los objetos que se han

propuesto. El campo tiene evolucionado desde la temprana orientada a objetos

(OO) diseño de los mediados de los años 1980 (sustantivo = objeto; verbo =

Método; = adjetivo atributo), donde la herencia y el polimorfismo juegan un papel

clave, a la campo del diseño basado en componentes, donde meta información Se

pueden definir y accede (a través la reflexión, por ejemplo). Aunque el diseño de

OO raíces provienen del concepto de abstracción de datos, el diseño impulsado

por la responsabilidad se ha propuesto como un enfoque alternativo para el diseño

OO.

7.4. Estructura de Datos Diseño Centrado

Estructura centrada en los datos de diseño comienza a partir de los datos

estructuras de un programa manipula en lugar de la función que realiza. El

ingeniero de software primera describe las estructuras de datos de entrada y

salida y luego se desarrolla la estructura de control del programa en base a estos

diagramas de estructura de datos. Varios Se han propuesto heurísticas para tratar

con especial casos, por ejemplo, cuando hay una falta de coincidencia entre las

estructuras de entrada y salida.

7.5. Diseño basado en componentes (CDB)

Un componente de software es una unidad independiente, que tiene interfaces y

dependencias bien definidas que puede estar compuesto y desplegados de forma

independiente. Direcciones de diseño basadas en componentes temas

relacionados a proporcionar, desarrollar y la integración de tales componentes con

el fin de mejorar reutilizar. Reutilizados y componentes de software off-the-shelf

debe cumplir los mismos requisitos de seguridad como un nuevo software. La

confianza es la gestión una preocupación de diseño; componentes tratado como

que tiene un cierto grado de confiabilidad debería no depende de componentes

menos fiables o servicios.

7.6. Otros métodos

También existen otros enfoques interesantes (ver el Modelos de Ingeniería de

Software y Métodos KA). Los métodos iterativos y adaptativas implementan

incrementos de software y reducir énfasis el requisito de software riguroso y

diseño. Diseño orientada a aspectos es un método por el cual software se

construye utilizando los aspectos de implementar las preocupaciones

transversales y extensiones que se identifican en los requisitos de software

proceso. Arquitectura orientada a servicios es una manera de construir software

distribuido usando Web los servicios ejecutados en ordenadores distribuidos.

Software Los sistemas se construyen a menudo mediante el uso de los servicios

de diferentes proveedores Por norma protocolos (como HTTP, HTTPS, SOAP)

tienen sido diseñado para soportar la comunicación de servicios y el intercambio

de información de servicio.

8. Herramientas de Diseño de Software

Herramientas de diseño de software se pueden utilizar para apoyar la creación de

los artefactos de diseño de software durante el proceso de desarrollo de software.

Pueden apoyar parte o la totalidad de las siguientes actividades:

• traducir el modelo de requisitos en una representación de diseño;

• proporcionar apoyo para la representación funcional componentes y su interfaz

(s);

• implementar heurísticas y refinamiento partición;

• proporcionar directrices para la evaluación de la calidad.