AO DEL CENTENARIO DE MACHU PICCHU PARA EL MUNDO

UNIVERSIDAD NACIONAL DE PIURA

FACULTAD DE INGENIERA INDUSTRIAL
ESCUELA PROFESIONAL DE INGENIERA INFORMTICA

TEMA

Programacin Orientada a

Objetos y ciclo de vida (UML)

PROFESOR

Ing. Senz.

CURSO

Programacin II.

ALUMNO

- Cruz Ramrez Edgardo.

Piura Per

POO y Ciclo de Vida UML

Programacin II

INDICE GENERAL
Programacin Orientada a Objetos (POO). 4
1. Introduccin 4 2. Origen.. 5 3. Conceptos fundamentales.. 5-6 Clase ... 5-6 Herencia . 5-6 Objeto 6 Mtodo.. 6 Evento 6 Mensaje. 6 Propiedad o atributo. 6 Estado interno. 6 Componentes de un objeto.. 6 Identificacin de un objeto . 6

4. Caractersticas de la POO 6
Abstraccin . 6 Encapsulamiento 7 Modularidad 7 Principio de ocultacin .. 7 Polimorfismo 7 Herencia 7 Recoleccin de basura .7-8

5. Resumen. 8

6. Motivacin.. 8 7. Cmo se piensa en objetos. 8-9

8. Clases en POO ... 9 Propiedades en clases.. 9 Mtodos en las clases .. 9 Objetos en POO ... 9 Estados en objetos ... 9 Mensajes en objetos . 9-10 9. Otras cosas .. 10

Lenguaje para Modelamiento Unificado (UML). 11

1. Introduccin.......................................................................................................... 11

2. Qu es el Lenguaje para Modelamiento Unificado (UML)? .. 12 3. Vistas del UML .. 12-13

Vista de casos de uso... 13 Vista de diseo 13 Vista de procesos ...13 Vista de implementacin.. 13 Vista de implantacin 13 4. Definicin de modelo .. 13

5. Diagramas UML . 13-14 5.1 Diagramas estructurales 15

Edgardo Cruz Ramrez

UNP-FII-EII

2|Pgina

POO y Ciclo de Vida UML

Programacin II

Diagrama de clases..... 15 Diagrama de objetos. 15 Diagrama de componentes 15 Diagrama de implantacin 15

5.2 Diagramas de comportamiento . 15 Diagrama de casos de uso.. 15 Diagrama de secuencia 15 Diagrama de colaboracin 15 Diagrama de estado 15 Diagrama de actividad 15 6 UML y su relacin con los procesos de desarrollo de software15-16

7 El ciclo de vida16

Edgardo Cruz Ramrez

UNP-FII-EII

3|Pgina

POO y Ciclo de Vida UML

Programacin II

Programacin Orientada a Objetos (POO)

1. Introduccin
Los objetos son entidades que combinan estado (atributo), comportamiento (mtodo) e identidad:
El estado est compuesto de datos, ser uno o varios atributos a los que se habrn asignado

unos valores concretos (datos).

El comportamiento est definido por los procedimientos o mtodos con que puede operar

dicho objeto, es decir, qu operaciones se pueden realizar con l.

La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con otras

palabras, es su identificador (concepto anlogo al de identificador de una variable o una constante). Un objeto contiene toda la informacin que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interaccin llamados mtodos, que favorecen la comunicacin entre ellos. Esta comunicacin favorece a su vez el cambio de estado en los propios objetos. Esta caracterstica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado y el comportamiento. Los mtodos (comportamiento) y atributos (estado) estn estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de mtodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a alguno de ellos. Hacerlo podra producir el hbito errneo de crear clases contenedoras de informacin por un lado y clases con mtodos que manejen a las primeras por el otro. De esta manera se estara realizando una programacin estructurada camuflada en un lenguaje de programacin orientado a objetos. La POO difiere de la programacin estructurada tradicional, en la que los datos y los procedimientos estn separados y sin relacin, ya que lo nico que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programacin estructurada anima al programador a pensar sobre todo en trminos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programacin estructurada slo se escriben funciones que procesan datos. Los programadores que emplean POO, en cambio, primero definen objetos para luego enviarles mensajes solicitndoles que realicen sus mtodos por s mismos.

Edgardo Cruz Ramrez

UNP-FII-EII

4|Pgina

POO y Ciclo de Vida UML

Programacin II

2.

Origen
Los conceptos de la programacin orientada a objetos tienen origen en Simula 67, un lenguaje diseado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard del Centro de Cmputo Noruego en Oslo. En este centro, se trabajaba en simulaciones de naves, que fueron confundidas por la explosin combinatoria de cmo las diversas cualidades de diferentes naves podan afectar unas a las otras. La idea ocurri para agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamientos. Fueron refinados ms tarde en Smalltalk, que fue desarrollado en Simula en Xerox PARC (cuya primera versin fue escrita sobre Basic) pero diseado para ser un sistema completamente dinmico en el cual los objetos se podran crear y modificar "en marcha" (en tiempo de ejecucin) en lugar de tener un sistema basado en programas estticos. La programacin orientada a objetos tom posicin como el estilo de programacin dominante a mediados de los aos ochenta, en gran parte debido a la influencia de C++, una extensin del lenguaje de programacin C. Su dominacin fue consolidada gracias al auge de las Interfaces grficas de usuario, para las cuales la programacin orientada a objetos est particularmente bien adaptada. En este caso, se habla tambin de programacin dirigida por eventos. Las caractersticas de orientacin a objetos fueron agregadas a muchos lenguajes existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp, Pascal, entre otros. La adicin de estas caractersticas a los lenguajes que no fueron diseados inicialmente para ellas condujo a menudo a problemas de compatibilidad y en la capacidad de mantenimiento del cdigo. Los lenguajes orientados a objetos "puros", por su parte, carecan de las caractersticas de las cuales muchos programadores haban venido a depender. Para saltar este obstculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en mtodos orientados a objetos, pero permitiendo algunas caractersticas imperativas de maneras "seguras". El Eiffel de Bertrand Meyer fue un temprano y moderadamente acertado lenguaje con esos objetivos pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la aparicin de Internet, y a la implementacin de la mquina virtual de Java en la mayora de navegadores. PHP en su versin 5 se ha modificado, soporta una orientacin completa a objetos, cumpliendo todas las caractersticas propias de la orientacin a objetos.

3.

Conceptos fundamentales
La programacin orientada a objetos es una forma de programar que trata de encontrar una solucin a estos problemas. Introduce nuevos conceptos, que superan y amplan conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:
Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La

instanciacin es la lectura de estas definiciones y la creacin de un objeto a partir de ellas.

Herencia: (por ejemplo, herencia de la clase C a la clase D) Es la facilidad mediante la cual

la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos mtodos y variables publicas declaradas en C. Los componentes registrados como "privados" (private) tambin se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y slo pueden ser accedidos a travs de otros mtodos pblicos. Esto es as para mantener hegemnico el ideal de OOP.

Edgardo Cruz Ramrez

UNP-FII-EII

5|Pgina

POO y Ciclo de Vida UML

Programacin II

Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de

comportamiento o funcionalidad (mtodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.
Mtodo: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecucin se

desencadena tras la recepcin de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un mtodo puede producir un cambio en las propiedades del objeto, o la generacin de un "evento" con un nuevo mensaje para otro objeto del sistema.
Evento: Es un suceso en el sistema (tal como una interaccin del usuario con la mquina, o

un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. Tambin se puede definir como evento, a la reaccin que puede desencadenar un objeto, es decir la accin que genera.
Mensaje: una comunicacin dirigida a un objeto, que le ordena que ejecute uno de sus

mtodos con ciertos parmetros asociados al evento que lo gener.

Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase

de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus caractersticas predeterminadas, y cuyo valor puede ser alterado por la ejecucin de algn mtodo.
Estado interno: es una variable que se declara privada, que puede ser nicamente accedida

y alterada por un mtodo del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase.
Componentes de un objeto: atributos, identidad, relaciones y mtodos. Identificacin de un objeto: un objeto se representa por medio de una tabla o entidad que

est compuesta por sus atributos y funciones correspondientes. En comparacin con un lenguaje imperativo, una "variable", no es ms que un contenedor interno del atributo del objeto o de un estado interno, as como la "funcin" es un procedimiento interno del mtodo del objeto.

4.

Caractersticas de la POO
Existe un acuerdo acerca de qu caractersticas contempla la "orientacin a objetos", las caractersticas siguientes son las ms importantes:
Abstraccin: denota las caractersticas esenciales de un objeto, donde se capturan sus

comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cmo se implementan estas caractersticas. Los procesos, las funciones o los mtodos pueden tambin ser abstrados y cuando lo estn, una variedad de tcnicas son requeridas para ampliar una abstraccin. El proceso de abstraccin permite seleccionar las caractersticas relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La

Edgardo Cruz Ramrez

UNP-FII-EII

6|Pgina

POO y Ciclo de Vida UML

Programacin II

abstraccin es clave en el proceso de anlisis y diseo orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar.
Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse

pertenecientes a una misma entidad, al mismo nivel de abstraccin. Esto permite aumentar la cohesin de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultacin, principalmente porque se suelen emplear conjuntamente.
Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una

aplicacin en partes ms pequeas (llamadas mdulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicacin en s y de las restantes partes. Estos mdulos que se puedan compilar por separado, pero que tienen conexiones con otros mdulos. Al igual que la encapsulacin, los lenguajes soportan la Modularidad de diversas formas.
Principio de ocultacin: Cada objeto est aislado del exterior, es un mdulo natural, y cada

tipo de objeto expone una interfaz a otros objetos que especifica cmo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificacin por quien no tenga derecho a acceder a ellas, solamente los propios mtodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstraccin. La aplicacin entera se reduce a un agregado o rompecabezas de objetos.
Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir

el mismo nombre, al llamarlos por ese nombre se utilizar el comportamiento correspondiente al objeto que se est usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocacin de un comportamiento en una referencia producir el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecucin", esta ltima caracterstica se llama asignacin tarda o asignacin dinmica. Algunos lenguajes proporcionan medios ms estticos (en "tiempo de compilacin") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.
Herencia: las clases no estn aisladas, sino que se relacionan entre s, formando una

jerarqua de clasificacin. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en rboles o enrejados que reflejan un comportamiento comn. Cuando un objeto hereda de ms de una clase se dice que hay herencia mltiple.
Recoleccin de basura: la recoleccin de basura o garbage collector es la tcnica por la

cual el entorno de objetos se encarga de destruir automticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignacin o liberacin de memoria, ya que el entorno la asignar al crear un nuevo objeto y la liberar cuando nadie

Edgardo Cruz Ramrez

UNP-FII-EII

7|Pgina

POO y Ciclo de Vida UML

Programacin II

lo est usando. En la mayora de los lenguajes hbridos que se extendieron para soportar el Paradigma de Programacin Orientada a Objetos como C++ u Object Pascal, esta caracterstica no existe y la memoria debe desasignarse manualmente.

5.

Resumen
La programacin orientada a objetos es un paradigma que utiliza objetos como elementos fundamentales en la construccin de la solucin. Surge en los aos 70. Un objeto es una abstraccin de algn hecho o ente del mundo real que tiene atributos que representan sus caractersticas o propiedades y mtodos que representan su comportamiento o acciones que realizan. Todas las propiedades y mtodos comunes a los objetos se encapsulan o se agrupan en clases. Una clase es una plantilla o un prototipo para crear objetos, por eso se dice que los objetos son instancias de clases. La programacin Orientada a objetos (POO) es una forma especial de programar, ms cercana a como expresaramos las cosas en la vida real que otros tipos de programacin. Con la POO tenemos que aprender a pensar las cosas de una manera distinta, para escribir nuestros programas en trminos de objetos, propiedades, mtodos y otras cosas que veremos rpidamente para aclarar conceptos y dar una pequea base que permita soltarnos un poco con este tipo de programacin.

6.

Motivacin
Durante aos, los programadores se han dedicado a construir aplicaciones muy parecidas que resolvan una y otra vez los mismos problemas. Para conseguir que los esfuerzos de los programadores puedan ser utilizados por otras personas se cre la POO. Que es una serie de normas de realizar las cosas de manera que otras personas puedan utilizarlas y adelantar su trabajo, de manera que consigamos que el cdigo se pueda reutilizar. La POO no es difcil, pero es una manera especial de pensar, a veces subjetiva de quien la programa, de manera que la forma de hacer las cosas puede ser diferente segn el programador. Aunque podamos hacer los programas de formas distintas, no todas ellas son correctas, lo difcil no es programar orientado a objetos sino programar bien. Programar bien es importante porque as nos podemos aprovechar de todas las ventajas de la POO.

7.

Cmo Se Piensa En Objetos

Pensar en trminos de objetos es muy parecido a cmo lo haramos en la vida real. Por ejemplo vamos a pensar en un coche para tratar de modelarlo en un esquema de POO. Diramos que el coche es el elemento principal que tiene una serie de caractersticas, como podran ser el color, el modelo o la marca. Adems tiene una serie de funcionalidades asociadas, como pueden ser ponerse en marcha, parar o aparcar. Pues en un esquema POO el coche sera el objeto, las propiedades seran las caractersticas como el color o el modelo y los mtodos seran las funcionalidades asociadas como ponerse en marcha o parar. Por poner otro ejemplo vamos a ver cmo modelaramos en un esquema POO una fraccin, es decir, esa estructura matemtica que tiene un numerador y un denominador que divide al numerador, por ejemplo 3/2. La fraccin ser el objeto y tendr dos propiedades, el numerador y el denominador. Luego podra tener varios mtodos como simplificarse, sumarse con otra fraccin o nmero, restarse con otra fraccin, etc.

Edgardo Cruz Ramrez

UNP-FII-EII

8|Pgina

POO y Ciclo de Vida UML

Programacin II

Estos objetos se podrn utilizar en los programas, por ejemplo en un programa de matemticas hars uso de objetos fraccin y en un programa que gestione un taller de coches utilizars objetos coche. Los programas Orientados a objetos utilizan muchos objetos para realizar las acciones que se desean realizar y ellos mismos tambin son objetos. Es decir, el taller de coches ser un objeto que utilizar objetos coche, herramienta, mecnico, recambios, etc. 8. Clases en POO Las clases son declaraciones de objetos, tambin se podran definir como abstracciones de objetos. Esto quiere decir que la definicin de un objeto es la clase. Cuando programamos un objeto y definimos sus caractersticas y funcionalidades en realidad lo que estamos haciendo es programar una clase. En los ejemplos anteriores en realidad hablbamos de las clases coche o fraccin porque slo estuvimos definiendo, aunque por encima, sus formas. Propiedades en clases Las propiedades o atributos son las caractersticas de los objetos. Cuando definimos una propiedad normalmente especificamos su nombre y su tipo. Nos podemos hacer a la idea de que las propiedades son algo as como variables donde almacenamos datos relacionados con los objetos. Mtodos en las clases Son las funcionalidades asociadas a los objetos. Cuando estamos programando las clases las llamamos mtodos. Los mtodos son como funciones que estn asociadas a un objeto. Objetos en POO Los objetos son ejemplares de una clase cualquiera. Cuando creamos un ejemplar tenemos que especificar la clase a partir de la cual se crear. Esta accin de crear un objeto a partir de una clase se llama instanciar (que viene de una mala traduccin de la palabra instace que en ingls significa ejemplar). Por ejemplo, un objeto de la clase fraccin es por ejemplo 3/5. El concepto o definicin de fraccin sera la clase, pero cuando ya estamos hablando de una fraccin en concreto 4/7, 8/1000 o cualquier otra, la llamamos objeto. Para crear un objeto se tiene que escribir una instruccin especial que puede ser distinta dependiendo el lenguaje de programacin que se emplee, pero ser algo parecido a esto. miCoche = new Coche() Con la palabra new especificamos que se tiene que crear una instancia de la clase que sigue a continuacin. Dentro de los parntesis podramos colocar parmetros con los que inicializar el objeto de la clase coche. Estados en objetos Cuando tenemos un objeto sus propiedades toman valores. Por ejemplo, cuando tenemos un coche la propiedad color tomar un valor en concreto, como por ejemplo rojo o gris metalizado. El valor concreto de una propiedad de un objeto se llama estado.

Edgardo Cruz Ramrez

UNP-FII-EII

9|Pgina

POO y Ciclo de Vida UML

Programacin II

Para acceder a un estado de un objeto para ver su valor o cambiarlo se utiliza el operador punto. miCoche.color = rojo El objeto es miCoche, luego colocamos el operador punto y por ltimo el nombre de la propiedad a la que deseamos acceder. En este ejemplo estamos cambiando el valor del estado de la propiedad del objeto a rojo con una simple asignacin. Mensajes en objetos Un mensaje en un objeto es la accin de efectuar una llamada a un mtodo. Por ejemplo, cuando le decimos a un objeto coche que se ponga en marcha estamos pasndole el mensaje ponte en marcha. Para mandar mensajes a los objetos utilizamos el operador punto, seguido del mtodo que deseamos invocar. miCoche.ponerseEnMarcha() En este ejemplo pasamos el mensaje ponerseEnMarcha(). Hay que colocar parntesis igual que cualquier llamada a una funcin, dentro iran los parmetros. 9. Otras cosas Hay mucho todava que conocer de la POO ya que slo hemos hecho referencia a las cosas ms bsicas. Tambin existen mecanismos como la herencia y el polimorfismo que son unas de las posibilidades ms potentes de la POO. La herencia sirve para crear objetos que incorporen propiedades y mtodos de otros objetos. As podremos construir unos objetos a partir de otros sin tener que reescribirlo todo. El polimorfismo sirve para que no tengamos que preocuparnos sobre lo que estamos trabajando, y abstraernos para definir un cdigo que sea compatible con objetos de varios tipos.

Edgardo Cruz Ramrez

UNP-FII-EII

10 | P g i n a

POO y Ciclo de Vida UML

Programacin II

Lenguaje para Modelamiento Unificado (UML)

1. Introduccin
UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estndar de facto de la industria, debido a que ha sido concebido por los autores de los tres mtodos ms usados de orientacin a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Estos autores fueron contratados por la empresa Rational Software Co. para crear una notacin unificada en la que basar la construccin de sus herramientas CASE. En el proceso de creacin de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, as como grupos de analistas y desarrolladores.

Logo de UML Esta notacin ha sido ampliamente aceptada debido al prestigio de sus creadores y debido a que incorpora las principales ventajas de cada uno de los mtodos particulares en los que se basa: Booch, OMT y OOSE. UML ha puesto fin a las llamadas guerras de mtodos que se han mantenido a lo largo de los 90, en las que los principales mtodos sacaban nuevas versiones que incorporaban las tcnicas de los dems. Con UML se fusiona la notacin de estas tcnicas para formar una herramienta compartida entre todos los ingenieros software que trabajan en el desarrollo orientado a objetos. El objetivo principal cuando se empez a gestar UML era posibilitar el intercambio de modelos entre las distintas herramientas CASE orientadas a objetos del mercado. Para ello era necesario definir una notacin y semntica comn. En la figura 2 se puede ver cul ha sido la evolucin de UML hasta la creacin de UML 1.1. Hay que tener en cuenta que el estndar UML no define un proceso de desarrollo especfico, tan solo se trata de una notacin. En este curso se sigue el proceso propuesto por Craig Larman[Larman99] que se ajusta a un ciclo de vida evolutivo e incremental dirigido por casos de uso.

Edgardo Cruz Ramrez

UNP-FII-EII

11 | P g i n a

POO y Ciclo de Vida UML

Programacin II

2.

Qu es el Lenguaje para Modelamiento Unificado (UML)?

Es un lenguaje de modelamiento para la especificacin, visualizacin, construccin y documentacin de los artefactos de un proceso de sistema intensivo.
Dentro de un proceso de sistema intensivo, un mtodo es aplicado para llegar o

evolucionar un sistema.
Como un lenguaje, es usado para la comunicacin. Es decir, un medio para capturar el

conocimiento (semnticas) respecto a un tema y expresar el conocimiento (sintaxis) resguardando el tema propsito de la comunicacin. El tema es el sistema en estudio.
Como un lenguaje para modelamiento, se enfoca en la comprensin de un tema a travs

de la formulacin de un modelo del tema (y su contexto respectivo). El modelo abarca el conocimiento cuidando del tema, y la apropiada aplicacin de este conocimiento constituye inteligencia.
Cuidando la unificacin, integra las mejores prcticas de la ingeniera de la industria

tecnolgica y sistemas de informacin pasando por todos os tipos de sistemas (software y no - software), dominios (negocios versus software) y los procesos de ciclo de vida.
En cuanto a cmo se aplica para especificar sistemas, puede ser usado para comunicar

"qu" se requiere de un sistema y "cmo" un sistema puede ser realizado.

En cuanto a cmo se aplica para visualizar sistemas, puede ser usado para describir

visualmente un sistema antes de ser realizado.

En cuanto a cmo se aplica para construir sistemas, puede ser usado para guiar la

realizacin de un sistema similar a los "planos".

En cuanto a cmo se aplica para documentar sistemas, puede ser usado para capturar

conocimiento respecto a un sistema a lo largo de todo el proceso de su ciclo de vida. UML no es:
Un lenguaje de programacin visual, sino un lenguaje de modelamiento visual. Una herramienta o depsito de especificacin, sino un lenguaje para modelamiento de

especificacin.
Un proceso, sino que habilita procesos.

Fundamentalmente, UML est relacionado con la captura, comunicacin y nivelacin (disgregacin en niveles) de conocimientos.

3.

Vistas del UML

En la construccin de software usando UML, existen cinco vistas para visualizar, especificar, construir y documentar la arquitectura del software. UML permite representar cada vista mediante un conjunto de diagramas, las vistas son las siguientes:

Edgardo Cruz Ramrez

UNP-FII-EII

12 | P g i n a

POO y Ciclo de Vida UML

Programacin II

Vista de casos de uso: Muestra la funcionalidad del sistema desde el punto de vista de un actor externo que interacta con l. Esta vista es til a clientes, diseadores y desarrolladores. Vista de diseo: Muestra la funcionalidad del diseo dentro del sistema en trminos de la estructura esttica y comportamiento dinmico del sistema. Esta vista es til a diseadores y desarrolladores. Se definen propiedades tales como: persistencia, concurrencia, interfaces y estructuras internas a las clases. Vista de procesos: Muestra la concurrencia del sistema, comunicacin y sincronizacin. til a desarrolladores e integradores. Vista de implementacin: Muestra la organizacin de los componentes de cdigo. til a desarrolladores. Vista de implantacin (tambin conocida como vista de despliegue): Muestra la implantacin del sistema en la arquitectura fsica. til a desarrolladores, integradores y verificadores.

4.

Definicin de modelo
Un sistema (tanto en el mundo real como en el mundo del software) suele ser extremadamente intrincado, por ello es necesario dividir el sistema en partes o fragmentos si queremos entender y administrar su complejidad. Estas partes podemos representarlas como modelos que describan y abstraigan sus aspectos esenciales. Un modelo captura una vista de un sistema del mundo real. Es una abstraccin de dicho sistema considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo y a un apropiado nivel de detalle. Los modelos se componen de otros modelos, de diagramas y documentos que describen detalles del sistema. El UML especifica varios diagramas. Si queremos caracterizar los modelos, podemos poner de manifiesto la informacin esttica o dinmica de un sistema. Un modelo esttico describe las propiedades estructurales del sistema; en cambio, un modelo dinmico describe las propiedades de comportamiento de un sistema. Es importante mencionar que el UML es un lenguaje para construir modelos; no gua al desarrollador en la forma de realizar el anlisis y diseo orientado a objetos ni indica cul proceso de desarrollo adoptar. Para modelar un sistema es suficiente utilizar una parte de UML, "el 80 por ciento de la mayora de los problemas pueden modelarse usando alrededor del 20 por ciento de UML".

5.

Diagramas UML
UML es un lenguaje notacional. Parte importante de esta notacin son los diagramas que nos permiten modelar un sistema. Un diagrama es una representacin grfica de una coleccin de elementos de modelado, la mayora de las veces mostrados como grafo conexo de vrtices (cosas) y arcos (relaciones). Los buenos diagramas hacen el sistema que se est

Edgardo Cruz Ramrez

UNP-FII-EII

13 | P g i n a

POO y Ciclo de Vida UML

Programacin II

desarrollando ms comprensible y cercano a los objetivos. En UML se definen nueve diagramas, los cuales se pueden mezclar en cada vista (ver figura 5.1 y 5.2).

Fig. 5.1 Diagramas empleados por UML

Fig. 5.2 Vistas de un software y sus respectivos diagramas UML

Edgardo Cruz Ramrez

UNP-FII-EII

14 | P g i n a

POO y Ciclo de Vida UML 5.1 Diagramas estructurales

Programacin II

Los cuatro diagramas estructurales de UML existen para visualizar, especificar, construir y documentar los aspectos estticos del sistema. Estn organizados sobre grupos de objetos que se encontrarn cuando se est modelando un sistema. Diagrama de clases: Un diagrama de este tipo muestra un conjunto de clases, interfaces, y sus relaciones. Diagrama de objetos: Muestra un conjunto de objetos y sus relaciones. A diferencia de los diagramas anteriores, estos diagramas se enfocan en la perspectiva de casos de uso, y prototipos. Diagrama de componentes: Muestra el conjunto de componentes y sus relaciones y se utilizan para ilustrar la vista de la implementacin esttica de un sistema. Diagrama de implantacin: Muestra un conjunto de nodos y sus relaciones, se usan para ilustrar la vista de implantacin esttica de un sistema. 5.2 Diagramas de comportamiento Los cinco diagramas de comportamiento de UML son usados para visualizar, especificar, construir y documentar los aspectos dinmicos de un sistema. Se puede pensar en los aspectos dinmicos como las representaciones de las partes cambiantes del sistema. Diagrama de casos de uso: Muestra el conjunto de casos de uso y actores (incluyendo sus relaciones). Estos diagramas se utilizan para ilustrar la vista del caso de uso del sistema. Diagrama de secuencia: Es un diagrama de interaccin que enfatiza el orden en tiempo de los mensajes. Diagrama de colaboracin: Es un diagrama de interaccin que enfatiza la organizacin estructural de los objetos que envan y reciben mensajes. El diagrama de colaboracin muestra un conjunto de objetos, las ligas entre ellos y los mensajes enviados y recibidos por dichos objetos. Nota: Los diagramas de secuencia y de colaboracin son isomrficos, i.e. se puede hacer la conversin de uno a otro sin perder informacin. Diagrama de estado: Muestra una mquina de estado, consistente en estados, transiciones, eventos y actividades. Estos diagramas enfatizan el comportamiento ordenado por eventos de un objeto. Diagrama de actividad: Muestra el flujo de una actividad a otra dentro del sistema. Ha sido diseado para mostrar una visin simplificada de lo que ocurre durante una operacin o suceso. 6. UML y su relacin con los procesos de desarrollo de software Un proceso de desarrollo de software es un mtodo de organizar las actividades relacionadas con la creacin, presentacin y mantenimiento de los sistemas de software. El lenguaje UML no define un proceso oficial de desarrollo, en realidad UML se combina con un proceso de desarrollo para obtener un producto final (ver figura 6.1). Craig Larman da dos razones importantes que explican esto: 1. Aumentar la posibilidad de una aceptacin generalizada de la notacin estndar del modelado, sin la obligacin de adoptar un proceso oficial.

Edgardo Cruz Ramrez

UNP-FII-EII

15 | P g i n a

POO y Ciclo de Vida UML

Programacin II

2. La esencia de un proceso apropiado admite mucha variacin y depende de las habilidades del personal, de la razn investigacin-desarrollo, de la naturaleza del problema y de las herramientas.

Fig. 6.1 UML y el proceso de desarrollo

7.

El ciclo de vida
En el ciclo de vida de un proyecto software existen cuatro fases. La iniciacin, que es cuando la idea inicial est lo suficientemente fundada para poder garantizar la entrada en la fase de elaboracin, esta fase es cuando se produce la definicin de la arquitectura y la visin del producto. En esta fase se deben determinar los requisitos del sistema y las pruebas sobre el mismo. Posteriormente se pasa a la fase de construccin, que es cuando se pasa de la base arquitectnica ejecutable hasta su disponibilidad para los usuarios, en esta fase se reexaminan los requisitos y las pruebas que ha de soportar. La transicin, cuarta fase del proceso, 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 el proyecto es continuamente reexaminado y mejorado erradicando errores y aadiendo nuevas funcionalidades no contempladas. Un elemento que distingue a este proceso y afecta a las cuatro fases es una iteracin, que es un conjunto bien definido de actividades, con un plan y unos criterios de evaluacin, que acaban en una versin del producto, bien interna o externa.

Figura 1. Estructura del ciclo de vida

Edgardo Cruz Ramrez

UNP-FII-EII

16 | P g i n a