You are on page 1of 8

Centro Universitario UAEM Atlacomulco

Evelin Carbajal Garca


Ico9

CONCEPTOS Y PRINCIPIOS DE DISEO

El diseo del software, al igual que los enfoques de diseo de ingeniera en


otras disciplinas, va cambiando continuamente a medida que se desarrollan
mtodos nuevos, anlisis mejores y se amplia el conocimiento. Las
metodologas de diseo del software carecen de la profundidad, flexibilidad
y naturaleza cuantitativa que se asocian normalmente a las disciplinas de
diseo de ingeniera ms clsicas. Sin embargo, s existen mtodos para el
diseo del software; tambin se dispone de calidad de diseo y se pueden
aplicar notaciones de diseo.

EL DISEO DEL SOFTWARE E INGENIERIA DEL SOFTWARE

Una vez que se analizan y especifican los requisitos del software, el diseo
del software es la primera de las tres actividades tcnicas -diseo,
generacin de cdigo y pruebas- que se requieren para construir y verificar
el software. Cada actividad transforma la informacin de manera que d
lugar por ltimo a un software de computadora validado.

Cada uno de los elementos del modelo de anlisis proporciona la


informacin necesaria para crear los cuatro modelos de diseo que se
requieren para una especificacin completa de diseo.

El diseo de datos transforma el modelo del dominio de informacin que se


crea durante el anlisis en las estructuras de datos que se necesitarn para
implementar el software.

El diseo arquitectnico define la relacin entre los elementos estructurales


principales del software, los patrones de diseo que se pueden utilizar para
lograr los requisitos que se han definido para el sistema, y las restricciones
que afectan a la manera en que se pueden aplicar los patrones de diseo
arquitectnicos

El diseo de la interfaz describe la manera de comunicarse el software


dentro de s mismo, con sistemas que interoperan dentro de l y con las
personas que lo utilizan.

El diseo a nivel de componentes transforma los elementos estructurales de


la arquitectura del software en una descripcin procedimental de los
componentes del software.

El diseo proporciona las representaciones del software que se pueden


evaluar en cuanto a calidad, es la nica forma de convertir exactamente los
requisitos de un cliente en un producto o sistema de software finalizado.

EL PROCESO DE DISEO

El diseo del software es un proceso iterativo mediante el cual los requisitos


se traducen en un plano para construir el software.

Diseo y calidad del software. Para la evaluacin de un buen diseo:


Centro Universitario UAEM Atlacomulco
Evelin Carbajal Garca
Ico9

El diseo deber implementar todos los requisitos explcitos del


modelo de anlisis, y debern ajustarse a todos los requisitos
implcitos que desea el cliente;
El diseo deber ser una gua legible y comprensible para aquellos
que generan cdigo y para aquellos que comprueban y
consecuentemente, dan soporte al software;
El diseo deber proporcionar una imagen completa del software,
enfrentndose a los dominios de comportamiento, funcionales y de
datos desde una perspectiva de implementacin.

Con el fin de evaluar la calidad de una representacin de diseo, debern


establecerse los criterios tcnicos para un buen diseo.

1. Un diseo deber presentar una estructura arquitectnica que (1) se


haya creado mediante patrones de diseo reconocibles, (2) que est
formada por componentes que exhiban caractersticas de buen
diseo), y (3) que se puedan implementar de manera evolutiva,
facilitando as la implementacin y la comprobacin.
2. Un diseo deber ser modular; esto es, el software deber dividirse
lgicamente en elementos que realicen funciones y subfunciones
especficas.
3. Un diseo deber contener distintas representaciones de datos,
arquitectura, interfaces y componentes (mdulos).
4. Un diseo deber conducir a estructuras de datos adecuadas para
los objetos que se van a implementar y que procedan de patrones de
datos reconocibles.
5. Un diseo deber conducir a componentes que presenten
caractersticas funcionales independientes.
6. Un diseo deber conducir a interfaces que reduzcan la complejidad
de las conexiones entre los mdulos y con el entorno externo.
7. Un diseo deber derivarse mediante un mtodo repetitivo y
controlado por la informacin obtenida durante el anlisis de los
requisitos del software.

La evolucin del diseo de software. Independientemente del modelo de


diseo que se utilice, un ingeniero del software deber aplicar un conjunto
de principios fundamentales y conceptos bsicos para el diseo a nivel de
componentes, de interfaz, arquitectnico y de datos.

PRINCIPIOS DEL DISEO

El diseo de software es tanto un proceso como un modelo. El proceso de


diseo es una secuencia de pasos que hacen posible que el diseador
describa todos los aspectos del software que se va construir.

El modelo de diseo es el equivalente a los planes de un arquitecto para


una casa. Comienza representando la totalidad de todo lo que se va a
construir (por ejemplo, una representacin en tres dimensiones de la casa) y
refina lentamente lo que va a proporcionar la gua para construir cada
detalle (por ejemplo, el diseo de fontanera).
Centro Universitario UAEM Atlacomulco
Evelin Carbajal Garca
Ico9

Los principios bsicos de diseo hacen posible que el ingeniero del software
navegue por el proceso de diseo.

En el proceso de diseo no deber utilizarse orejeras . Un buen


diseador deber tener en cuenta enfoques alternativos, juzgando
todos los que se basan en los requisitos del problema, los recursos
disponibles para realizar el trabajo y los conceptos de diseo.
El diseo deber poderse rastrear hasta el modelo de anlisis. Dado
que un solo elemento del modelo de diseo suele hacer un
seguimiento de los mltiples requisitos, es necesario tener un medio
de rastrear cmo se han satisfecho los requisitos por el modelo de
diseo.
El diseo no deber inventar nada que ya est inventado. Los
sistemas se construyen utilizando un conjunto de patrones de diseo,
muchos de los cuales probablemente ya se han encontrado antes.
Estos patrones debern elegirse siempre como una alternativa para
reinventar.
El diseo deber minimizar la distancia intelectual entre el
software y el problema como si de la misma vida real se tratara. Es
decir, la estructura del diseo del software (siempre que sea posible)
imita la estructura del dominio del problema.
El diseo deber presentar uniformidad e integracin. Un diseo es
uniforme si parece que fue una persona la que lo desarroll por
completo. Las reglas de estilo y de formato debern definirse para un
equipo de diseo antes de comenzar el trabajo sobre el diseo.
El diseo deber estructurarse para admitir cambios.
El diseo deber estructurarse para degradarse poco a poco, incluso
cuando se enfrenta con datos, sucesos o condiciones de operacin
aberrantes. Un software bien diseado no deber nunca explotar
como una <<bomba. Deber disearse para adaptarse a
circunstancias inusuales, y si debe terminar de funcionar, que lo haga
de forma suave.
El diseo no es escribir cdigo y escribir cdigo no es disear. Incluso
cuando se crean diseos procedimentales para componentes de
programas, el nivel de abstraccin del modelo de diseo es mayor
que el cdigo fuente. Las nicas decisiones de diseo realizadas a
nivel de codificacin se enfrentan con pequeos datos de
implementacin que posibilitan codificar el diseo procedimental.
El diseo deber evaluarse en funcin de la calidad mientras se va
creando, no despus de terminarlo.
El diseo deber revisarse para minimizar los errores conceptuales
(semnticos).. Un equipo de diseadores deber asegurarse de haber
afrontado los elementos conceptuales principales antes de
preocuparse por la sintaxis del modelo del diseo.

CONCEPTOS DEL DISEO

El comienzo de la sabidura para un ingeniero del software es reconocer la


diferencia entre hacer que un programa funcione y conseguir que lo haga
Centro Universitario UAEM Atlacomulco
Evelin Carbajal Garca
Ico9

correctamente. Los conceptos de diseo de software fundamentales


proporcionan el marco de trabajo necesario para conseguir que lo haga
correctamente.

Abstraccin. La nocin psicolgica de abstraccin permite concentrarse


en un problema a algn nivel de generalizacin sin tener en consideracin
los datos irrelevantes de bajo nivel; la utilizacin de la abstraccin tambin
permite trabajar con conceptos y trminos que son familiares en el entorno
del problema sin tener que transformarlos en una estructura no familiar.

Una abstraccin procedimental es una secuencia nombrada de instrucciones


que tiene una funcin especfica y limitada.

Una abstraccin de datos es una coleccin nombrada de datos que describe


un objeto de datos

La abstraccin de control es la tercera forma de abstraccin que se utiliza


en el diseo del software. Al igual que las abstracciones procedimentales y
de datos, este tipo de abstraccin implica un mecanismo de control de
programa sin especificar los datos internos.

Refinamiento. El desarrollo de un programa se realiza refinando


sucesivamente los niveles de detalle procedimentales. Una jerarqua se
desarrolla descomponiendo una sentencia macroscpica de funcin (una
abstraccin procedimental) paso a paso hasta alcanzar las sentencias del
lenguaje de programacin.

El refinamiento verdaderamente es un proceso de elaboracin. Se comienza


con una sentencia de funcin (o descripcin de informacin) que se define a
un nivel alto de abstraccin. Esto es, la sentencia describe la funcin o
informacin conceptualmente, pero no proporciona informacin sobre el
funcionamiento interno de la informacin.

Modularidad. La modularidad es el nico atributo del software que permite


gestionar un programa intelectualmente. El software monoltico (es decir,
un programa grande formado por un nico mdulo) no puede ser entendido
fcilmente por el lector.

Se definen cinco criterios que nos permitirn evaluar un mtodo de diseo


en relacin con la habilidad de definir un sistema modular efectivo:

Capacidad de descomposicin modular. Si un mtodo de diseo


proporciona un mecanismo sistemtico para descomponer el
problema en subproblemas, reducir la complejidad de todo el
problema, consiguiendo de esta manera una solucin modular
efectiva.
Capacidad de empleo de componentes modulares. Si un mtodo de
diseo permite ensamblar los componentes de diseo (reusables)
existentes en un sistema nuevo, producir una solucin modular que
no inventa nada ya inventado.
Centro Universitario UAEM Atlacomulco
Evelin Carbajal Garca
Ico9

Capacidad de comprensin modular. Si un mdulo se puede


comprender como una unidad autnoma (sin referencias a otros
mdulos) ser ms fcil de construir y de cambiar.
Continuidad modular. Si pequeos cambios en los requisitos del
sistema provocan cambios en los mdulos individuales, en vez de
cambios generalizados en el sistema, se minimizar el impacto de los
efectos secundarios de los cambios.
Proteccin modular. Si dentro de un mdulo se produce una condicin
aberrante y sus efectos se limitan a ese mdulo, se minimizar el
impacto de los efectos secundarios inducidos por los errores.

Arquitectura del software. La arquitectura es la estructura jerrquica de


los componentes del programa (mdulos), la manera en que los
componentes interactan y la estructura de datos que van a utilizar los
componentes.

Dada la especificacin de estas propiedades, el diseo arquitectnico se


puede representar mediante uno o ms modelos diferentes.

Los modelos estructurales representan la arquitectura como una


coleccin organizada de componentes de programa.
Los modelos del marco de trabajo aumentan l nivel de abstraccin del
diseo en un intento e identificar los marcos de trabajo (patrones)
repetibles el diseo arquitectnico que se encuentran en tipos
similares de aplicaciones.
Los modelos dinmicos tratan los aspectos de comportamiento de la
arquitectura del programa, indicando cmo puede cambiar la
estructura o la configuracin del sistema en funcin de los
acontecimientos externos.
Los modelos de proceso se centran en el diseo del proceso tcnico
de negocios que tiene que adaptar el sistema. Finalmente los
modelos funcionales se pueden utilizar para representar la jerarqua
funcional de un sistema.

Jerarqua de control. La jerarqua de control, denominada tambin


estructura de programa, representa la organizacin de los componentes de
programa (mdulos) e implica una jerarqua de control.

La relacin de control entre los mdulos se expresa de la manera siguiente:


se dice que un mdulo que controla otro mdulo es superior a l, e
inversamente, se dice que un mdulo controlado por otro mdulo es
subordinado del controlador.

La jerarqua de control tambin representa dos caractersticas sutiles


diferentes de la arquitectura del software: visibilidad y conectividad. La
visibilidad indica el conjunto de componentes de programa que un
componente dado puede invocar o utilizar como datos, incluso cuando se
lleva a cabo indirectamente. La conectividad indica el conjunto de
componentes que un componente dado invoca o utiliza directamente como
datos.
Centro Universitario UAEM Atlacomulco
Evelin Carbajal Garca
Ico9

Divisin estructural. La estructura del programa se puede dividir tanto


horizontal como verticalmente. La divisin horizontal de la arquitectura
proporciona diferentes ventajas:

proporciona software ms fcil de probar


conduce a un software ms fcil de mantener
propaga menos efectos secundarios
proporciona software ms fcil de ampliar

La divisin vertical, frecuentemente llamada factorizacin (factoring)


sugiere que dentro de la estructura de programa el control (toma de
decisiones) y el trabajo se distribuyan de manera descendente. Los mdulos
del nivel superior debern llevar a cabo funciones de control y no realizarn
mucho trabajo de procesamiento. Los mdulos que residen en la parte
inferior de la estructura debern ser los trabajadores, aquellos que realizan
todas las tareas de entrada, proceso y salida.

Estructura de datos. La estructura de datos es una representacin de la


relacin lgica entre elementos individuales de datos. La estructura dicta
las alternativas de organizacin, mtodos de acceso, grado de capacidad de
asociacin y procesamiento de la informacin.

La organizacin y complejidad de una estructura de datos estn limitadas


nicamente por la ingenuidad del diseador. Sin embargo, existe un nmero
limitado de estructuras de datos clsicas que componen los bloques de
construccin para estructuras ms sofisticadas.

Un elemento escalar es la estructura de datos ms simple. Como su nombre


indica, un elemento escalar representa un solo elemento de informacin que
puede ser tratado por un identificador

Cuando los elementos escalares se organizan como una lista o grupo


contiguo, se forma un vector secuencial. Los vectores son las estructuras de
datos ms comunes y abren la puerta a la indexacin variable de la
informacin.

Cuando el vector secuencia1 se ampla a dos, tres y por ltimo a un nmero


arbitrario de dimensiones, se crea un espacio n-dimensional. El espacio n-
dimensional ms comn es la matriz bidimensional. En muchos lenguajes de
programacin, un espacio n-dimensional se llama array.

Procedimiento de software. El procedimiento de software se centra en el


procesamiento de cada mdulo individualmente. El procedimiento debe
proporcionar una especificacin precisa de procesamiento, incluyendo la
secuencia de sucesos, los puntos de decisin exactos, las operaciones
repetitivas e incluso la estructura/organizacin de datos.

Ocultacin de informacin. El procedimiento de software se centra en el


procesamiento de cada mdulo individualmente. El procedimiento debe
proporcionar una especificacin precisa de procesamiento, incluyendo la
Centro Universitario UAEM Atlacomulco
Evelin Carbajal Garca
Ico9

secuencia de sucesos, los puntos de decisin exactos, las operaciones


repetitivas e incluso la estructura/organizacin de datos.

DISEO MODULAR EFECTIVO

Independencia funcional. La independencia funcional se consigue


desarrollando mdulos con una funcin determinante y una aversin a
una interaccin excesiva con otros mdulos. Dicho de otra manera,
queremos disear el software de manera que cada mdulo trate una
subfuncin de requisitos y tenga una interfaz sencilla cuando se observa
desde otras partes de la estructura del programa.

Cohesin. Un mdulo cohesivo lleva a cabo una sola tarea dentro de un


procedimiento de software, lo cual requiere poca interaccin con los
procedimientos que se llevan a cabo en otras partes de un programa. Dicho
de manera sencilla, un mdulo cohesivo deber (idealmente) hacer una sola
cosa.

Acoplamiento. El acoplamiento es una medida de interconexin entre


mdulos dentro de una estructura de software. El acoplamiento depende de
la complejidad de interconexin entre los mdulos, el punto donde se realiza
una entrada o referencia a un mdulo, y los datos que pasan a travs de la
interfaz.

El grado ms alto de acoplamiento, acoplamiento de contenido, se da


cuando un mdulo hace uso de datos o de informacin de control
mantenidos dentro de los lmites de otro mdulo. En segundo lugar, el
acoplamiento de contenido ocurre cuando se realizan bifurcaciones a mitad
de mdulo. Este modo de acoplamiento puede y deber evitarse.

HEURISTICA DE DISEO PARA UNA MODULARIDAD EFECTIVA

La estructura de programa se puede manipular de acuerdo con el siguiente


conjunto de heursticas:

1. Evaluar la primera iteracin de la estructura de programa para


reducir al acoplamiento y mejorar la cohesin.
2. Intentar minimizar las estructuras con un alto grado de salida;
esforzarse por la entrada a medida que aumenta la profundidad.
3. Mantener el mbito del efecto de un mdulo dentro del mbito de
control de ese mdulo.
4. Evaluar las interfaces de los mdulos para reducir la complejidad y la
redundancia, y mejorar la consistencia.
5. Definir mdulos cuya funcin se pueda predecir, pero evitar mdulos
que sean demasiado restrictivos.
6. Intentar conseguir mdulos de entrada controlada, evitando
conexiones patolgicas.

DOCUMENTACION DEL DISEO


Centro Universitario UAEM Atlacomulco
Evelin Carbajal Garca
Ico9

La Especificacin del diseo aborda diferentes aspectos del modelo de


diseo y se completa a medida que el diseador refina su propia
representacin del software. En primer lugar, se describe el mbito global
del esfuerzo realizado en el diseo. La mayor parte de la informacin que se
presenta aqu se deriva de la Especificacin del sistema y del modelo de
anlisis (Especificacin de los requisitos del software).

Contiene una referencia cruzada de requisitos. El propsito de esta


referencia cruzada (normalmente representada como una matriz simple) es:
(1) establecer que todos los requisitos se satisfagan mediante el diseo del
software, y (2) indicar cuales son los componentes crticos para la
implementacin de requisitos especficos.

Las restricciones de diseo, tales como limitaciones fsicas de memoria o la


necesidad de una interfaz externa especializada, podrn dictar requisitos
especiales para ensamblar o empaquetar el software. Consideraciones
especiales originadas por la necesidad de superposicin de programas,
gestin de memoria virtual, procesamiento de alta velocidad u otros
factores podrn originar modificaciones en diseo derivadas del flujo o
estructura de la informacin. Adems, esta seccin describe el enfoque que
se utilizar para transferir software al cliente.

La ltima seccin de la Especificacin del diseo contiene datos


complementarios, ser aconsejable desarrollar un Manual preliminar de
Operaciones de instalacin e incluirlo como apndice para la documentacin
del diseo.

CONCLUSIONES

Una vez que se analizan y especifican los requisitos del software que se va a
contruir, se deben contemplar tres tcnicas: el diseo, la generacin de
codigo y las pruebas que se requieran para construir y verificar el
software,estas actividades transforman la informacin de tal forma que el
resultado sea un software por computadora validado.
El proceso de diseo es una secuencia de pasos que hacen posible que el
diseador describa todos los aspectos del software que se va construir.

La utilizacin de mdulos es la manera en que los componentes interactan


y definen la estructura de datos que van a utilizar los componentes del
sistema que se desea disear. El obejtivo es disear el software de manera
que cada mdulo trate una subfuncin de requisitos y que tenga una
interfaz sencilla cuando se observa desde otras partes de la estructura del
programa.

Adems de proporcionar software mas fcil de probar, mantener y ampliar,


que tenga menos efectos secundarios (inconsistencias y/o errores),un
software de calidad.

You might also like