Issuu on Google+

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..............................................................................................................................................1 Diseño de la solución...............................................................................................................1 Modularidad............................................................................................................................1 Arquitectura del software........................................................................................................2 Herramientas del diseño en A/DOO........................................................................................2 Referencias y lecturas recomendadas.......................................................................................3 Lecturas recomendadas..................................................................................................3 Referencias.....................................................................................................................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­12  Instituto de Ingeniería Eléctrica  ­     Facultad de Ingeniería     ­ Universidad de la República, Uruguay.    

3 de 3


12_Diseño