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.

Análisis y Diseño Orientado a Objetos (A/DOO).

Índice de contenido

Análisis y Diseño Orientado a Objetos (A/DOO)...............................................................................1Análisis y Diseño.....................................................................................................................1Patrones..................................................................................................................................1Habilidades más importantes para el A/DOO..........................................................................2UML: Lenguaje Unificado de Modelado...................................................................................2A/DOO en el UP......................................................................................................................2Un juego de dados...................................................................................................................3Referencias y lecturas recomendadas.......................................................................................4

Lecturas recomendadas..................................................................................................4Referencias.....................................................................................................................5

En el proceso de desarrollo de software, el análisis es el estudio del problema, el diseño es la búsqueda de una solución abstracta a ese problema, la construcción es la escritura del código, prueba y documentación del código, la implantación es la instalación del software en las máquinas destino y la puesta en marcha del sistema. Debe tenerse en cuenta que los distintos procesos de desarrollo usan a veces términos distintos para aludir a estos conjuntos de actividades.

Análisis y Diseño.

El A/DOO, Análisis y Diseño Orientado a Objetos, aplica la tecnología de objetos a las fases de Análisis y Diseño del proceso de desarrollo de software. En el análisis orientado a objetos se buscan y describen los objetos y conceptos involucrados en el problema, así como las relaciones existentes entre estos objetos y conceptos. En el diseño orientado a objetos se definen los objetos de software y su colaboración mutua para la resolución del problema.

El Análisis pone énfasis en la investigación del problema y el descubrimiento de los requerimientos, en lugar de ponerlo en la solución. Trata de definir qué hay que hacer sin indicar cómo se hará. El Diseño pone énfasis en encontrar una solución conceptual al problema capaz de satisfacer todos los requerimientos, en lugar de ponerlo en la implementación. Trata de definir cómo debe hacerse algo en forma abstracta (conceptual), sin comprometer decisiones de construcción tales como lenguaje de programación o hardware específico.

Usando otra terminología, suele decirse a veces que el Análisis trabaja en el dominio del problema (un modelo de la realidad), mientras que el diseño lo hace en el dominio de la solución (modelo de los componentes de software). En este contexto, un dominio es una delimitación formal que define una materia o un área de interés específico. El dominio del problema refiere al ámbito del usuario, con su terminología, forma de ver, manejo de las cosas y aspiraciones. El dominio de la solución se refiere al software, los modelos y componentes de software con que se piensa dar solución al problema; se expresa en la terminología de los desarrolladores, pero debe permitir describir la solución al cliente.

Patrones.

Los patrones son fórmulas de solución a problemas típicos de diseño expresados como principios de buena práctica; proponen "soluciones ejemplares" a situaciones conocidas de aparición frecuente 

1 de 5

en el desarrollo de software. Estos principios se aplican al diseño de objetos y a la asignación de responsabilidades.

Patrones GRASP: 9 principios fundamentales para el diseño de objetos y de asignación de responsabilidades. Patrones GoF: 23 patrones, de los cuales unos 15 son extensamente usados, propuestos por Gamma, Helm, Johnson y Vlissides [Gamma1995]. GoF viene por "Gang of Four", la "pandilla de los cuatro", como se denomina en algunos medios a sus autores.

Habilidades más importantes para el A/DOO.

Las habilidades más importantes requeridas para el A/DOO son:1. Asignación de responsabilidades, inevitable. 

• qué objetos de qué clase deben hacer qué cosas; • cómo deben relacionarse los objetos unos con otros, cómo debe ser esa relación. • los patrones ayudan a lograr una asignación de responsabilidades efectiva. 

2. Diseño de objetos: • encontrar abstracciones y objetos adecuados. 

UML: Lenguaje Unificado de Modelado.

UML (Unified Modelling Language, lenguaje unificado de modelado) es un lenguaje visual estándar para el modelado; se le llama "unificado" porque combina diversos tipos de diagramas propuestos en distintos momentos por distintos autores. 

El UML• es una notación visual normalizada (estándar). • es un lenguaje para expresar el A/DOO. • permite construir un modelo del problema y un modelo de la solución. • los diagramas UML son los "planos" del software; equivalen al diagrama de un circuito 

electrónico o los planos de la estructura de un puente. 

El UML ha sido adoptado por el Object Management Group (OMG) como el estándar oficial para el modelado de sistemas con enfoque orientado a objetos. La OMG lo define así:

El Lenguaje Unificado de Modelado (UML) es un lenguaje para especificar, visualizar, construir  y documentar los artefactos de los sistemas de software, así como para el modelado de las  tareas empresariales y otros sistemas que no son de software.

Un artefacto es cualquier producto del trabajo en A/DOO: código, documento de texto, diagrama, componente binario ejecutable, cualquier elemento creado durante el desarrollo del software, ya sea para humanos o para máquinas.

A/DOO en el UP.

En el proceso unificado (UP) el análisis y diseño orientado a objetos (A/DOO) se centran en estas tres disciplinas:

• Modelado del negocio: construcción de un modelo de los objetos del dominio, si se trata de un a aplicación aislada. Cuando se analiza toda la empresa o se está haciendo la reingeniería de sus procesos incluye el modelado dinámico de los procesos de toda la empresa. 

• Requisitos: descubrimiento de los requisitos funcionales, restricciones y límite del sistema. • Diseño: construcción del modelo de objetos y relaciones propuesto como solución. 

Otros términos del UP:• Implementación: programar el sistema; no incluye el despliegue (entrega, instalación, 

2 de 5

configuración). • Entorno: adaptación del proceso a la situación particular del proyecto, selección de 

herramientas para el desarrollo. 

Un juego de dados.

Modelaremos el siguiente juego de dados: un jugador lanza dos dados simultáneamente; si la suma de valores de las dos caras es 7 gana, si no pierde.

El análisis de requerimientos puede hacerse mediante Casos de Uso, una historia escrita de la funcionalidad requerida por el usuario. Un caso de uso puede describirse en forma de texto:

Alternativa o complementariamente, el Caso de Uso puede representarse en un diagrama:

El análisis orientado a objetos busca identificar los conceptos, atributos y asociaciones significativas para el problema. Una de las formas de expresar esta identificación es mediante un Modelo de Dominio, un conjunto de diagramas con los conceptos relativos al problema:

El diagrama puede leerse como “un Jugador lanza dos dados”, “un Jugador juega un JuegoDados”, “un JuegoDados incluye dos dados”. El Jugador tiene un atributo “nombre”, el Dado tiene un “valorCara”; el JuegoDados no tiene atributos.

El diseño busca describir los objetos de software y la forma como éstos colaboran entre sí para realizar las tareas requeridas. Una forma de expresar esta colaboración es el Diagrama de Secuencia, donde se muestran las distintas acciones en orden cronológico.

3 de 5

Caso de Uso:Jugar partida de dados: un Jugador recoge y lanza dos dados. Si la 

suma de ambos dados da 7  gana; si no lo es, pierde.

El actor Jugador realiza una acción mostrada como un mensaje jugar() dirigido a un objeto JuegoDados, quien implementa ese método. Aunque en la realidad es el jugador quien lanza los dados, en el diseño de software esa responsabilidad la tiene el objeto de tipo JuegoDados, quien no tiene un identificador propio (no tiene un nombre). Los objetos de nombres dado1 y dado2, de tipo Dado, implementan métodos lanzar() y obtenerValorDado(), por lo cual pueden recibir esos mensajes. La secuencia de acciones avanza en el tiempo en sentido descendente.

Además de esta visión dinámica de las colaboraciones entre objetos interesa una visión estática de las clases de objetos implicados y sus relaciones. Esto se expresa mediante un Diagrama de Clases:

El diagrama de clases muestra clases de software, no conceptos del dominio del problema. En el diagrama de clases no aparece el concepto de jugador; no es necesario para el software.

La siguiente etapa sería la implementación o construcción del software, mediante la codificación en algún lenguaje de programación. Sin embargo, hasta el momento, el diseño realizado no ha comprometido ningún lenguaje en particular. La adaptación del diseño a las exigencias de un lenguaje particular de programación se llama diseño de implementación; este diseño modificado ya no es independiente del lenguaje de programación, y no muestra una solución general del problema, sino una adaptada a las exigencias del lenguaje de programación. Un buen diseño no debe incorporar exigencias de un lenguaje de programación en particular, sino resolver el problema como tal. La adaptación a las exigencias de un lenguaje de programación, si son necesarias, se harán en el último momento, inmediatamente antes del comienzo de la codificación.

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.

4 de 5

• [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­09Instituto de Ingeniería Eléctrica    ­    Facultad de Ingeniería    ­ Universidad de la República, Uruguay.   

5 de 5