TALLER 1

REALIZADO POR:

REINALDO MORALES SERRATO

PRESENTADO A:

JOSE OMAR MAYORGA

INGENIERIA DE SISTEMAS

UNIVERSIDADDEL TOLIMA

INSTITUTO DE EDUCACION A DISTANCIA

2011
 Objetivos

 Identificar los diferentes diagramas de UML(Lenguaje Unificado

Modelado )

 Analizar las tres clases de bloques de continuacion, que eson

elementos, relaciones y diagramas.

 Conoser la historia de uml (Lenguaje Unificado Modelado ) y su

importancia para la ingenieria del software

 Establecer diferncias entre los diagramas de uml (Lenguaje Unificado

Modelado )

 Manejar cada uno de los diagrams uml (Lenguaje Unificado Modelado)

 Nucleo Numero Uno

1. El UML
2. Historia
3. Razones de su importancia
4. Diagramas de Casos de Uso.
5. Diagramas de clases.
5.1 Abstracción de Datos
5.2 Polimorfismo
5.3 herencia

UML LENGUAJE UNIFICADO DE MODELADO

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés,

Unified Modeling Language) es el lenguaje de modelado de sistemas de
software más conocido y utilizado en la actualidad; está respaldado por el OMG
(Object Management Group). Es un lenguaje gráfico para visualizar,
especificar, construir y documentar un sistema. UML ofrece un estándar para
describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales
tales como procesos de negocio y funciones del sistema, y aspectos concretos
como expresiones de lenguajes de programación, esquemas de bases de
datos y componentes reutilizables.

.
 CLASES
COMPONENTE
S
OBJETOS
ESTRUCTURA
ESTRUCTURA
COMPUESTA

DESPLIEGUE
PAQUETES
DIAGRAMA

ACTIVIDADES SECUENCIA

CASOS DE USO
COMPORTAMIENTO GLOBAL DE
MAQUINA DE INTERACCION
ESTADO
COMUNICACION
INTERACCION
TIEMPOS

DIAGRMAS UML

Es importante resaltar que UML es un "lenguaje de modelado" para especificar

o para describir métodos o procesos. Se utiliza para definir un sistema, para
detallar los artefactos en el sistema y para documentar y construir. En otras
palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software entregando gran variedad de

formas para dar soporte a una metodología de desarrollo de software (tal como
el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué
metodología o proceso usar.

UML no puede compararse con la programación estructurada, pues UML

significa Lenguaje Unificado de Modelado, no es programación, solo se
diagrama la realidad de una utilización en un requerimiento. Mientras que,
programación estructurada, es una forma de programar como lo es la
orientación a objetos, sin embargo, la programación orientada a objetos viene
siendo un complemento perfecto de UML, pero no por eso se toma UML sólo
para lenguajes orientados a objetos.

UML cuenta con varios tipos de diagramas, los cuales muestran diferentes
aspectos de las entidades representadas
Diagramas de Estructura

Diagrama de clases es un tipo de diagrama estático que describe la estructura

de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los
diagramas de clases son utilizados durante el proceso de análisis y diseño de
los sistemas, donde se crea el diseño conceptual de la información que se
manejará en el sistema, y los componentes que se encargaran del
funcionamiento y la relación entre uno y otro.

Representación de: - Requerimientos en entidades y actuaciones. - La

arquitectura conceptual de un dominio - Soluciones de diseño en una
arquitectura - Componentes de software orientados a objetos

Definiciones

 Propiedades también llamados atributos o características, son

valores que corresponden a un objeto, como color, material, cantidad,
ubicación. Generalmente se conoce como la información detallada del
objeto. Suponiendo que el objeto es una puerta, sus propiedades serían:
la marca, tamaño, color y peso.

 Operaciones comunmente llamados metodos, son aquellas actividades

o verbos que se pueden realizar con/para este objeto, como por ejemplo
abrir, cerrar, buscar, cancelar, acreditar, cargar. De la misma manera
que el nombre de un atributo, el nombre de una operación se escribe
con minúsculas si consta de una sola palabra. Si el nombre contiene
más de una palabra, cada palabra será unida a la anterior y comenzará
con una letra mayúscula, a excepción de la primera palabra que
comenzará en minúscula. Por ejemplo: abrirPuerta, cerrarPuerta,
buscarPuerta, etc.

 Interfaz es un conjunto de operaciones que permiten a un objeto

comportarse de cierta manera, por lo que define los requerimientos
mínimos del objeto. Hace referencia a polimorfismo.

 Herencia se define como la reutilización de un objeto padre ya definido

para poder extender la funcionalidad en un objeto hijo. Los objetos hijos
heredan todas las operaciones y/o propiedades de un objeto padre. Por
ejemplo: Una persona puede especializarse en Proveedores,
Acreedores, Clientes, Accionistas, Empleados; todos comparten datos
básicos como una persona, pero además cada uno tendrá información
adicional que depende del tipo de persona, como saldo del cliente, total
de inversión del accionista, salario del empleado, etc.

Al diseñar una clase se debe pensar en cómo se puede identificar un objeto

real, como una persona, un transporte, un documento o un paquete. Estos
ejemplos de clases de objetos reales, es sobre lo que un sistema se diseña.
Durante el proceso del diseño de las clases se toman las propiedades que
identifican como único al objeto y otras propiedades adicionales como datos
que corresponden al objeto. Con los siguientes ejemplos se definen tres
objetos que se incluyen en un diagrama de clases:

Diagrama de componentes es un diagrama tipo del Lenguaje Unificado de

Modelado.

Un diagrama de componentes representa cómo un sistema de software es

dividido en componentes y muestra las dependencias entre estos
componentes. Los componentes físicos incluyen archivos, cabeceras,
bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de
Componentes prevalecen en el campo de la arquitectura de software pero
pueden ser usados para modelar y documentar cualquier arquitectura de
sistema.

Debido a que estos son más parecidos a los diagramas de casos de usos estos
son utilizados para modelar la vista estática y dinámica de un sistema. Muestra
la organización y las dependencias entre un conjunto de componentes. No es
necesario que un diagrama incluya todos los componentes del sistema,
normalmente se realizan por partes. Cada diagrama describe un apartado del
sistema.

En él se situarán librerías, tablas, archivos, ejecutables y documentos que

formen parte del sistema.

Uno de los usos principales es que puede servir para ver qué componentes
pueden compartirse entre sistemas o entre diferentes partes de un sistema.

Diagramas de objetos son utilizados durante el proceso de Análisis y Diseño

de los sistemas informáticos en la metodología UML.

Se puede considerar un caso especial de un diagrama de clases en el que se

muestran instancias específicas de clases (objetos) en un momento particular
del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos
de un diagrama de clase. Los diagramas de objetos no muestran la
multiplicidad ni los roles, aunque su notación es similar a los diagramas de
clase.

Una diferencia con los diagramas de clase es que el compartimiento de arriba

va en la forma Nombre de objeto: Nombre de clase.

Por ejemplo, Miguel: Persona.

Diagrama de estructura compuesta es un tipo de diagrama de estructura

estática en el Lenguaje de Modelado Unificado (UML), que muestra la
estructura interna de una clase y las colaboraciones que esta estructura hace
posibles. Esto puede incluir partes internas, puertas mediante las cuales, las
partes interactúan con cada una de las otras o mediante las cuales, instancias
de la clase interactúan con las partes y con el mundo exterior, y conectores
entre partes o puertas. Una estructura compuesta es un conjunto de elementos
interconectados que colaboran en tiempo de ejecución para lograr algún
propósito. Cada elemento tiene algún rol definido en la colaboración.

Conceptos de estructura compuesta

Las entidades de estructura compuesta claves identificadas en la

especificación UML 2.0 son: clasificadores estructurados, partes, puertas,
conectores, y colaboraciones.

Parte

Una parte representa un rol jugado en tiempo de ejecución por una instancia de
una clase o por una colección de instancias. La parte puede nombrar
solamente un rol, una superclase abstracta, o puede nombrar una clase
concreta específica. La parte puede incluir un factor de multiplicidad
(cardinalidad), tal como el [0..*] mostrado para Viewer en el diagrama.

Puerta

Una puerta es un punto de interacción que puede ser usado para conectar
clasificadores estructurados con sus partes y con el ambiente. Las puertas
pueden opcionalmente especificar los servicios que proveen y los servicios que
requieren de otras partes del sistema. En el diagrama, cada uno de los
cuadrados pequeños es una puerta. Cada puerta tiene un tipo y esta etiquetado
con un nombre, tal como "var", "indVar1", or "view" en el diagrama. Las puertas
pueden contener un factor de multiplicidad, por ejemplo [3].

Las puertas pueden ya sea delegar los requerimientos recibidos a partes

internas, o pueden entregarlos directamente para el comportamiento del
clasificador estructurado en el que la puerta está contenido. Las puertas
públicas que son visibles en el ambiente son mostradas sobre el borde (límite o
frontera), mientras que las puertas protegidas que no son visibles en el
ambiente son mostradas dentro de la frontera (borde o límite). Todas las
puertas en el diagrama son privadas, excepto por la puerta view a lo largo del
límite derecho de FibonacciSystem.

Conector

Un conector une dos o más entidades, permitiéndoles interactuar en tiempo de

ejecución. Un conector es representado por una línea que une una
combinación de partes, puertas y

Colaboración
Una colaboración es generalmente más abstracta que un clasificador
estructurado. Ésta es mostrada como un óvalo sin relleno conteniendo los roles
que las instancias pueden jugar en la colaboración.

Clasificador estructurado

Un Clasificador Estructurado representa una clase, frecuentemente una clase

abstracta, cuyo comportamiento puede ser completa o parcialmente descrito
mediante interacciones entre partes.

Un Clasificador Encapsulado es un tipo de clasificador estructurado que

contiene puertas. En el diagrama abajo, ambos FibonacciSystem y Variable
son clasificadores encapsulados, porque ambos tienen puertas a lo largo de
sus límites.

Diagrama de paquetes muestra cómo un sistema está dividido en

agrupaciones lógicas mostrando las dependencias entre esas agrupaciones.
Dado que normalmente un paquete está pensado como un directorio, los
diagramas de paquetes suministran una descomposición de la jerarquía lógica
de un sistema.

Los Paquetes están normalmente organizados para maximizar la coherencia

interna dentro de cada paquete y minimizar el acoplamiento externo entre los
paquetes. Con estas líneas maestras sobre la mesa, los paquetes son buenos
elementos de gestión. Cada paquete puede asignarse a un individuo o a un
equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo
requerido.

Un ejemplo de diagrama de despliegue.

Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de
Modelado que se utiliza para modelar el hardware utilizado en las
implementaciones de sistemas y las relaciones entre sus componentes.

Los elementos usados por este tipo de diagrama son nodos (representados
como un prisma), componentes (representados como una caja rectangular con
dos protuberancias del lado izquierdo) y asociaciones.

En el UML 2.0 los componentes ya no están dentro de nodos. En cambio,

puede haber artefactos u otros nodos dentro de un nodo.

Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o

una base de datos construida o modificada en un proyecto. Estos artefactos
implementan colecciones de componentes. Los nodos internos indican
ambientes, un concepto más amplio que el hardware propiamente dicho, ya
que un ambiente puede incluir al lenguaje de programación, a un sistema
operativo, un ordenador o un cluster de terminales.

La mayoría de las veces el modelado de la vista de despliegue implica modelar

la topología del hardware sobre el que se ejecuta el sistema. Aunque UML no
es un lenguaje de especificación hardware de propósito general, se ha
diseñado para modelar muchos de los aspectos hardware de un sistema a un
nivel suficiente para que un ingeniero software pueda especificar la plataforma
sobre la que se ejecuta el software del sistema.

Usos

Algunos de los usos que se les da a los diagramas de despliegue son para
modelar:

 Sistemas empotrados: Un sistema empotrado es una colección de

hardware con una gran cantidad de software que interactúa con el
mundo físico.
 Sistemas cliente-servidor: Los sistemas cliente-servidor son un
extremo del espectro de los sistemas distribuidos y requieren tomar
decisiones sobre la conectividad de red de los clientes a los servidores y
sobre la distribución física de los componentes software del sistema a
través de nodos.
 Sistemas completamente distribuidos: En el otro extremo
encontramos aquellos sistemas que son ampliamente o totalmente
distribuidos y que normalmente incluyen varios niveles de servidores.
Tales sistemas contienen a menudo varias versiones de componentes
software, alguno de los cuales pueden incluso migrar de un nodo a otro.
El diseño de tales sistemas requiere tomar decisiones que permitan un
cambio continuo de la topología del sistema.

Diagramas de Comportamiento
Diagrama de actividades representa los flujos de trabajo paso a paso de
negocio y operacionales de los componentes en un sistema. Un Diagrama de
Actividades muestra el flujo de control general.

En SysML el diagrama de Actividades ha sido extendido para indicar flujos

entre pasos que mueven elementos físicos (e.g., gasolina) o energía (e.g.,
presión). Los cambios adicionales permiten al diagrama soportar mejor flujos
de comportamiento y datos continuos.

La especificación del Lenguaje de Modelado Unificado OMG define un

diagrama de actividad como: “… una variación de una máquina estados, lo cual
los estados representan el rendimiento de las acciones o subactividades y las
transiciones se provocan por la realización de las acciones o subactividades.” [1]
El propósito del diagrama de actividad es modelar un proceso de flujo de
trabajo (workflow) y/o modelar operaciones. Una Operación es un servicio
proporcionado por un objeto, que está disponible a través de una interfaz. Una
Interfaz es un grupo de operaciones relacionadas con la semántica.
Diagrama de casos de uso

El Lenguaje de Modelado Unificado define una notación gráfica para

representar casos de uso llamada modelo de casos de uso. UML no define
estándares para que el formato escrito describa los casos de uso, y así mucha
gente no entiende que esta notación gráfica define la naturaleza de un caso de
uso; sin embargo una notación gráfica puede solo dar una vista general simple
de un caso de uso o un conjunto de casos de uso. Los diagramas de casos
de uso son a menudo confundidos con los casos de uso. Mientras los dos
conceptos están relacionados, los casos de uso son mucho más detallados que
los diagramas de casos de uso.

Diagramas de Casos de Uso UML

El estándar de Lenguaje de Modelado Unificado de OMG define una notación

gráfica para realizar diagramas de casos de uso, pero no el formato para
describir casos de uso. Mucha gente sufre la equivocación pensando que un
caso de uso es una notación gráfica (o es su descripción). Mientras la notación
gráfica y las descripciones son importantes, ellos forman parte de la
documentación de un caso de uso --un propósito para el que el actor puede
usar el sistema.

 La descripción escrita del comportamiento del sistema al afrontar una

tarea de negocio o un requisito de negocio. Esta descripción se enfoca
en el valor suministrado por el sistema a entidades externas tales como
usuarios humanos u otros sistemas.

 La posición o contexto del caso de uso entre otros casos de uso. Dado
que es un mecanismo de organización, un conjunto de casos de uso
coherentes, consistentes promueve una imagen fácil del comportamiento
 del sistema, un entendimiento común entre el cliente/propietario/usuario
y el equipo de desarrollo.

Relaciones de Casos de Uso

Las tres relaciones principales entre los casos de uso son soportadas por el
estándar UML, el cual describe notación gráfica para esas relaciones.

Inclusión (include o use)

Es una forma de interacción o creación, un caso de uso dado puede "incluir"

otro. El primer caso de uso a menudo depende del resultado del caso de uso
incluido. Esto es útil para extraer comportamientos verdaderamente comunes
desde múltiples casos de uso a una descripción individual, desde el caso de
uso que lo incluye hasta el caso de uso incluido, con la etiqueta "«include»".
Este uso se asemeja a una expansión de una macro, donde el comportamiento
del caso incluido es colocado dentro del comportamiento del caso de uso base.
No hay parámetros o valores de retorno.

Extensión (Extend)

Es otra forma de interacción, un caso de uso dado, (la extensión) puede

extender a otro. Esta relación indica que el comportamiento del caso de uso
extensión puede ser insertado en el caso de uso extendido bajo ciertas
condiciones. La notación, es una flecha de punta abierta con línea discontinua,
desde el caso de uso extensión al caso de uso extendido, con la etiqueta
«extend». Esto puede ser útil para lidiar con casos especiales, o para
acomodar nuevos requisitos durante el mantenimiento del sistema y su
extensión. La extensión se utiliza en casos de uso, un caso de uso a otro caso
siempre debe tener extensión o inclusión.

"La extensión, es el conjunto de objetos a los que se aplica un concepto. Los

objetos de la extensión son los ejemplos o instancias de los conceptos."

Generalización

En la tercera forma de relaciones entre casos de uso, existe una relación

generalización/especialización. Un caso de uso dado puede estar en una forma
especializada de un caso de uso existente. La notación es una línea sólida
terminada en un triángulo dibujado desde el caso de uso especializado al caso
de uso general. Esto se asemeja al concepto orientado a objetos de sub-
clases, en la práctica puede ser útil factorizar comportamientos comunes,
restricciones al caso de uso general, describirlos una vez, y enfrentarse a los
detalles excepcionales en los casos de uso especializados.

"Entonces la Generalización es la actividad de identificar elementos en común

entre conceptos y definir las relaciones de una superclase (concepto general) y
subclase (concepto especializado). Es una manera de construir clasificaciones
taxonómicas entre conceptos que entonces se representan en jerarquías de
clases. Las subclases conceptuales son conformes con las superclases
conceptuales en cuanto a la intención y extensión."

Diagrama de estados es un diagrama utilizado para identificar cada una de las

rutas o caminos que puede tomar un flujo de información luego de ejecutarse
cada proceso.

SOLICITAR VERIFICAR UBICACION

INICIO BOLETA USUARIO USUARIO

COMPROBACION ENTRADA DEL REGISTRO DE VENTA DE

TAQUILLA USUARIO VENTA BOLETA

AUTORIZAR FIN
INICIO FUNCION
ENTRADA

Permite identificar bajo qué argumentos se ejecuta cada uno de los procesos y
en qué momento podrían tener una variación.

El diagrama de estados permite visualizar de una forma secuencial la ejecución

de cada uno de los procesos.

El diagrama de secuencia es un tipo de diagrama usado para modelar

interacción entre objetos en un sistema según UML. En inglés se pueden
encontrar como "sequence diagram", "event-trace diagrams", "event scenarios"
o "timing diagrams"[1]
Ejemplo de Diagrama de Secuencia

Diagrama de secuencia muestra la interacción de un conjunto de objetos en

una aplicación a través del tiempo y se modela para cada caso de uso.
Mientras que el diagrama de casos de uso permite el modelado de una vista
business del escenario, el diagrama de secuencia contiene detalles de
implementación del escenario, incluyendo los objetos y clases que se usan
para implementar el escenario, y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué

objetos son necesarios para la implementación del escenario. Si se dispone de
la descripción de cada caso de uso como una secuencia de varios pasos,
entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son
necesarios para que se puedan seguir los pasos. Un diagrama de secuencia
muestra los objetos que intervienen en el escenario con líneas discontinuas
verticales, y los mensajes pasados entre los objetos como flechas horizontales.

Tipos de mensajes

Existen dos tipos de mensajes: síncronicos y asíncronicos. Los mensajes

síncronicos se corresponden con llamadas a métodos del objeto que recibe el
mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la
llamada. Este tipo de mensajes se representan con flechas con la cabeza llena.
Los mensajes asíncronicos terminan inmediatamente, y crean un nuevo hilo de
ejecución dentro de la secuencia. Se representan con flechas con la cabeza
abierta.

También se representa la respuesta a un mensaje con una flecha discontinua.

Pueden ser usados en dos formas

 De instancia: describe un escenario especifico (un escenario es una

instancia de la ejecución de un caso de uso).
 Genérico: describe la interacción para un caso de uso; Utiliza
ramificaciones ("Branches"), condiciones y bucles.
Estructura

Los mensajes se dibujan cronológicamente desde la parte superior del

diagrama a la parte inferior; la distribución horizontal de los objetos es
arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre
'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño,
el nombre 'business' es reemplazado con el nombre del método que está
siendo llamado por un objeto en el otro. El método llamado, o invocado,
pertenece a la definición de la clase instanciada por el objeto en la recepción
final del mensaje

Diagrama de comunicación es una versión simplificada del diagrama de

colaboración de la versión de UML 1.x.

Un diagrama de comunicación modela las interacciones entre objetos o partes

en términos de mensajes en secuencia. Los diagramas de comunicación
representan una combinación de información tomada desde el diagrama de
clases, secuencia, y diagrama de casos de uso describiendo tanto la estructura
estática como el comportamiento dinámico de un sistema.

Los diagramas de comunicación y de secuencia describen información similar,

y con ciertas transformaciones, pueden ser transformados unos en otros sin
dificultad.

Para mantener el orden de los mensajes en un diagrama de comunicación, los

mensajes son etiquetados con un número cronológico y colocado cerca del
enlace por el cual se desplaza el mensaje. Leer un diagrama de comunicación
conlleva comenzar en el mensaje 1.0, y seguir los mensajes desde un objeto
hasta el siguiente, sucesivamente

Diagrama de tiempos o cronograma es una gráfica de formas de onda

digitales que muestra la relación temporal entre varias señales, y cómo varía
cada señal en relación a las demás.
Un cronograma puede contener cualquier número de señales relacionadas
entre sí. Examinando un diagrama de tiempos, se puede determinar los
estados, nivel alto o nivel bajo, de cada una de las señales en cualquier
instante de tiempo especificado, y el instante exacto en que cualquiera de las
señales cambia de estado con respecto a las restantes.

El propósito primario del diagrama de tiempos es mostrar los cambios en el

estado o la condición de una línea de vida (representando una Instancia de un
Clasificador o un Rol de un clasificador) a lo largo del tiempo lineal. El uso más
común es mostrar el cambio de estado de un objeto a lo largo del tiempo, en
respuesta a los eventos o estímulos aceptados. Los eventos que se reciben se
anotan, a medida que muestran cuándo se desea mostrar el evento que causa
el cambio en la condición o en el estado.

En el estándar de Lenguaje de Modelado Unificado de OMG los diagramas de

tiempo son una representación especial de interacción que se enfoca en el
tiempo de los mensajes enviados entre objetos. Se pueden usar estos
diagramas para mostrar restricciones detalladas sobre el tiempo, ó para
mostrar los cambios con líneas de vida respecto al tiempo. Los diagramas de
tiempo son generalmente utilizados con sistemas en tiempo real o en sistemas
embebidos.

Diagrama global de las interacciones (en inglés: interaction overview

diagram) es una de las trece clases de diagramas en el Lenguaje de Modelado
Unificado (UML), un lenguaje de modelamiento para software y otros sistemas.

El diagrama global de las interacciones es un diagrama de comportamiento,

más precisamente, uno de los cuatro diagramas de interacción. Muestra una
cierta vista sobre los aspectos dinámicos de los sistemas modelados. Aunque
un diagrama global de las interacciones es una representación gráfica de una
interacción, éste se distingue fuertemente de los diagramas de secuencia y de
comunicación, dos de los otros diagramas de interacción. De hecho, algunos
elementos gráficos del diagrama global de las interacciones están tomados del
diagrama de actividades, otro diagrama de comportamiento para el modelado
de actividades.

Los modelos de interacción pueden llegar a ser muy grandes para sistemas
complejos. Si el número de líneas de vida participantes y el número de
mensajes intercambiados excede una cierta medida, se impone “modularizar”
las interacciones y dividir en partes pequeñas, más manejables, de acuerdo a
principios universales del diseño de sistemas, que también pueden ser
visualizadas con la ayuda de un clásico diagrama de secuencias. La visión de
conjunto de toda la interacción, de manera que la Big Picture o bien el cuadro
global, puede entonces ser representada con la ayuda del diagrama global de
las interacciones, provisto para eso.

HISTORIA DE UML

El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh

se unió a la compañía Rational fundada por Booch (dos reputados
investigadores en el área de metodología del software).

El objetivo de ambos era unificar dos métodos que habían desarrollado: el

método Booch y el OMT (Object Modelling Tool ). El primer borrador apareció
en octubre de 1995. En esa misma época otro reputado investigador,
Jacobson, se unió a Rational y se incluyeron ideas suyas. Estas tres personas
son conocidas como los “tres amigos”. Además, este lenguaje se abrió a la
colaboración de otras empresas para que aportaran sus ideas. Todas estas
colaboraciones condujeron a la definición de la primera versión de UML

Es un lenguaje de modelado visual que se usa para especificar, visualizar,

construir y documentar artefactos de un sistema de software. Se usa para
entender, diseñar, configurar, mantener y controlar la información sobre los
sistemas a construir.

UML capta la información sobre la estructura estática y el comportamiento

dinámico de un sistema. Un sistema se modela como una colección de objetos
discretos que interactúan para realizar un trabajo que finalmente beneficia a un
usuario externo.

El lenguaje de modelado pretende unificar la experiencia pasada sobre

técnicas de modelado e incorporar las mejores prácticas actuales en un
acercamiento estándar.

UML no es un lenguaje de programación. Las herramientas pueden ofrecer

generadores de código de UML para una gran variedad de lenguaje de
programación, así como construir modelos por ingeniería inversa a partir de
programas existentes.

La notación UML se deriva y unifica las tres metodologías de análisis y diseños

más extendidas.

Metodología de Grady Booch para la descripción de conjuntos de objetos y sus

relaciones.
Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object -
Modelling Technique).

Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software

Engineering) mediante la metodología de casos de uso (use case).

El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim

Rumbaugh de Rational Software Corporation empezaron a unificar sus
métodos. A finales de 1995, Ivar Jacob son y su compañía Objectory se
incorporaron a Rational en su unificación, aportando el método OOSE.

De las tres metodologías 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 relación y
colaboración.

Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que

todo en su método se deriva de los escenarios de uso. UML se ha ido
fomentando y aceptando como estándar desde el OMG, que es también el
origen de CORBA, el estándar líder en la industria para la programación de
objetos distribuidos.

En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación

estándar de facto para el análisis y el diseño orientado a objetos.

UML es el primer método en publicar un meta-modelo en su propia notación,

incluyendo la notación para la mayoría de la información de requisitos, análisis
y diseño. Se trata pues de un meta-modelo auto-referencial (cualquier lenguaje
de modelado de propósito general debería ser capaz de modelarse a sí
mismo).

RAZONES DE SU IMPORTANCIA

UML es el primer método en publicar una meta-modelo en su propia notación,

incluyendo la notación para la mayoría de la información de requisitos, análisis
y diseño. Se trata pues de un meta-modelo auto-referencial (cualquier lenguaje
de modelado de propósito general debería ser capaz de modelarse a sí
mismo).
 Durante el desarrollo del UML sus autores tuvieron en cuenta

 Proporcionar una notación y semánticas suficientes para poder alcanzar

una gran cantidad de aspectos del modelado contemporáneo de una
forma directa y económica.

Proporcionar las semánticas suficientes para alcanzar aspectos del
 modelado que son de esperar en un futuro, como por ejemplo aspectos
relacionados con la tecnología de componentes, el cómputo distribuido,
etc.

Proporcionar mecanismos de extensión de forma que proyectos
concretos puedan extender el meta-modelo a un coste bajo.

Proporcionar mecanismos de extensión de forma que aproximaciones de
modelado futuras podrían desarrollarse encima del UML.

Permitir el intercambio de los modelos entre una gran variedad de
herramientas.

Proporcionar semánticas suficientes para especificar las interfaces a
bibliotecas para la comparación y el almacenamiento de componentes
del modelo.


Ser tan simple como sea posible pero manteniendo la capacidad de

modelar toda la gama de sistemas que se necesita construir.

UML es un lenguaje de modelado de propósito general que pueden usar
todos los modeladores.

UML no pretende ser un método de desarrollo completo.

Debe ser un lenguaje universal, como cualquier lenguaje de propósito
general.
Imponer un estándar mundial.

Mediante el fomento del uso de UML OMG pretende alcanzar los siguientes
objetivos:

 Proporcionar a los usuarios un lenguaje de modelado visual expresivo y

utilizable para el desarrollo e intercambio de modelos significativos.

Proporcionar mecanismos de extensión y especialización.

Ser independiente del proceso de desarrollo y de los lenguajes de
programación.

Proporcionar una base formal para entender el lenguaje de modelado.
 Fomentar el crecimiento del mercado de las herramientas OO.
  Soportar conceptos de desarrollo de alto nivel como pueden ser
colaboraciones, frameworks, patterns, y componentes, Integrar las
mejores prácticas utilizadas hasta el momento.

ABSTRACTO DE DATOS

Un tipo de dato abstracto (TDA) o Tipo abstracto de datos (TAD) es un

modelo matemático compuesto por una colección de operaciones definidas
sobre un conjunto de datos para el modelo.

En el mundo de la programación existen diversos lenguajes que se han ido

creando con el paso del tiempo y que se han perfeccionado debido a las
necesidades de los programadores de la época a la que pertenecen. Los
primeros lenguajes de programación eran de tipo lineal, ya que un programa se
recorría desde un punto marcado como Inicio hasta llegar a un punto Fin. Con
el tiempo se fueron creando nuevos lenguajes y en nuestros días los más
utilizados son los llamados “Orientados a Objetos”.

Los Lenguajes Orientados a Objetos (LOO) tienen la característica de que no

son lenguajes lineales, sino que se forman de diversas funciones, las cuales
son llamadas en el orden en que el programa mismo las pide o el usuario
determina. Para entender mejor cómo funcionan los Lenguajes Orientados a
Objetos, vamos a introducir un concepto fundamental en las Estructuras de
Datos denominado Abstracción de Datos y que es parte importante de estos
Lenguajes y de la manera en que funciona la mayoría del software comercial
de nuestros días.

POLIMOSRFISMO

En programación orientada a objetos el polimorfismo se refiere a la capacidad

para que varias clases derivadas de una antecesora utilicen un mismo método
de forma diferente.

Por ejemplo, podemos crear dos clases distintas: Pez y Ave que heredan de la
superclase Animal. La clase Animal tiene el método abstracto mover que se
implementa de forma distinta en cada una de las subclases (peces y aves se
mueven de forma distinta).

Como se mencionó anteriormente, el concepto de polimorfismo se puede

aplicar tanto a funciones como a tipos de datos. Así nacen los conceptos de
funciones polimórficas y tipos polimórficos. Las primeras son aquellas
funciones que pueden evaluarse o ser aplicadas a diferentes tipos de datos de
forma indistinta; los tipos polimórficos, por su parte, son aquellos tipos de datos
que contienen al menos un elemento cuyo tipo no está especificado.
Se puede clasificar el polimorfismo en dos grandes clases:

 Polimorfismo dinámico (o polimorfismo paramétrico) es aquél en el

que el código no incluye ningún tipo de especificación sobre el tipo de
datos sobre el que se trabaja. Así, puede ser utilizado a todo tipo de
datos compatible.
 Polimorfismo estático (o polimorfismo ad hoc) es aquél en el que los
tipos a los que se aplica el polimorfismo deben ser explicitados y
declarados uno por uno antes de poder ser utilizados.

El polimorfismo dinámico unido a la herencia es lo que en ocasiones se conoce

como programación genérica.

También se clasifica en herencia por redefinición de métodos abstractos y por

método sobrecargado. El segundo hace referencia al mismo método con
diferentes parámetros.

Otra clasificación agrupa los polimorfismo en dos tipos: Ad-Hoc que incluye a
su vez sobrecarga de operadores y coerción, Universal (inclusión o controlado
por la herencia, paramétrico o genericidad).

Ejemplo de polimorfismo

En este ejemplo haremos uso del lenguaje C++ para mostrar el polimorfismo.
También se hará uso de las funciones virtuales puras de este lenguaje, aunque
para que el polimorfismo funcione no es necesario que las funciones sean
virtuales puras, es decir, perfectamente el código de la clase "superior" (en
nuestro caso Empleado) podría tener código

#include<iostream>
using namespace std;

class figura {
public:
float base;
float altura;
public:
float captura();
virtual unsigned float perimetro()=0;
virtual unsigned float area()=0;
};

class rectangulo: public figura{

public:
void imprime();
unsigned float perimetro(){return 2*(base+altura);}
unsigned float area(){return base*altura;}
};

class triangulo: public figura{

public:
 void muestra();
unsigned float perimetro(){return 2*altura+base}
unsigned float area(){return (base*altura)/2;}
};

void figura::captura(){
cout<<"CALCULO DEL AREA Y PERIMETRO DE UN TRIANGULO
ISÓSCELES Y UN RECTANGULO:" <<endl;
cout<<"escribe la altura: ";
cin>>altura;
cout<<"escribe la base: ";
cin>>base;
cout<<"EL PERIMETRO ES:" << perimetro();
cout<<"EL AREA ES:" << area();
};

Analicemos ahora el código para entender el polimorfismo expuesto en la

interfaz: La interfaz expone un método que puede ser implementado por las
diferentes clases, normalmente relacionadas entre si. Las clases Sumar y
Restar implementan la interfaz pero el método de la interfaz lo declaramos
privado para evitar ser accedido libremente y además tienen un método
llamado Calcular que llama a la clase Operacion donde tenemos otro método
con el mismo nombre. Es esta clase última la que realiza el polimorfismo y
debe fijarse como es a través de una instancia de la interfaz que llama al
método operar. La interfaz sabe a qué método de qué clase llamar desde el
momento que asignamos un valor a la variable OP en el método Calcular de la
clase Operacion, que a se vez recibió la referencia del método Calcular desde
la clase que la llama, sea está cual sea se identifica a sí misma, mediante la
referencia Me ó This según el lenguaje empleado. Debe notarse que la
instancia de la interfaz accede a sus métodos aunque en sus clases se hayan
declarado privadas.

Diferencias entre polimorfismo y sobrecarga

 El polimorfismo como se muestra en el ejemplo anterior, suele ser

bastante ventajoso aplicado desde las interfaces, ya que permite crear
nuevos tipos sin necesidad de tocar las clases ya existentes
(imaginemos que deseamos añadir una clase Multiplicar), basta con
recompilar todo el código que incluye los nuevos tipos añadidos. Si se
hubiera recurrido a la sobrecarga durante el diseño exigiría retocar la
clase anteriormente creada al añadir la nueva operación Multiplicar, lo
que además podría suponer revisar todo el código donde se instancia a
la clase.

 La sobrecarga se da siempre dentro de una sola clase, mientras que el

polimorfismo se da entre clases distintas.

 Un método está sobrecargado si dentro de una clase existen dos o más

declaraciones de dicho método con el mismo nombre pero con
 parámetros distintos, por lo que no hay que confundirlo con
polimorfismo.

 En definitiva: La sobrecarga se resuelve en tiempo de compilación

utilizando los nombres de los métodos y los tipos de sus parámetros; el
polimorfismo se resuelve en tiempo de ejecución del programa, esto es,
mientras se ejecuta, en función de que clase pertenece un objeto.

HERENCIA

En orientación a objetos la herencia es el mecanismo fundamental para

implementar la reutilización y extensibilidad del software. A través de ella los
diseñadores pueden construir nuevas clases partiendo de una jerarquía de
clases ya existente (comprobadas y verificadas) evitando con ello el rediseño,
la re modificación y verificación de la parte ya implementada. La herencia
facilita la creación de objetos a partir de otros ya existentes, obteniendo
características (métodos y atributos) similares a los ya existentes.

Es la relación entre una clase general y otra clase más específica. Por ejemplo:
Si declaramos una clase párrafo derivada de una clase texto, todos los
métodos y variables asociadas con la clase texto, son automáticamente
heredados por la subclase párrafo.

La herencia es uno de los mecanismos de la programación orientada a objetos,

por medio del cual una clase se deriva de otra, llamada entonces superclase,
de manera que extiende su funcionalidad. Una de sus funciones más
importantes es la de proveer Polimorfismo y late binding.

Ejemplo en Java

public class Mamifero{

private int patas;
private String nombre;
public void imprimirPatas(){
JOptionPane.showMessageDialog(null," Tiene " + patas +
"patas\n","Mamifero",JOptionPane.INFORMATION_MESSAGE);
}
public Mamifero(String nombre, int patas){
this.nombre = nombre;
this.patas = patas;
}
}

public class Perro extends Mamifero {

public Perro(String nombre){
super(nombre, 4);
 }
}

public class Gato extends Mamifero {

public Gato(String nombre){
super(nombre, 4);
}
}

public class CrearPerro {

public static void main(String [] args) {
Perro perrito = new Perro("Canelita");
perrito.imprimirPatas(); /*Está en la clase mamífero*/
}
}

Se declaran las clases mamíferos, gato y perro, haciendo que gato y perro
sean unos mamíferos (derivados de esta clase), y se ve como a través de ellos
se nombra al animal pero así también se accede a patas dándole el valor por
defecto para esa especie.

Clase Abstracta

La herencia permite que existan clases que nunca serán instanciadas

directamente. En el ejemplo anterior, una clase "perro" heredaría los atributos y
métodos de la clase "mamífero", así como también "gato", "delfín" o cualquier
otra subclase; pero, en ejecución, no habrá ningún objeto "mamífero" que no
pertenezca a alguna de las subclases. En ese caso, a una clase así se la
conocería como Clase Abstracta. La ausencia de instancias específicas es su
única particularidad, para todo lo demás es como cualquier otra clase.

Herencia y ocultación de información

El diseñador puede definir qué variables de instancia y métodos de los objetos

de una clase son visibles. En C++ y java esto se consigue con las
especificaciones private, protected y public. Sólo las variables y métodos
definidos como públicos en un objeto serán visibles por todos los objetos.

En cuanto a las subclases, que heredan las estructuras de las superclases, el

diseñador puede controlar qué miembros de las superclases son visibles en las
subclases. En el caso de java y C++ los especificadores de acceso (private,
protected, public) de los miembros de la superclase afectan también a la
herencia:

 Private: ningún miembro privado de la superclase es visible en la

subclase.

 Protected: los miembros protegidos de la superclase son visibles en la

subclase, pero no visibles para el exterior.
  Public: los miembros públicos de la superclase siguen siendo públicos
en la subclase.

Redefinición de métodos

En la clase derivada se puede redefinir algún método ya definido en la clase

base. Para redefinir un método en la subclase, basta con declarar una función
miembro con el mismo nombre. Si en una clase en particular se invoca a un
método, y el método no está definido en la misma, es buscado
automáticamente en las clases superiores. Sin embargo, si existieran dos
métodos con el mismo nombre y distinto código, uno en la clase y otro en una
superclase, se ejecutaría el de la clase, no el de la superclase.

Por lo general, siempre se puede acceder explícitamente al método de la clase

superior mediante una sintaxis diferente, la cual dependerá del lenguaje de
programación empleado.

Ventajas

 Ayuda a los programadores ahorrar código y tiempo, ya que si tiene una

clase lista es solo de implementarla y listo todo el código de esta se
resume a solo un llamado.

 Los objetos pueden ser construidos a partir de otros similares. Para ello
es necesario que exista una clase base y una jerarquía
(relacionamiento) de clases.

 La clase derivada puede heredar código y datos de la clase base,

añadiendo código o modificando lo heredado.

 Las clases que heredan propiedades de otra clase pueden servir como
clase base de otras.

Estereotipos de herencia

 Herencia simple: Un objeto puede extender las características de otro

objeto y de ningún otro, es decir, que solo puede heredar o tomar
atributos de un solo padre o de una sola clase.

 Herencia múltiple: Un objeto puede extender las características de uno o

más objetos, es decir, puede tener varios padres. En este aspecto hay
discrepancias entre los diseñadores de lenguajes. Algunos de ellos han
preferido no admitir la herencia múltiple por las posibles coincidencias en
nombres de métodos o datos miembros. Por ejemplo C++, Python
permiten herencia múltiple, mientras que Java, Ada y C# sólo permiten
herencia simple.
 conclusiones

 Los diagramas se utilizan para representar diferentes perspectivas de un

sistema de forma que un diagrama es una proyección del mismo. UML
proporciona un amplio conjunto de diagramas que normalmente se usan
en pequeños subconjuntos para poder representar las cinco vistas
principales de la arquitectura de un sistema.

 El UML debe entenderse como un estándar para modelado y no como

un estándar de proceso software. Aunque UML debe ser aplicado en el
contexto de un proceso, la experiencia ha mostrado que organizaciones
diferentes y dominios del problema diferentes requieren diferentes
procesos. Como de modelado visual que se usa para especificar,
visualizar, construir y documentar artefactos de un sistema de software.
Se usa para entender, diseñar, configurar, mantener y controlar la
información sobre los sistemas a construir.

 El polimorfismo es otro de los pilares fundamentales de la programación

orientada a objetos. Es la capacidad de almacenar objetos de un
determinado tipo en variables de tipos antecesores del primero a costa,
claro está, de sólo poderse acceder a través de dicha variable a los
miembros comunes a ambos tipos.