You are on page 1of 7

Diseño del Software

Diseñar es una forma de resolución de problemas y juega un papel
clave en el desarrollo de software porque permite a los ingenieros
de software producir diversos modelos que:



Caracterizan la solución a implementar.
Pueden ser analizados y evaluados con el fin de determinar si
se satisfacen los requisitos.
Facilitan el examen y evaluación de alternativas.
Sirven para planificar las siguientes actividades del
desarrollo.

Diseñar es el esfuerzo para definir la arquitectura, componentes,
interfaces y otras características de un sistema o componente IEEE
610-1990].
El Diseño de Software es la actividad del ciclo de vida del software
en la cual se analizan los requisitos para producir una descripción
de la estructura interna del software que sirva de base para su
construcción.
La salida o resultado del diseño es un conjunto de modelos y
artefactos que registran las principales decisiones adoptadas.
Un diseño de software describe la arquitectura del software (cómo
está descompuesto y organizado en componentes), las interfaces entre
dichos componentes, y los componentes a un nivel de detalle que
permita su construcción.
El estándar ISO 12207 identifica dos tipos de diseño de software:
1. Arquitectural o Arquitectónico [alto nivel]: Describe la
estructura y organización de alto nivel, es decir, los
subsistemas o componentes y sus relaciones
2. Detallado [bajo nivel]: Describe cada componente y su
comportamiento específico, de forma que puede procederse a su
construcción.

. En el diseño arquitectónico se decisiones como las siguientes: hace necesario tomar algunas ¿Existe una arquitectura genérica que pueda ser usada? ¿Cómo será distribuido el sistema? ¿Qué estilos arquitectónicos son apropiados? ¿Qué aproximación se utilizará para estructurar el sistema? ¿Cómo se descompondrá el sistema en módulos? ¿Qué estrategia de control se utilizará? ¿Cómo se evaluará el diseño arquitectónico resultante? ¿Cómo se documentará la arquitectura? Principios elementales de diseño Los principios de diseño son verdades básicas o leyes generales que se utilizan como base de razonamiento o como guía para actuar. su resultado se conoce como arquitectura del software y representa el enlace o conexión entre la especificación de requisitos y el diseño. Algunos principios básicos son: Abstracción: consideración aislada de las cualidades esenciales de un objeto. previo al diseño detallado.Diseño Arquitectural o Arquitectónico Es el primer paso en el diseño de un sistema. Los principios del diseño software son nociones claves consideradas fundamentales en muchas aproximaciones y conceptos de diseño diferentes. habitualmente con el fin de situar diferentes funcionalidades o responsabilidades en diferentes componentes. de forma que las actividades a realizar pueden cambiar según la naturaleza del sistema a desarrollar. Descomposición: descomponer un software en diversas unidades más pequeñas. Implica un esfuerzo creativo. o del mismo objeto en su pura esencia o noción. Acoplamiento: Fortaleza de las relaciones entre módulos. Cohesión: cómo están relacionados los elementos de un mismo módulo. puede llevarse a cabo en paralelo con actividades de especificación de requisitos.

los programadores tienden a desarrollar funcionalidades que no están seguros de necesitar. que hace que una clase obtenga las referencias a objetos que necesita para funcionar.Encapsulamiento (ocultamiento de información): consiste en agrupar y empaquetar los elementos y detalles internos de una abstracción y hacer que dichos detalles sean inaccesibles desde fuera. y no desparramado por todo el código fuente. Así se ahorra tiempo y esfuerzo. La una unidad solo debe hablar con amigos y nunca con extraños. se debe extraer ese código a una función para encapsularlo. . El principio de Hollywood: basado en la típica respuesta que se les da a los actores que hacen una prueba para una película: “No nos llame. una unidad solo debe tener conocimiento limitado de otras unidades. a través de una entidad externa. El código siempre puede mejorar. El código duplicado es propenso a generar errores y es difícil de mantener. Cuánto más sencillo sea. Hay que evitar la complejidad como norma general. Si se puede. este estará localizado en un solo punto. para evitar problemas posteriores. nosotros le llamaremos“. Que sea simple. mejor. Un ejemplo del principio de Hollywood es la inversión de control (IoC). viene a decir que no se debe implementar algo si no se está seguro de necesitarlo. se debe refactorizar el código para dejarlo todavía más limpio y simple que antes. Simplemente lo hacen “por si acaso”. No te repitas: el DRY (Don’t repeat yourself) es uno de los principios más importantes. Si se está repitiendo código. estúpido: conocido como KISS (Keep It Simple Stupid) y se refiere a que el diseño de un programa debe ser sencillo. Y además muy simple de entender. El principio YAGNI: muchas veces. y solo conocer aquellas que están relacionadas. No hay que escribir código duplicado. Este principio está relacionado con el principio de inversión de dependencias de SOLID. La Ley de Demeter: Según este principio. pero sobre todo la complejidad innecesaria. Si se tiene que hacer un cambio. El principio YAGNI (You ain’t gonna need it). La regla del Boy Scout: los diseñadores deben hacer como los Boy Scout. que dejan el campo más limpio que cuándo llegaron.

Modularidad del software Un buen diseño debe estar basado en una alta cohesión y un bajo acoplamiento. El diseño estructurado. para resolver un problema complejo de desarrollo de software. El diseño de datos reconoce y transforma la información requerida por el software en estructuras de datos que puedan ser implementadas durante la fase de codificación. desarrollar. de manera sencilla y lo más independientemente posible del resto de la aplicación. fue “programación modular”. mientras que la relación que se da entre los componentes internos del software se denomina interfaz interna. y pasó luego a la orientación a objetos. El diseño procedimental transforma los componentes estructurales del software en descripciones procedimentales o algorítmicas. cuando se quiere usar un nombre genérico. a este tipo de diseño se le denomina interfaz externa. 3) de interfaz y 4) procedimental. los módulos de la programación estructurada serían los procedimientos y . cuando se habla de componentes estructurales dependiendo de la metodología de desarrollo pueden ser módulo y clases. El diseño arquitectónico se encarga de la definición de los componentes estructurales del software. Esas partes. Esto es. luego caído en desuso. Modularidad El aporte más importante que hizo el diseño estructurado fue la idea de que. conviene separarlo en partes más pequeñas. dicha regla proviene de la década de los ochentas y fue uno de los primeros principios proclamados del diseño estructurado. se basó en las propias funciones del sistema. De allí que otro nombre para la programación estructurada. El diseño de interfaz establece la relación que se dará entre hombre y máquina. al plantear la separación del sistema en módulos. que se puedan diseñar.Al momento de desarrollar software y en específico al comenzar con la fase de diseño se pueden reconocer los siguientes tipos: 1) arquitectónico. 2) de datos. probar y modificar. habitualmente se denominan módulos. La cohesión y acoplamiento tiene que ver con la modularidad.

pero importante para agrupar clases en el diseño de aplicaciones medianas. y volver a hacer el test. Como se dijo. pero estos tienen una importancia menor respecto del módulo por excelencia. Bertrand Meyer tiene una frase bastante acertada al hablar de cómo obtener los módulos en la orientación a objetos: “No pregunte qué hace el sistema. ¿Qué ocurriría con los otros dos? . que serían los métodos u operaciones de las clases. suele aparecer otro tipo de módulo más. La orientación a objetos también tiene módulos funcionales. del dominio del problema. A mayor cohesión. sino primero el problema (en el análisis) y luego. En programación estructurada se modulariza la solución. en el análisis y diseño orientados a objetos. no se modulariza la solución. se logra alta cohesión cuando cada módulo (función o procedimiento) realiza una única tarea trabajando sobre una sola estructura de datos. partiendo de esas clases conceptuales. En el diseño estructurado. En el diseño orientado a objetos las cosas son más complejas. hay tres tipos de módulos: clases. En el diseño orientado a objetos. Cohesión La cohesión tiene que ver con que cada módulo del sistema se refiera a un único proceso o entidad. se puede adoptar las mismas definiciones y recetas que para los procedimientos y funciones del diseño estructurado. sino a quién se lo hace”. Un test o prueba que se suele hacer a los módulos funcionales para ver si son cohesivos es analizar que puedan describirse con una oración simple. el “cómo” del desarrollo. que es la clase. al modularizar. métodos y paquetes. de escasa relevancia semántica.funciones. en cambio. se modulariza la solución (diseño). e debería analizar su partición en más de un módulo. la modularización esencial se da a nivel de clases. sino (al menos en una primera aproximación) entidades del dominio del problema. Si hay más de un verbo activo en la descripción del procedimiento o función. lo que se hace es tomar la solución del problema. Finalmente. Por lo tanto. Por lo tanto. en el diseño orientado a objetos. que no son funciones del sistema. programar. y separarla en partes. Con los métodos. con un solo verbo activo. mejor: el módulo en cuestión será más sencillo de diseñar. probar y mantener. el paquete.

Se puede garantizar una fuerte cohesión disminuyendo al mínimo las responsabilidades de una clase: si una clase tiene muchas responsabilidades probablemente haya que dividirla en dos o más. programar. también habría que tratar de “sustantivarla” y aplicarle la prueba para ver si es cohesiva. se logra bajo acoplamiento reduciendo las interacciones entre procedimientos y funciones. A menor acoplamiento. Si la clase estuviera representando alguna operación (por la aplicación de algún patrón de diseño. asociación y dependencia débil. De nuevo. como pasó con la cohesión. de mayor a menor: generalización/herencia. En el diseño estructurado. composición. probar y mantener. el diseño orientado a objetos complica las cosas con sus tres tipos de módulos.Las clases tendrán alta cohesión cuando se refieran a una única entidad. en el sentido de que debe tener vinculaciones mínimas con otros . Para visualizar estas cuestiones. reduciendo la cantidad y complejidad de los parámetros y disminuyendo al mínimo los parámetros por referencia y los efectos colaterales. Una clase con alta cohesión suele cumplir el principio de única responsabilidad. Sin embargo. Y el test a aplicar sería ver si se puede describir a la clase con una oración simple que tenga un único sustantivo en el sujeto. en cambio. lo crucial en los paquetes es el acoplamiento. Sin embargo. nadie impide aplicarle los mismos tests que a las clases. En los paquetes no es usual analizar cohesión. los diagramas de clases son herramientas fundamentales. Acoplamiento El acoplamiento mide el grado de relacionamiento de un módulo con los demás. mejor: el módulo en cuestión será más sencillo de diseñar. Las dependencias que importan son. ¿Y los paquetes? Un paquete debe cumplir con estos mismos requisitos. Una clase. se puede analizarlos con los mismos criterios que a los módulos del diseño estructurado. A los métodos. tendrá bajo acoplamiento cuando tenga la menor dependencia posible de otras clases. Esta dependencia significa que – si bien puede haber muchas clases que dependen de una – debería haber pocas dependencias hacia otras clases desde una sola. por ejemplo).

paquetes. . Cada una de esas partes en que se encuentre dividido el sistema recibe el nombre de módulo. En este caso. uno se puede apoyar con un diagrama de paquetes. ser independiente del resto de los módulos y comunicarse con ellos (con todos o sólo con una parte) a través de unas entradas y salidas bien definidas. Idealmente un módulo debe poder cumplir las condiciones de caja negra. es decir. la modularidad es la capacidad que tiene un sistema de ser estudiado. visto o entendido como la unión de varias partes que interactúan entre sí y que trabajan para alcanzar un objetivo común. realizando cada una de ellas una tarea necesaria para la consecución de dicho objetivo. ya que este muestra dependencias entre conjuntos de clases y sirve para eliminar problemas de acoplamiento. A modo de resumen. asociación o simple dependencia débil. sea por herencia. Se dice que hay dependencia entre paquetes cuando hay clases de un paquete que dependen de clases de otro paquete.