PROGRAMACIN III

UML















JULY ROSSINY CAICEDO AREVALO















CERES UNIMINUTO
AGOSTO 21 DEL 2014
GUADUAS, CUNDINAMARCA
PROGRAMACIN III
UML















JULY ROSSINY CAICEDO AREVALO
TUTOR: OSCAR JAVIER FORIGUA














CERES UNIMINUTO
AGOSTO 21 DEL 2014
GUADUAS, CUNDINAMARCA
UML
UML significa Lenguaje Unificado de Modelado (Unified Modeling Language) Es un
lenguaje que se usa para entender, disear, configurar, mantener y controlar la
informacin sobre los sistemas a construir.
UML capta la informacin sobre la estructura esttica y el comportamiento dinmico de
un sistema. Un sistema se modela como una coleccin de objetos discretos que
interactan para realizar un trabajo que finalmente beneficia a un usuario externo.
El lenguaje de modelado pretende unificar la experiencia pasada sobre tcnicas de
modelado e incorporar las mejores prcticas actuales en un acercamiento estndar.
UML no es un lenguaje de programacin. Las herramientas pueden ofrecer
generadores de cdigo de UML para una gran variedad de lenguaje de programacin,
as como construir modelos por ingeniera inversa a partir de programas existentes.
UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo
aspectos conceptuales tales como procesos de negocio, funciones del sistema, y
aspectos concretos como expresiones de lenguajes de programacin, esquemas de
bases de datos y compuestos reciclados.
UML no puede compararse con la programacin estructurada, pues UML significa
Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad de
una utilizacin en un requerimiento. Mientras que, programacin estructurada, es una
forma de programar como lo es la orientacin a objetos, la programacin orientada a
objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML
slo para lenguajes orientados a objetos.

HISTORIA DEL UML
El UML nace de la necesidad de un proceso estndar de anlisis y diseo era necesario
contar con una notacin y un proceso estndar. La notacin UML se deriva y unifica de
las tres metodologas de anlisis:

Metodologa de Grady Booch para la descripcin de conjuntos de objetos y sus
relaciones.
Tcnica de modelado orientada a objetos de James Rumbaugh (OMT: Object-
Modeling Technique).
Aproximacin de Ivar Jacobson (OOSE: Object- Oriented Software Engineering)
mediante la metodologa de casos de uso (use case).

Durante los ochenta y principios de los noventa Grady Booch, James Rumbaugh, e Ivan
Jacobson trabajaban por separado en desarrollo de notaciones para el anlisis y diseo
de sistemas orientados a objetos. Los tres llegaron por separado a obtener bastante
reconocimiento.

De las tres metodologas de partida, las de Bco. y Rumbaugh pueden ser descritas
como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado
de los objetos que componen el sistema, su relacin y colaboracin.
Por otro lado, la metodologa de Jacobson es ms centrada a usuario, ya que todo en
su mtodo se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando
como estndar desde el OMG, que es tambin el origen de CORBA, el estndar lder
en la industria para la programacin de objetos distribuidos.
Booch haba escrito "Object-Oriented Analysis and Design with Applications" un libro de
referencia en el anlisis y diseo orientado a objetos desarrollando su propia notacin.

Por otro lado Jacobson se haba revelado como un visionario del anlisis (padre de los
casos de uso) y sobre todo del diseo orientado a objetos, sorprendiendo a todo el
mundo en "Object-Oriented Software Engineering: A Use Case Driven Approach".

Por su parte James Rumbaugh haba desarrollado su propia notacin de diseo
orientado a objetos llamada OMT (Object Modeling Technique) en su libro "Object-
Oriented Modeling and Design".

En 1994, James Rumbaugh se uni con Grady Booch en Rational Software Corporation
(ahora una divisin de IBM), y comenzaron a trabajar para unificar sus populares
procesos, Pronto se uni a ellos Ivar Jacobson. En 1996, el grupo liber las primeras
versiones de UML para la comunidad de ingeniera de software, solicitando
retroalimentacin. Casi al mismo tiempo, una organizacin conocida como Object
Management Group hizo una invitacin para participar en la creacin de un lenguaje
comn de modelado. El OMG es una organizacin sin fines de lucro que promueve la
estandarizacin de las tecnologas orientadas a objetos, emitiendo lineamientos y
especificaciones como UML. Varias empresas (entre ellas HP, IBM, Microsoft, Oracle y
Rational Software) haban reconocido ya la necesidad de un lenguaje comn de
modelado. Estas compaas formaron el consorcio UML Partners (Socios de UML) en
respuesta a la solicitud de proposiciones por parte del OMG(el consorcio que desarroll
la versin 1.1 de UML y la envi al OMG). La propuesta fue aceptada y, en 1997, el
OMG asumi la responsabilidad del mantenimiento y revisin de UML en forma
continua. La versin que est ahora disponible marca la primera modificacin
importante al UML desde el estndar de la versin 1.1 de 1997, presentada como la
versin UML 2.


En 1997 UML 1.1
Fue aprobada por la OMG convirtindose en la notacin estndar de facto para el
anlisis y el diseo orientado a objetos.
UML es el primer mtodo en publicar un meta-modelo en su propia notacin, incluyendo
la notacin para la mayora de la informacin de requisitos, anlisis y diseo. Se trata
pues de un meta-modelo auto-referencial (cualquier lenguaje de modelado de propsito
general debera ser capaz de modelarse a s mismo).
UML 1.x
Como notacin de modelado, la influencia de la OMT domina UML (por ejemplo el uso
de rectngulos para clases y objetos). Aunque se quit la notacin de "nubes" de
Booch, si se adopt la capacidad de Booch para especificar detalles de diseo en los
niveles inferiores. La notacin de Casos de Uso del Objectory y la notacin de
componentes de Booch fueron integrados al resto de la notacin, pero la integracin
semntica era relativamente dbil en UML 1.1, y no se arregl realmente hasta la
revisin mayor de UML 2.0.
UML 2.x
UML ha madurado considerablemente desde UML 1.1. Varias revisiones menores (UML
1.3, 1.4 y 1.5) han corregido defectos y errores de la primera versin de UML. A estas le
ha seguido la revisin mayor UML 2.0 que fue adoptada por el OMG en 2005.
Aunque UML 2.1 nunca fue lanzado como una especificacin formal, las versiones 2.1.1
y 2.1.2, aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009. UML 2.3 fue
lanzado oficialmente en mayo de 2010. UML 2.4.1 fue lanzado oficialmente en agosto
de 2011. UML 2.5 fue lanzado en octubre de 2012 como una versin "En proceso" y
todava tiene que ser formalmente liberada.

IMPORTANCIA DE UML
Hoy en da, UML ("Unified Modeling Language") est consolidado como el lenguaje
estndar en el anlisis y diseo de sistemas de cmputo. Mediante UML es posible
establecer la serie de requerimientos y estructuras necesarias para plasmar un sistema
de software previo al proceso intensivo de escribir cdigo.
Entre ms complejo es el sistema que se desea crear ms beneficios presenta el uso
de UML las razones de esto son evidentes, sin embargo, existen dos puntos claves : El
primero se debe a que mediante un plano/visin global resulta ms fcil detectar las
dependencias y dificultades implcitas del sistema, y la segunda razn radica en que los
cambios en una etapa inicial (Anlisis) resultan ms fciles de realizar que en una etapa
final de un sistema como lo sera la fase intensiva de codificacin.
En todas las disciplinas de la Ingeniera se hace evidente la importancia de los modelos
ya que describen el aspecto y la conducta de "algo". Ese "algo" puede existir, estar en
un estado de desarrollo o estar, todava, en un estado de planeacin. Es en este
momento cuando los diseadores del modelo deben investigar los requerimientos del
producto terminado y dichos requerimientos pueden incluir reas tales como
funcionalidad y confiabilidad. Adems, a menudo, el modelo es dividido en un nmero
de vistas, cada una de las cuales describe un aspecto especfico del producto o sistema
en construccin.
El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de
pequeo tamao se obtienen beneficios de modelado, sin embargo es un hecho que
entre ms grande y ms complejo es el sistema, ms importante es el papel de que
juega el modelado por una simple razn: "El hombre hace modelos de sistemas
complejos porque no puede entenderlos en su totalidad".
Los principales beneficios de UML son:
Mejores tiempos totales de desarrollo (de 50 % o ms).
Modelar sistemas (y no slo de software) utilizando conceptos orientados a
objetos.
Establecer conceptos y artefactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas complejos de misin
crtica.
Crear un lenguaje de modelado utilizado tanto por humanos como por mquinas.
Mejor soporte a la planeacin y al control de proyectos.
Alta reutilizacin y minimizacin de costos.
El diagrama de UML es muy importante por varias razones:

1) Posee caractersticas ms visuales que programticas, por lo cual facilita la
comunicacin entre los analistas de la aplicacin y los conocedores de las reglas de
negocio. Esto reduce las posibilidad de desarrollar softwares que no cumplan con las
expectativas del cliente, ya que en la trasmisin de los requisitos iniciales del cliente al
programador no se capt lo que el usuario quiere realmente, o no hubo una buena
explicacin por parte del cliente.
2) Facilita el proceso de desarrollo del software para el programador, ya que
anteriormente logr visualizar de manera grfica lo que quiere plasmar en cdigos, es
ms fcil traducir de este concepto visual que directamente de los requerimientos del
cliente.


3) Determina la mejor manera de solucionar la situacin propuesta, ya que realizando el
Diagrama de UML se puede visualizar de mejor manera las acciones que suelen
repetirse, los objetos, clases, mtodos, funciones, entre otros que son similares y de
esta manera se acorta el tiempo de desarrollo y se pone en prctica la "reutilizacin",
trmino muy bien visto en esta poca de libre informacin - software libre y de
programacin orientada a objetos.

DIAGRAMAS DE CASOS DE USO
Los diagramas de casos de uso documentan el comportamiento de un sistema desde el
punto de vista del usuario. Por lo tanto los casos de uso determinan los requisitos
funcionales del sistema, es decir, representan las funciones que un sistema puede
ejecutar.
Describen una interaccin tpica entre un usuario (actores) y un sistema de
cmputo.
Es una tcnica para capturar informacin de cmo un sistema o negocio trabaja
actualmente, o de cmo se desea que trabaje
Produce algo de valor para algn actor como el clculo de algn resultado
Describe qu hace un sistema pero no especifica cmo lo hace
El caso de uso capta alguna funcin visible para el usuario.
El caso de uso puede ser pequeo o grande.
El caso de uso logra un objetivo discreto para el usuario.
Un caso de uso debe ser simple, claro y conciso
Estos tipos de diagramas son empleados con ms frecuencia en alguna de las
siguientes etapas:
Determinacin de Requerimientos: Por lo general nuevos requerimientos de
sistema generan nuevos Casos de Usos, conforme es analizado y diseado el
sistema.
Comunicacin con el Cliente: Debido a la sencillez de este tipo de diagramas,
son fciles de emplear para comunicarse con el cliente final del proyecto.

Generacin de pruebas de Sistemas: A travs de los diagramas de Casos de
Uso se pueden generar una serie de pruebas de sistema.


Elementos de los diagramas de Casos de Uso
Actor: Un actor representa quien o que inicia una accin dentro del sistema, en
otras palabras, es simplemente un rol que es llevado a cabo por una persona o
cosa. Un Actor en un diagrama de Caso de Uso es representado por una figura
en forma de persona.

Caso de Uso: El Caso de Uso en s es representado por un ovalo que describe la
funcionalidad que se requiere por el sistema.

Comunicacin: Este elemento representa la relacin que existe entre un Caso de
uso y un Actor, dicho elemento es representado simplemente por una lnea recta
que se extiende de la figura del actor hacia el ovalo del Caso de uso.

Limite de Sistema (System Boundry): Empleado para delimitar los lmites del
sistema, y representado por un rectngulo con color de fondo distintivo.

Inclusin: Una inclusin es utilizada para indicar que un Caso de Uso (ovalo)
depende de otro caso, es decir, significa que la funcionalidad de determinado
caso se requiere para realizar las tareas de otro. Este elemento es representado
por una lnea punteada con flecha y comentario <> que se extiende del Caso de
Uso base hacia el Caso de Uso de inclusin.

Extensin: Una extensin representa una variacin de un Caso de Uso a otro,
una extensin representa una dependencia especfica. Este elemento es
representado por una lnea punteada con flecha y comentario <> que origina del
Caso de Uso base hacia el Caso de uso de extensin.
EJEMPLO DE UN DIAGRAMA DE CASOS DE USO

DIAGRAMA DE CLASES
Los diagramas de clases son diagramas de estructura esttica que muestran las clases
del sistema y sus interrelaciones (incluyendo herencia, agregacin, asociacin, etc.).
Los diagramas de clase son el pilar bsico del modelado con UML, siendo utilizados
tanto para mostrar lo que el sistema puede hacer (anlisis), como para mostrar cmo
puede ser construido (diseo). Las clases se documentan con una descripcin de lo
que hacen, sus mtodos y sus atributos. Las relaciones entre clases se documentan
con una descripcin de su propsito, sus objetos que intervienen en la relacin y su
opcionalidad (cuando un objeto es opcional el que intervenga en una relacin).
Un diagrama de Clases representa las clases que sern utilizadas dentro del sistema y
las relaciones que existen entre ellas.
Es el ms utilizado y ms conocido de los diagramas orientados a objetos. Es la
fuente de generacin de cdigo.
El diagrama de clase representa clases, sus partes y la forma en la que las
clases de los objetos estn relacionados con otro.
Una clase es una definicin de un tipo de objeto.
Partes del diagrama de clases
a) Clases: Es la unidad bsica que encapsula toda la informacin de un Objeto (un
objeto es una instancia de una clase). A travs de ella podemos modelar el
entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectngulo que posee tres divisiones asi:
En donde:
Superior: Contiene el nombre de la Clase
Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase
(pueden ser private, protected o public).
Inferior: Contiene los mtodos u operaciones, los cuales son la forma como interacta
el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

b) Atributos: describe las caractersticas de una clase de objetos, como color,
material, cantidad, ubicacin. Generalmente se conoce como la informacin
detallada del objeto. Ejemplo: el objeto es una puerta, sus propiedades o
atributos seran: la marca, tamao, color y peso.

Tipos de atributos:

public (+, ): Indica que el atributo ser visible tanto dentro como fuera de
la clase, es decir, es accesible desde todos lados.
private (-, ): Indica que el atributo slo ser accesible desde dentro de la
clase (slo sus mtodos lo pueden utilizar).
protected (#, ): Indica que el atributo no ser accesible desde fuera de la
clase, pero si podr ser accesado por mtodos de la clase adems de las
subclases que se deriven.

c) Operaciones/Mtodos: son aquellas actividades o verbos que se pueden
realizar con o para este objeto, como por ejemplo abrir, cerrar, buscar, cancelar,
confirmar, cargar. El nombre de una operacin se escribe con minsculas si
consta de una sola palabra. Si el nombre contiene ms de una palabra, cada
palabra ser unida a la anterior y comenzar con una letra mayscula, a
excepcin de la primera palabra que comenzar en minscula. Por ejemplo:
abrirPuerta, cerrarPuerta, buscarPuerta, etc.


Tipos de mtodos:

public (+, ): Indica que el mtodo ser visible tanto dentro como fuera de
la clase, es decir, es accesible desde todos lados.
private (-, ): Indica que el mtodo slo ser accesible desde dentro de la
clase (slo otros mtodos de la clase lo pueden utilizar).
protected (#, ): Indica que el mtodo no ser accesible desde fuera de la
clase, pero si podr ser accesado por mtodos de la clase adems de
mtodos de las subclases que se deriven.

d) Herencia: Indica que una subclase hereda los mtodos y atributos especificados
por una Super Clase (tambin llamada clase padre), por ende la Subclase
adems de poseer sus propios mtodos y atributos, poseer las caractersticas y
atributos visibles de la Super Clase (public y protected).

e) Asociacin: La relacin entre clases conocida como Asociacin, permite
asociar objetos que colaboran entre si. Cabe destacar que no es una relacin
fuerte, es decir, el tiempo de vida de un objeto no depende del otro.
Ejemplo:
Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden
de compra solo puede tener asociado un cliente.
f) Dependencia: Representa un tipo de relacin muy particular, en la que una
clase es instanciada (su instanciacin es dependiente de otro objeto/clase). Se
denota por una flecha punteada.

El uso ms particular de este tipo de relacin es para denotar la dependencia
que tiene una clase de otra, como por ejemplo una aplicacin grafica que
instancia una ventana (la creacin del Objeto Ventana esta condicionado a la
instanciacin proveniente desde el objeto Aplicacin):
En este ejemplo el objeto creado (en este caso la Ventana grfica) no se almacena
dentro del objeto que lo crea (en este caso la Aplicacin).
VENTAJAS
Es el ms utilizado y ms conocido de los diagramas orientados a objetos.
Genera un cdigo automticamente.
Propone soluciones a algunos errores.
Representa las relaciones entre las clases de sistema.
Se disea los componentes de los sistemas.
Se protegen los datos.
Se posibilita una reduccin de acoplamiento.
Es la fuente de generacin de cdigo.
El diagrama de clase representa clases, sus partes y la forma en la que las
clases de los objetos estn relacionados con otro.

ABSTRACCION DE DATOS
La abstraccin de datos sirve para plantear diseos de una estructura de algn dato en
particular. Una estructura de datos es una coleccin de datos que tienen operaciones
relacionadas con la capacidad para poder manipularlos.
El proceso de abstraccin es bsicamente separar cada una de las partes esenciales
de un objeto, sistema o problema. Existen dos tipos de abstraccin tiene un y es un,
cada uno de ellos implica lo siguiente:
Tiene_Un
Dividir un sistema complejo en sus partes y dividir sus partes para hacerla mas sencilla.
Ejemplos: Un avin tiene un motor. Una bicicleta tiene una llanta.
Es_Un
Toma un sistema complejo y lo ve como una instancia de una abstraccin ms general.
Ejemplos: un avin es un transporte areo. Una bicicleta es un vehculo con llantas.
Un tipo de dato abstracto es un tipo de modelo.
Los tipos de datos abstractos (TDA) contienen estructuras de datos con la cual
modelamos una entidad y funciones de abstraccin las cuales usamos con las
estructuras de datos.
Existen diferentes niveles de abstraccin:
Lgico abstracto. Se define la estructura y operaciones relacionadas con ella.
Fsico. Se define el lenguaje de programacin para la implementacin.
Aplicacin. El uso del TDA se limita a llamar las operaciones sobre la estructura que se
requiera siempre cumpliendo con las reglas de cada operacin.

POLIMORFISMO
Es la capacidad que tienen los objetos de una clase de responder al mismo mensaje o
evento en funcin de los parmetros utilizados durante su invocacin.
El polimorfismo se refiere a que una caracterstica de una clase puede tomar varias
formas, representa en nuestro caso la posibilidad de desencadenar operaciones
distintas en respuesta a un mismo mensaje. Cada subclase hereda las operaciones
pero tiene la posibilidad de modificar localmente el comportamiento de estas
operaciones.
Ejemplo:
Todo animal duerme, pero cada clase lo hace de forma distinta.

Tipos de Polimorfismo
Dinmico: es el que el cdigo no incluye ningn tipo de especificacin sobre el tipo de
datos.
Esttico: es el que los tipos a los que se aplica el polimorfismo deben ser explicitados y
declarados uno por uno antes de ser utilizados.


HERENCIA
Es una propiedad que permite que los objetos sean creados a partir de otros ya
existentes, obteniendo caractersticas (mtodos y atributos) similares a los ya
existentes.
Utilizando la herencia, un objeto solo necesita definir aquellas cualidades que lo hacen
nico dentro de una clase.
Ejemplo:

TIPOS DE HERENCIA
Herencia Sencilla:
En herencia sencilla Un objeto puede tomar las caractersticas de otro objeto y de
ningn otro, es decir solo puede tener un padre.

Herencia Mltiple:
La herencia mltiple se presenta cuando una subclase tiene ms de una superclase. Se
recomienda un uso restringido y disciplinado de la herencia.