Introduccin

El diseo se define en como el proceso para definir la arquitectura, los

componentes, los interfaces, y otras caractersticas de un sistema o un
componente y el resultado de este proceso.
Visto como proceso, el diseo del software es la actividad del ciclo de vida de la
cual los requisitos se analizan para producir una descripcin de la estructura
interna del software que servir como la base para su construccin.
Ms exacto, un diseo del software (el resultado) debe describir la arquitectura del
software, en cmo la descomposicin del software, la organizacin de los
componentes, y los interfaces entre los mismos componentes.
INTERRUPCIN DE LOS ASUNTOS PARA EL DISEO DEL SOFTWARE
1. Fundamentos del diseo del software
Los conceptos, las nociones, y la terminologa introducida aqu forman una base
subyacente para entender el papel y el alcance del diseo del software.
1.1. Conceptos generales de diseo
El software no es el nico campo donde est implicado el diseo. En el sentido
amplio, podemos ver diseo como forma de solucionar un problema. Por ejemplo,
el concepto de un problema travieso del problema-uno sin definitivo solucin-es
interesante en trminos de entender los lmites del diseo. [Un nmero de otras
nociones y conceptos estn tambin de inters en diseo el entender en su
sentido general: metas, apremios, alternativas, representaciones, y soluciones.
1.2. Contexto del diseo del software
Para entender el papel del diseo del software, es importante entender el
contexto, el ciclo de vida de la tecnologa de dotacin lgica. As, es importante
entender las caractersticas principales del anlisis de requisitos del software
contra diseo del software contra la construccin del software contra la prueba del
software.
1.3. Proceso del diseo del software
El diseo del software generalmente se considera un proceso de dos etapas:
1.3.1. Diseo arquitectnico

El diseo arquitectnico describe cmo el software se descompone y se organiza

en los componentes (la arquitectura) del software
1.3.2. Diseo detallado
El diseo detallado describe el comportamiento especfico de estos componentes.
La salida de este proceso es un sistema de modelos y los artefactos que registran
las decisiones principales que se han tomado.
1.4. Principios del Diseo de Software
Segn el diccionario del ingls de Oxford, un principio es una verdad bsica o
una ley general... que se utiliza como una base del razonamiento o gua de la
accin. Los principios del diseo del software, tambin llamados tcnicas
permisibles [Bus96], son nociones dominantes que consideran fundamental a los
diversos acercamientos y conceptos del diseo del software. Las tcnicas que lo
permiten son las siguientes:
1.4.1. Abstraccin
La abstraccin es el proceso de olvidarse de la informacin para poder tratar las
cosas que son diferentes como si fueran iguales. En el contexto del diseo del
software, dos mecanismos dominantes de la abstraccin son parametrizacin y
especificacin. La abstraccin por la especificacin conduce a tres clases
importantes de abstraccin: abstraccin procesal, abstraccin de los datos y
abstraccin de control (iteracin)
1.4.2 Acoplamiento y Cohesin
El acoplamiento se define como la fuerza de las relaciones entre los mdulos,
mientras que la cohesin es definida por como los elementos que componen un
mdulo son relacionados.
1.4.3 Descomposicin y modularizacin
Descomposicin y modularizacin del software en partes ms pequeas e
independientes, generalmente con la meta de poner diversas funcionalidades o
responsabilidades en diversos componentes.

1.4.4 Encapsulamiento y Ocultamiento de la informacin

Medios que ocultan del encapsulamiento/de la informacin que agrupan y
empaquetan los elementos y los detalles internos de una abstraccin y que hacen
esos detalles inaccesibles
1.4.5 Separacin de interfaz e implementacin
La separacin del interfaz y de la puesta en prctica implica el definir de un
componente especificando un interfaz pblico, aparte de los detalles de cmo se
observa el componente
1.4.6 Suficiencia, Totalidad, y estados Primitivos
Alcanzando desahogo, lo completo, y medios no primitivos se asegura que un
componente de software captura todas las caractersticas importantes de una
abstraccin
1.4.7 Separacin de intereses
Una preocupacin es una "rea de inters con respecto a un software diseo ".
Una preocupacin diseo es un rea de diseo que es relevante para uno o ms
de sus las partes interesadas. Cada vista de la arquitectura marcos uno o ms
preocupaciones. La separacin de las preocupaciones por las vistas permite a las
partes interesadas centrarse en algunas cosas a la vez y ofrece una los medios de
gestin de la complejidad
2. Cuestiones claves en diseo del software
Se tiene que tener en cuenta a la hora de disear software una serie de principios
claves. Algunos son preocupaciones que todo el software debe tratar -por ejemplo,
funcionamiento de la calidad. Otra edicin importante es cmo se descomponer,
se organiza, y constituyen los paquetes de software. Esto es tan fundamental que
todos los acercamientos del diseo deben tratarlo de un modo u otro (vase las
tcnicas del asunto 1.4 y la subrea 6, los mtodos que permiten el diseo del
software). En cambio, otras ediciones se ocupan de un cierto aspecto del
comportamiento del software que no est en el dominio del uso, pero que trata
algunos de los dominios de soporte. *Bos00+ Tales ediciones, que
interseccionaron a menudo la funcionalidad del sistema, se han referido como
aspectos: *aspectos+ tender para no ser unidades de la descomposicin
funcional del software, sino algo para ser las caractersticas que afectan el
funcionamiento o la semntica de los componentes de manera sistemticas

(Kic97). Un nmero de estas claves, ediciones de la cruz-corte son los siguientes

(presentado en orden alfabtico):
2.1 Concurrencia
Cmo descomponer el software en procesos, tareas, e hilos y reparto con eficacia
relacionada, atomicidad, la sincronizacin, y ediciones programar.
2.2 Control y direccin de acontecimientos
Cmo organizar datos y controlar flujo, cmo manejar acontecimientos reactivos y
temporales a travs de varios mecanismos tales como invocacin y servicios
repetidos implcitos. [Bas98: c5; Mey97: c32; Pfl01: c5]
2.3. Persistencia de los datos
Cmo los datos duraderos deben ser dirigidos.

2.4 Distribucin de componentes

Cmo distribuir el software a travs del hardware, cmo los componentes se
comunican, cmo el middleware se puede utilizar para ocuparse de software
heterogneo. [Bas03: c16; Bos00: c5; Bus96: c el 2 Mar de 94: DD; Mey97: c30;
Pre04: c30]
2.5 Direccin del error y de excepcin y tolerancia de fallos
Cmo prevenir y tolerar averas y ocuparse de condiciones excepcionales. [Lis01:
c4; Mey97: c12; Pfl01: c5]
2.6 Interaccin y presentacin
Cmo estructurar y organizar las interacciones con los usuarios y la presentacin
de la informacin (por ejemplo, separacin de la presentacin y de la lgica del
negocio usando el acercamiento del Modelo-Vista- Regulador). [Bas98: c6; Bos00:
c5; Bus96: c2; Lis01: c13; Mey97: c32] Debe ser observado que este asunto no
est sobre especificar los detalles del interfaz utilizador, que es la tarea del diseo
del interfaz utilizador (una parte de ergonmica del software); ver las disciplinas
relacionadas de la tecnologa de dotacin lgica.
2.7. seguridad

Diseo para la seguridad tiene que ver con la forma de prevenir divulgacin no
autorizada, creacin, cambio, eliminacin, o la denegacin de acceso a la
informacin y otros recursos. Tambin se ocupa de cmo tolerar ataques o
violacines relacionadas con la seguridad de daos limitante, servicio continuado,
el exceso de velocidad reparacin y recuperacin, y en su defecto y recuperar
segura. El control de acceso es un concepto fundamental de la seguridad, y
tambin hay que asegurar el uso adecuado de la criptologa.
3.3 Patrones de diseo
Sucintamente descrito, un patrn es "una comn solucin a un problema comn
en un contexto dado ". Mientras que los estilos arquitectnicos se pueden ver
como patrones que describen la organizacin de alto nivel de software, otros
patrones de diseo se pueden utilizar para describir los detalles en un nivel
inferior. estos menor patrones de diseo de nivel incluyen los siguientes:
Patrones de creacin (por ejemplo, constructor, fbrica, prototipo, Singleton)
Los patrones estructurales (por ejemplo, un adaptador, puente, compuesto,
decorador, fachada, peso mosca, apoderado)
Los patrones de comportamiento (por ejemplo, comandos, intrprete, iterador,
mediador, recuerdo, observador, estado, estrategia, plantilla, visitante).
4. Diseo de la Interfaz de Usuario
El diseo de la interfaz de usuario es una parte esencial del proceso de diseo de
software. Debe asegurarse de que la interaccin entre el humano y la mquina
proporciona una operacin y control de la mquina eficaz. Para que el software
pueda alcanzar su pleno potencial, la interfaz de usuario debe ser diseado para
que coincida con las habilidades, experiencia y expectativas de sus usuarios
previstos.
4.1. Principios generales del diseo de interfaz de usuario
Facilidad de aprendizaje. El software debe ser fcil de aprender para que el
usuario puede empezar a trabajar rpidamente con el software.
familiaridad del usuario. La interfaz debe utilizar trminos y conceptos extrados
de las experiencias de las personas que van a utilizar el software.
Consistencia. La interfaz debe ser consistente para que las operaciones
comparables se activan de la misma manera.
Mnima sorpresa. El comportamiento de software no debe sorprender a los

usuarios.
Recuperabilidad. La interfaz debe proporcionar mecanismos que permiten a los
usuarios recuperar a partir errores.
Gua para el usuario. La interfaz debe dar retroalimentacin 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
interaccin adecuados para diversos tipos de usuarios y para los usuarios con
diferentes capacidades (ciegos, problemas de visin, sordo, daltnico, etc.).4.2
Tcnicas de evaluacin y calidad del anlisis.
4.2. Cuestiones de Diseo de Interfaz de Usuario
El diseo de interfaz de usuario debe resolver dos cuestiones clave:
Cmo debera el usuario interactuar con el software?
Cmo debe la informacin desde el software se presentar al usuario?
Diseo de interfaz de usuario debe integrar usuario la interaccin y la presentacin
de la informacin. Debe considerar un compromiso entre los estilos ms
apropiados para la interaccin y presentacin para el software, los antecedentes y
la experiencia de los usuarios de software y los dispositivos disponibles.
4.3. El diseo de las modalidades de interaccin del usuario
La interaccin del usuario implica dando rdenes and providing datos asociados al
software. estilos de interaccin del usuario se pueden clasificar en los siguientes
estilos principales:
Pregunta respuesta. La interaccin se limita esencialmente a un nico
intercambio de preguntas y respuestas entre el usuario y el software.
El usuario enva una pregunta al software, y el software devuelve la respuesta a la
pregunta.
Manipulacin directa. Los usuarios interactan con objetos en la pantalla del
ordenador. Directo manipulacin a menudo incluye un sealador dispositivo (como
un ratn, trackball o un dedo en pantallas tctiles) que manipula una de objetos y
acciones que especifican lo invoca se debe hacer con ese objeto.
Seleccin de men. El usuario selecciona un comando de una lista de los
comandos de men.

 Forma de relleno. El usuario rellena los campos de una formar. A veces campos
incluyen mens, en cuyo caso la forma tiene botones de accin para al usuario
iniciar la accin.
El lenguaje de comandos. El usuario emite un comando y proporciona los
parmetros relacionados para dirigir el software de qu hacer.
Lenguaje natural. El usuario emite un comando en lenguaje natural. Es decir, el
lenguaje natural es una interfaz a un lenguaje de comandos y se analiza y se
traduce en comandos de software.
4.4. Diseo de la Presentacin de la Informacin
presentacin de la informacin puede ser textual o grfica en la naturaleza. Un
buen diseo mantiene la presentacin de informacin por separado de la
informacin en s misma.
El enfoque MVC (Modelo-Vista-Controlador) es una forma efectiva de mantener la
presentacin de informacin se separe de la informacin que se presenta.
Los ingenieros de software tambin consideran el software tiempo de respuesta y
la retroalimentacin en el diseo de presentacin de la informacin. El tiempo de
respuesta se mide generalmente desde el punto en el que un usuario ejecuta una
cierta accin de control hasta que el software responde con una respuesta. Una
indicacin del progreso es deseable, mientras que el software se est preparando
la respuesta.
La retroalimentacin puede ser proporcionada mediante la reformulacin de la
entrada del usuario mientras que el procesamiento se est terminando.
Abstract visualizaciones pueden ser utilizados cuando grandes cantidades de
informacin se han de presentar.
De acuerdo con el estilo de presentacin de la informacin, los diseadores
tambin pueden utilizar el color para mejorar la interfaz. Existen varias pautas
importantes:
Limite el nmero de colores utilizados.
Use cambio de color para mostrar el cambio de software estado.
Use cdigos de colores para apoyar la tarea del usuario.
Use cdigos de colores en una reflexiva y coherente camino.
Use colores para facilitar el acceso de las personas con ceguera o deficiencia

cromtica de color (Por ejemplo, utilizar el cambio de color y la saturacin el brillo

del color, trate de evitar azul y rojo combinaciones).
No se confe slo en el color para transmitir Informacin importante para los
usuarios con diferente capacidades (ceguera, problemas de visin, ceguera al
color, etc.).
4.5. Proceso de diseo de Interfaz de usuario
El diseo de la interfaz de usuario es un proceso iterativo; prototipos de interfaz a
menudo se utilizan para determinar las caractersticas, la organizacin, y la
apariencia de la interfaz de usuario del software. Este proceso incluye tres
actividades principales:
Anlisis del usuario. En esta fase, el diseador analiza las tareas de los usuarios,
el entorno de trabajo, otro software, y cmo los usuarios interactan con otras
personas.
la creacin de prototipos de software. El desarrollo de prototipos
ayudan a los usuarios de software para guiarla evolucin de
La interfaz.
evaluacin de la interfaz. Los diseadores pueden observar las experiencias de
los usuarios con la interfaz en evolucin.
4.6. Localizacin e internacionalizacin
El diseo de interfaz de usuario a menudo necesita considerar la
internacionalizacin y localizacin, que son medios para adaptar el software a los
diferentes idiomas, las diferencias regionales y los requisitos tcnicos de un
mercado objetivo. La internacionalizacin es el proceso de diseo de una
aplicacin de software de manera que
se puede adaptar a varios idiomas y regiones sin mayores cambios de ingeniera.
La localizacin es el proceso de adaptacin de software internacionalizado para
una regin o idioma mediante la adicin de componentes especficos de
localizacin y traduccin del texto. Localizacin e internacionalizacin deben tener
en cuenta factores tales como smbolos, nmeros, moneda, tiempo y unidades de
medida.
4.7. Metforas y modelos conceptuales
los diseadores de interfaces de usuario pueden utilizar metforas y modelos
conceptuales para establecer correspondencias entre el software y el sistema de
referencia alguna a conocer a los usuarios en el mundo real, lo que puede ayudar
a los usuarios a aprender ms fcilmente y usar la interfaz. Por ejemplo,
la operacin de "borrar archivo" se puede convertir en una

metfora con el icono de un cubo de basura.

En el diseo de una interfaz de usuario, los ingenieros de software deben tener
cuidado de no usar ms de una metfora para cada concepto. Metforas tambin
presentan problemas potenciales con respecto a la internacionalizacin, ya que no
todas las metforas son significativos o se aplican de la misma manera en todas
las culturas
6. Notaciones del Diseo de Software
Existen muchas notaciones para representar artefactos de diseo de software.
Algunos se utilizan para describir la organizacin estructural de un diseo, otros
para representar el comportamiento del software. Ciertas notaciones se utilizan
sobre todo durante el diseo arquitectnico y los dems, principalmente durante el
diseo detallado, aunque algunas anotaciones se pueden utilizar para ambos
propsitos. Adems, algunas notaciones se utilizan sobre todo en el contexto de
los mtodos de diseo especficos (ver tema 7, Diseo de Software Estrategias y
Mtodos). Tenga en cuenta que el diseo de software a menudo se logra
utilizando mltiples anotaciones. A continuacin, se clasifican en las notaciones
para describir el punto de vista estructural (esttico) frente a la vista del
comportamiento (dinmica).

6.1. Las descripciones estructurales (esttico Vista)

Las siguientes anotaciones, en su mayora, pero no siempre grfica, describir y
representar los aspectos estructurales de un diseo de que el software es, que se
utilizan para describir los componentes principales y la forma en que estn
interconectados (visin esttica):
lenguajes de descripcin de Arquitectura (AVD): textual, tienden a ser formales,
idiomas utilizados para describir la arquitectura de software en trminos de
componentes y conectores.
diagramas de clase y objeto: se utiliza para representar un conjunto de clases (y
objetos) y sus interrelaciones.
Diagramas de componentes: se utiliza para representar un conjunto de
componentes ( "parte fsica y reemplazable [s] de un sistema que [se ajustan] ay
[proporcionar] la realizacin de un conjunto de interfaces" [18]) y sus
interrelaciones.
Tarjetas de responsabilidad Clase colaboradoras (CRC): se utiliza para denotar
los nombres de los componentes (clase), sus responsabilidades, y los nombres de
sus componentes colaboradoras '.

 Los diagramas de despliegue: se utiliza para representar un conjunto de nodos

(fsicas) y sus interrelaciones, y, por tanto, para modelar los aspectos fsicos del
software.
diagramas de entidad-relacin (ERD): se utilizan para representar los modelos
conceptuales de los datos almacenados en los depsitos de informacin.
Descripcin de interfaces (IDL) idiomas: lenguajes de programacin que se usa
para definir las interfaces (nombres y tipos de operaciones exportados) de los
componentes de software.
Grficos de Estructura: se utiliza para describir la estructura de los programas de
llamada (llamada cuales mdulos, y son llamados por, qu otros mdulos).
6.2. Las descripciones de comportamiento (vista dinmica)
Las siguientes notaciones y lenguajes, algunos grfica y algunos textual, se
utilizan para describir el comportamiento dinmico de los sistemas y componentes
de software. Muchas de estas notaciones son tiles sobre todo, pero no
exclusivamente, durante el diseo detallado. Por otra parte, las descripciones del
comportamiento pueden incluir una justificacin de la decisin de diseo tales
como la forma de un diseo 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 las actividades concurrentes.
Diagramas de comunicacin: se utilizan para mostrar las interacciones que se
producen entre un grupo de objetos; se hace hincapi en los objetos, sus enlaces,
y los mensajes que intercambian en estos enlaces.
Los 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 descripcin
basada en el modelado de la circulacin de informacin alrededor de una red de
elementos operativos, con cada elemento haciendo uso de o la modificacin de la
informacin que fluye en ese elemento" [4 *]. Los flujos de datos (y por tanto los
diagramas de flujo de datos) se pueden utilizar para el anlisis de la seguridad, ya
que ofrecen la identificacin de posibles caminos para el ataque y la revelacin de
la informacin confidencial.
Las tablas de decisin y diagramas: se utilizan para representar combinaciones
complejas de condiciones y acciones.
Diagramas de flujo: se utiliza para representar el flujo de control y las acciones
asociadas a realizar.
Los diagramas de secuencia: se utiliza para mostrar las interacciones entre un
grupo de objetos, con nfasis en el ordenamiento hora de los mensajes
intercambiados entre los objetos.
transicin de estados y tabla de estado: diagramas utilizados para mostrar el flujo
de control de estado a estado y cmo el comportamiento de un componente
cambia en funcin de su estado actual en una mquina de estados. lenguajes de
especificacin formales: lenguajes textuales que utilizan nociones bsicas de
matemticas (por ejemplo, la lgica, juego, secuencia) para definir con rigor y de
forma abstracta interfaces de componentes de software y comportamiento, a

menudo en trminos de condiciones previas y posteriores. (Ver tambin los

modelos de ingeniera de software y mtodos KA).
pseudo cdigo y el diseo del programa idiomas (PDL): estructurados lenguajes
de programacin que se usa para describir, en general, en el diseo detallado del
macho
7. Diseo de Software estrategias y mtodos
Existen varias estrategias generales para ayudar a guiar el proceso de diseo. En
contraste con las estrategias generales, los mtodos son ms especficos en
cuanto a que proporcionan generalmente un conjunto de anotaciones para ser
usado con el mtodo, una descripcin del proceso que se utilizar cuando se
sigue el mtodo, y un conjunto de directrices para el uso del mtodo. Tales
mtodos son tiles como un marco comn para los equipos de ingenieros de
software. (Ver tambin los modelos de ingeniera de software y mtodos KA).
7.1. Las estrategias generales
Algunos ejemplos citados con frecuencia delas estrategias generales tiles en el
proceso de diseo incluyen las estrategias divide y vencers y refinamiento paso a
paso, de arriba hacia abajo frente a las estrategias de abajo hacia arriba, y las
estrategias que hacen uso de la heurstica, el uso de modelos y lenguajes de
patrones, y el uso de un enfoque iterativo e incremental.
7.2. Funcin-Oriented (Estructurado) Diseo
Este es uno de los mtodos clsicos de diseo de software, donde los centros de
descomposicin en la identificacin de las principales funciones del software y
luego elaborar y refinar ellos de una manera jerrquica de arriba abajo. Diseo
estructurado se utiliza generalmente despus de un anlisis estructurado,
produciendo de este modo (entre otras cosas) diagramas de flujo de datos y
descripciones de procesos asociados. Los investigadores han propuesto diversas
estrategias (por ejemplo, el anlisis de la transformacin, anlisis de las
transacciones) y heurstica (por ejemplo, fan-in / fan-out, el alcance del efecto vs.
alcance de control) para transformar un DFD en una arquitectura de software
general representado como una carta de estructura.
7.3. Diseo Orientado a Objetos
Se han propuesto numerosos mtodos de diseo de software basados en objetos.
El campo ha evolucionado a partir de la (OO) inicial de diseo orientado a objetos
de mediados de la dcada de 1980 (sustantivo = objeto; verbo = mtodo; adjetivo
= atributo), donde la herencia y el polimorfismo juegan un papel clave, al campo
del diseo basado en componentes, donde metainformacin se puede definir y se
accede a (a travs de la reflexin, por ejemplo). Aunque las races del diseo

orientado a objetos provienen del concepto de abstraccin de datos, diseo

impulsado por la responsabilidad ha sido propuesta como un enfoque alternativo al
diseo orientado a objetos.
7.4. Estructura de Datos Diseo Centrado
estructura centrada en datos de diseo comienza a partir de las estructuras de
datos de un programa manipula en lugar de partir de la funcin que
realiza. El ingeniero de software describe en primer lugar 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. Se han propuesto
varias heursticas para hacer frente a los casos ejemplo especial-para, cuando
hay una falta de coincidencia entre las estructuras de entrada y salida.
7.5. Diseo basado en componentes (CDB)
Un componente de software es una unidad independiente, que tiene interfaces y
dependencias que se pueden componer y desplegarse de forma independiente
bien definidos. aborda cuestiones de diseo basadas en componentes
relacionados con la prestacin, el desarrollo y la integracin de estos
componentes con el fin de mejorar la reutilizacin. Reutilizados y off-the-shelf
componentes de software deben cumplir los mismos requisitos de seguridad como
un nuevo software. gestin de la confianza es un problema de diseo;
componentes tratan como si tuvieran un cierto grado de fiabilidad no debe
depender de los componentes o servicios sean menos fiables.
7.6. Otros mtodos
Tambin existen otros enfoques interesantes (ver los modelos de ingeniera de
software y mtodos KA). Los mtodos iterativos y adaptativas aplicar incrementos
de software y reducir nfasis en el requisito de software rigurosa y diseo.
diseo orientado a aspectos es un mtodo por el cual el software se construye con
aspectos para implementar las preocupaciones y las extensiones transversales
que son identificados durante el proceso de requisitos de software. arquitectura
orientada a servicios es una manera de construir software distribuido mediante
servicios web ejecutados en ordenadores distribuidos. Los sistemas de software
se construyen a menudo por el uso de servicios de diferentes proveedores ya que
los protocolos estndar (como HTTP, HTTPS, SOAP) han sido diseados para
soportar la comunicacin y el intercambio de servicios de informacin de servicio.
8. Herramientas de Diseo de Software
herramientas de diseo de software se pueden utilizar para apoyar la creacin de
los artefactos de diseo 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 representacin de diseo;
proporcionar apoyo para la representacin de los componentes funcionales y su
interfaz (s);
implementar heursticas refinamiento y la particin;
proporcionar directrices para la evaluacin de la calidad.