eidos uml - diseno orientado a objetos con uml spanish.pdf

download eidos uml - diseno orientado a objetos con uml spanish.pdf

of 117

Transcript of eidos uml - diseno orientado a objetos con uml spanish.pdf

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    1/117

    Este texto muestra lasdistintas tcnicas quese necesitan para

    disear aplicacionesinformticas desde laperspectiva de laorientacin a objetos,usando lo que sedenomina UML(Lenguaje Unificado deModelado).

    Pretende adiestrar enlas tcnicas de anlisis

    orientadas al objeto ascomo capacitar en losmtodos, notacin ysmbolos de UML.

    Los conceptos se llevana la prctica con VisualModeler, laherramienta deMicrosoft para elmodelado de objetos.

    Va dirigido a personascon amplia experienciaen desarrollo deaplicaciones desde laperspectiva de laprogramacin.

    DDIISSEEOOOORRIIEENNTTAADDOOAA

    OOBBJJEETTOOSSCCOONNUUMMLLRRAALLAALLAARRCCNN

    Desarrollo de software

    UUUMMMLLL

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    2/117

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    3/117

    ADVERTENCIA LEGAL

    Todos los derechos de esta obra estn reservados a Grupo EIDOS Consultora y Documentacin

    Informtica, S.L.

    El editor prohbe cualquier tipo de fijacin, reproduccin, transformacin, distribucin, ya sea medianteventa y/o alquiler y/o prstamo y/o cualquier otra forma de cesin de uso, y/o comunicacin pblica de la

    misma, total o parcialmente, por cualquier sistema o en cualquier soporte, ya sea por fotocopia, medio

    mecnico o electrnico, incluido el tratamiento informtico de la misma, en cualquier lugar del universo.

    El almacenamiento o archivo de esta obra en un ordenador diferente al inicial est expresamente

    prohibido, as como cualquier otra forma de descarga (downloading), transmisin o puesta a disposicin

    (an en sistema streaming).

    La vulneracin de cualesquiera de estos derechos podr ser considerada como una actividad penal

    tipificada en los artculos 270 y siguientes del Cdigo Penal.

    La proteccin de esta obra se extiende al universo, de acuerdo con las leyes y convenios internacionales.

    Esta obra est destinada exclusivamente para el uso particular del usuario, quedando expresamente

    prohibido su uso profesional en empresas, centros docentes o cualquier otro, incluyendo a sus empleadosde cualquier tipo, colaboradores y/o alumnos.

    Si Vd. desea autorizacin para el uso profesional, puede obtenerla enviando un e-mail [email protected]

    al fax (34)-91-5017824.

    Si piensa o tiene alguna duda sobre la legalidad de la autorizacin de la obra, o que la misma ha llegado

    hasta Vd. vulnerando lo anterior, le agradeceremos que nos lo comunique al e-mail [email protected] al

    fax (34)-91-5017824). Esta comunicacin ser absolutamente confidencial.

    Colabore contra el fraude. Si usted piensa que esta obra le ha sido de utilidad, pero no se han abonado los

    derechos correspondientes, no podremos hacer ms obras como sta.

    Ral Alarcn, 2000

    Grupo EIDOS Consultara y Documentacin Informtica, S.L., 2000

    ISBN 84-88457-03-0

    Diseo orientado a objetos con UMLRal Alarcn

    Responsable editorial

    Paco Marn ([email protected])

    AutoedicinMagdalena Marn ([email protected])

    Ral Alarcon ([email protected])

    Coordinacin de la edicin

    Antonio Quirs ([email protected])

    Grupo EIDOSC/ Tllez 30 Oficina 2

    28007-Madrid (Espaa)

    Tel: 91 5013234 Fax: 91 (34) 5017824

    www.grupoeidos.com/www.eidos.es www.LaLibreriaDigital.com

    mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]://www.grupoeidos.com/www.eidos.eshttp://www.grupoeidos.com/www.eidos.eshttp://www.lalibreriadigital.com/http://www.lalibreriadigital.com/http://www.lalibreriadigital.com/http://www.grupoeidos.com/www.eidos.esmailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]
  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    4/117

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    5/117

    ndice

    NDICE...................................................................................................................................................5

    INTRODUCCIN AL MODELADO ORIENTADO A OBJETOS.................................................9

    MODELADO ........................................................................................................................................10PRINCIPIOS BSICOS DEL MODELADO................................................................................................11ORIENTACIN A OBJETOS ..................................................................................................................11VENTAJAS DE LA ORIENTACIN A OBJETOS .......................................................................................12CONCEPTOS BSICOS DE LA ORIENTACIN A OBJETO........................................................................12

    INTRODUCCIN AL LENGUAJE UNIFICADO DE MODELADO, UML...............................15

    VISTA GENERAL DE UML ..................................................................................................................16BLOQUES DE CONSTRUCCIN DE UML .............................................................................................17Elementos Estructurales................................................................................................................17

    Clases.........................................................................................................................................17Interfaz.......................................................................................................................................18Colaboracin..............................................................................................................................18Casos de Uso..............................................................................................................................18Clase Activa...............................................................................................................................19Componentes .............................................................................................................................19Nodos.........................................................................................................................................19

    Elementos de comportamiento.......................................................................................................20Interaccin .................................................................................................................................20

    Maquinas de estados..................................................................................................................20Elementos de agrupacin ..............................................................................................................20

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    6/117

    6

    Elementos de anotacin.................................................................................................................21Relaciones......................................................................................................................................21

    Dependencia ..............................................................................................................................21Asociacin .................................................................................................................................21Generalizacin...........................................................................................................................22 Realizacin ................................................................................................................................22

    Diagramas .....................................................................................................................................22Diagramas de Clases..................................................................................................................22Diagramas de Objetos................................................................................................................23Diagramas de Casos de Usos.....................................................................................................23Diagramas de Secuencia y de Colaboracin..............................................................................23Diagramas de Estados................................................................................................................23Diagramas de Actividades .........................................................................................................23Diagramas de Componentes ......................................................................................................23Diagramas de Despliegue ..........................................................................................................23

    ARQUITECTURA .................................................................................................................................24CICLO DE VIDA ..................................................................................................................................25

    MODELADO ESTRUCTURAL........................................................................................................27REPRESENTACIN DE LAS CLASES EN UML......................................................................................28RESPONSABILIDADES.........................................................................................................................29RELACIONES ......................................................................................................................................30

    Relacin de Dependencia ..............................................................................................................30Relacin de Generalizacin...........................................................................................................31Relacin de Asociacin..................................................................................................................33

    INTERFACES .......................................................................................................................................35ROLES ................................................................................................................................................36PAQUETES ..........................................................................................................................................37

    Trminos y conceptos ....................................................................................................................37

    Elementos Contenidos ...................................................................................................................38INSTANCIAS........................................................................................................................................39Operaciones...................................................................................................................................39

    Estado ............................................................................................................................................39Modelado de instancias concretas................................................................................................. 40Modelado de instancias prototpicas.............................................................................................40

    DIAGRAMAS DE CLASES Y DE OBJETOS ................................................................................. 43

    DIAGRAMAS DE CLASES ....................................................................................................................43Usos comunes ................................................................................................................................44

    Modelado de colaboraciones simples............................................................................................44Modelado de un Esquema Lgico de Base de Datos.....................................................................45

    DIAGRAMAS DE OBJETOS ..................................................................................................................46Usos comunes ................................................................................................................................48Modelado de estructuras de objetos .............................................................................................. 48

    MODELADO DEL COMPORTAMIENTO.....................................................................................51

    INTERACCIONES.................................................................................................................................51Contexto.........................................................................................................................................52Objetos y Roles ..............................................................................................................................53

    Enlaces...........................................................................................................................................53Mensajes ........................................................................................................................................54Modelado de un flujo de control....................................................................................................55

    CASOS DE USO ...................................................................................................................................56Casos de uso y actores...................................................................................................................58Casos de uso y flujo de eventos .....................................................................................................58

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    7/117

    Casos de uso y escenarios .............................................................................................................59Casos de uso y colaboraciones......................................................................................................59

    Modelado del Comportamiento de un Elemento ...........................................................................60

    DIAGRAMAS PARA EL MODELADO DEL COMPORTAMIENTO ........................................63

    DIAGRAMAS DE CASOS DE USO .........................................................................................................64Usos comunes ................................................................................................................................64

    Modelado del contexto de un sistema............................................................................................65Modelado de los requisitos de un sistema ..................................................................................... 66

    DIAGRAMAS DE INTERACCIN...........................................................................................................67Diagramas de Secuencia ...............................................................................................................67Diagramas de Colaboracin .........................................................................................................68Modelado de flujos de control por ordenacin temporal ..............................................................69Modelado de flujos de control por organizacin...........................................................................70

    DIAGRAMAS DE ACTIVIDADES ...........................................................................................................72Estados de la accin y estados de la actividad..............................................................................73Transiciones...................................................................................................................................74

    Bifurcacin ....................................................................................................................................75Divisin y Unin............................................................................................................................75Calles (Swimlanes) ........................................................................................................................76Usos comunes ................................................................................................................................76

    VISUAL MODELER...........................................................................................................................79

    CONCEPTOS........................................................................................................................................80Sistemas cliente servidor en tres capas .........................................................................................80Vistas de Visual Modeler...............................................................................................................81

    Vista Lgica (Logical View)......................................................................................................81 Vista de Componentes (Component View) ................................................................................82Vista de Despliegue (Deployment View) .................................................................................. 83

    BARRA DE HERRAMIENTAS DE VISUAL MODELER............................................................................84Sobre Archivo ................................................................................................................................84Sobre Edicin.................................................................................................................................84Sobre Utilidades ............................................................................................................................85Sobre Diagramas...........................................................................................................................85Sobre Visualizacin .......................................................................................................................85

    BARRA DE HERRAMIENTAS PARA LOS DIAGRAMAS ..........................................................................86Elementos comunes a todos los diagramas ...................................................................................86Elementos para los Diagramas de Clases.....................................................................................86

    Clases (Class).............................................................................................................................87Interfaces....................................................................................................................................91Clases de Utilidades (Class Utility)...........................................................................................92

    Asociaciones (Asociation).........................................................................................................92Asociacin unidireccional (Unidirectional Association)...........................................................93Agregacin (Agregation)...........................................................................................................94Generalizacin (Generalization)................................................................................................94Dependencia (Dependency).......................................................................................................95Paquetes Lgicos (Package) ......................................................................................................96

    Elementos para los Diagramas de Componentes.......................................................................... 96Componente (Component).........................................................................................................96Dependencia (Dependency).......................................................................................................98Paquetes de Componentes (Package) ........................................................................................98

    Elementos para los Diagramas de Despliegue..............................................................................99Nodo (Node) ..............................................................................................................................99Conexin (Conection)..............................................................................................................100

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    8/117

    8

    INGENIERA DIRECTA E INVERSA CON VISUAL MODELER...........................................101

    VISUAL MODELER ADD-IN PARA VISUAL BASIC.............................................................................102GENERACIN DE CDIGO DESDE VISUAL MODELER......................................................................103

    Propiedades para las Clases .......................................................................................................103OptionBase ..............................................................................................................................103

    OptionExplicit..........................................................................................................................103OptionCompare........................................................................................................................104Creatable..................................................................................................................................104 GenerateInitialization y GenerateTermination ........................................................................104CollectionClass........................................................................................................................104

    Propiedades para la relacin de Generalizacin........................................................................106ImplementsDelegation.............................................................................................................106

    Propiedades para los Mtodos .................................................................................................... 107OperationName........................................................................................................................107LibrayName.............................................................................................................................107AliasName ...............................................................................................................................107IsStatic .....................................................................................................................................107

    EntryCode y ExitCode.............................................................................................................107Propiedades para la especificacin del Modulo .........................................................................108

    Module Specification...............................................................................................................108Propiedades para la definicin de una Propiedad o Rol ............................................................108IsConst .........................................................................................................................................108

    New..........................................................................................................................................108WithEvents ..............................................................................................................................108Subscript ..................................................................................................................................109NameIfUnlabeled.....................................................................................................................109GenerateDataMember..............................................................................................................109GenerateGet/Let/SetOperation.................................................................................................109

    ASISTENTE PARA LA GENERACIN DE CDIGO VISUAL BASIC.......................................................109

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    9/117

    Introduccin al modelado orientado aobjetos

    El desarrollo de proyectos software ha sufrido una evolucin desde los primeros sistemas de calculo,implementados en grandes computadores simplemente ayudados mediante unas tarjetas perforadasdonde los programadores escriban sus algoritmos de control, hasta la revolucin de los sistemas deinformacin e Internet. Han existido dos grandes cambios desde aquellos sistemas meramentealgortmicos donde todo el esfuerzo de desarrollo se centraba en la escritura de programas querealizaran algn tipo de calculo. El primero de ellos es la aparicin del modelo relacional, un modelocon fuerte base matemtica que supuso el desarrollo las bases de datos y propici la aparicin de losgrandes sistemas de informacin. El segundo cambio es sobre los lenguajes de programacin, laaparicin de losLenguajes Orientados a Objetos (aunque los primero lenguajes con caractersticas deorientacin a objetos aparecieron en la dcada de los setenta, por ejemplo Simula 67) supuso unarevolucin en la industria software. El problema entonces radicaba en poder sacarle partido a loslenguajes orientados a objetos por lo que aparecieron numerosas metodologas para el diseoorientado objetos, hubo un momento en el que se poda decir que el concepto de orientacin a objetosestaba de moda y todo era orientado a objetos, cuando realmente lo que ocurra es que las grandesempresas que proporcionaban los compiladores y lenguajes de programacin lavaban la cara" a suscompiladores, sacaban nuevas versiones que adoptaran alguno de los conceptos de orientacin aobjetos y los vendan como orientados a objetos.

    Para poner un poco de orden, sobre todo en lo que respecta a la modelizacin de sistemas software,aparece UML (Unified Modeling Languaje, Lenguaje Unificado de Modelado) que pretende unificarlas tres metodologas ms difundidas (OMT, Bootch y OOSE) e intentar que la industria software

    termine su maduracin comoIngeniera. Y lo consigue en tal manera que lo que UML proporcionason las herramientas necesarias para poder obtener losplanos del softwareequivalentes a los que seutilizan en la construccin, la mecnica o la industria aeroespacial. UML abarca todas las fases del

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    10/117

    Diseo orientado a objetos con UML Grupo EIDOS

    10

    ciclo de vida de un proyecto, soporta diferentes maneras de visualizacin dependiendo de quin tengaque interpretar los planosy en que fase del proyecto se encuentre. Lo que describiremos en este cursoes una introduccin al diseo orientado a objetos y que solucin aporta UML, explicando suscaractersticas principales.

    Modelado

    Para producir software que cumpla su propsito hay que obtener los requisitos del sistema, esto seconsigue conociendo de una forma disciplinada a los usuarios y hacindolos participar de maneraactiva para que no queden cabos sueltos. Para conseguir un software de calidad, que sea duradero yfcil de mantener hay que idear una slida base arquitectnica que sea flexible al cambio. Paradesarrollar software rpida y eficientemente, minimizando el trabajo de recodificacin y evitando crearmiles de lneas de cdigo intil hay que disponer, adems de la gente y las herramientas necesarias, deun enfoque apropiado.

    Para conseguir, que a la hora de desarrollar software de manera industrial se obtenga un producto decalidad, es completamente necesario seguir ciertas pautas y no abordar los problemas de manerasomera, con el fin de obtener un modelo que represente lo suficientemente bien el problema quehemos de abordar. El modelado es la espina dorsal del desarrollo software de calidad. Se construyenmodelos para poder comunicarnos con otros, para explicar el comportamiento del sistema adesarrollar, para comprender, nosotros mismos, mejor ese sistema, para controlar el riesgo y endefinitiva para poder atacar problemas que sin el modelado su resolucin seria imposible, tanto desdeel punto de vista de los desarrolladores (no se pueden cumplir los plazos estimados, no se consigueajustar los presupuestos...) como desde el punto de vista del cliente, el cual, si finalmente se le entregael producto del desarrollo, se encontrar con infinidades de problemas, desde que no se cumplen lasespecificaciones hasta fallos que dejan inutilizado el sistema.

    Cuando nos referimos al desarrollo software en el mbito industrial, no se pretende que la capacidadde modelar se reduzca a empresas que disponen de gran numero de empleados o empresas que han deabordar proyectos eminentemente grandiosos, si no que nos referimos a la capacidad de obtener unproducto comercial (sea cual sea su coste o tamao) que cumpla lo que en la industria se sueledenominar como calidad total1 y que adems pueda reportar beneficios a corto o medio plazo,evitando, por ejemplo, implantaciones casi eternas debido a la falta de previsin o al haber abordadolos problemas muy a la ligera.

    Por todas estas razones es inevitable el uso de modelos. Pero, qu es un modelo?. La respuesta esbien sencilla, un modelo es una simpl if icacin de la r ealidad. El modelo nos proporciona los planosde un sistema, desde los ms generales, que proporcionan una visin general del sistema, hasta los msdetallados. En un modelo se han de incluir los elementos que tengan ms relevancia y omitir los queno son interesantes para el nivel de abstraccin que se ha elegido. A travs del modelado conseguimoscuatro objetivos:

    Los modelos nos ayudan a visualizar cmo es o queremos que sea un sistema.

    Los modelos nos permiten especificar la estructura o el comportamiento de un sistema.

    Los modelos nos proporcionan plantillas que nos guan en la construccin de un sistema.

    1Calidad total se refiere a niveles de calidad tan altos en todas las fases de la vida de un proyecto (ya sea mecnico,industrial, civil...) que no haya que estar modificando en las fases siguientes debido a errores que se deban haberdetectado previamente.

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    11/117

    Grupo EIDOS 1. Introduccin al modelado orientado a objetos

    11

    Los modelos documentan las decisiones que hemos adoptado.

    En la realidad, no siempre se hace un modelado formal, la probabilidad de que exista un modeladoformal para abordar un sistema es inversamente proporcional a la complejidad del mismo, esto es,cuanto ms fcil sea un problema, menos tiempo se pasa modelndolo y esto es porque cuando hay de

    aportar una solucin a un problema complejo el uso del modelado nos ayuda a comprenderlo, mientrasque cuando tenemos un problema fcil el uso del modelado que hacemos se reduce a representarmentalmente el problema o, como mucho, a escribir unos cuantos garabatos sobre un papel.

    Principios bsicos del modelado

    Existen cuatro principios bsicos, estos principios son fruto de la experiencia en todas las ramas de laingeniera.

    a) La eleccin de qu modelos se creen influye directamente sobre cmo se acomete el

    problema. Hay que seleccionar el modelo adecuado para cada momento y dependiendo de quemodelo se elija se obtendrn diferentes beneficios y diferentes costes. En la industria softwarese ha comprobado que un modelado orientado a objetos proporciona unas arquitecturas msflexibles y readaptables que otros por ejemplo orientados a la funcionalidad o a los datos.

    b) Todo modelo puede ser expresado a diferentes niveles de precisin. Esto es, es necesariopoder seleccionar el nivel de detalle que se desea ya que en diferentes partes de un proyecto yen diferentes etapas se tendrn unas determinadas necesidades.

    c) Los mejores modelos estn ligados a la realidad. Lo principal es tener modelos que nospermitan representar la realidad lo ms claramente posible, pero no slo esto, tenemos quesaber, exactamente cuando se apartan de la realidad para no caer en la ocultacin de ningn

    detalle importante.

    d) Un nico modelo no es suficiente. Cualquier sistema que no sea trivial se afronta mejor desdepequeos modelos casi independientes, que los podamos construir y estudiarindependientemente y que nos representen las partes ms diferenciadas del sistema y susinterrelaciones.

    Orientacin a Objetos

    La programacin estructurada tradicional se basa fundamentalmente en la ecuacin de Wirth:

    Algoritmos + Estructuras de Datos = Programas

    Esta ecuacin significa que en la programacin estructurada u orientada a procedimientos los datos yel cdigo se trata por separado y lo nico se realiza son funciones o procedimientos que tratan esosdatos y los van pasando de unos a otros hasta que se obtiene el resultado que se desea.

    LaProgramacinOrientada a Objetos,POO(OOP, Object Oriented Programming, en ingles), es unatcnica de programacin cuyo soporte fundamental es el objeto. Un objeto es una extensin de un Tipo

    Abstracto de Datos (TAD), concepto ampliamente utilizado desde la dcada de los setenta. Un TAD esun tipo definido por el usuario, que encapsula un conjunto de datos y las operaciones sobre estosdatos.

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    12/117

    Diseo orientado a objetos con UML Grupo EIDOS

    12

    A la hora de definir TADs (u objetos) se usa un concepto que nos ayuda a representar la realidadmediante modelos informticos, laabstraccin, que es un proceso mental por el que se evitan losdetalles para centrarse en las cosas ms genricas de manera que se facilite su comprensin. De hechola abstraccin no slo se utiliza en la informtica, un arquitecto al que le han encargado realizar losplanos de un edificio no comenzar por disear los planos con mximo nivel de detalle, sino que

    comenzar a realzar ciertos esbozos en un papel para posteriormente ir refinando. Por supuesto quecuando est realizando los esbozos no se preocupa de por dnde van a ir las lneas elctricas ni lastuberas de saneamiento, abstrae esos detalles para atacarlos posteriormente cuando tenga clara laestructura del edificio.

    La diferencia entre el concepto de TAD y el de objetoradica en que adems del proceso de abstraccinque se utiliza para su definicin, existen otros dos con los que se forma el ncleo principal de laprogramacin orientada a objetos, estos son la herencia y elpolimorfismo.

    Ventajas de la orientacin a objetos

    Las ventajas ms importantes de la programacin orientada a objetos son las siguientes:

    Mantenibilidad (facilidad de mantenimiento). Los programas que se disean utilizando elconcepto de orientacin a objetos son ms fciles de leer y comprender y el control de lacomplejidad del programa se consigue gracias a la ocultacin de la informacin que permitedejar visibles slo los detalles ms relevantes.

    Modificabilidad (facilidad para modificar los programas). Se pueden realizar aadidos osupresiones a programas simplemente aadiendo, suprimiendo o modificando objetos.

    Resusabilidad. Los objetos, si han sido correctamente diseados, se pueden usar numerosas

    veces y en distintos proyectos.

    Fiabilidad. Los programas orientados a objetos suelen ser ms fiables ya que se basan en eluso de objetos ya definidos que estn ampliamente testados.

    Estas ventajas son directas a los programadores. Estos, se podra decir, que son los ejecutores de undeterminado proyecto software. Pero la orientacin a objetos no slo reporta beneficios a losprogramadores. En las etapas de anlisis, previas a la codificacin, el utilizar un modelado orientado aobjetos reporta grandes beneficios ya estas mismas ventajas son aplicables a todas las fases del ciclode vida de un proyecto software.

    La tendencia actual es a tratar temas conceptuales de primer plano (o sea, en las fases de anlisis) y notemas finales de implementacin. Los fallos durante la etapa de implementacin son ms difciles decorregir y ms costosos que si se dan en las etapas previas. El modelado orientado a objetos tiende alrefinamiento sucesivo de manera que se llega a la etapa de implementacin con un diseo losuficientemente explicito para que no existan casos inesperados y todo independientemente dellenguaje de programacin (salvo en etapas muy prximas a la implementacin donde no hay msremedio que contar con el soporte que se recibe del lenguaje elegido). El desarrollo orientado a objetoses ms una manera de pensar y no una tcnica de programacin.

    Conceptos bsicos de la orientacin a objeto

    Como ya hemos dicho la orientacin a objetos se basa en conceptos como clase, objeto, herencia ypolimorfismo, pero tambin en otros muchos. En esta seccin se intenta, sin entrar en detalles, realizar

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    13/117

    Grupo EIDOS 1. Introduccin al modelado orientado a objetos

    13

    una breve descripcin de los conceptos ms importantes que existen en el modelado orientado aobjetos. Estos conceptos sern explicados y ampliados posteriormente desde la perspectiva de UML.

    Clase:Es una descripcin de un conjunto de objetos similares. Por ejemplo la clase Coches.Una clase contiene los atributos y las operaciones sobre esos atributos que hacen que una

    clase tenga la entidad que se desea.

    Objeto: Un objeto es una cosa, generalmente extrada del vocabulario del espacio delproblema o del espacio de la solucin. Todo objeto tiene un nombre (se le puede identificar),un estado (generalmente hay algunos datos asociados a l) y un comportamiento (se le puedenhacer cosas a objeto y l puede hacer cosas a otros objetos). Un objeto de la clase Cochespuede ser unFord Mustang.

    Atributo: Es una caracterstica concreta de una clase. Por ejemplo atributos de la claseCochespueden ser el Color, elNumero de Puertas...

    Mtodo: Es una operacin concreta de una determinada clase. Por ejemplo de la clase

    Cochespodramos tener un mtodo arrancar()que lo que hace es poner en marcha el coche.

    Instancia: Es una manifestacin concreta de una clase (un objeto con valores concretos).Tambin se le suele llamar ocurrencia. Por ejemplo una instancia de la clase Cochespuedeser: Un Ford Mustang, de color Gris con 3 puertas

    Herencia:Es un mecanismo mediante el cual se puede crear una nueva clase partiendo deuna existente, se dice entonces que la nueva clase hereda las caractersticas de la caseexistentes aunque se le puede aadir ms capacidades (aadiendo datos o capacidades) omodificar las que tiene. Por ejemplo supongamos que tenemos la VehiculosDeMotor. En estaclase tenemos los siguientes atributos: Cilindrada y Numero de Ruedas, y el mtodoacelerar(). Mediante el mecanismo de herencia podemos definir la clase Coches y la clase

    Motos. Estas dos clases heredan los atributos Cilindrada y Numero de Ruedas de la claseVehculosDeMotor pero a su vez tendrn atributos propios (como hemos dicho antes el

    Numero de Puertas es un atributo propio de la clase Cochesque no tienen sentido en la claseMotos). Se puede decir que Coches extiende la clase VehculosDeMotor, o queVehculosDeMotores una generalizacinde las clases Coches yMotos.

    Figura 1. Ejemplo de Herencia

    VehiculosDeMotor

    CilindradaNumero de Ruedas

    acelerar()

    Coches

    Cilindrada

    Numero de Ruedas

    Numero de Puertas

    acelerar()

    Motos

    Cilindrada

    Numero de Ruedas

    Ti oCarenado

    acelerar()

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    14/117

    Diseo orientado a objetos con UML Grupo EIDOS

    14

    Polimorfismo:Hace referencia a la posibilidad de que dos mtodos implementen distintasacciones, aun teniendo el mismo nombre, dependiendo del objeto que lo ejecuta o de losparmetros que recibe. En el ejemplo anterior tenamos dos objetos que heredaban elmtodo acelerar()de la clase VehiculosDeMotor. De hecho en clase VehiculosDeMotoralser general no tiene sentido que tenga una implementacin concreta de este mtodo. Sinembargo, en las clases Coches y Motos si que hay una implementacin clara y distinta delmtodo acelerar(), lo podemos ver en el cdigo fuente 1 y 2. De este modo podramostener un objeto VehculosDeMotor, llamado vdm,en el que residiera un objeto Coche. Sirealizramos la llamada vdm.acelerar()sabra exactamente que ha de ejecutar el mtodoCoches::acelerar().

    Coches::acelerar(){

    Pisar ms el pedal derecho

    }

    Cdigo fuente 1. Posible implementacin para coches

    Motos::acelerar(){

    Girar ms el puo derecho

    }

    Cdigo fuente 2. Implementacin para motos

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    15/117

    Introduccin al lenguaje unificado demodelado, UML

    UML es un lenguaje estndar que sirve para escribir los planos del software, puede utilizarse paravisualizar, especificar, construir y documentar todos los artefactos que componen un sistema con grancantidad de software. UML puede usarse para modelar desde sistemas de informacin hastaaplicaciones distribuidas basadas en Web, pasando por sistemas empotrados de tiempo real. UML essolamente un lenguaje por lo que es slo una parte de un mtodo de desarrollo software, esindependiente del proceso aunque para que sea optimo debe usarse en un proceso dirigido por casos deuso, centrado en la arquitectura, iterativo e incremental.

    UML es un lenguaje por que proporciona un vocabulario y las reglas para utilizarlo, adems es unlenguaje de modelado lo que significa que el vocabulario y las reglas se utilizan para la representacinconceptual y fsica del sistema.

    UML es un lenguaje que nos ayuda a interpretar grandes sistemas mediante grficos o mediante textoobteniendo modelos explcitos que ayudan a la comunicacin durante el desarrollo ya que al serestndar, los modelos podrn ser interpretados por personas que no participaron en su diseo (eincluso por herramientas) sin ninguna ambigedad. En este contexto, UML sirve para especificar,modelos concretos, no ambiguos y completos.

    Debido a su estandarizacin y su definicin completa no ambigua, y aunque no sea un lenguaje deprogramacin, UML se puede conectar de manera directa a lenguajes de programacin como Java,C++ o Visual Basic, esta correspondencia permite lo que se denomina como ingeniera directa(obtener el cdigo fuente partiendo de los modelos) pero adems es posible reconstruir un modelo enUML partiendo de la implementacin, o sea, la ingeniera inversa.

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    16/117

    Diseo orientado a objetos con UML Grupo EIDOS

    16

    Vista general de UML

    Estructurales Comportamiento Agrupacin Anotacin

    Elementos

    Dependencia Asociacin Generalizacin Realizacin

    Relaciones

    Clases Objetos Casos de Uso Secuencia Colaboracin Estados Componentes Despliegue

    Diagramas

    Bloques de Construccin

    Nombres Alcance Visibilidad Integr idad

    Reglas

    Especificaciones Adornos Divisiones Comunes Extensibilidad

    Mecanismos

    Afectan

    Afectan

    Actan

    Colaboran

    UML proporciona la capacidad de modelar actividades de planificacin de proyectos y de susversiones, expresar requisitos y las pruebas sobre el sistema, representar todos sus detalles as como lapropia arquitectura. Mediante estas capacidades se obtiene una documentacin que es valida durantetodo el ciclo de vida de un proyecto.

    Vista general de UML

    Para conocer la estructura de UML, en la figura 3 vemos una vista general de todos sus componentes,esto har que nos resulte ms fcil la comprensin de cada uno de ellos.

    El lenguaje UML se compone de tres elementos bsicos, los bloques de construccin, las reglas yalgunos mecanismos comunes. Estos elementos interaccionan entre s para dar a UML el carcter decompletitud y no-ambigedad que antes comentbamos.

    Los bloques de construccin se dividen en tres partes: Elementos, que son las abstracciones de

    primer nivel, Relaciones, que unen a los elementos entre s, y los Diagramas, que son agrupacionesinteresantes de elementos.

    Existen cuatro tipos de elementos en UML, dependiendo del uso que se haga de ellos: elementosestructurales, elementos de comportamiento, elementos de agrupacin y elementos de anotacin.

    Las relaciones, a su vez se dividen para abarcar las posibles interacciones entre elementos que se nospueden presentar a la hora de modelar usando UML, estas son: relaciones de dependencia, relacionesde asociacin, relaciones de generalizacin y relaciones de realizacin.

    Se utilizan diferentes diagramas dependiendo de qu, nos interese representar en cada momento, paradar diferentes perspectivas de un mismo problema, para ajustar el nivel de detalle..., por esta razn

    UML soporta un gran numero de diagramas diferentes aunque, en la practica, slo se utilicen unpequeo nmero de combinaciones.

    Figura 2. Vista general de los elementos de UML

    UML proporciona un conjunto de reglas que dictan las pautas a la hora de realizar asociaciones entreobjetos para poder obtener modelos bien formados, estas son reglas semnticas que afectan a los

    nombres, al alcance de dichos nombres, a la visibilidadde estos nombres por otros, a la integridadde unos elementos con otros y a la ejecucin, o sea la vista dinmica del sistema.

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    17/117

    Grupo EIDOS 2. Introduccin al lenguaje unificado de modelado, UML

    17

    UML proporciona una serie de mecanismos comunes que sirven para que cada persona o entidadadapte el lenguaje a sus necesidades, pero dentro de un marco ordenado y siguiendo unas ciertas reglaspara que en el trasfondo de la adaptacin no se pierda la semntica propia de UML. Dentro de estosmecanismos estn las especificaciones, que proporcionan la explicacin textual de la sintaxis ysemntica de los bloques de construccin. Otro mecanismo es el de los adornos que sirven paraconferir a los modelos de ms semntica, los adornos son elementos secundarios ya que proporcionanms nivel de detalle, que quiz en un primer momento no sea conveniente descubrir. Las divisionescomunespermiten que los modelos se dividan al menos en un par de formas diferentes para facilitar lacomprensin desde distintos puntos de vista, en primer lugar tenemos la divisin entre clase y objeto(clase es una abstraccin y objeto es una manifestacin de esa abstraccin), en segundo lugar tenemosla divisin interfaz / implementacin donde la interfaz presenta un contrato (algo que se va a cumplirde una determinada manera) mientras que la implementacin es la manera en que se cumple dichocontrato. Por ultimo, los mecanismos de extensibilidad que UML proporciona sirven para evitarposibles problemas que puedan surgir debido a la necesidad de poder representar ciertos matices, poresta razn UML incluye los estereotipos, para poder extender el vocabulario con nuevos bloques deconstruccin, los valores etiquetados, para extender las propiedades un bloque, y las restricciones,

    para extender la semntica.De esta manera UML es un lenguaje estndar abierto-cerradosiendo posible extender el lenguajede manera controlada.

    Bloques de construccin de UML

    A continuacin se van a describir todos los elementos que componen los bloques estructurales deUML, as como su notacin, para que nos sirva de introduccin y se vaya generando un esquemaconceptual sobre UML. En temas sucesivos se tratar con ms profundidad cada uno de los bloques.

    Elementos Estructurales

    Los elementos estructurales en UML, es su mayora, son las partes estticas del modelo y representancosas que son conceptuales o materiales.

    Clases

    Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos,operaciones, relaciones y semntica. Una clase implementa una o ms interfaces. Grficamente serepresenta como un rectngulo que incluye su nombre, sus atributos y sus operaciones (figura 3).

    Figura 3. Clases

    Ventana

    origen

    tamao

    abrir()

    cerrar()

    mover()

    dibujar()

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    18/117

    Diseo orientado a objetos con UML Grupo EIDOS

    18

    Interfaz

    Una interfaz es una coleccin de operaciones que especifican un servicio de una determinada clase ocomponente. Una interfaz describe el comportamiento visible externamente de ese elemento, puedemostrar el comportamiento completo o slo una parte del mismo. Una interfaz describe un conjunto deespecificaciones de operaciones (o sea su signatura) pero nunca su implementacin. Se representa conun circulo, como podemos ver en la figura 4, y rara vez se encuentra aislada sino que ms bienconectada a la clase o componente que realiza.

    Figura 4. Interfaz

    ColaboracinDefine una interaccin y es una sociedad de roles y otros elementos que colaboran para proporcionarun comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Lascolaboraciones tienen una dimensin tanto estructural como de comportamiento. Una misma clasepuede participar en diferentes colaboraciones. Las colaboraciones representan la implementacin depatrones que forman un sistema. Se representa mediante una elipse con borde discontinuo, como en lafigura 5.

    Figura 5. Colaboracin

    Casos de Uso

    Un caso de uso es la descripcin de un conjunto de acciones que un sistema ejecuta y que produce undeterminado resultado que es de inters para un actor particular. Un caso de uso se utiliza paraorganizar los aspectos del comportamiento en un modelo. Un caso de uso es realizado por una

    colaboracin. Se representa como en la figura 6, una elipse con borde continuo.

    Figura 6. Casos de Uso

    IOrtografa

    Cadena de

    responsabilidad

    Realizar

    Pedido

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    19/117

    Grupo EIDOS 2. Introduccin al lenguaje unificado de modelado, UML

    19

    Clase Activa

    Es una clase cuyos objetos tienen uno o ms procesos o hilos de ejecucin por lo y tanto pueden darlugar a actividades de control. Una clase activa es igual que una clase, excepto que sus objetosrepresentan elementos cuyo comportamiento es concurrente con otros elementos. Se representa igualque una clase (figura 3), pero con lneas ms gruesas (figura 7).

    Figura 7. Clases Activas

    Componentes

    Un componente es una parte fsica y reemplazable de un sistema que conforma con un conjunto deinterfaces y proporciona la implementacin de dicho conjunto. Un componente representa tpicamenteel empaquetamiento fsico de diferentes elementos lgicos, como clases, interfaces y colaboraciones.

    Figura 8. Componentes

    Nodos

    Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recursocomputacional que, por lo general, dispone de algo de memoria y, con frecuencia, de capacidad deprocesamiento. Un conjunto de componentes puede residir en un nodo.

    Figura 9. Nodos

    Estos siete elementos vistos son los elementos estructurales bsico que se pueden incluir en un modeloUML. Existen variaciones sobre estos elementos bsicos, tales como actores, seales, utilidades (tipos

    de clases), procesos e hilos (tipos de clases activas) y aplicaciones, documentos, archivos, bibliotecas,pginas y tablas (tipos de componentes).

    Gestor de Eventos

    suspender()vaciarCola()

    orderform.java

    Servidor

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    20/117

    Diseo orientado a objetos con UML Grupo EIDOS

    20

    Elementos de comportamiento

    Los elementos de comportamiento son las partes dinmicas de un modelo. Se podra decir que son losverbos de un modelo y representan el comportamiento en el tiempo y en el espacio. Los principales

    elementos son los dos que siguen.

    Interaccin

    Es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto deobjetos, dentro de un contexto particular para conseguir un propsito especfico. Una interaccininvolucra otros muchos elementos, incluyendo mensajes, secuencias de accin (comportamientoinvocado por un objeto) y enlaces (conexiones entre objetos). La representacin de un mensaje es unaflecha dirigida que normalmente con el nombre de la operacin.

    Figura 10. Mensajes

    Maquinas de estados

    Es un comportamiento que especifica las secuencias de estados por las que van pasando los objetos olas interacciones durante su vida en respuesta a eventos, junto con las respuestas a esos eventos. Unamaquina de estados involucra otros elementos como son estados, transiciones (flujo de un estado a

    otro), eventos (que disparan una transicin) y actividades (respuesta de una transicin)

    Figura 11. Estados

    Elementos de agrupacin

    Forman la parte organizativa de los modelos UML. El principal elemento de agrupacin es el paquete,que es un mecanismo de propsito general para organizar elementos en grupos. Los elementosestructurales, los elementos de comportamiento, incluso los propios elementos de agrupacin sepueden incluir en un paquete.

    Un paquete es puramente conceptual (slo existe en tiempo de desarrollo). Grficamente se representacomo una carpeta conteniendo normalmente su nombre y, a veces, su contenido.

    dibujar

    Esperando

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    21/117

    Grupo EIDOS 2. Introduccin al lenguaje unificado de modelado, UML

    21

    Figura 12. Paquetes

    Elementos de anotacin

    Los elementos de anotacin son las partes explicativas de los modelos UML. Son comentarios que sepueden aplicar para describir, clasificar y hacer observaciones sobre cualquier elemento de un modelo.El tipo principal de anotacin es la nota que simplemente es un smbolo para mostrar restricciones ycomentarios junto a un elemento o un conjunto de elementos.

    Figura 13. Notas

    Relaciones

    Existen cuatro tipos de relaciones entre los elementos de un modelo UML.Dependencia, asociacin,generalizaciny realizacin, estas se describen a continuacin:

    Dependencia

    Es una relacin semntica entre dos elementos en la cual un cambio a un elemento (el elementoindependiente) puede afectar a la semntica del otro elemento (elemento dependiente). Se representacomo una lnea discontinua (figura 14), posiblemente dirigida, que a veces incluye una etiqueta.

    Figura 14. Dependencias

    Asociacin

    Es una relacin estructural que describe un conjunto de enlaces, los cuales son conexiones entreobjetos. La agregacin es un tipo especial de asociacin y representa una relacin estructural entre untodo y sus partes. La asociacin se representa con una lnea continua, posiblemente dirigida, que aveces incluye una etiqueta. A menudo se incluyen otros adornos para indicar la multiplicidad y rolesde los objetos involucrados, como podemos ver en la figura 15.

    Reglas del

    negocio

    Obtiene una

    copia del objeto

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    22/117

    Diseo orientado a objetos con UML Grupo EIDOS

    22

    Figura 15. Asociaciones

    Generalizacin

    Es una relacin de especializacin / generalizacin en la cual los objetos del elemento especializado(el hijo) pueden sustituir a los objetos del elemento general (el padre). De esta forma, el hijo compartela estructura y el comportamiento del padre. Grficamente, la generalizacin se representa con unalnea con punta de flecha vaca (figura 16).

    Figura 16. Generalizacin

    Realizacin

    Es una relacin semntica entre clasificadores, donde un clasificador especifica un contrato que otroclasificador garantiza que cumplir. Se pueden encontrar relaciones de realizacin en dos sitios: entreinterfaces y las clases y componentes que las realizan, y entre los casos de uso y las colaboracionesque los realizan. La realizacin se representa como una mezcla entre la generalizacin (figura 16) y ladependencia (figura 14), esto es, una lnea discontinua con una punta de flecha vaca (figura 17).

    Figura 17. Realizacin.

    Diagramas

    Los diagramas se utilizan para representar diferentes perspectivas de un sistema de forma que un

    diagrama es una proyeccin del mismo. UML proporciona un amplio conjunto de diagramas quenormalmente se usan en pequeos subconjuntos para poder representar las cinco vistas principales dela arquitectura de un sistema.

    Diagramas de Clases

    Muestran un conjunto de clases, interfaces y colaboraciones, as como sus relaciones. Estos diagramasson los ms comunes en el modelado de sistemas orientados a objetos y cubren la vista de diseoesttica o la vista de procesos esttica (s incluyen clases activas).

    *

    empleadopatrn

    0..1

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    23/117

    Grupo EIDOS 2. Introduccin al lenguaje unificado de modelado, UML

    23

    Diagramas de Objetos

    Muestran un conjunto de objetos y sus relaciones, son como fotos instantneas de los diagramas declases y cubren la vista de diseo esttica o la vista de procesos esttica desde la perspectiva de casosreales o prototpicos.

    Diagramas de Casos de Usos

    Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus relaciones. Cubren lavista esttica de los casos de uso y son especialmente importantes para el modelado y organizacin delcomportamiento.

    Diagramas de Secuencia y de Colaboracin

    Tanto los diagramas de secuencia como los diagramas de colaboracin son un tipo de diagramas deinteraccin. Constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que sepueden enviar unos objetos a otros. Cubren la vista dinmica del sistema. Los diagramas de secuenciaenfatizan el ordenamiento temporal de los mensajes mientras que los diagramas de colaboracinmuestran la organizacin estructural de los objetos que envan y reciben mensajes. Los diagramas desecuencia se pueden convertir en diagramas de colaboracin sin perdida de informacin, lo mismoocurren en sentido opuesto.

    Diagramas de Estados

    Muestran una maquina de estados compuesta por estados, transiciones, eventos y actividades. Estosdiagramas cubren la vista dinmica de un sistema y son muy importantes a la hora de modelar elcomportamiento de una interfaz, clase o colaboracin.

    Diagramas de Actividades

    Son un tipo especial de diagramas de estados que se centra en mostrar el flujo de actividades dentro deun sistema. Los diagramas de actividades cubren la parte dinmica de un sistema y se utilizan paramodelar el funcionamiento de un sistema resaltando el flujo de control entre objetos.

    Diagramas de ComponentesMuestra la organizacin y las dependencias entre un conjunto de componentes. Cubren la vista de laimplementacin esttica y se relacionan con los diagramas de clases ya que en un componente sueletener una o ms clases, interfaces o colaboraciones

    Diagramas de Despliegue

    Representan la configuracin de los nodos de procesamiento en tiempo de ejecucin y loscomponentes que residen en ellos. Muestran la vista de despliegue esttica de una arquitectura y serelacionan con los componentes ya que, por lo comn, los nodos contienen uno o ms componentes.

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    24/117

    Diseo orientado a objetos con UML Grupo EIDOS

    24

    Arquitectura

    El desarrollo de un sistema con gran cantidad de software requiere que este sea visto desde diferentesperspectivas. Diferentes usuarios (usuario final, analistas, desarrolladores, integradores, jefes de

    proyecto...) siguen diferentes actividades en diferentes momentos del ciclo de vida del proyecto, lo queda lugar a las diferentes vistas del proyecto, dependiendo de qu interese ms en cada instante detiempo.

    La arquitectura es el conjunto de decisiones significativas sobre:

    La organizacin del sistema

    Seleccin de elementos estructurales y sus interfaces a travs de los cuales se constituye elsistema.

    El Comportamiento, como se especifica las colaboraciones entre esos componentes.

    Composicin de los elementos estructurales y de comportamiento en subsistemasprogresivamente ms grandes.

    El estilo arquitectnico que gua esta organizacin: elementos estticos y dinmicos y susinterfaces, sus colaboraciones y su composicin.

    Figura 18. Modelado de la arquitectura de un sistema

    La una arquitectura que no debe centrarse nicamente en la estructura y en el comportamiento, sinoque abarque temas como el uso, funcionalidad, rendimiento, capacidad de adaptacin, reutilizacin,capacidad para ser comprendida, restricciones, compromisos entre alternativas, as como aspectosestticos. Para ello se sugiere una arquitectura que permita describir mejor los sistemas desdediferentes vistas, figura 18, donde cada una de ellas es una proyeccin de la organizacin y laestructura centrada en un aspecto particular del sistema.

    La vista de casos de uso comprende la descripcin del comportamiento del sistema tal y como espercibido por los usuarios finales, analistas y encargados de las pruebas y se utilizan los diagramas decasos de uso para capturar los aspectos estticos mientras que los dinmicos son representados por

    diagramas de interaccin, estados y actividades.

    Vista de

    Diseo

    Vista de

    implementacin

    Vista de

    procesos

    Vista de

    despliegue

    Vista de los

    casos de Uso

    vocabulario,funcionalidadd

    comportamiento

    Funcionamiento,capacidad de

    crecimiento, rendimiento

    Ensamblado del sistema,

    gestin de las

    configuraciones

    Topologa delsistema,distribucin, entreinstalacin

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    25/117

    Grupo EIDOS 2. Introduccin al lenguaje unificado de modelado, UML

    25

    La vista de diseocomprende las clases, interfaces y colaboraciones que forman el vocabulario delproblema y de la solucin. Esta vista soporta principalmente los requisitos funcionales del sistema, osea, los servicios que el sistema debe proporcionar. Los aspectos estticos se representan mediantediagramas de clases y objetos y los aspectos dinmicos con diagramas de interaccin, estados yactividades.

    La vista de procesos comprende los hilos y procesos que forman mecanismos de sincronizacin yconcurrencia del sistema cubriendo el funcionamiento, capacidad de crecimiento y el rendimiento delsistema. Con UML, los aspectos estticos y dinmicos se representan igual que en la vista de diseo,pero con el nfasis que aportan las clases activas, las cuales representan los procesos y los hilos.

    La Vista de implementacincomprende los componentes y los archivos que un sistema utiliza paraensamblar y hacer disponible el sistema fsico. Se ocupa principalmente de la gestin deconfiguraciones de las distintas versiones del sistema. Los aspectos estticos se capturan con losdiagramas de componentes y los aspectos dinmicos con los diagramas de interaccin, estados yactividades.

    La vista de desplieguede un sistema contiene los nodos que forman la topologa hardware sobre la quese ejecuta el sistema. Se preocupa principalmente de la distribucin, entrega e instalacin de las partesque constituyen el sistema. Los aspectos estticos de esta vista se representan mediante los diagramasde despliegue y los aspectos dinmicos con diagramas de interaccin, estados y actividades.

    Ciclo de Vida

    Se entiende por ciclo de vida de un proyecto softwarea todas las etapas por las que pasa un proyecto,desde la concepcin de la idea que hace surgir la necesidad de disear un sistema software, pasandopor el anlisis, desarrollo, implantacin y mantenimiento del mismo y hasta que finalmente muere por

    ser sustituido por otro sistema.

    Aunque UML es bastante independiente del proceso, para obtener el mximo rendimiento de UML sedebera considerar un proceso que fuese:

    Dirigido por los casos de uso, o sea, que los casos de uso sean un artefacto bsico paraestablecer el comportamiento del deseado del sistema, para validar la arquitectura, para laspruebas y para la comunicacin entre las personas involucradas en el proyecto.

    Centrado en la arquitecturade modo que sea el artefacto bsico para conceptuar, construir,gestionar y hacer evolucionar el sistema.

    Un proceso iterativo, que es aquel que involucra la gestin del flujo de ejecutables delsistema, e incremental, que es aquel donde cada nueva versin corrige defectos de la anterior eincorpora nueva funcionalidad. Un proceso iterativo e incremental se denomina dirigido por elriesgo, lo que significa que cada nueva versin se ataca y reducen los riesgos mssignificativos para el xito del proyecto.

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    26/117

    Diseo orientado a objetos con UML Grupo EIDOS

    26

    Figura 19. Ciclo de vida del desarrollo software

    Este proceso, dirigido a los casos de uso, centrado en la arquitectura, iterativo e incremental pudedescomponerse en fases, donde cada fase es el intervalo de tiempo entre dos hitos importantes delproceso, cuando se cumplen los objetivos bien definidos, se completan los artefactos y se tomandecisiones sobre si pasar o no a la siguiente fase. En el ciclo de vida de un proyecto software existen

    cuatro fases, vanse en la figura 19. La iniciacin, que es cuando la idea inicial est lo suficientementefundada para poder garantizar la entrada en la fase de elaboracin, esta fase es cuando se produce ladefinicin de la arquitectura y la visin del producto. En esta fase se deben determinar los requisitosdel sistema y las pruebas sobre el mismo. Posteriormente se pasa a la fase de construccin, que escuando se pasa de la base arquitectnica ejecutable hasta su disponibilidad para los usuarios, en estafase se reexaminan los requisitos y las pruebas que ha de soportar. La transicin, cuarta fase delproceso, que es cuando el software se pone en mano de los usuarios.

    Raramente el proceso del software termina en la etapa de transicin, incluso durante esta fase elproyecto es continuamente reexaminado y mejorado erradicando errores y aadiendo nuevasfuncionalidades no contempladas.

    Un elemento que distingue a este proceso y afecta a las cuatro fases es una iteracin, que es unconjunto de bien definido de actividades, con un plan y unos criterios de evaluacin, que acaban enuna versin del producto, bien interna o externa.

    Iniciacin Elaboracin Construccin Transicin

    Modelado del negocio

    Requisitos

    Anlisis y Diseo

    Implementacin

    Pruebas

    Despliegue

    Gestin del Cambio yConfiguraciones

    Gestin del proyecto

    EntornoIteraciones

    preliminaresIter #1 Iter #2 Iter #n Iter

    n+1Itern+2

    Iter#m

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    27/117

    Modelado Estructural

    A la hora de modelar un sistema es necesario identificar las cosas ms importantes eligiendo un nivelde abstraccin capaz de identificar todas las partes relevantes del sistema y sus interacciones. En esteprimer acercamiento no debemos contar con los detalles particulares de las cosas que hemosidentificado como importantes, estos detalles atacarn posteriormente en cada una de las parteselegidas.

    Por ejemplo, si estuvisemos trabajando en una tienda que vende ordenadores como proveedor final ynuestro jefe nos pidiera que montramos un ordenado, directamente la divisin que tendramos es lasiguiente: necesitamos un monitor, un teclado, un ratn y una CPU, sin importarnos (inicialmente,claro) que la CPU este compuesta por varios elementos ms. Una vez que tenemos claro que partesforman un ordenador nos daramos cuenta que tanto el teclado como el ratn y el monitor son partems o menos atmicas ya que, aunque estos tres objetos estn compuestos por un montn de

    componentes electrnicos, la composicin de estos no nos interesa para al nivel de abstraccin queestamos trabajando (el de proveedor final). Al darnos cuenta de esto prepararamos el monitor, elteclado y el ratn, pero en nuestro almacn tenemos monitores de 15 y 17 pulgadas, tecladosergonmicos y estndares y ratones de diferentes tamaos, colores, etc. Una vez que hemosdeterminado las propiedades de cada uno de ellos pasaramos a preocuparnos por la CPU, ahora escuando veramos que para montar la CPU nos hacen falta una placa base, un microprocesador, unadisquetera, un disco duro y un CD-ROM, cada uno de estos elementos con sus propiedades, disqueterade 1,44Mb, disco duro de 4Gb, microprocesador a 500Mhz y un CD-ROM 32x.

    Una vez que tenemos todo el material en el banco de trabajo tendramos que montar el ordenadorsabiendo que cada una de las partes interacta con el resto de alguna manera, en la CPU la disquetera,el CD-ROM y el disco duro van conectados al bus de datos, este adems est conectado a la placa base

    y el micro tiene un lugar bien definido tambin en la placa base, despus conectaramos el teclado, elmonitor y el ratn a la CPU y ya esta!, nuestro ordenador est montado.

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    28/117

    Diseo orientado a objetos con UML Grupo EIDOS

    28

    El modelado estructural es la parte de UML que se ocupa de identificar todas las partes importantesdeun sistema as como sus interacciones. Para modelar las partes importantes del vocabulario del sistemase utilizan las clases, que nos permiten: identificacin y representacin de sus propiedades y susoperaciones mediante el mecanismo de abstraccin. Las relacionesse utilizan para poder modelar lasinteracciones entre las clases.

    Representacin de las Clases en UML

    Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos,operaciones, relaciones y semntica. Hay que hacer una especial diferenciacin para no confundir elconcepto de clase con el de objeto. Un objeto es una instancia individual de una clase, as podramostener una clase que fuera los monitoresy un objeto de la clase monitores que fuera un monitor marcaA de 17 pulgadas, con la pantalla plana. En UML se usan un rectngulo para representar las clases,con distintos compartimentos para indicar sus atributos y sus operaciones.

    Una clase es identifica por un nombre que la distingue del resto, el nombre es una cadena de texto. Esenombre slo se denomina nombre simple; un nombre de camino consta del nombre de la claseprecedido del nombre del paquete en el que se encuentra incluida. En las figuras 20 y 21 podemos verla estructura de una clase y distintos nombres de camino y nombres simples.

    Un atributo es una propiedad de una clase identificada con unnombre. Describe un rango de valores que pueden tomar lasinstancias de la propiedad. Los atributos representan propiedadescomunes a todos los objetos de una determinada clase, por ejemplotodos los monitores tienen la propiedad dimensin, que se suelemedir en pulgadas. Un cliente tiene las propiedades nombre,apellidos, direccin, telfono... Los atributos son propiedadesinteresantes de las clases. Una instancia de una determinada clasetendr valores concretos para sus atributos, mientras que las clasestienen rangos de valores que pueden admitir sus atributos.

    El nombre de los atributos es un texto que normalmente se escribeen minsculas si slo es una palabra o la primera palabra delnombre del atributo en minsculas y el resto de las palabras con laprimera letra en maysculas, por ejemplo, nombrePropietario.

    Una operacin es una implementacin de un servicio que puede ser

    requerido a cualquier objeto de la clase para que muestre sucomportamiento. Una operacin representa algo que el objeto puedehacer. Por ejemplo, un comportamiento esperado por cualquier usuario de un monitor es que este sepueda encender y apagar. El nombre de las operaciones sigue las mismas reglas de notacin que losatributos pero suelen ser verbos cortos que indican una accin o comportamiento de la clase.

    Como norma general, cuando se dibuja una clase no hay que mostrar todos sus atributos ni todas susoperaciones, slo se deben mostrar los subconjuntos de estos ms relevantes y una buena prctica esutilizar estereotipos2para organizar los atributos y las operaciones.

    2

    Estereotipos son bloques bsicos de construccin a los que se les ha aadido etiquetas, iconos o texto explicativo para proporcionar ms semntica a

    estos bloques, consiguiendo as unos diagramas ms explicativos. Por ejemplo, dentro del bloque de las clases, se estereotipa el espacio reservado para las

    operaciones para poder indicar de que tipo son. Existe una lista de los estereotipos estndar de UML en el apndice A.

    Monitor

    Marcamodelo

    encender()

    Nombre

    Atributos

    Operaciones

    Figura 20. Representacin de Clases

    Nombres sim les

    Cliente Figura

    Ordenadores::Monitor

    java::awt::Rectangle

    Nombres de camino

    Figura 21. Tipos de nombres

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    29/117

    Grupo EIDOS 3. Modelado Estructural

    29

    Para modelar el vocabulario del sistema hay que identificar aquellas cosas que utilizan los usuarios oprogramadores para describir el problema, para conseguir esto se sugiere un anlisis basado en casosde uso. Para cada clase hay que determinar un conjunto de responsabilidades y posteriormentedeterminar los atributos y las operaciones necesarias para llevar a cabo las responsabilidades de laclase.

    A veces, las cosas que tenemos que modelar no tienen equivalente software, como por ejemplo, genteque emite facturas o robots que empaquetan automticamente los pedidos, pueden formar parte delflujo de trabajo que se intenta modelar. Para modelar cosas que no son software hay que obtenerabstracciones para poder representar esas cosas como clases y si lo que se est modelando es algntipo de hardware que contiene software se tiene que considerar modelarlo como un tipo de Nodo, demanera que ms tarde se pueda completar su estructura.

    En ocasiones puede resultar necesario especificar ms aun sobre las caractersticas de las operacioneso atributos como por ejemplo, tipos de datos que utilizan, visibilidad, caractersticas concretas dellenguaje que utilizan, excepciones a que puede producir... UML proporciona una notacin concretapara estas caractersticas avanzadas pero se entrar en discusin sobre ellas ya que estn fuera de losobjetivos de esta introduccin al modelado orientado a objetos con UML.

    Responsabilidades

    Una responsabilidad es un contrato u obligacin de una clase, sea, el fin para el que es creada.Cuando creamos una clase se est expresando que todos los objetos de la clase tienen el mismo tipo deestado y el mismo tipo de comportamiento. Los atributos y las operaciones son caractersticas de laclase que le permiten llevar a cabo sus responsabilidades. Al iniciar el modelado de clases es unabuena practica por iniciar especificando las responsabilidades de cada clase. Una clase puede tenercualquier numero de responsabilidades pero en la prctica el numero se reduce a una o a unas pocas.Cuando se van refinando los modelos las responsabilidades se van convirtiendo en atributos yoperaciones, se puede decir que las responsabilidades de una clase estn en un nivel ms alto deabstraccin que los atributos y las operaciones. Para representar responsabilidades se utiliza un cuartocompartimiento en el bloque de construccin de la clase, en el cual se especifican mediante frasescortas de texto libre las responsabilidades que ha de cumplir la clase.

    AgenteFraudes

    nuevo()

    nuevo(p: Poltica)

    procesar(o: Pedido)

    ...

    Estereotipos

    Figura 22. Estereotipos para caractersticas de las clases

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    30/117

    Diseo orientado a objetos con UML Grupo EIDOS

    30

    A la hora de determinar las responsabilidades, y su distribucin, que tiene que cumplir un sistema ensu conjunto, hemos de identificar un grupo de clases que colaboren entre s para llevar a cabo algntipo de comportamiento. Hay que determinar un conjunto de responsabilidades para cada una de esasclases teniendo cuidado de no dar demasiadas responsabilidades a una sola clase ni obtener clases conmuy pocas responsabilidades. De esta manera, clases con muchas responsabilidades se dividen envarias abstracciones menores y las clases con responsabilidades triviales se introducen en otrasmayores

    Relaciones

    Como ya hemos comentado en otras ocasiones, las relaciones son la manera de representar lasinteracciones entre las clases. Siguiendo con el ejemplo del montaje del ordenador, cada piezainteracta con otra de una determinada manera y aunque por si solas no tienen sentido todas juntasforman un ordenador, esto es lo que se denomina una relacin de asociacin, pero adems hay unasque no pueden funcionar si no estn conectadas a otras como por ejemplo un teclado, el cual, sin estarconectado a una CPU es totalmente intil, adems si la CPU cambiase su conector de teclado este yano se podra conectar a no ser que cambiase el tambin, esto se puede representar mediante unarelacin de dependencia. Es ms, tenemos una disquetera de 1,44Mb, un disco duro, un CD-ROM.

    Para referirnos a todos estos tipos de discos podramos generalizar diciendo que tenemos una serie dediscos con ciertas propiedades comunes, como pueden ser la capacidad, la tasa de transferencia enlectura y escritura... esto es lo que se denomina una relacin de generalizacin. La construccin derelaciones no difiere mucho de la distribucin de responsabilidades entre las clases. Si se modela enexceso se obtendrn diagramas con un alto nivel de dificultad para poder leerlos debidoprincipalmente al lo que se forma con las relaciones, por el contrario, si se modela insuficientementese obtendrn diagramas carentes de semntica.

    Para poder representar con UML cmo se conectan las cosas entre s, ya sea lgica o fsicamente,utilizamos las relaciones. Existen tres tipos de relaciones muy importantes: dependencias,generalizaciones y asociaciones. Una relacin se define como una conexin entre elementos. Acontinuacin describimos los tres tipos ms importantes de relaciones:

    Relacin de Dependencia

    Es una relacin de uso entre dos elementos de manera que el un cambio en la especificacin delelemento independiente puede afectar al otro elemento implicado en la relacin. Determinamos elelemento dependiente aquel que necesita del otro elemento implicado en la relacin (el independiente)para poder cumplir sus responsabilidades. Por ejemplo supongamos que tenemos una clase querepresenta un aparato reproductor Vdeo, con sus funciones y sus propiedades. Bien, para utilizar elmtodo grabar()de la clase video, dependemos directamente de la clase Canal ya que grabaremos uncanal u otro dependiendo de cual tenga seleccionado aparato de vdeo. A su vez la clase Televisin

    tambin depende de la clase Canal para poder visualizar un determinado canal por la Televisin.

    Monitor

    Responsabilidades

    --Visualizar caracteres e

    Fi ura 23. Res onsabilidades

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    31/117

    Grupo EIDOS 3. Modelado Estructural

    31

    En la figura 24 podemos observar un ejemplo de relacin de dependencia. Si en algn momento laclase Canal cambiara (se modificara o aadiera nueva funcionalidad) las clases Video y Televisin(que dependen de ella) podran verse afectadas por el cambio y dejar de funcionar. Como podemosobservar en esta figura tanto al mtodo grabar() de la clase video, como al mtodo cambiar() de laclase Televisin se le ha aadido ms semntica representando el parmetro c de tipo Canal. Este es unmecanismo comn en UML de diseo avanzado de clases. Cuando queremos aportar ms informacinsobre una clase y sus mtodos existe una nomenclatura bien definida para determinar ms los atributosy mtodos de la clase indicando si son ocultos o pblicos, sus tipos de datos, parmetros que utilizan ylos tipos que retornan.

    Normalmente, mediante una dependencia simple sin adornos suele bastar para representar la mayorade las relaciones de uso que nos aparecen, sin embargo, existen casos avanzados en los que esconveniente dotar al diagrama de ms semntica, para estos casos UML proporciona estereotiposconcretos, estos se pueden consultar en el apndiceA.

    Relacin de Generalizacin

    Es una relacin entre un elemento general (llamado superclase o padre) y un caso ms especfico deese elemento (llamado subclase o hijo). La generalizacin a veces es llamada relacin es-un-tipo-de, sea, un elemento (por ejemplo, una clase Rectngulo) es-un-tipo-de un elemento ms general (porejemplo, la clase figura). La generalizacin implica que los objetos hijo se pueden utilizar en cualquierlugar donde aparece el padre, pero no a la inversa. La clase hijo siempre hereda todos los atributos y

    mtodos de sus clases padre y a menudo (no siempre) el hijo extiende los atributos y operaciones delpadre. Una operacin de un hijo puede tener la misma signatura que en el padre pero la operacinpuede ser redefinida por el hijo; esto es lo que se conoce como polimorfismo. La generalizacin serepresenta mediante una flecha dirigida con la punta hueca. Una clase puede tener ninguno, uno ovarios padres. Una clase sin padres y uno o ms hijos se denomina clase raz o clase base. Una clasesin hijos se denomina clase hoja. Una clase con un nico padre se dice que utiliza herencia simple yuna clase con varios padres se dice que utiliza herencia mltiple. UML utiliza las relaciones degeneralizacin para el modelado de clases e interfaces, pero tambin se utilizan para establecergeneralizaciones entre otros elementos como por ejemplo los paquetes.

    Figura 24. Ejemplo de Dependencias

    Video

    poner()

    pasar()

    rebobinar()

    parar()

    grabar(c:Canal)

    cabezales

    tipoReproduccin

    Televisin

    encender()

    apagar()

    cambiar(c:Canal)

    pulgadas

    numCanales

    Canal

    buscar()

    fijar()

    frecuencia

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    32/117

    Diseo orientado a objetos con UML Grupo EIDOS

    32

    Mediante las relaciones de generalizacin podemos ver que un Cuadrado es-un-tipo-de Rectnguloque a su vez es-un-tipo-de figura. Con esta relacin podemos representar la herencia, de este modo, laclase cuadrado, simplemente por herencia sabemos que tiene dos atributos, esquina(heredado de su

    padre Rectngulo) y origen(heredado del padre de Rectngulo, la clase figura, que se puede decir quees su abuelo). Lo mismo ocurre con las operaciones, la clase Cuadrado dispone de las operacionesmover(),cambiarTamao()y dibujar(), heredadas todas desde figura.

    Normalmente la herencia simple es suficiente para modelar los problemas a los que nos enfrentamospero en ciertas ocasiones conviene modelar mediante herencia mltiple aunque vistos en esta situacinse ha de ser extremadamente cuidadoso en no realizar herencia mltiple desde padres que solapen suestructura o comportamiento. La herencia mltiple se representa en UML simplemente haciendo llegarflechas (iguales que las de la generalizacin) de un determinado hijo a todos los padres de los quehereda. En el siguiente ejemplo podemos observar como se puede usar la herencia mltiple pararepresentar especializaciones cuyos padres son inherentemente disjuntos pero existen hijos conpropiedades de ambos. En el caso de los Vehculos, estos se pueden dividir dependiendo de por dondecirculen, as tendremos Vehculos areos, terrestres y acuticos. Esta divisin parece que nos cubrecompletamente todas las necesidades, y as es. Dentro de los vehculos terrestres tendremosespecializaciones como coches, motos, bicicletas, etc. Dentro de los acuticos tendremos, por ejemplo,barcos, submarinos, etc. Dentro de los areos tendremos por ejemplo, aviones, globos, zeppelines... Eneste momento tenemos una clasificacin bastante clara de los vehculos, pero que ocurre con losvehculos que pueden circular tanto por tierra como por agua, sea vehculos anfibios, como porejemplo un tanque de combate preparado para tal efecto, en este caso podemos pensar en utilizar unmecanismo de herencia mltiple para representar que dicho tanque rene capacidades, atributos yoperaciones tanto de vehculo terrestre como acutico.

    Figura 25. Ejemplo de Generalizacin

    Figura

    mover()cambiarTamao()dibujar()

    origen

    Rectngulo

    esquina:Punto

    Crculo

    Radio:Float

    Polgono

    dibujar()

    puntos:Lista

    Cuadrado

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    33/117

    Grupo EIDOS 3. Modelado Estructural

    33

    Figura 26. Ejemplo de Herencia Mltiple

    Relacin de Asociacin

    Una asociacin es una relacin estructural que especifica que los objetos de un elemento estnconectados con los objetos de otro. Dada una asociacin entre dos clases, se puede navegar desde unobjeto de una de ellas hasta uno de los objetos de la otra, y viceversa. Es posible que la asociacin sed de manera recursiva en un objeto, esto significa que dado un objeto de la clase se puede conectarcon otros objetos de la misma clase. Tambin es posible, aunque menos frecuente, que se conectenms de dos clases, estas se suelen llamar asociaciones n-arias. Las relaciones de asociaciones seutilizan cuando se quieren representar relaciones estructurales.

    A parte de la forma bsica de representar las asociaciones, mediante una lnea continua entre las clasesinvolucradas en la relacin, existen cuatro adornos que se aplican a las asociaciones para facilitar sucomprensin:

    Nombre: Se utiliza para describir la naturaleza de la relacin. Para que no existaambigedad en su significado se le puede dar una direccin al nombre por medio de unaflecha que apunte en la direccin que se pretende que el nombre sea ledo.

    Rol:Cuando una clase participa en una asociacin esta tiene un rol especifico que juegaen dicha asociacin. El rol es la cara que dicha clase presenta a la clase que se encuentraen el otro extremo. Las clases pueden jugar el mismo o diferentes roles en otrasasociaciones.

    Multiplicidad: En muchas situaciones del modelado es conveniente sealar cuantosobjetos se pueden conectar a travs de una instancia de la asociacin. Este cuantos sedenomina multiplicidad del rol en la asociacin y se expresa como un rango de valores oun valor explicito. Cuando se indica multiplicidad en un extremo de una asociacin se estindicando que, para cada objeto de la clase en el extremo opuesto debe haber tantosobjetos en este extremo. Se puede indicar una multiplicidad de exactamente uno (1), ceroo uno (0..1), muchos (0..*), uno o ms (1..*) e incluso un numero exacto (por ejemplo, 5).

    Agregacin:Una asociacin normal entre dos clases representa una relacin estructuralentre iguales, es decir, ambas clases estn conceptualmente al mismo nivel. A vecesinteresa representar relaciones del tipo todo / parte, en las cuales una cosa representa la

    cosa grande (el todo) que consta de elementos ms pequeos (las partes). Este tipo derelacin se denomina de agregacin la cual representa una relacin del tipo tiene-un.

    VehculoAcutico VehculoAreo

    Vehculo

    VehculoTerrestre

    VehculoAnfibioCoche Moto Barco AvinSubmarino

    Tanque

    Globo

  • 7/25/2019 eidos uml - diseno orientado a objetos con uml spanish.pdf

    34/11