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.