Libro 1 Completo UML V51

7/24/2019 Libro 1 Completo UML V51

1/205

Anlisis y Diseo deSistemas Orientado aObjetosVersin 5.1

Libro 1


2/205


3/205

Anlisis y Diseo deSistemas Orientado aObjetosCdigo de Curso: CY450Versin 5.1

Gua del Estudiante

Libro 1: Anlisis yDiseo de SistemasOrientado a Objetos

IBM IT Education ServicesWorldwide Certified Material


4/205

.

Informacin de la Publicacin

Esta publicacin ha sido producida usando Microsoft Word 2000 y Microsoft PowerPoint2000 para Windows.

Marcas Registradas

IBM es una marca registrada por International Business Machines Corporation.

Otras compaas, productos, y nombre de servicios pueden ser marcas registradas omarcas de servicios de otros.

Marcas Registradas de otras compaas segn se muestra

Windows Microsoft Corporation

Red Hat Linux Red Hat

Edicin Diciembre 2007

La informacin contenida en este documento no ha sido sometida a ninguna pruebaformal de IBM y est distribuida en base a como est sin ninguna garanta expresa oimplcita. El uso de esta informacin o la implementacin de cualquiera de estastcnicas es responsabilidad del cliente y depende de la habilidad del cliente evaluar eintegrarlas dentro del entorno operacional del cliente. Aun cuando cada punto puedehaber sido revisado por IBM en su exactitud y para una situacin especfica, no hay

garanta de que los mismos resultados o similares, funcionarn en otra parte. Losclientes que intenten adaptar estas tcnicas a sus propios entornos, lo hacen bajo supropio riesgo.

Copyright International Business Machines Corporation, 2007. Todos losderechos reservados.

Este documento no puede ser reproducido total o parcialmente sin previo permisoescrito de IBM.


5/205

Gua del Estudiante Anlisis y Diseo de Sistemas Orientado a Objetos

i Copyright IBM Corp. 2007

Los materiales del curso no pueden ser reproducidos total oparcialmente sin el previo permiso escrito de IBM.

ContenidoDescripcin del Curso ........................................................................................1Descripcin de Unidades ...................................................................................3

Volumen 1: Modelado Bsico ............................................................................6Unidad 1: Introduccin a UML...........................................................................7

1. La Necesidad del Anlisis y Diseo Orientado a Objetos (OOAD) 8

2. Fundamentos de la Orientacin a Objetos 12

3. Importancia del Modelado 19

4. UML 19

5. El Modelo UML 19

Resumen 19

Unidad 1: Examen de Autoevaluacin 19

Respuestas a la Unidad 1: Examen de Autoevaluacin 19

Unidad 2: Modelado del Comportamiento con Casos de Uso ......................19

1. Introduccin 19

2. Importancia de los Casos de Uso 19

3. Casos de Uso 19

4. Anlisis de un Caso de Uso 19

5. Diagrama de Caso de Uso 19

6. Diagramas de Actividad 19

7. Caso de Estudio 19

Resumen 19


Respuestas de la Unidad 2: Examen de Autoevaluacin 19

Unidad 3: Lab. de Modelado del Comportamiento con Casos de Uso.........19

1. Ejercicio de Laboratorio 19

Unidad 4: Modelado Estructural Bsico .........................................................191. Modelado Estructural 19

2. Diagramas de Clase 19

3. Relaciones entre Clases 19

4. Mecanismos Comunes 19


Resumen 19


6/205

Anlisis y Diseo de Sistemas Orientado a Objetos Gua del Estudiante

ii Copyright IBM Corp. 2007

Los materiales del curso no pueden ser reproducidos total oparcialmente sin el previo permiso escrito de IBM.



Volumen 2: Modelado Avanzado.....................................................................19

Unidad 1: Modelado Estructural Avanzado ....................................................19

1. Introduccin 19

2. Clasificadores 19

3. Elementos Abstractos 19

4. Multiplicidad 19

5. Clases Plantillas (Template) 19

6. Estereotipos para Clases 19

7. Relaciones 19

8. Interfaces y Realizacin 19

9. Roles 19

10. Paquetes 19

11. Instancias 19

12. Diagramas de Objetos 19


14. Algunas Recomendaciones 19

Resumen 19



Unidad 2: Laboratorio de Modelado Estructural Avanzado ..........................19

Ejercicio de Laboratorio 19

Unidad 3: Modelado de interaccin.................................................................191. Introduccin 19

2. Interaccin 19

3. Colaboracin 19

4. Diagramas de Interaccin 19

5. Manejar Tiempo y Espacio 19

6. Cmo Crear un Diagrama de Colaboracin 19

Resumen 19


Respuestas a Unidad 3: Examen de Autoevaluacin 19

Unidad 4: Lab. de Modelado de Interaccin...................................................19


7/205


8/205


9/205


Libro 1: Anlisis y Diseo de Sistemas Orientado a Objetos Descripcin del Curso 1

Copyright IBM Corp. 2007Los materiales del curso no pueden ser reproducidos total o

parcialmente sin el previo permiso escrito de IBM.

Descripcin del CursoNombre del Curso

Anlisis y Diseo de Sistemas Orientado a Objetos.

Duracin

La duracin de este curso es de 40 horas acadmicas.

Propsito

El propsito de este curso es obtener conocimientos y destrezas en el manejo de losPrincipios de la Orientacin a Objeto y en el Lenguaje Unificado de Modelado UML(Unified Modeling Language), considerado como un estndar de la industria delsoftware para apoyar el anlisis y diseo de sistemas orientados a objetos (OOAD). El

uso del Lenguaje Unificado de Modelado UML permite al desarrollador de sistemasespecificar, visualizar, construir y documentar los artefactos de sistemas de softwareorientados a objetos, utilizando un formato visual de modelado con sus tres elementosimportantes a saber: los bloques de construccin (que incluyen mas de nuevediagramas), las reglas que ayudan a juntar esos bloques de construccin y algunosmecanismos de extensin.

Audiencia

Estudiantes, profesionales y desarrolladores que desean conocer acerca de Anlisis yDiseo de Sistemas Orientado a Objetos.

Prerrequisitos

Introduccin a las computadoras personales y a Windows XP.

Fundamentos a la programacin Orientada a Objetos.

Objetivos del Curso

Al final de este curso Ud. ser capaz de:

Describir la necesidad del estudio del Anlisis y Diseo Orientado a Objetos.

Conocer los conceptos bsicos del paradigma orientado a objetos.

Describir la importancia del modelado UML.


10/205


Unidad 1:Programacin en C Los Primeros Pasos Volumen 1: Fundamentos de C 2

Copyright IBM Corp. 2007Los materiales del curso no pueden ser reproducidos en parte

o en su totalidad sin el previo permiso escrito de IBM.

Describir el uso y funcionamiento de los diagramas UML en el aspectoestructural.

Describir el uso y funcionamiento de los diagramas UML en el aspecto decomportamiento.

Conocer las diferencias entre la especificacin UML 1.x y la especificacin UML2.0.

Describir el uso y funcionamiento de los diagramas de la especificacin UML 2.0en el aspecto estructural y de comportamiento.

Aprender a manejar herramientas de modelado.

Agenda

Cada unidad del curso tiene una duracin de 2 a 3 horas acadmicas.


11/205


Libro 1: Anlisis y Diseo de Sistemas Orientado a Objetos Descripcin de Unidades 3



Descripcin de UnidadesVolumen 1: Modelado Bsic o

Unidad 1: Introduccin a UML

Esta unidad comienza dando la motivacin para el estudio del Anlisis y el DiseoOrientado a Objetos. Ayuda a entender los diversos principios de orientado a objetos yproporciona una introduccin al Lenguaje Unificado de Modelado (UML).

Unidad 2: Modelado del Comportamiento con Casos de Uso

Esta unidad da inicio al Lenguaje de Modelado Unificado (UML), comenzando con elDiagrama de Casos de Uso, el cual es el diagrama que permite modelar un sistema dela forma como lo entendera el usuario. Este tipo de diagramas es muy usado en eltranscurso del levantamiento de informacin, debido a que el usuario puede tener unamejor visin del sistema sin entrar en profundidad de programacin.

Unidad 3: Laboratorio de Modelado del Comportamiento con Casos deUso

Esta unidad pretende poner en prctica los conocimientos adquiridos en la unidadanterior, utilizando un ejercicio prctico de laboratorio.

Unidad 4: Modelado Estructural Bsico

En esta unidad se discute uno de los diagramas ms importantes de UML como lo es elDiagrama de Clases. Conceptos como Clases, Objetos, herencia, polimorfismo,relaciones entre clases y objetos, estereotipos, entre otros, que permiten mostrar una

cara esttica del sistema.

Volumen 2: Mod elado Avanzado

Unidad 1: Modelado Estructural Avanzado

Esta unidad se refiere a los diferentes tipos de clasificadores, adems de proporcionarmayor informacin sobre interfaces, tipos y paquetes. Discute diagramas e instancias deobjetos. Ayuda al estudiante a aprender cmo construir diagramas de objetos.

Unidad 2: Laboratorio de Modelado Estructural

Esta unidad de Laboratorio se construye sobre la base de las unidades anteriores en elmodelado estructural y ayuda a aprender a crear clases abstractas a partir de undocumento de requerimientos dado. Proporciona una forma de desarrollar la habilidadde derivar diagramas de clase y diagramas de objetos en diferentes escenarios.


12/205





Unidad 3: Modelado de Interaccin

Esta unidad proporciona detalles de dos de los diagramas ms importantes paramodelar la dinmica de un sistema, estos diagramas son: Diagramas de secuencia ydiagramas de colaboracin. Los diagramas de interaccin describen el modo en que losgrupos de objetos colaboran para realizar un trabajo y la subclasificacin (Diagramas de

secuencia y colaboracin) permite ver esa colaboracin de dos maneras distintas perocompatibles.

Unidad 4: Laboratorio de Modelado de Interaccin

Esta unidad de Laboratorio se construye sobre la base de la unidad anterior en elmodelado de interaccin y ayuda a aprender a crear Diagramas de secuencia ycolaboracin a partir de un documento de requerimientos dado.

Unidad 5: Modelado de Comportamiento Avanzado

Esta unidad proporciona detalles de algunos de los aspectos avanzados de modelado

de comportamiento. Discute los eventos y seales, mquinas de estado y mtodos deconstruccin de diagramas de mapa de estado con cierto detalle. Una enumeracinbreve de las diferencias y similitudes entre procesos e hilos se proporciona como unabase conceptual.

Unidad 6: Modelado Arquitectnico

Con la complejidad creciente de sistemas de software, la importancia del modeladoarquitectural est siendo enfatizada tanto en la industria y como en el entornoacadmico. Esta unidad enfatiza los componentes, el despliegue y las colaboraciones.Proporciona detalles de diagramas de componente y diagramas de despliegue.

Volumen 3: Introd ucc in a UML 2.0 y a Herramientas de Modelado

Unidad 1: Introduccin a UML 2.0 (Diagramas Estructurales)

Esta unidad proporciona una introduccin a la nueva versin de UML llamada UML 2.0.Explica los cambios ms relevantes entre esta nueva versin y las versiones anterioresde UML. Tambin, se enumeran las diferencias entre los diagramas estructurales del lasversiones 1.X y la versin 2.0. Se explican de forma bsica los nuevos diagramas de lanueva especificacin.

Unidad 2: Introduccin a UML 2.0 (Diagramas de Comportamiento)

En esta unidad se explican de manera bsica los diagramas de comportamiento de lanueva versin de UML, tales como: Diagramas de Casos de Uso, Diagramas de

Actividad, Diagramas de interaccin, Diagramas de Mquinas de Estado, as comotambin se detallan los nuevos diagramas incluidos en la versin 2.0 de UML.


13/205


Libro 1: Anlisis y Diseo de Sistemas Orientado a Objetos Descripcin de Unidades 5



Apndice A: Manejo de la Herramienta EclipseUML Free Edition

Esta unidad proporciona una introduccin a la herramienta EclipseUML Free Edition, elcual es un plugin para ser instalado en la Plataforma Eclipse. Aqu se explica cmocrear nuevo proyecto en eclipse, como crear paquetes, instalacin en windows y linux,como crear un diagrama UML y la barra de herramientas de cada tipo de diagrama,

proporcionndole al estudiante las prcticas necesarias para el manejo de herramientasde modelado.

Apndice B: Manejo de la Herramienta Rational Software Modeler

Esta unidad proporciona una introduccin a la herramienta Rational Software Modeler,la cual es la herramienta por excelencia de IBM para modelado con UML. Aqu, seexplican cmo crear diagramas, exportar a imagen, crear proyectos, ingeniera haciadelante y reversa, entre otras caractersticas, proporcionado al estudiante prcticas pararealizar modelos UML en esta herramienta.


14/205





Volumen 1: Modelado Bsico


15/205


Libro 1: Anlisis y Diseo de Sistemas Orientado a Objetos Unidad 1: Introduccin a UML 7



Unidad 1: Introduccin a UML

Objetivos de Aprendizaje

Al final de esta unidad, usted ser capaz de:

Describir la necesidad del Anlisis y Diseo Orientado a Objetos (ObjectOriented Analysis and Design - OOAD).

Explicar los principios de la orientacin a objetos.

Describir el trabajo del Lenguaje Unificado de Modelado (Unified ModelingLanguage - UML).

Describir la importancia del modelado en UML.


16/205


Unidad 1: Introduccin a UML Libro 1: Anlisis y Diseo de Sistemas Orientado a Objetos 8



1. La Necesidad del Anlisis y Diseo Orientado aObjetos (OOAD)El desarrollo de aplicaciones de software es fundamentalmente un proceso complejo,por lo que, entender, disear, desarrollar y desplegar grandes sistemas de software sonlos retos que enfrenta la industria de software en la actualidad. El proceso del ciclo devida involucra las siguientes etapas:

Entender los requerimientos.

Analizar los requerimientos.

Disear el sistema de software.

Implementar el sistema de software.

Probar el sistema de software.

Realizar mantenimiento del sistema de software.

Al completar cada una de las etapas, se crean uno o ms documentos (reportes o

cdigo). Estos documentos son llamadosproductos de trabajoy permiten comprender elsistema en cada etapa.

Despus de la primera etapa, de entender los requerimientos, se crea un producto detrabajo llamado entendimiento preliminar de requerimientos. Muchos analistas no venesta etapa de modo diferente a la segunda etapa de anlisis de los requerimientos y lasfusionan en una. Sin embargo, el entender los requerimientos juega un rol importante enel desarrollo de software de hoy da debido a que los dominios de aplicaciones desoftware son cada vez ms variados y complejos. La etapa de analizar losrequerimientos da origen a un producto de trabajo llamado especificacin derequerimientos de software.

El producto de trabajo de la tercera etapa, correspondiente a disear el sistema, es eldocumento de diseo.En la etapa de implementacin, el sistema resulta en la creacinde manuales de diversos tipos, tales como: el manual de usuario, manual administrativoy otros. En algunos casos, cualquier tipo de cdigo que se use en la parte inicial de laimplementacin es tambin documentado.

La fase de prueba crea productos de trabajo en las siguientes reas:

Metodologas de prueba.

Planes y casos de pruebas utilizados.

Resultados obtenidos de la prueba del sistema.

Aunque cada etapa resulta en un producto de trabajo til, se est conciente de losdiferentes problemas que los analistas y desarrolladores de software deben confrontar.Los requerimientos son poco claros y voltiles por naturaleza. Un requerimientoignorado o dejado de lado tiene un efecto cascada en todo el proceso de desarrollo delsistema. Entender un sistema grande y complejo es en s una tarea difcil. El anlisis ydiseo de sistemas complejos es un proceso difcil que demanda tiempo. Las


17/205





metodologas de anlisis y diseo estructurado usadas anteriormente, intentaronproporcionar soluciones y eran exitosas en muchas situaciones. Sin embargo, el mundoreal es complejo, y con el creciente uso de computadoras en todos los aspectos de lavida, el manejo de aplicaciones complejas del mundo real es cada vez ms desafiante.

OOAD tiene la capacidad inherente para ocuparse de los diferentes aspectos de

sistemas de software complejos. Mientras la metodologa de anlisis y diseoestructurado construye un sistema usando funciones, la orientacin a objetos construyesistemas usando objetos. Estos objetos tienen una correspondencia directa con losobjetos del mundo real. Las entidades del mundo real son simples de entender. Por lotanto, no es una tarea muy difcil transferir conocimiento del mundo real al dominio delsoftware, usando la orientacin a objetos.

Para mostrar la importancia de OOAD, se muestra una narracin de la construccin delbuque de guerra Vasa, ms conocida como la Tragedia de Vasa.

El Rey Gustav de Suecia, quien obtuvo grandes victorias en las Guerras Blticas,anhelaba poseer el mejor buque insignia en toda Europa. l quera un barco que fuese

el orgullo de la Marina Sueca. El Rey design a Hendrick Hybertzoon, un expertoconstructor de barcos de Holanda, para que construyera el buque insignia, y le dioinstrucciones preliminares. Pronto, Hybertzoon pudo construir un modelo a escala delbuque insignia propuesto. El Rey Gustav estaba feliz con el prototipo y orden aHybertzoon para que procediera con la construccin del verdadero barco. Un bosqueentero de robles fue dado al experto constructor de barcos para obtener madera paraeste prestigioso proyecto.

Ni el Rey Gustav ni sus consejeros, incluyendo el Almirante de la Marina Sueca,proporcionaron a Hybertzoon alguna especificacin escrita. Hybertzoon decidi que elbarco deba tener una longitud de 108 pies y orden que se cortara la madera delbosque de robles de acuerdo a eso. La construccin estaba progresando hasta que un

da el Rey vino a inspeccionar. l consider que la longitud del barco debaincrementarse en otros 35 pies. Despus de todo, iba a ser el orgullo de la MarinaSueca, pero Hybertzoon ya haba cortado la madera y haba terminado de construir laquilla del barco. La quilla deba ser extendida con una longitud adicional de madera demodo que la longitud pudiera incrementarse a 120 pies.

El Rey Gustav se enter durante sus vacaciones de verano que el Rey de Dinamarcatambin estaba construyendo un buque insignia. Tambin se enter que el barco Dansiba a tener tres cubiertas de caones mientras que su barco tena slo dos! El ego delRey Gustav no pudo soportar esto. l orden que se instalara en su buque insignia otracubierta de caones con 50 caones de bronce (cada uno pesando ms de unatonelada). Tambin orden que su barco fuera completado antes de la fecha estimada

original. El dinero no iba a ser un obstculo para este proyecto. Hybertzoon no eracapaz de convencer al Rey de que no era posible hacer cambios estructuralesimportantes despus de que la quilla haba sido colocada y se haba hecho elentarimado. Hybertzoon acept las demandas imposibles del Rey, pero muri antes decompletar la tarea, quizs debido al stress. La tarea de completar el proyecto fue dada asu hermano, Arent Hybertzoon de Groote, a pesar de su relativa inexperiencia.


18/205





A principio del Siglo 17, los constructores de barcos estaban an por empezar a utilizarmtodos analticos para construir barcos. Ellos solamente hacan suposiciones bienfundamentadas acerca de las especificaciones del barco y aprendan a travs delproceso de ensayo y error. Las especificaciones eran secretos celosamente guardadosy no estaban sujetas a revisiones abiertas. El peso de las armas (unas 50 toneladasextra) no figur en los clculos para el buque insignia Sueco. Tampoco otros tems

como un horno de cocina que se aadira al peso total. El constructor del barco creyque el entarimado adicional en los lados y un lastre adicional de 130 toneladas seencargaran del asunto. El entarimado fue completado, pero el constructor del barco sedio cuenta entonces que no haba espacio bajo la cubierta para otras 130 toneladas deroca para proporcionar lastre. Este aspecto fue ignorado completamente.

Despus de que el buque insignia real estuvo al fin listo, la Marina Sueca prob el barcohaciendo que 30 marinos corrieran a lo largo del barco. El barco casi se inclin hacia unlado en una ocasin, pero nadie supo cmo resolver el problema de estabilidad. Elbarco fue declarado probado y listo para zarpar, dado que el tiempo estipulado y lapaciencia del Rey se estaban agotando. El barco fue bautizado como Vasa y fuelanzado del puerto de Estocolmo en Agosto de 1628. Difcilmente, el barco haba

navegado apenas unos cuantos kilmetros cuando una pequea rfaga de vientosacudi la vela mayor. El orgullo de la Marina Sueca se volc y se hundiinmediatamente.

Se pueden aprender algunas lecciones de la tragedia de Vasa. stas son:

La construccin de barcos era un trabajo artesanal. Se practicaba con poconfasis en algn mtodo cientfico o de ingeniera.

El Rey no dio especificaciones por escrito. Todos los requerimientos del barcofueron recogidos verbalmente.

No se aplicaron mtodos de diseo. La tarea de construir un buque de guerraestaba basada en unos cuantos bosquejos y modelos.

Los resultados o consecuencias de cambiar los requerimientos en las diferentesetapas de la construccin del barco no se conocan.

La prueba no se condujo cientficamente y cualquier indicacin de algnproblema no fue tomada en cuenta.

Todos los pedidos y demandas del cliente fueron aceptados sin analizar si eraposible incorporarlos.

Cada punto mencionado anteriormente tiene relacin con lo que sucede tpicamente enun esfuerzo de desarrollo de software. La construccin de barcos era una tarea grandey compleja. Los sistemas complejos del mundo real requieren adems que el desarrollode sistemas sea dirigido de la manera correcta. Con la llegada del anlisis y diseo

estructurado de sistemas de software, se proporcion un enfoque de ingeniera para eldesarrollo de sistemas de software. Para la mayora de los puntos cubiertosanteriormente, la metodologa de anlisis y diseo estructurado se ocup de ellos. Sinembargo, la metodologa no proporcion una solucin para hacer corresponderdirectamente los objetos del mundo real en el dominio de software. La orientacin a


19/205





objetos ofrece una solucin que ayuda a los desarrolladores a hacer corresponder elmundo real tan cerca como sea posible al dominio de la solucin. Existen muchasmetodologas que permiten soluciones para problemas complejos. A continuacin, sediscutirn brevemente las diversas metodologas disponibles y luego se estudiar endetalle la orientacin a objetos.

Orientada a Aspectos:La Programacin Orientada a Aspectos (POA) permite alos desarrolladores escribir, ver y editar un aspecto diseminado por todo elsistema como una entidad por separado, de una manera inteligente, eficiente eintuitiva. Un aspecto se define como una propiedad que afecta el rendimiento(performance) o la semntica de los componentes en forma sistemtica(Ejemplo: sincronizacin, manejo de memoria, distribucin, etc.). La POA es unanueva metodologa de programacin que implica separar la funcionalidad bsicade los aspectos y los aspectos entre s. Esta separacin se realiza a travs demecanismos que permitan la abstraccin y la composicin de los mismos, a finde poder implementar todos los requerimientos del sistema.

Literal: Esta metodologa combina un lenguaje de programacin y uno dedocumentacin. Donald Knuth es el inventor de la programacin literal. El

propsito de esta metodologa es mejorar la capacidad para la documentacindel lenguaje de programacin nativo. Un programa es tratado tpicamente comouna pieza de literatura. Tambin puede verse en el modo hipertexto.

Estructurada:Esta metodologa es la ms usada y la mayora est familiarizadacon ella. Lenguajes como BASIC, Pascal, COBOL y C son algunos de losejemplos que pueden ser usados para programar usando esta metodologa. Laprogramacin estructurada permite organizar programas en una jerarqua demdulos. Cada mdulo tiene un solo punto de entrada y, a menudo, un solopunto de salida.

Orientada a Objetos:Esta metodologa se basa en modelar el mundo real y haganado importancia significativa en los ltimos tiempos. En la orientacin a

objetos se trabaja con objetos en el sistema que interactan unos con otros atravs de mensajes. La orientacin a objetos proporciona los recursos paraocuparse de los objetos de un sistema complejo. El anlisis y diseo de unsistema desde una perspectiva orientada a objetos forma el ncleo de estecurso. Se aprender todo acerca de la orientacin a objetos a medida que seavance en el curso.

Patrones: De acuerdo con Dirk Riehle y Heinz Zullighoven, un patrn es laabstraccin de una forma concreta, la cual reaparece frecuentemente encontextos especficos no arbitrarios. Dr. Christopher Alexander, un arquitecto,concibi el concepto de patrones en el planeamiento urbano y arquitectura deconstrucciones. La aplicacin de patrones para el desarrollo de software estinspirada por su trabajo. Simplemente los patrones son soluciones probadas

para problemas frecuentes dentro de un cierto contexto. De acuerdo conAlexander, cada patrn es una regla de tres partes, la cual expresa una relacinentre un cierto contexto, un problema y una solucin.

Cualquiera de las metodologas mencionadas anteriormente para desarrollar unsistema, seguir el proceso del ciclo de vida de desarrollo de software.


20/205





Indiferentemente de la metodologa subyacente, el entender los requerimientos,analizarlos, disear el sistema, implementarlo y probarlo son etapas esenciales de unproceso de construccin de sistema. Por lo tanto, cada metodologa requerir untraductor de requerimientos, un analista de requerimientos, un analista de sistemas, undiseador de sistemas, un programador y un probador, para llevar a cabo las diferentesetapas del proceso de construccin de sistemas.

2. Fundamentos de la Orientacin a Objetos

Antes de continuar y aprender acerca del Lenguaje de Modelado Unificado (UML), sediscutirn brevemente los principios de la orientacin a objetos.

2.1 Modelado del Mundo Real

El creciente poder de la computacin y la tecnologa ha dado lugar a muchos esfuerzosde desarrollo de sistemas grandes y complejos. El modelado del mundo real forma labase para la orientacin a objetos y ayuda a los analistas de sistemas a entender mejor

el sistema.A continuacin se presentan los requerimientos recopilados para automatizar el pago decuentas a travs de la Internet.

Se requiere que el cliente llene un formulario de aplicacin para permitir el pago decuentas a travs de los servicios ofrecidos por BillPaymentJunction, Inc.

En el paradigma de anlisis y diseo estructurado, el escenario anterior se pensara deforma lgica en trminos de las funciones llenarFormularioAplicacin() y pagarFactura().El paradigma de anlisis y diseo estructurado no est basado en modelar el mundoreal. En la orientacin a objetos, se intentar modelar el mundo real y los objetos delmundo real. Se aprecia que el mundo real tiene clientes, formularios de aplicacin,facturas, pagos de cuentas y servicios. Entre stos, se pueden clasificar algunos deellos como acciones (pagos de cuentas y servicios) y otros como entidades (clientes,formularios de aplicacin, facturas). Primero se modelan estas entidades del mundo realy luego se asocian las acciones identificadas como las funciones o responsabilidadesde estas entidades.

2.2 Tipos de Dato Abstracto

En la orientacin a objetos, el modelado de la vida real resulta en tipos de datoabstracto. Un tipo de dato abstracto es un modelo matemtico. Las operaciones sondefinidas en el modelo para permitir la aplicacin del tipo de dato en un entorno deprogramacin. Algunos se refieren a la programacin orientada a objetos comoprogramacin de los tipos de dato abstracto. Las entidades Cliente y FormularioAplicacindel ejemplo presentado en la seccin anterior son tipos de dato abstracto.En la orientacin a objetos, se trabaja principalmente con datos. Por tanto, las


21/205





operaciones son definidas sobre esos datos. Cada dato que se vuelve parte de unsistema orientado a objetos es, en esencia, un tipo de dato abstracto.

2.3 Abstraccin de Datos

La abstraccin de datos es fundamental para el pensamiento orientado a objetos. La

abstraccin permite a una persona concentrarse en los aspectos esenciales delproblema a la mano, mientras ignora detalles que tienden a distraer. El mundo real escomplejo y presenta demasiados elementos que deben manejarse simultneamente. Senecesita superar la complejidad para poder resolver los problemas. La abstraccin esuna manera conveniente de manejar la complejidad. El Institute of Electrical andElectronics Engineers Inc. - IEEE define la abstraccin como una visin del problemaque extrae la informacin esencial relevante a un propsito particular e ignora el restode la informacin.

Dicho simplemente, la abstraccin es eliminar lo innecesario. Por ejemplo, un libro enuna biblioteca puede ser visto de modo diferente que un libro en una editorial. En unabiblioteca, el libro puede verse que tiene un ttulo, nombre de la editorial, fecha de

publicacin, nmero de edicin, precio y autor. El mismo libro, desde el punto de vistade la editorial, puede verse que tiene un ttulo, nmero de pginas, rea impresa dellibro y muchas otras cosas relacionadas a la publicacin del libro. De modo similar, enuna aplicacin, la abstraccin de una entidad se basa en su necesidad y relevancia enla aplicacin.

2.4 Encapsulamiento

La esencia del encapsulamiento recae en que cuando un objeto trae consigo sufuncionalidad, esta ltima se oculta. Con el encapsulamiento de los datos se consigueque las personas que utilicen un objeto slo tengan que comprender su interfaz,olvidndose de cmo est implementada, y en definitiva, reduciendo la complejidad de

utilizacin.

La utilidad del encapsulamiento se ve en la reduccin de la complejidad, esto es debidoa que las Clases se comportan como cajas negras donde slo se conoce elcomportamiento pero no los detalles internos, y esto es conveniente porque solointeresa conocer qu hace la Clase, pero no como lo hace.

Tomemos un ejemplo de un telecajero, se puede ir a un telecajero a retirar dinero,consultar saldo y realizar transferencias. Estas son funcionalidades que se lesproporcionan a los usuarios, pero no es posible conocer como estas funcionalidadesestn implementadas y los usuarios no estn preocupados por conocerlas.

En la orientacin a objetos, el encapsulamiento ayuda a mantener juntos los elementosde datos, as como las funciones y procedimientos que operan sobre ellos.

En el paradigma procedimental, los datos y operaciones se mantienen separados, talcomo se muestra en la Figura 1.1.


22/205





Figura 1.1: Datos y Operaciones en el Paradigma Procedimental

En el paradigma orientado a objetos, los datos y las operaciones estn juntos dentro deuna cpsula, tal como se muestra en la Figura 1.2.

Figura 1.2: Datos y Operaciones en el Paradigma Orientado a Objetos

2.5 Ocultamiento de la Informacin

El encapsulamiento conlleva al ocultamiento de la informacin, esto es, tanto los datoscomo la implementacin de las operaciones de un objeto son ocultados al usuario. Porlo general, la mayora de las personas que ve televisin no sabe o no se preocupa de lacomplejidad electrnica que hay detrs de la pantalla, ni de todas las operaciones quetienen que ocurrir para mostrar una imagen en la pantalla. La televisin hace lo que

tiene que hacer sin mostrarnos el proceso necesario para ello, esto es, ocultamiento dela informacin. Al tener encapsulado juntos los datos miembros y las diferentesoperaciones, el usuario debe saber cmo acceder a las operaciones para trabajar conlos datos.

DATOS /CARACTERSTICAS

OPERACIONES

OPERACIONES

DATOS/CARACTERISTICAS


23/205





2.6 Clase

Las clases son tipos de datos definidos por el usuario. Las clases, en la tecnologaorientada a objetos, representan la mayor parte de las veces a las entidades del mundoreal, excepto para unos pocos conceptos abstractos. Dado el dominio de un problema,el dominio de la solucin en la tecnologa orientada a objetos, contendr clases que son

identificadas como entidades en el dominio del problema.

Se presenta el ejemplo de un sistema bancario para entender esto. Los bancospermiten a los clientes operar con diferentes tipos de cuentas, como ahorro, corriente ydepsito de plazo fijo. Los clientes usan formularios de depsito para depositar dinero yusan formularios de retiro para retirar dinero del banco. La transferencia de fondos deuna cuenta a otra, dentro del mismo banco se puede hacer usando un formularioespecialmente diseado para este propsito. La perspectiva dada aqu es desde elpunto de vista del cliente del banco. Internamente, el banco tendr muchos otrosformularios adicionales para acometer estas tareas. A partir de esta corta descripcin,se pueden representar algunas de las siguientes entidades del mundo real y suscorrespondencias a clases en el mundo orientado a objetos. Esto es ilustrado en la

Figura 1.3.Mundo Real Mundo Orientado a Objetos

Figura 1.3: Correspondencia de Entidades del Mundo Real a Clases en el EscenarioBancario

2.7 Objeto

En trminos sencillos, un objeto es una instancia de una clase. Los objetos interactancon otros para proporcionar una solucin a un problema. Se asumir por ejemplo que setiene definida una clase Pila. Este tipo de dato definido por el usuario puede ser usadoslo cuando se crean instancias del tipo de dato. Por lo tanto, se puede crear miPila,tuPila y suPila como instancias de la clase Pila. Es el objeto quien ocupamemoria en una computadora.

Cliente delBanco

Cuenta deAhorros

CuentaCorriente

Depsitos

ClienteCuentaAhorros

CuentaCorriente

PlanillaDepositos


24/205





Un objeto promete cumplir el contrato prometido por su clase. Cada objeto puededefinirse en trminos del comportamiento que muestra o se espera que muestre. Unobjeto carro se define por su comportamiento como, moverse, acelerar, llevarpersonas, detenerse o voltear. Basado en su comportamiento, es fcil caracterizarun carro como estar en movimiento o esttico. El objeto carro puede poseer otraspropiedades fsicas como modelo, ao de fabricacin, tamao de tanque de

combustible, nmero de llantas, caractersticas de seguridad y nmero de registro.

Se puede decir que un objeto tiene lo siguiente:

Estado, en un instante dado en el tiempo:

El estado de un objeto son las propiedades y los valores que toman estaspropiedades en un instante en el tiempo. En un ejemplo de pila, el objetomiPila de la clase Pila puede tener dos propiedades estticas,elemento_pilay tope_de_pila. Los valores que tienen son dinmicos pornaturaleza, dado que pueden cambiar con el paso del tiempo. Un objeto conocesu estado en cualquier instante de tiempo. En la orientacin a objetos, un objeto

conoce acerca de s mismo y revela su estado a travs de su interfaz. Identidad, que es nica entre objetos de la misma clase:

La identidad de un objeto se refiere a la manera nica en que el objeto esconocido, referido y distinguido de todos los objetos en el sistema. Los objetossuPila y miPila se identifican como objetos diferentes en el sistema, dadoque poseen su espacio en memoria y un estado.

Comportamiento, que son usualmente los datos y funciones de dicha clase:

El comportamiento consiste de responsabilidades que promete llevar a cabo elobjeto. Es la manera en que un objeto reacciona a los mensajes que recibe (deotros objetos). Las operaciones push (agregar) y pop (extraer) definidas en laclase Pila son dos de los comportamientos presentados por la clase.

Una clase es un marco de trabajo (framework). Los objetos son manifestacionesconcretas de este marco de trabajo. Una definicin de clase debe existir para que losobjetos sean creados y para interactuar unos con otros. Es a travs de la interaccin deobjetos que funciona el sistema completo orientado a objetos.

2.8 Interfaz e Implementacin

Cuando la complejidad de una entidad en el mundo real llega a ser muy grande, seprecisa ocultar al usuario algunos de los detalles menos necesarios acerca de esaentidad. Usualmente, cada entidad tiene dos aspectos:

Interfaz.

Implementacin.


25/205





Una interfaz es la forma en la cual se presenta la clase al mundo real. Unaimplementacin es el mtodo que se sigue para hacer que el objeto de la clase realicesus responsabilidades.

Considere el siguiente ejemplo para entender la distincin entre interfaz eimplementacin:

El aire acondicionado de un automvil es una interfaz con mtodos definidos como:Distribuir el aire(), enfriar el aire(), entre otros, pero cada automvil implementa estosmtodos segn sus caractersticas, por ejemplo la distribucin de aire de una camionetaPick-up no puede ser la misma que la de una camioneta VAN, ya que esta ltimanecesita ms salidas de aire en su interior para que el enfriamiento sea uniforme.

En el ejemplo anterior, se ha visto de qu modo las actividades del mundo real se basanen interfaces e implementaciones. La mayora de las actividades que se realizan sebasan en el conocimiento del comportamiento proporcionado por la entidad en la queuno se interesa. Como usuario de un servicio, uno est interesado en lo quela entidadproporciona y no en cmo la entidad satisface el requerimiento. El qu describe la

interfaz de la entidad y el cmo proporciona la implementacin de la entidad. Estadistincin es crucial para el desarrollo orientado a objetos.

2.9 Mtodos

En la mayora de los lenguajes orientados a objetos, las operaciones que puede realizarun cliente sobre un objeto se declaran como mtodos. Los mtodos son una parte de ladeclaracin de la clase. C++ usa el trmino funcin miembro y Java usa el trminomtodospara denotar el mismo concepto. Se usarn estos trminos de modo indistinto.

Los mtodos son los algoritmos usados por la clase para implementar la tareaprometida por la interfaz. Por lo tanto, en el ejemplo de la pila, la tarea o responsabilidad

de agregar un elemento a la pila (push) se denomina un mtodo.

2.10 Mensajes

Los objetos se comunican unos con otros a travs de mensajes. Un mensaje es unpedido a un objeto para que realice una tarea a travs de un mtodo apropiado. Es elmecanismo usado por un objeto para hacer que otro objeto lleve a cabo una tarea. Elobjeto iniciador conoce la interfaz del objeto sobre el cual esta accin es iniciada. Elobjeto receptor satisface el requerimiento del objeto iniciador aceptndolo eimplementando la tarea.

Un buen ejemplo de la vida real podra ser un televisor y su control remoto, cuando

usted desea ver un programa en especial, busca el control remoto y presiona el botnde encendido. En ese momento el control remoto le enva literalmente al televisor unmensaje para que se encienda. El televisor recibe el mensaje, lo identifica como unapeticin y la realiza.


26/205





Un mensaje puede cambiar el estado del objeto receptor. Un mensaje puede tener ceroo ms argumentos explcitos. En este contexto, el objeto receptor es un argumentoimplcito que siempre est presente. El mensaje retorna un valor de cierto tipo,posiblemente void, al emisor del mensaje. Tpicamente, un mensaje contiene losiguiente:

El nombre del objeto que va a recibir el mensaje.

El nombre del mensaje.

Argumentos que son pasados al objeto receptor. Esto es opcional. Tambin sepueden pasar los mismos objetos como argumentos.

2.11 Herencia

Herencia, quiere decir que la clase X comparte la estructura y comportamiento de laclase Y. En este contexto, la clase Y se denomina la superclase y la clase X sedenomina la subclase. A veces se referir a la clase Ycomo el padre y la clase Xcomosu hija.

La Figura 1.4 describe la herencia entre las entidades Vehculoy Carro.

Figura 1.4: Herencia entre Vehculo y Carro

La subclase no slo necesita heredar la estructura y comportamiento tal como seencuentran en la superclase. Puede, y a veces lo hace, redefinir el comportamientoproporcionado por el padre. De modo alternativo, la subclase puede tambin aumentarlos servicios proporcionados por la superclase. La superclase se denomina tambin laclase base, mientras que la subclase es tambin referida como la clase derivada.

Ahora, Por qu una clase debe heredar la estructura y comportamiento de otra clase?La superclase publica algunas caractersticas que son ms generales por naturaleza.Las subclases pueden especializarse en estas caractersticas al heredar la claseoriginal y redefinir aquellas caractersticas. Por lo tanto, la herencia se refiere a unarelacin de generalizacin-especializacin entre clases.

Vehculo

Carro

Su erClase

SubClase


27/205





Por ejemplo, animal es una categora general de donde se deriva un caballo. La idea esmodelar el hecho de que un caballo es un animal. De modo similar, el hecho de queun guila sea un tipo de ave puede lograrse al heredar el guila de un ave. La idea esmuy simple. Piense en un guila. Qu imagen se obtiene inmediatamente? Se obtienela imagen de una criatura que tiene alas y tiene la habilidad de volar. El hecho de que elguila tenga alas y pueda volar es fundamental para cualquier ave. El comportamiento

general de volar est encapsulado en un ave lo cual es verdadero para cualquiera quees un ave. De modo similar, la estructura de un ave, que tiene alas, tambin estencapsulada en el ave. Ahora, corre por cuenta del guila especializarse bajo estaestructura y comportamiento, dado que tiene su propia manera de volar o mantener susalas. Por lo tanto, se puede decir que un guila es un ave.

El mundo real tambin tiene algunas excepciones. Mientras casi todas las aves tienen lahabilidad de volar, algunas aves como el avestruz no pueden volar. La especializacinpuede ocuparse tambin de tales excepciones.

La jerarqua de herencia especifica la relacin es un entre la subclase y la superclase.Es tambin posible que una subclase sea una superclase de otra clase. El ejemplo en la

Figura 1.5 resalta esto.

Figura 1.5: Jerarqua de Herencia

La Figura 1.5 describe una jerarqua de herencia la cual establece que cada subclasees un tipo de su superclase. Se presentan los siguientes ejemplos:

Empleado es una Persona.

Staff Administrativo es un Empleado.

Algunos ejemplos de una jerarqua es un se listan a continuacin:

Bsqueda binaria es un tipo de algoritmo de bsqueda.

Estudiante es una persona.

Persona

Estudiante Empleado

EstudianteGraduado

Estudiante deExtensin

Profesor StaffAdministrativo

ProfesorContratado

ProfesorTemporal


28/205





Rosa es una flor.

Animal es un ser vivo.

Humano es un mamfero.

Carro es un tipo de vehculo.

Pantaln es un tipo de prenda de vestir. Lapicero es un tipo de instrumento de escritura.

Los objetos que son diseados cuidadosamente para ser muy generales pueden serreutilizados en muchas circunstancias, ahorrando mucho esfuerzo en futuros problemasde programacin. La herencia que se ha visto hasta ahora es conocida como herenciasimple.

Es tambin posible para una subclase heredar de dos superclases. En esa situacin, laherencia se conoce como herencia mltiple. Los animales anfibios, como la rana y latortuga, son ejemplos de esto. Se muestra un ejemplo en la Figura 1.6.

Figura 1.6: Herencia Mltiple

Sin embargo, la herencia mltiple puede crear problemas. Tanto Animal Terrestrecomo Animal Acutico, por ejemplo, pueden definir un mtodo llamado mtodo derespiracin. Evidentemente, Animal Terrestre respira a travs de la nariz, mientrasque Animal Acutico respira a travs de agallas. Ahora, con herencia mltiple, Cul

de los mtodos de respiracin hereda Animal de anfibio?. Esto se conoce como elproblema del diamante. La jerarqua mostrada en la Figura 1.6 describe un problemade diamante.

Animal

AnimalTerrestre

AnimalAcutico

AnimalAnfibio


29/205





Cabe destacar que no todos los lenguajes de programacin implementan la herenciamltiple. C++ usa la palabra reservada virtualdurante la herencia para indicar que slouna copia del mtodo es derivada en la subclase. En el caso de Java no proporcionadicha capacidad.

2.12 Agregacin

Se estudi que la herencia proporciona una jerarqua de generalizacin-especializacin.Es tambin posible que una entidad contenga otra entidad. Asuma que se tienen cuatroentidades, Carro, Puerta, Asiento y Cap. Se puede afirmar que la entidad Carrocontiene Puertas, Asientos y un Cap. Se est enfatizando la relacin de contenedorcuando se asevera de esta manera. Esto es conocido como una relacin tiene unentre entidades. Presentado de otra manera, se puede decir, Un Carro tienePuertas,

Asientos y un Cap, tal como se muestra en la Figura 1.7.

Figura 1.7: Relacin Tiene un (has a)

La figura anterior describe la relacin tiene un entre Carro y las otras entidades.Denota que la entidad Carro tiene Puertas, Asientos y un Cap. La relacin tiene un esconocida tambin como la relacin contenedora.

A veces, se tiende a confundir la relacin contenedora entre dos entidades. Seentender esto con un ejemplo. Considere las dos entidades, Persona y Bebida. En

espaol, se dice, Persona tiene una Bebida, pero esto no significa que la entidadPersona contiene la entidad Bebida. Lo que se quiere decir con contenedora es que laentidad contenida es parte de la entidad contenedora. Esa aseveracin no es verdaderacon respecto a Persona y Bebida. Ellas existen separadamente y la entidad Personaslo es capaz de beber la Bebida, no de contener la entidad Bebida.

Es tambin incorrecto indicar, Lapicero tiene un Color. Color es un atributo de unLapicero, no una entidad. Las caractersticas de cualquier entidad sern indicadas enespaol como la entidad tiene caractersticas. Por eso las propiedades no calificanpara que se les llamen entidades. Las jerarquas es un y tiene un son slo entre dosentidades.

Algunos ejemplos de una relacin tiene un se listan a continuacin: Libro tiene Prrafos.

Prrafo tiene Palabras.

Sistema de Computadora tiene un Teclado.

Carro

Puerta Asiento Cap


30/205





Aves tienen Alas.

Edificio tiene Cuartos.

Entender la distincin entre la relacin es un y tiene un es muy importante en eldesarrollo de sistemas orientados a objetos.

2.13 Polimorfismo

Polimorfismo significa la posibilidad de hacer que una operacin exhiba diferentecomportamiento en instancias diferentes. El comportamiento depende de los tipos dedatos usados en diferentes operaciones. Por ejemplo, las fechas se pueden crear dealgunas de las siguientes maneras:

Usando tres enteros distintos, da, mes y ao (15, 8, 1947).

Usando una cadena (15/08/1947), de donde se pueden extraer las tres partes.

Usando un entero largo (19471508), de donde se pueden extraer las trespartes.

En los paradigmas de programacin tradicional, se debe proporcionar diferentesnombres para las tres funcionalidades. Se les puede llamar fechaEnteros,fechaStringy fechaLarga. Sin embargo, mediante el concepto de polimorfismo, sepuede proporcionar slo un nombre fecha y proporcionar tres diferentesfuncionalidades. La correspondencia entre la llamada actual y la implementacin de lafuncionalidad depender de los argumentos pasados con la llamada. Polimorfismosignifica un nombre, mltiples funcionalidades.

2.14 Tipo

Un tipo (type) es un estereotipo de una clase. Un estereotipo permite al diseador crearnuevos bloques de construccin extendiendo bloques existentes. Se usa el tipo paraespecificar un dominio de objetos y sus operaciones. Las implementaciones de estasoperaciones no estn incluidas en el tipo. Se usa el tipo cuando se desea modelar elsignificado de una abstraccin y la adherencia de la abstraccin a una interfaz.Tpicamente los tipos se usan para representar estructuras de datos. Por ejemplo, unaentidad estudiante se puede disear con una interfaz, mientras que la estructura dedatos que representa los detalles de un estudiante, como la estructura de datos lista, sepuede disear como un tipo.

2.15 Rol

Cada entidad tiene un cierto comportamiento asociado a ella. Un rol describe elcomportamiento de una entidad. Por ejemplo, una persona puede jugar diferentes roles

como profesora, hermana, hija, madre o pintora. Cuando un objeto juega un rol,presenta un determinado comportamiento al mundo exterior, dependiendo del rol que

juega el objeto en ese momento.


31/205





2.16 Paquete

Un paquete es un mecanismo para agrupar elementos. Normalmente, los elementoscohesivos son organizados en un paquete. Los elementos que se hacen referencia aquson elementos de modelo de alto nivel, a saber, clases y sus relaciones. Esto es similaral concepto de mdulos, donde los elementos de la funcin son agrupados.

A continuacin se discutir la importancia del modelado.

3. Importancia del Modelado

Un modelo es una representacin de la realidad. Grady Booch, James Rumbaugh e IvarJacobson definen un modelo como una simplificacin de la realidad. Un modeloproporciona el diseo de un sistema. Usando un modelo, se puede hacer lo siguiente:

Visualizar un sistema.

Especificar la estructura y comportamiento de un sistema.

Crear plantillas para construir el sistema. Documentar las decisiones hechas a lo largo del sistema.

Nota: No es suficiente un solo modelo para entender y representar un sistema.

Modelar sistemas de software es tan importante como modelar un edificio antes de suconstruccin. Un lenguaje de modelado consiste tpicamente de elementos del modelo,notaciones y directivas. Para ocuparse de los sistemas complejos, es esencial lavisualizacin. La visualizacin del sistema se convierte a un formato entendible por losdesarrolladores usando una tcnica de Modelado. UML es un lenguaje de modeladovisual que ayuda a construir sistemas grandes y complejos orientados a objetos ybasados en componentes.

A continuacin se aprender acerca de UML.

4. UML

UMLes un lenguaje usado para especificar, visualizar, construir y documentar lasdiversas piezas de sistemas de software y tambin para modelado de negocios y otrossistemas que no sean software. El uso de UML en el desarrollo de sistemas orientadosa objetos gan importancia cuando los tres autores de esta metodologa, Grady Booch,James Rumbaugh e Ivar Jacobson, llegaron juntos a Rational Software Corporation.Estos autores presentaron un lenguaje de modelado visual que puede considerarsecomo un estndar para el desarrollo de sistemas Orientados a Objetos. UML fuedesarrollado en Rational Software Corporation, con contribuciones de otrosmetodologstas, lderes, vendedores de software y muchos usuarios. Hoy da, UML esconsiderado el estndar de la industria para el desarrollo de sistemas de softwareorientados a objetos.


32/205





Antes de UML, existieron tres metodologas populares de desarrollo de sistemasOrientados a Objetos, cada cual un invento de los tres autores anteriores. Lametodologa de Grady Booch fue llamada Boochgrams. La tcnica de James Rumbaughera conocida como Tcnica de Modelado de Objetos (Object Modeling Technique -OMT) y el mtodo de Ivar Jacobson fue llamado Ingeniera de Software Orientado aObjetos (Object-Oriented Software Engineering - OOSE).

UML proporciona un lenguaje de modelado de aplicaciones para lo siguiente:

Modelado de proceso de negocios con casos de uso.

Modelado de clases y objetos.

Modelado de componentes.

Modelado de distribucin e implementacin (deployment).

5. El Modelo UML

Para entender UML en su totalidad, se deben aprender tres importantes elementos. Son

estos:

Bloques de construccin de UML.

Reglas que ayuden a agrupar los bloques de construccin.

Mecanismos comunes aplicados en el proceso de uso del lenguaje demodelado.

La estructura de los bloques de construccin de UML se describe en la Figura 1.8.


33/205





Figura 1.8: Estructura de Bloques de Construccin de UML

A continuacin se discute cada elemento, relacin y diagrama.

5.1 Bloques de Construccin

Los bloques de construccin de UML se clasifican en tres amplios conceptos:

Elementos del modelo.

Relaciones.

Diagramas.

5.2 Elementos del Modelo

Existen cuatro tipos de elementos del modelo.

Elementos Estructurales:Los elementos estructurales son entidades estticas.No revelan un comportamiento dinmico. Forman los nombres para el modelo

UML. Representan ya sea un elemento fsico o uno conceptual. Existen sietetipos de elementos de modelo estructural. stos son:

- Clase:Representa un dominio de objetos que comparten los mismos atributos,operaciones y relaciones.


34/205





- Interfaz:Es un conjunto de operaciones que revela los servicios ofrecidos poruna clase o componente.

- Caso de Uso:Es una descripcin de un conjunto de acciones que realiza unsistema con respecto a un actor particular interesado en el sistema. Un actores una entidad que interacta con algn aspecto del sistema. Una definicinformal de caso de uso ser proporcionada en el Volumen 2, Unidad 1 Modelado Bsico del Comportamiento.

- Colaboracin:Es la realizacin de un caso de uso.

- Clase Activa:Es una clase cuyos objetos pueden poseer uno o ms procesos.Tales objetos pueden iniciar una actividad de control.

- Componente: Es la parte reemplazable de un sistema. Tal reemplazo esposible slo si el componente se ajusta al contrato proporcionado por lainterfaz.

- Nodo:Es un recurso que puede ser computado y por lo tanto, existe en tiempode ejecucin. Es un elemento estructural fsico.

Elementos de Comportamiento: Los elementos que representan el modelo

dinmico se denominan elementos de comportamiento. Se tienen dos elementosde comportamiento: Interaccin y Mquina de Estado. Las interacciones sonmensajes que son pasados entre objetos para permitirles interactuar unos conotros para acometer una tarea particular. Una mquina de estado describe losdiferentes estados que atraviesa un objeto en respuesta a eventos.

Elementos de Agrupacin: Partes del modelo UML que representan aspectosorganizacionales son llamados elementos de agrupacin.El paquete es el nicoelemento de agrupacin. Un paquete se usa para organizar elementoscohesivos en grupos.

Elementos de Anotacin:Estos elementos se usan para describir las partes deUML. Se tiene un elemento de anotacin llamado nota, que se usa para

documentar restricciones y comentarios asociados con los elementos.5.3 Relaciones

UML proporciona cuatro tipos de relaciones:

Dependencia:Es una relacin semntica entre dos elementos. Un cambio enun elemento puede causar un cambio en el elemento dependiente.

Asociacin: Es una relacin estructural. Es el enlace entre dos o ms objetosen el sistema. Es a travs de la asociacin que los objetos interactan unos conotros para cumplir tareas especficas.

Generalizacin: Es la relacin de generalizacin / especializacin. El objeto

especializado, el hijo, hereda los atributos, operaciones, relaciones y semnticade la clase generalizada, el padre.

Realizacin: Esta relacin existe entre las interfaces y las clases ocomponentes que realizan las interfaces. Tambin existe entre casos de uso ylas colaboraciones que realizan los casos de uso. La relacin de realizacin


35/205





describe la relacin semntica. Se aprender posteriormente ms acerca de larelacin de realizacin.

5.4 Diagramas

Un diagrama es una representacin grfica. Cada diagrama de UML proporciona una

vista diferente del sistema. UML proporciona nueve tipos de diagramas. Son estos: Diagrama de Clases:Muestra un conjunto de clases, interfaces, colaboraciones

y sus relaciones.

Diagrama de Objetos:Muestra un conjunto de objetos y sus relaciones.

Diagrama de Casos de Uso:Muestra casos de uso, actores y sus relaciones.sta es una perspectiva importante para entender un sistema.

Diagrama de Secuencias: Muestra el ordenamiento en el tiempo de losmensajes. Tambin muestra el enfoque de control de cada objeto que participaen un escenario.

Diagrama de Colaboracin:Muestra la organizacin estructural de objetos que

interactan unos con otros. Diagrama de Estados:Se usa para representar mquinas de estado. Consiste

de estados, transiciones, eventos y acciones.

Diagrama de Actividad:Muestra el flujo de una actividad a otra en el sistema.ste es un tipo nico de diagrama de estados.

Diagrama de Componentes:Muestra la organizacin y dependencias entre unconjunto de componentes en el sistema.

Diagrama de Distribucin e Implementacin (Deployment): Muestra losnodos y los componentes que residen en ellos.

5.5 Reglas

Las reglas ayudan a los bloques de construccin de UML a especificar un modelo bienformado. Un modelo est bien formado si es auto-consistente y sincroniza con todos losotros modelos relacionados. UML incluye reglas semnticas para:

Nombre: Se usa para identificar elementos del modelo, relaciones y diagramas.

Visibilidad: Especifica la manera en que los nombres pueden ser vistos yusados por los clasificadores.

mbito:Es el contexto en el cual los nombres residen.

Ejecucin:Es la manera en que el modelo dinmico se simula.

Integridad:Especfica cmo los elementos del modelo se relacionan unos conotros.

5.6 Mecanismos Comunes

Los mecanismos se usan a lo largo de UML para simplificar el proceso de construccindel modelo. Existen cuatro tipos de mecanismos, stos son:


36/205





Especificacin:Es el mecanismo que proporciona la descripcin de la sintaxis ysemntica de los bloques de construccin de UML. La representacin grficasimplemente proyecta partes relevantes del modelo en consideracin, y por lotanto revela un aspecto especfico del sistema.

Adornos:Los adornos son simples decoraciones que ayudan a entender el rol

del elemento del modelo en el sistema. Un elemento del modelo se representapor un componente visual en UML, el cual es el smbolo bsico para eseelemento del modelo. Los adornos se usan para agregar ms detalles alelemento del modelo.

Divisin Comn:La construccin de sistemas orientados a objetos conlleva adividir el mundo real en diferentes segmentos. Una divisin se relaciona a:

- Clases e instancias de clases.

- Casos de uso e instancias de casos de uso.

- Componentes e instancias de componentes.

Otra divisin se relaciona a la separacin entre interfaz e implementacin. Lasimplementaciones realizan el contrato especificado por la interfaz.

Otra divisin ocurre entre los casos de uso y colaboraciones, donde lascolaboraciones son realizaciones concretas de casos de uso.

Mecanismos de Extensibilidad: UML proporciona tres tipos de mecanismosextensibles. stos son:

- Estereotipos.

- Valores etiquetados (Tagged values).

- Restricciones.

Un estereotipo permite al diseador crear nuevos bloques de construccin extendiendo

bloques existentes. Los valores marcados se usan para crear informacin nueva en laespecificacin de un elemento del modelo. Una restriccin se usa para crear nuevasreglas al extender aquellas existentes. Habiendo discutido brevemente el modelo UML,se aprender acerca de los tres tipos de modelado que ofrece UML. stos son:

Modelado estructural.

Modelado de comportamiento.

Modelado arquitectnico.

En los siguientes volmenes se estudiarn cada uno de ellos a profundidad.


37/205





Resumen

Ahora que ha completado esta unidad, usted debe ser capaz de:

Describir la necesidad del Anlisis y Diseo Orientado a Objetos (ObjectOriented Analysis and Design - OOAD).

Explicar los principios de la orientacin a objetos. Describir el trabajo del Lenguaje Unificado de Modelado (Unified Modeling

Language - UML).

Describir la importancia del modelado en UML.


38/205





Unidad 1: Examen de Autoevaluacin1) Cul(es) fase(s) del esfuerzo de la construccin del barco (en la Tragedia de

Vasa) puede relacionarse al esfuerzo del desarrollo de software?

a) Requerimientos

b) Diseoc) Prueba

d) Todas las anteriores

2) Cul de los siguientes conceptos se relaciona a eliminar lo innecesario?

a) Encapsulamiento

b) Ocultamiento de informacin

c) Abstraccin

d) Ninguna de las anteriores

3) Cul de los siguientes no es un bloque de construccin de UML?

a) Elementos del modelo

b) Relaciones

c) Diagramas

d) Adornos

4) UML fue la primera metodologa inventada para desarrollar sistemas orientados aobjetos

a) Verdaderob) Falso

5) Cules de las siguientes afirmaciones son correctas?

a) La esencia del encapsulamiento recae en que cuando un objeto trae consigosu funcionalidad, esta ltima se oculta.

b) Los objetos interactan con otros para proporcionar una solucin a unproblema.

c) Una interfaz es el mtodo que se sigue para hacer que el objeto de la claserealice sus responsabilidades.

d) Las operaciones que puede realizar un cliente sobre un objeto se declarancomo atributos.


39/205





6) Cul de las siguientes relaciones enfatiza una relacin de uso (using)?

a) Asociacin

b) Agregacin

c) Generalizacin

d) Dependencia

7) Animal mamfero, es una categora general de donde se deriva un caballo. Qutipo de relacin existe entre animal y caballo?

a) Asociacin

b) Agregacin

c) Generalizacin

d) Dependencia

8) La relacin tiene un es conocida tambin como la relacin asociativa

a) Verdadero

b) Falso

9) Permite a una persona concentrarse en los aspectos esenciales del problema a lamano, mientras ignora detalles que tienden a distraer

a) Encapsulamiento

b) Rol

c) Tipo

d) Abstraccin

10) Cules de las siguientes afirmaciones son correctas?

a) La jerarqua de herencia permite que la subclase herede los miembros dedatos y operaciones.

b) Polimorfismo significa la capacidad para hacer que una operacin exhiba elmismo comportamiento en diferentes instancias.

c) El encapsulamiento es un mecanismo para agrupar los datos y los mtodosde las clases.

d) Ninguna de las anteriores.


40/205





Respuestas a la Unidad 1: Examen de Autoevaluacin1) d

2) c

3) d

4) b5) a y b

6) d

7) c

8) b

9) d

10) a y c


41/205


Libro 1: Anlisis y Diseo de Sistemas Orientado a ObjetosUnidad 2: Modelado del Comportamiento con Casos de Uso 33



Unidad 2: Modelado del Comportamientocon Casos de Uso

Objetivos de AprendizajeAl final de esta unidad, usted ser capaz de:

Definir la importancia de los casos de uso.

Definir cada uno de los elementos involucrados en un diagrama de casos deuso.

Describir el anlisis para un caso de uso.

Describir la importancia y los elementos de los diagramas de actividad.

Elaborar un diagrama de casos de uso.

Elaborar diagramas de actividad.


42/205


Unidad 2: Modelado del Comportamiento con Casos de UsoLibro 1: Anlisis y Diseo de Sistemas Orientado a Objetos 34



1. Introduccin

Cuando se comienza el desarrollo de un sistema es de crucial importancia comprenderel punto de vista del usuario. Comprender tal punto de vista es clave para generarsistemas que sean tanto tiles como funcionales, es decir, que cumplan con losrequerimientos y sean sencillos de trabajar.

El modelado, desde el punto de vista del usuario, es llamado Casos de Uso. En estaunidad se comprender todo lo relacionado con los casos de uso, su importancia y sufuncin, adems de los diagramas de actividad que describen cada caso de uso delsistema.

2. Importancia de los Casos de Uso

El caso de uso es una excelente herramienta para que los usuarios describan el sistemadesde sus propios puntos de vista.

La idea es involucrar a los usuarios en las etapas iniciales del anlisis y diseo delsistema. Esto aumentar las probabilidades de que el sistema sea de mayor provechopara las personas que lo utilizan, en vez de ser un sistema computacionalincomprensible para los usuarios finales.

3. Casos de Uso

Un caso de uso es una interaccin entre un usuario u otra entidad y el sistema que esdiseado. Un caso de uso es una descripcin de un conjunto de acciones que realiza unsistema con respecto a un actor particular interesado en el sistema. Formulado por IvarJacobson, los casos de uso se popularizaron en la mayora de sistemas orientados aobjetos. El usuario o la entidad que tiene inters en el sistema que se est diseando es

llamado actor. En otras palabras, un actor es una entidad que interacta con el sistema.

Un caso de uso involucra interacciones entre diversos actores y el sistema. El actorpuede ser otro sistema o subsistema. El actor representa el rol que cumplen losusuarios mientras interactan con el sistema.

Los casos de uso son tiles por varias razones ya que ayudan a hacer lo siguiente:

Descubrir requerimientos.

Capturar la necesidad del usuario al enfocarse en la tarea que el usuarionecesita realizar con el sistema.

Formular planes de prueba del sistema.

Controlar el desarrollo iterativo.

A continuacin se muestran algunos casos de uso tpicos:

Generar nmero identificacin.


43/205





Imprimir reporte.

Ver estadsticas.

Asignar curso.

Crear documento.

Publicar libro.Se observa de lo anterior que todos los casos de uso son una combinacin de un verboy un sustantivo. Al listar los casos de uso, se observa esencialmente el sistema desde elpunto de vista del actor. En consecuencia, cada caso de uso o conjunto de casos deuso tiene sentido slo en el contexto de un actor.

Para los casos de uso anteriores, se pueden identificar los siguientes actores:

Gerente de Registro.

Oficinista del Banco.

Responsable de actualizar Inventario.

Adjudicador de cursos. Autor.

Editor libros.

Los actores no son las abstracciones del sistema. Ellos representan los usuariosexternos que pueden usar el sistema que se est diseando.

Cada caso de uso tiene un nombre; puede ser un nombre simple o un nombre de ruta.El nombre de ruta puede tener el nombre del paquete en donde se ubica el caso de uso.

En UML, un caso de uso se dibuja como una elipse con el nombre dentro de la elipse,tal como se muestra en la Figura 2.1.

Figura 2.1: Casos de Uso: Usando Nombres Simples y Nombres de Ruta

Los actores que participan en el sistema pueden ser heredados de un actor existente.

Un ejemplo se muestra en la Figura 2.2.

Validar curso DetalladorCurso::Validar curso

Nombre simple Nombre de ruta


44/205





Figura 2.2: Ejemplo de Herencia en Actores

3.1 Colaboraciones

Un caso de uso captura el comportamiento deseado del sistema. Esto no especifica dequ modo ser llevado a cabo el comportamiento. Pero eventualmente, cada caso deuso tiene que ser implementado, creando una sociedad de clases y otros elementos que

ayuden a implementar el comportamiento del caso de uso. Por ejemplo, la sociedad declases necesarias para implementar el caso de uso Asignar Curso consiste deGerenteRegistro,Curso, Disciplina, Estudiantey Visualizador.

La colaboracin se usa en UML para representar una sociedad de elementos, tantoestticos como dinmicos, que ayuden a implementar el comportamiento de un caso deuso, esto es, un caso de uso es realizado por una colaboracin.

La colaboracin de un caso de uso se representa como una elipse punteada, y larealizacin del caso de uso se describe como una lnea punteada con la flechaapuntando hacia el caso de uso que realiza, tal como se ilustra en la Figura 2.3.

Figura 2.3: Representacin de una Realizacin de Caso de Uso por Colaboracin

3.2 Flujo de Eventos

Un caso de uso se usa para ilustrar lo que hace un sistema; sin embargo, un caso deuso no especifica el modo en que el sistema lo implementa.

La descripcin de un flujo de eventos describe el comportamiento de un caso de uso. Elflujo de eventos se puede mostrar usando cualquiera de los siguientes mtodos:

Texto estructurado informal.

Asignarcursos

Administrarcursos


45/205





Texto estructurado con precondiciones y postcondiciones.

Seudocdigo.

En cualquiera de los mtodos anteriores, puede describirse el flujo principal de eventosas como el flujo excepcional o alternativo.

Un ejemplo de flujo de eventos que usa texto informal se da a continuacin. Esto espara un caso de uso llamado Asignar Cursoy el actor involucrado es el Gerentede Registro, quien es responsable de la asignacin de cursos.

Caso de uso:Asignar Curso

El flujo principal de eventos para el caso de uso Asignar Cursoser el siguiente:

El sistema indica al Gerente de Registro para ingresar el cdigo dedisciplina del curso, para el cual tiene que hacerse la asignacin.

El Gerente de Registroingresa el cdigo de disciplina a travs del teclado.

El sistema verifica la validez del cdigo de disciplina. Luego el sistema indica al Gerente de Registropara ingresar si los cursos

van a ser asignados a un solo estudiante, a un grupo de estudiantes o a todoslos estudiantes.

El Gerente de Registroelige una de las tres opciones.

El sistema muestra los cursos disponibles para el semestre actual para laasignacin.

El Gerente de Registroelige los cursos a ser asignados.

El sistema muestra los detalles al Gerente de Registro y espera unaconfirmacin.

El Gerente de Registroconfirma la asignacin.

El sistema genera una entrada en el registro del estudiante para el semestreactual acerca de los cursos que han sido asignados para el estudiante.

El Gerente de Registrosale del sistema.

El flujo excepcional de eventos para el caso de uso Asignar Cursoser el siguiente:

El Gerente de Registropuede cancelar la operacin en cualquier momento.No se realiza cambio alguno al registro del estudiante.

El Gerente de Registro puede ingresar el cdigo de disciplina cualquiernmero de veces. En tanto no presione el botn OK, puede limpiar y reingresar el

cdigo de disciplina. El sistema indica al Gerente de Registro para ingresar nuevamente el

cdigo de disciplina si el cdigo de disciplina no es vlido.

El flujo de eventos anterior es para uno de los casos de uso. Cada caso de uso puedeser asociado con una descripcin de flujo de eventos, de un modo similar.


46/205





En la Figura 2.4, se muestra un formato para el flujo de eventos del tipo Textoestructurado con precondiciones y postcondiciones, cabe destacar que no es un modelonico, sino una referencia.

Figura 2.4: Formato para Flujo de Eventos de Tipo Texto Estructurado

3.3 Escenarios

Un escenario es una instancia de un caso de uso. Normalmente existe una expansinde un caso de uso a un escenario. Un solo caso de uso puede resultar en variosescenarios. Para la mayora de casos de uso, se pueden tener escenarios primarios ysecundarios. Los escenarios primarios definen las secuencias esenciales y los

secundarios definen las secuencias alternativas. Por ejemplo, el caso de uso Generarlista de estudiantes graduados puede tener variantes como generar listasbasado en ciertas entradas que son diferentes para estudiantes universitarios, depostgrado y de investigacin. Estas variantes pueden ser modeladas como secuenciasalternas.

3.4 Relaciones

Se pueden usar tres tipos de relaciones con casos de uso. stas son:

Generalization(generalizacin):En la herencia de los casos de uso, elcaso de uso secundario hereda las acciones y significado del primario, adems

agrega sus propias acciones. Tal como se muestra en la Figura 2.5.


47/205





Figura 2.5: Relacin de Generalizacin

La figura anterior indica que los casos de uso Validar curso Pregrado yValidar curso Postgrado heredan de un caso de uso ms generalizado,Validar curso. El caso de uso hijo hereda el comportamiento y significadodel caso de uso padre. As como es posible con clases, un caso de uso hijopuede ser sustituido donde sea que aparezca el caso de uso padre. Larepresentacin de la generalizacin es una flecha vaca que apunta del caso deuso hijo al caso de uso padre

Include (inclusin): Los casos de uso pueden incluir otros casos de uso.Cuando existen secuencias de pasos en comn es importante crear un nuevocaso de uso que agrupe esas secuencias, luego existirn casos de usos queincluirn al nuevo creado, de manera de simplificar el diagrama. Es importante

destacar que los casos de uso que se incluyen nunca aparecern solo,simplemente funcionan como parte de un caso de uso que lo incluya. Elestereotipo se usa para denotar la relacin include. Larepresentacin en UML es una flecha abierta punteada que sale desde el casode uso base y apunta al caso de uso que se quiere incluir. Un ejemplo puedeverse en la Figura 2.6.

Extend(extensin):Los casos de uso pueden extenderse de otros casos deuso. La relacin extend indica que el comportamiento del caso de uso base esextendido o ampliado por otro caso de uso (caso de uso que extiende), en laubicacin especificada por el punto de extensin. El caso de uso base puedeexistir por s mismo. Los puntos de extensin pueden ser mencionados dentrodel caso de uso base, adems los puntos de extensin son puntos donde elcomportamiento del caso de uso extendido aparece. Estos casos de uso puedetener uno o ms puntos de extensin. Todos los puntos de extensin tienennombre. La representacin en UML es una flecha abierta punteada que sale delcaso de uso que extiende y apunta al caso de uso base. Un ejemplo puedeverse en la Figura 2.6.

Validarcurso

Validarcurso

Pregrado

Validarcurso

Postgrado


48/205





Figura 2.6: Relaciones includey extend

En la Figura 2.6, el caso de uso Generar tarjeta registroincluye explcitamente

el comportamiento de los casos de uso Validar curso y Validar estudiante.Validar curso y Validar estudiante no pueden existir por s mismos, sin serincluidos por un caso de uso.

Tambin, se muestra que el caso de uso Ver status estudiante extiende elcomportamie

Libro 1 Completo UML V51

Documents

Transcript of Libro 1 Completo UML V51