IIE ­ Instituto de Ingeniería Eléctrica.DesaSoft ­ Desarrollo de Software para Ingeniería Eléctrica.Guías de clase.   Parte II: Ingeniería de Software.

Diseño.

Índice de contenido

Diseño..............................................................................................................................................1Diseño de la solución...............................................................................................................1Modularidad............................................................................................................................1Arquitectura del software........................................................................................................2Herramientas del diseño en A/DOO........................................................................................2Referencias y lecturas recomendadas.......................................................................................3

Lecturas recomendadas..................................................................................................3Referencias.....................................................................................................................3

Diseño de la solución.

Diseño es el proceso creativo de producir una solución a un problema. La palabra diseño se usa también para designar la propia solución. Podemos declarar que algo es una solución a un problema si satisface todos los requerimientos planteados en la especificación del problema. Es posible, para un problema concreto, manejar alternativas de solución, en cuyo caso el cliente y los desarrolladores deberán optar entre varios diseños alternativos. También es preciso aceptar que durante el desarrollo puede haber cambios en la descripción del sistema, que obligarán a realizar cambios en la solución; estas situaciones deberán manejarse por consenso entre desarrollador y cliente.

Durante la elaboración del diseño se produce primero un diseño conceptual o diseño del sistema capaz de comunicar al cliente con toda exactitud lo que hará el sistema, en un lenguaje comprensible por él y los usuarios. Una vez aprobado el diseño conceptual se procede al diseño técnico, donde se explicitan con exactitud las características del hardware y el software necesarios para resolver el problema del cliente, y contiene el detalle técnico necesario para permitir a los desarrolladores construir el sistema.

Un buen diseño conceptual debe tener las siguientes características:• se escribe en el lenguaje del cliente. • no contiene términos técnicos propios de la disciplina informática. • describe claramente las funciones del sistema, sin ambigüedades ni omisiones. • es independiente de la implementación, tanto en hardware como en software. • refleja los requerimientos. 

El diseño técnico es la versión técnica de la solución conceptual. Contiene como mínimo estas descripciones:

• componentes de hardware y sus funciones. • jerarquía y funciones de los componentes de software. • estructuras de datos y flujos de datos.

Modularidad.

Diseñar un sistema es determinar un conjunto de componentes y de interfaces entre 

1 de 3

componentes que satisfagan un conjunto específico de requerimientos (Tom DeMarco, 1982). Existen diferentes enfoques para esta descomposición modular, pero cualquiera sea el adoptado la descomposición separa el diseño en partes denominadas módulos o componentes. Un sistema es modular cuando cada una de las actividades que realiza las realiza exactamente un único componente, para el cual están perfectamente definidas sus entradas y salidas, así como el proceso de transformación ocurrido en su interior para producir las salidas a partir de las entradas. El componente está bien definido cuando todas sus entradas son esenciales para su función, y todas las salidas son generadas por una de sus acciones. En consecuencia, la falta de una entrada impide el cumplimiento completo de las funciones del componente.

Arquitectura del software.

En el software se denomina arquitectura a la descripción de la asociación entre las capacidades del sistema identificadas en los requerimientos con los componentes del sistema que las implementarán. En general, estos componentes son módulos, y se describen también las interconexiones entre ellos.

Existen muchas definiciones de arquitectura en el software, pero todas coinciden en que describe el software a grandes rasgos. Comprende:

• organización de los elementos más importantes del sistema. • responsabilidades principales del sistema y sus subsistemas, así como la forma de 

colaboración entre estos. • las motivaciones o fundamentos que sustentan el diseño tal como fue concebido (por qué el 

sistema se hizo así).

Pueden caracterizarse estilos arquitectónicos del software. Un estilo comprende sus componentes, conectores y exigencias de combinación de los componentes. Algunos estilos arquitectónicos reconocidos son:

• tuberías y filtros. • orientación a objetos. • invocación implícita. • estratificación o modelo de capas. • repositorios. • intérpretes. • control de procesos. • cliente servidor. 

Una descripción breve de estos estilos puede hallarse en [Plfeeger2002], sección 5.3.

Herramientas del diseño en A/DOO.

Durante la etapa de Análisis se han obtenido los requerimientos del problema. Durante el la etapa de Diseño se desarrolla, a nivel lógico, una solución basada en el paradigma orientado a objetos. Las herramientas principales de diseño son:

• diagramas de interacción: representan el modo en que los objetos colaboran entre sí para satisfacer los requerimientos del problema. Hay dos variedades: diagramas de colaboración y diagramas de secuencia; ambas representan lo mismo, con énfasis en distintos aspectos (relaciones entre objetos en el diagrama de colaboración, desarrollo en el tiempo en el diagrama de secuencia). 

• diagrama de clases de diseño: comprenden la descripción de las clases de software e interfaces, y sus asociaciones. 

En la práctica ambas herramientas se usan en paralelo, empleado el conocimiento de una para hacer avanzar la otra. La construcción de los diagramas de interacción requiere la aplicación de principios de asignación de responsabilidades (qué objetos harán qué cosas) y el uso de los principios y patrones de diseño (identificar situaciones típicas a las que pueden aplicarse soluciones probadas).

2 de 3

Referencias y lecturas recomendadas.

El contenido de este documento está basado en las fuentes citadas a continuación, cuya lectura o consulta no pretenden sustituir.

Lecturas recomendadas.

• [Larman2003] Larman, Craig. UML y patrones. Una introducción al análisis y diseño orientado a objetos y al Proceso Unificado, 2a. edición. Madrid, 2003.ISBN 84­205­3438­2.

• [Fowler1997] Fowler, Martin y Scott, Kendall. UML distilled. Applying the Standard Object Modelling Language. Addison Wesley Longman, Inc., 1997. ISBN 0­201­32563­2.

• [Pfleeger2002] PFLEEGER, SHARI LAWRENCE. Ingeniería de software, teoría y práctica, 1a. edición. Buenos Aires, Pearson educación, 2002. ISBN: 987­9460­71­5.

Referencias.

• [Jacobson2000] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. El proceso unificado de desarrollo de software. Pearson Educación, Madrid, 2000. ISBN: 84­7829­036­2.

• [Booch1999] Booch, Grady; Jacobson, Ivar; Rumbaugh, James. El lenguaje unificado de modelado. Pearson Educación, Madrid, 2000. ISBN: 84­7829­028­1.

Errores, omisiones, comentarios: Víctor González Barbone, vagonbar en fing.edu.uy

Desarrollo de Software para Ingeniería Eléctrica ­ Rev. 2009­05­12Instituto de Ingeniería Eléctrica    ­    Facultad de Ingeniería    ­ Universidad de la República, Uruguay.   

3 de 3