UNIDAD II

TÉCNICAS BASICAS DE MODELADO DE OBJETOS.

Cuando se trabaja para construir un producto o un

sistema, es importante seguir una serie de pasos predecibles.

La técnica que adoptemos depende del software que

estemos construyendo. Un proceso puede ser apropiado para
crear un software de un sistema de aviación, mientras que un
proceso diferente por completo puede ser adecuado para la
creación de un sitio Web.

Para adentrarnos en el tema vamos primeramente a dar estas definiciones:

 Técnica: es Conjunto de procedimientos y recursos de que se sirve una
ciencia o un arte.
 Modelado: es una técnica que ayuda a “visualizar” el sistema a construir.
 Objeto: Un objeto es una representación detallada, concreta y particular de
un “algo”. Tal representación determina su identidad, su estado y su
comportamiento particular en un momento dado.

Entonces podemos decir que una técnica de modelado de objetos es un conjunto

de procedimientos para visualizar una serie de características asignadas a un objeto.

En nuestro tema, la tecnología orientada a objetos propone una forma de pensar

de modo abstracto acerca de problemas a resolver empleando conceptos del mundo
real y no conceptos de computadoras. La notación gráfica propuesta ayuda al
desarrollo de software visualizando el problema sin recurrir en forma prematura a la
implementación.

La técnica de Modelado de Objetos (Object Modeling Technique- OMT) se basa

en un conjunto de conceptos que definen que es Orientación a Objetos y una
notación gráfica independiente.

La técnica de Modelado Orientado a Objetos se funda en pensar en los

problemas a resolver empleando modelos que se han organizado tomando como
base conceptos del mundo real. La unidad básica es el objeto que combina las
estructuras de datos con los comportamientos en una entidad única.

OMT es una metodología (y una notación gráfica) para el desarrollo orientado a

objetos que se extiende desde el análisis hasta la implementación pasando por el
diseño.

Esta metodología consta de las siguientes fases:

 Análisis: Se construye un modelo de la situación del mundo real que muestra
sus propiedades (aspectos) importantes sin tener en cuenta la
implementación eventual. El analista debe trabajar con quien hace la solicitud
para comprender el problema porque las definiciones del mismo no suelen ser
completas ni correctas. El modelo de análisis es una abstracción resumida y
precisa de lo que debe hacer el sistema deseado y no de la forma en que se
hará. Los objetos del modelo deberán ser conceptos del dominio de la
aplicación y no conceptos de implementación de la computadora tales como
estructuras de datos. Un buen modelo podrá ser comprendido y criticado por
expertos de la aplicación que no sean programadores. El modelo de análisis
no deberá contener ninguna decisión de implementación, los objetos se
describirán en términos de atributos y operaciones que son visibles para el
usuario.
 Diseño del sistema: se toman decisiones de alto nivel acerca de la
arquitectura global. Durante el diseño, el sistema de destino se organiza en
subsistemas basados tanto en la estructura del análisis como en la
arquitectura propuesta. El diseñador de sistemas deberá decidir qué
características de rendimiento hay que optimizar. Seleccionando una
estrategia para atacar el problema y efectuando las reservas de recursos
tentativas.
 Diseño de objetos: se construye un modelo de diseño basándose en el
modelo de análisis que lleven incorporados detalles de implementación. El
diseñador añade detalles al modelo de acuerdo con la estrategia establecida
durante el diseño del sistema. El foco de atención del diseño de objetos son
las estructuras de datos y los algoritmos necesarios para implementar cada
una de las clases. Las clases de objetos procedentes del análisis siguen
siendo significativas pero se aumentan con estructuras de datos y algoritmos
del dominio de la computadora seleccionados para optimizar medidas
importantes de rendimiento. Tanto los objetos del dominio de la aplicación
como los objetos del dominio de la computadora se describen utilizando unos
mismos conceptos y una misma notación orientados a objetos aún cuando
existan en planos conceptuales diferentes.
 Implementación: las clases de objetos y las relaciones desarrolladas durante
su diseño se traducen finalmente a un lenguaje de programación concreto, a
una base de datos o a una implementación en hardware. La programación
debería ser una parte relativamente pequeña del ciclo de desarrollo y
fundamentalmente mecánica porque todas las decisiones importantes deberán
hacerse durante el diseño. El lenguaje de destino influye en cierta medida
sobre las decisiones de diseño pero éste no debería depender de la estructura
final de un lenguaje de programación. Durante la implementación es
importante respetar las ideas de la ingeniería del software, de tal manera que
 el seguimiento hasta el diseño sea sencillo y de tal forma que el sistema
implementado siga siendo flexible y extensible.
Es posible aplicar conceptos orientados a objetos a lo largo del todo el ciclo de
vida de desarrollo del sistema, desde el análisis hasta la implementación pasando
por el diseño. Se pueden traspasar las mismas clases de una etapa a otra sin
modificar la notación aunque ganarán detalles adicionales de implementación en las
etapas posteriores. Siendo el punto de vista de análisis y el de implementación de
‘‘Ventana’’ correctos tienen propósitos distintos y representan grados de abstracción.
Los mismos conceptos orientados a objetos de identidad, clasificación, polimorfismo
y herencia son aplicables a todo el ciclo de desarrollo completo.

El beneficio principal del desarrollo orientado a objetos no es reducir el tiempo de

desarrollo; el desarrollo orientado a objetos puede requerir más tiempo que el
desarrollo convencional porque se pretende que promueva la reutilización futura y la
reducción de los posteriores errores y el futuro mantenimiento. El tiempo transcurrido
hasta que el código se completa por primera vez es posiblemente el mismo que el
transcurrido en una aproximación convencional o, quizás ligeramente mayor. El
beneficio del desarrollo orientado a objetos consiste en que las iteraciones
subsiguientes son más rápidas y más fáciles que empleando un desarrollo
convencional porque las revisiones están más localizadas. La práctica muestra que
suelen ser necesarias menos iteraciones porque se descubren y se corrigen más
problemas durante el desarrollo.

2.1 DEFINICION DE CLASES, ATRIBUTOS, METODOS Y OBJETOS

Clase

Es una abstracción que describe propiedades importantes para una aplicación y

que ignora el resto. La selección de clases es arbitraria y depende de la aplicación.
Una clase contienen el molde (estructura, esquema) a partir del cual se crean los
objetos que pertenecen a ella y el código que debe ejecutarse cada vez que un
objeto de la clase recibe un mensaje. Una clase contiene la descripción de las
características comunes de todos los objetos que pertenecen a ella: la especificación
del comportamiento, la definición de la estructura interna y la implementación de los
métodos.

Atributos

Los atributos son las características individuales que diferencian un objeto de otro
y determinan su apariencia, estado u otras cualidades. Los atributos se guardan en
variables denominadas de instancia, y cada objeto particular puede tener valores
distintos para estas variables.

Las variables de instancia también denominados miembros dato, son declaradas

en la clase pero sus valores son fijados y cambiados en el objeto.

Además de las variables de instancia hay variables de clase, las cuales se aplican
a la clase y a todas sus instancias. Por ejemplo, el número de ruedas de un
automóvil es el mismo cuatro, para todos los automóviles.

Métodos

Una operación que realiza acceso a los datos. Podemos definir método como un
programa procedimental o procedural escrito en cualquier lenguaje, que está
asociado a un objeto determinado y cuya ejecución sólo puede desencadenarse a
través de un mensaje recibido por éste o por sus descendientes.

Son sinónimos de 'método' todos aquellos términos que se han aplicado

tradicionalmente a los programas, como procedimiento, función, rutina, etc. Sin
embargo, es conveniente utilizar el término 'método' para que se distingan
claramente las propiedades especiales que adquiere un programa en el entorno
OOP, que afectan fundamentalmente a la forma de invocarlo (únicamente a través de
un mensaje) y a su campo de acción, limitado a un objeto y a sus descendientes,
aunque posiblemente no a todos.

Si los métodos son programas, se deduce que podrían tener argumentos, o

parámetros. Puesto que los métodos pueden heredarse de unos objetos a otros, un
objeto puede disponer de un método de dos maneras diferentes:
 Métodos propios. Están incluidos dentro de la cápsula del objeto.
 Métodos heredados.

Objetos

Objeto es el concepto clave de la Programación Orientada a Objetos, la idea de

objeto es similar a la del mundo real, un objeto puede ser una silla, una mesa. Tu
perro es un objeto.

Los objetos tienen dos características: Un estado y un comportamiento. Fíjate que

por ejemplo tu perro tiene un estado: nombre, color, raza, altura, etc. y un
comportamiento: ladrar, cavar pozo, llorar, dormir, comer, etc.

Un auto es un objeto. También tiene un estado: Cantidad de puertas, color,

tamaño, etc. y un comportamiento: acelerar, frenar, subir cambio, bajar cambio, girar
izq., girar der., etc.

Entonces podemos definir a un objeto en POO, como un conjunto de datos y

funciones relacionadas. A las funciones de los objetos, tales como acelerar en el
caso del auto, de aquí en más las llamaremos métodos, a los datos los llamaremos
atributos.
 Los objetos en programación, son modelados observando objetos del mundo real,
por ejemplo implementamos el objeto "perro" dentro de nuestro programa definiendo
los atributos y métodos del objeto perro real.

2.2 EL MODELO COMO RESULTADO DE LA ABSTRACCIÓN

Un modelo es una abstracción de algo, que se elabora para comprender ese algo
antes de construirlo. El modelo omite detalles que no resultan esenciales para la
comprensión del original y por lo tanto facilita dicha comprensión.

Los modelos se utilizan en muchas actividades de la vida humana: antes de

construir una casa el arquitecto utiliza un plano, los músicos representan la música
en forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos
antes de empezar a utilizar los óleos, etc. Unos y otros abstraen una realidad
compleja sobre unos bocetos, modelos al fin y al cabo. La OMT, por ejemplo, intenta
abstraer la realidad utilizando tres clases de modelos OO: el modelo de objetos, que
describe la estructura estática; el modelo dinámico, con el que describe las
relaciones temporales entre objetos; y el modelo funcional que describe las
relaciones funcionales entre valores. Mediante estas tres fases de construcción de
modelos, se consigue una abstracción de la realidad que tiene en sí misma
información sobre las principales características de ésta.

Los modelos además, al no ser una representación que incluya todos los detalles
de los originales, permiten probar más fácilmente los sistemas que modelan y
determinar los errores. Según se indica en la Metodología OMT (Rumbaugh), los
modelos permiten una mejor comunicación con el cliente por distintas razones:
 Es posible enseñar al cliente una posible aproximación de lo que será el
producto final.
  Proporcionan una primera aproximación al problema que permite visualizar
cómo quedará el resultado.
 Reducen la complejidad del original en subconjuntos que son fácilmente
tratables por separado.

Se consigue un modelo completo de la realidad cuando el modelo captura los

aspectos importantes del problema y omite el resto. Los lenguajes de programación
que estamos acostumbrados a utilizar no son adecuados para realizar modelos
completos de sistemas reales porque necesitan una especificación total con detalles
que no son importantes para el algoritmo que están implementando. En OMT se
modela un sistema desde tres puntos de vista diferentes donde cada uno representa
una parte del sistema y una unión lo describe de forma completa. En esta técnica de
modelado se utilizó una aproximación al proceso de implementación de software
habitual donde se utilizan estructuras de datos (modelo de objetos), las operaciones
que se realizan con ellos tienen una secuencia en el tiempo (modelo dinámico) y se
realiza una transformación sobre sus valores (modelo funcional).

Existe un lenguaje de modelado llamado UML (El UML es una técnica de

modelado de objetos y como tal supone una abstracción de un sistema para llegar a
construirlo en términos concretos. El modelado no es más que la construcción de un
modelo a partir de una especificación.), el cual utiliza parte de este planteamiento
obteniendo distintos puntos de vista de la realidad que modela mediante los distintos
tipos de diagramas que posee.

Con la creación del UML se persigue obtener un lenguaje que sea capaz de
abstraer cualquier tipo de sistema, sea informático o no, mediante los diagramas, es
decir, mediante representaciones gráficas que contienen toda la información
relevante del sistema. Un diagrama es una representación gráfica de una colección
de elementos del modelo, que habitualmente toma forma de grafo donde los arcos
que conectan sus vértices son las relaciones entre los objetos y los vértices se
corresponden con los elementos del modelo. Los distintos puntos de vista de un
sistema real que se quieren representar para obtener el modelo se dibuja dé forma
que se resaltan los detalles necesarios para entender el sistema.

Principios de Modelado

En cualquier proyecto de ingeniería como la construcción de un gran edificio, un

avión, una represa hidroeléctrica, la construcción de un procesador de textos o un
software de comunicaciones para Internet, requieren de etapas de modelado que
permitan experimentar y visualizar el sistema que se construirá. De la experiencia en
ingeniería se extractan los siguientes principios de modelado:
a) La forma como vemos el problema tiene una profunda influencia en forma
como acometemos el problema y le damos solución al mismo. Si pensamos
que el mundo esta compuesto de clases (Abstracciones de la realidad y de la
solución del problema) y objetos (instancias de éstas abstracciones) que
interactúan entre si para realizar una funcionalidad, así veremos el mundo.
Este es precisamente al paradigma a que le apuesta UML: el modelo
orientado a objetos. Si vemos la realidad como compuesta de procesos donde
cada uno a su vez se puede descomponer en subprocesos entonces estamos
concibiendo la realidad según el modelo estructurado y la arquitectura del
sistema en desarrollo estará conformada de programas y subprogramas.
b) Para modelar un sistema complejo no es suficiente un único modelo se
requieren múltiples modelos donde cada uno representa una vista (aspecto)
del sistema; estos modelos se complementan entre si. Esta es la razón de la
existencia de varios diagramas en UML que modelan diferentes aspectos del
sistema, desde las vistas lógicas y físicas del sistema hasta los aspectos
dinámicos, estáticos y funcionales del mismo.
c) Cualquier modelo puede ser representado con diferentes grados de precisión.
La precisión se puede ver desde dos ópticas: La primera es el grado de detalle
con que se representa un modelo; por ejemplo, si lo que se desea es razonar
 acerca de los requerimientos del sistema con un cliente o usuario final, se
puede elaborar un diagrama de clases que muestra las clases, sus atributos y
operaciones así como varios adornos(multiplicidad) en las relaciones; por otro
lado, si lo que se desea es transmitir el diagrama de clases para que sea
implementado en un DBMS (Data Base Management System, Sistema
Administrador de Bases de Datos) por un programador, el diagrama con toda
seguridad contendrá la visibilidad de las características (atributos y
operaciones) de las clases, los tipos de datos de los atributos y las signaturas
de las métodos de las clases. La segunda forma de ver la precisión de un
modelo se refiere al nivel de abstracción, ese decir, a los detalles y la vista
(porción del sistema o realidad) que presenta un modelo al lector; por ejemplo,
en un sistema Bancario que maneja los retiros que hacen los clientes ya sea
en un cajero automático o humano, el diagrama de clases contiene decenas
de éstas; sin embargo las personas encargadas de desarrollar la interfaz de
un cajero electrónico estarían interesadas en las clases necesarias para
realizar el comportamiento del cajero y omiten el resto de clases del sistema.
d) Los mejores Modelos están ligados a la realidad. El símbolo de un actor en un
diagrama de casos de uso representa, de hecho, un actor en el sistema real;
así como un componente en un diagrama de componentes representa un
componente físico del software. Cada elemento de UML como una clase,
objeto, estado, componente o nodo tiene su correspondencia con algún
elemento conceptual o físico del mundo real.

2.3 UML COMO UNA HERRAMIENTA DE MODELADO A OBJETOS

El Lenguaje de Modelado Unificado (UML, Unified Modeling Language) es un

lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que
comprende el desarrollo de software. UML entrega una forma de modelar cosas
conceptuales como lo son procesos del sistema y sus funciones, además de cosas
concretas como lo son escribir clases en un lenguaje determinado, esquemas de
base de datos y componentes de software reutilizables.

Una de las ventajas principales de UML es que unifica distintas notaciones.

Rumbaugh

Booch Jacobson

Meyer
Odell

UML
Shlaer-Mellor Hare
l
Wirfs-Brock
Gamma et. At.
Embly Fusion

UML se puede usar para modelar distintos tipos de sistemas: sistemas de

software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve
diagramas en los cuales modelar sistemas:
 Diagrama de Casos de Uso
 Diagrama de Secuencia
 Diagrama de Colaboración
 Diagrama de Estados
 Diagrama de Actividades
 Diagrama de Clases
 Diagrama de Objetos.
 Diagrama de Componentes
 Diagrama de Implementación
 Vamos a dar una breve descripción de cada uno de estos diagramas.
Casos de Uso (Use Case)

El diagrama de casos de uso representa la forma en como un Cliente (Actor)

opera con el sistema en desarrollo, además de la forma, tipo y orden en como los
elementos interactúan (operaciones o casos de uso).

Los casos de uso contienen los siguientes elementos:

 Actor:

Una definición previa, es que un Actor es un rol que un usuario juega con
respecto al sistema. Es importante destacar el uso de la palabra rol, pues con
esto se especifica que un Actor no necesariamente representa a una persona
en particular, sino más bien la labor que realiza frente al sistema.

Como ejemplo a la definición anterior, tenemos el caso de un sistema de

ventas en que el rol de Vendedor con respecto al sistema puede ser realizado
por un Vendedor o bien por el Jefe de Local.
 Caso de Uso:

Es una operación/tarea específica que se realiza tras una orden de algún

agente externo, sea desde una petición de un actor o bien desde la invocación
desde otro caso de uso.
 Relaciones:
o Asociación
 Es el tipo de relación más básica que indica la invocación desde un
actor o caso de uso a otra operación (caso de uso). Dicha relación se
denota con una flecha simple.

o Dependencia o Instanciación

Es una forma muy particular de relación entre clases, en la cual una

clase depende de otra, es decir, se instancia (se crea). Dicha relación se
denota con una flecha punteada.

o Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble
función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>)
o de Herencia (<<extends>>).

Este tipo de relación esta orientado exclusivamente para casos de uso

(y no para actores).
 Extends: Se recomienda utilizar cuando un caso de uso es similar a
otro (características).
 Uses: Se recomienda utilizar cuando se tiene un conjunto de
características que son similares en más de un caso de uso y no se
desea mantener copiada la descripción de la característica.

De lo anterior cabe mencionar que tiene el mismo paradigma en diseño

y modelamiento de clases, en donde esta la duda clásica de usar o
heredar.
Diagrama de Secuencia

El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar

interacción entre objetos en un sistema. Un diagrama de secuencia se modela para
cada caso de uso. 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 pasados entre los objetos.

En particular el diagrama de secuencia muestra los objetos participantes en la

interacción y la secuencia de mensajes intercambiados.

El diagrama de secuencia utiliza la siguiente simbología:

1. El rectángulo de la parte superior indica el objeto que participa en la
secuencia de la operación.
2. El rectángulo que se encuentra sobre la línea punteada que sale del objeto,
indica en momento de activación del propio objeto durante la duración del
proceso.
3. Las líneas sólidas con flecha representan los mensajes enviados entre los
objetos o desde el exterior hacia los objetos (usuarios).
4. Las líneas sólidas con flecha que sale de un objeto y regresa a si mismo,
indican mensajes internos enviado para y hacia el mismo objeto.
5. Las líneas punteadas representan la respuesta a los mensajes enviados por
los objetos. No todos los mensajes van a tener una respuesta.
Diagrama de Colaboración

El diagrama de colaboración muestra la interacción entre varios objetos y los

enlaces que existen entre ellos. Representa las interacciones entre objetos
organizadas alrededor de los objetos y sus vinculaciones.
 A diferencia de un diagrama de secuencias, un diagrama de colaboraciones
muestra las relaciones entre los objetos, no la secuencia en el tiempo en que se
producen los mensajes. Los diagramas de secuencias y los diagramas de
colaboraciones expresan información similar, pero en una forma diferente.

En cuanto a la representación, un Diagrama de Colaboración muestra a una serie

de objetos con los enlaces entre los mismos, y con los mensajes que se intercambian
dichos objetos. Los mensajes son flechas que van junto al enlace por el que
“circulan”, y con el nombre del mensaje y los parámetros (si los tiene) entre
paréntesis. Cada mensaje lleva un número de secuencia que denota cuál es el
mensaje que le precede, excepto el mensaje que inicia el diagrama, que no lleva
número de secuencia. Se pueden indicar alternativas con condiciones entre
corchetes (por ejemplo 3 [condición_de_test]: nombre_de_método(). También se
puede mostrar el anidamiento de mensajes con números de secuencia como 2.1,
que significa que el mensaje con número de secuencia 2 no acaba de ejecutarse
hasta que no se han ejecutado todos los 2. X.
Diagrama de Estados

Representan la secuencia de estados por los que un objeto o una interacción

entre objetos pasa durante su tiempo de vida en respuesta a estímulos (eventos)
recibidos.

Los diagramas de estado son útiles para saber como va a ser el

comportamiento de un objeto con relación a los mensajes que recibe.
Generalmente el diagrama de estado es utilizado para comprender el
comportamiento de un objeto cuyo funcionamiento es complejo. Todos los
diagramas de estado deben de tener un estado inicial y otro final, por
medio de rectángulos se representan los estados que puede tener el
objeto, las flecha indican las transiciones que el objeto debe realizar para
pasar de un estado a otro. En los diagramas de estado también es posible
indicar las condiciones que el objeto debe obedecer para poder cambiar
de estado.

Un estado en UML es cuando un objeto o una interacción satisface una condición,

desarrolla alguna acción o se encuentra esperando un evento.

Cuando un objeto o una interacción pasa de un estado a otro por la ocurrencia de un

evento se dice que ha sufrido una transición, existen varios tipos de transiciones
entre objetos: simples (normales y reflexivas) y complejas. Además una transición
puede ser interna si el estado del que parte el objeto o interacción es el mismo que al
que llega, no se provoca un cambio de estado y se representan dentro del estado, no
de la transición.
 Como en todas las metodologías OO se envían mensajes, en este caso es la
acción de la que puede enviar mensajes a uno o varios objetos destino.

Diagrama de Actividades

Un diagrama de Actividad demuestra la serie de actividades que deben ser

realizadas para un caso de uso, así como las distintas rutas que pueden irse
desencadenando en dicho caso de uso.

Es importante recalcar que aunque un diagrama de actividad es muy similar en

definición a un diagrama de flujo (típicamente asociado en el diseño de Software),
estos no son lo mismo. Un diagrama de actividad es utilizado en conjunción de un
diagrama caso de uso para auxiliar a los desarrolladores del sistema a entender
como es utilizado el sistema y como reacciona en determinados eventos. Lo anterior,
en contraste con un diagrama de flujo que ayuda a un programador a desarrollar
código a través de una descripción lógica de un proceso. Se pudiera considerar que
un diagrama de actividad describe el problema, mientras un diagrama de flujo
describe la solución.

Un estado de actividad se representa como una caja con los extremos

redondeados que contiene una descripción de actividad. Las transacciones simples
de terminación se muestran como flechas. Las ramas se muestran como condiciones
de guarda en transiciones o como diamantes con múltiples flechas de salida
etiquetadas. Una división o una unión de control se representan con múltiples flechas
que entran o salen de la barra gruesa de sincronización.

Cuando es necesario incluir eventos externos, la recepción de un evento se

puede mostrar como un disparador en una transición, o como un símbolo especial
que denota la espera de una señal.

A menudo es útil organizar las actividades en un modelo según su

responsabilidad. Esta clase de asignación puede mostrarse organizando las
actividades en regiones distintas separadas por líneas en el diagrama. Debido a su
aspecto, esto es conocido como Calles.

Un diagrama de actividades puede mostrar el flujo de objetos como valores. Para

un valor de salida, se dibuja una flecha con línea discontinua desde la actividad al
objeto. Para un valor de entrada, se dibuja una flecha con línea discontinua desde el
objeto a una actividad.

Los rectángulos son utilizados para representar las actividades, los cuales están
unidos por la flecha que indica la transición entre las actividades; en el caso de estos
diagramas también se incluyen los diamantes o rombos para indicar la toma de
decisiones, además de barras paralelas para indicar actividades que pueden
realizarse precisamente de forma paralela.
Diagrama de Clases

Un diagrama de clases sirve para visualizar las relaciones entre las clases que
involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de
contenido.

Un diagrama de clases esta compuesto por los siguientes elementos:

 Clase: atributos, métodos y visibilidad.
 Relaciones: Herencia, Composición, Agregación, Asociación y Uso.
 La clase es la unidad básica que encapsula toda la información de un Objeto (un
objeto es una instancia de una clase). A través de ella podemos modelar el entorno
en estudio (una Casa, un Auto, etc.).

En UML, una clase es representada por un rectángulo que posee tres divisiones:
 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 métodos u operaciones, los cuales son la forma como
interactúa el objeto con su entorno (dependiendo de la visibilidad: private,
protected o public).

En donde los atributos o características de una Clase pueden ser de tres tipos,
los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos
son:

 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 sólo será accesible desde dentro de la
clase (sólo sus métodos lo pueden accesar).

 protected (#, ): Indica que el atributo no será accesible desde fuera de la

clase, pero si podrá ser accesado por métodos de la clase además de las
subclases que se deriven (ver herencia).

Y los métodos u operaciones de una clase son la forma en como ésta interactúa
con su entorno, éstos pueden tener las características:

 public (+, ): Indica que el método será visible tanto dentro como fuera de la
clase, es decir, es accesible desde todos lados.
  private (-, ): Indica que el método sólo será accesible desde dentro de la
clase (sólo otros métodos de la clase lo pueden acceder).

 protected (#, ): Indica que el método no será accesible desde fuera de la

clase, pero si podrá ser accesado por métodos de la clase además de
métodos de las subclases que se deriven (ver herencia).

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden

interrelacionar dos o más clases (cada uno con características y objetivos diferentes).

Pero antes es necesario explicar el concepto de cardinalidad de relaciones: En

UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se
anotan en cada extremo de la relación y éstas pueden ser:
 Uno o muchos: 1..* (1..n)
 0 o muchos: 0..* (0..n)
 Número fijo: m (m denota el número).

Los enlaces entre clases y sus formas de relación son:

 Herencia (Generalización/Especialización)
 Asociación
 Agregación
 Dependencia/Instanciación

Herencia (Especialización/Generalización) :

Indica que una subclase hereda los métodos y atributos especificados por una
Súper Clase, por ende la Subclase además de poseer sus propios métodos y
atributos, poseerá las características y atributos visibles de la Súper Clase (public y
protected), ejemplo:

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir, Auto

posee las Características de Vehículo (Precio, VelMax, etc.) además posee algo
particular que es Descapotable, en cambio Camión también hereda las
características de Vehiculo (Precio, VelMax, etc.) pero posee como particularidad
propia Acoplado, Tara y Carga.

Cabe destacar que fuera de este entorno, lo único "visible" es el método

Características aplicable a instancias de Vehículo, Auto y Camión, pues tiene
definición pública, en cambio atributos como Descapotable no son visibles por ser
privados.

Agregación

Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen
los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere
componer objetos que son instancias de clases definidas por el desarrollador de la
aplicación, tenemos dos posibilidades:
 Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del
objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este
tipo de relación es comúnmente llamada Composición (el Objeto base se
construye a partir del objeto incluido, es decir, es "parte/todo").
 Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida
del objeto incluido es independiente del que lo incluye. Este tipo de relación es
comúnmente llamada Agregación (el objeto base utiliza al incluido para su
funcionamiento).

Un Ejemplo es el siguiente:

En donde se destaca que:

 Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee
las referencias).
 Cuando se destruye el Objeto Almacén también son destruidos los objetos
Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.
 La composición (por Valor) se destaca por un rombo relleno.
 La agregación (por Referencia) se destaca por un rombo transparente.

La flecha en este tipo de relación indica la navegabilidad del objeto referenciado.

Cuando no existe este tipo de particularidad la flecha se elimina.
Asociación

La relación entre clases conocida como Asociación, permite asociar objetos que
colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo
de vida de un objeto no depende del otro.

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una

orden de compra solo puede tener asociado un cliente.

Dependencia o Instanciación (uso)

Representa un tipo de relación muy particular, en la que una clase es instanciada

(su instanciación es dependiente de otro objeto/clase). Se denota por una flecha
punteada.

El uso más particular de este tipo de relación es para denotar la dependencia que
tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una
ventana (la creación del Objeto Ventana esta condicionado a la instanciación
proveniente desde el objeto Aplicación).

Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se
almacena dentro del objeto que lo crea (en este caso la Aplicación).
Diagrama de Objetos

Los diagramas de objetos se emplean para modelar la vista de diseño estática o

la vista de procesos estática de un sistema al igual que se hace con los diagramas
de clases, pero desde la perspectiva de instancias reales o prototípicas. Esta vista
sustenta principalmente los requisitos funcionales de un sistema. Los diagramas de
objetos permiten modelar estructuras de datos estáticas

En general los diagramas de objetos se utilizan para modelar estructuras de objetos,

lo que implica tomar una instantánea de los objetos de un sistema en un cierto
momento. Un diagrama de objetos representa una escena estática dentro de la
historia representad a por un diagrama de interacción. Los diagramas de objetos se
utilizan para visualizar, especificar, construir y documentar la existencia de ciertas
instancias en el sistema, junto a las relaciones entre ellas.
 En la figura se representa un conjunto de objetos extraídos de la implementación
de un robot. Como indica la figura, un objeto representa al propio robot, ( r es una
instancia de Robot), y r se encuentra actualmente en estado movimiento. Este objeto
tiene un enlace con m, una instancia de Mundo, que representa una abstracción del
modelo del mundo del robot. Este objeto tiene un enlace con un multiobjeto, un
conjunto de instancias de Elemento, que representan entidades que el robot ha
identificado, pero aún no ha asignado en su vista del mundo.

En este instante, m está enlazado a dos instancias de Area. Una de ellas (a2) se
muestra con sus propios enlaces a tres objetos Pared y un objeto Puerta. Cada una de
estas paredes está etiquetada con su anchura actual, y cada una se muestra
enlazada a sus paredes vecinas. Como sugiere este diagrama de objetos, el robot ha
reconocido el área que lo contiene, que tiene paredes en tres lados y una puerta en
el cuarto.

Como vemos los diagramas de objetos son especialmente útiles para modelar
estructuras de datos complejas. Evidentemente puede existir una multitud de
posibles instancias de una clase particular, y para un conjunto de clases con t
relaciones entre ellas, pueden existir muchas más configuraciones posibles de estos
objetos. Por lo tanto, al utilizar diagramas de objetos sólo se pueden mostrar
significativamente conjuntos interesantes de objetos concretos o prototípicos.

Diagrama de Componentes

Describe componentes de software y sus dependencias con otros componentes,

representando la estructura del código. Los componentes de software pueden ser:
componentes de código, componentes binarios que son los generados por la
compilación de los componentes de código y los componentes ejecutables.
 En este diagrama se pueden manejar paquetes, que son contenedores de clases
utilizados para mantener el espacio de nombres de clases dividido en
compartimentos, de manera que se utilizan para representar subsistemas del sistema
en el mundo físico. Cada paquete se liga con otros a través de dependencias, que se
representan con flechas de líneas discontinuas que van del componente dependiente
al componente del cual depende.

Cada paquete debe tener un diagrama de componentes para representar las

clases que contiene internamente, similar a hacer un acercamiento o "zoom" al
interior de cada uno de los paquetes.

Los componentes de software se representan con un rectángulo que contiene dos

pequeños rectángulos en su extremo izquierdo.

Diagrama de Implementación

Un diagrama de implementación muestra la configuración de los elementos de

procesamiento en tiempo de ejecución y los componentes software, procesos y
objetos que se ejecutan en ellos. Instancias de los componentes software
representan manifestaciones en tiempo de ejecución del código. Componentes que
solo sean utilizados en tiempo de compilación deben mostrarse en el diagrama de
componentes.
 Un diagrama de implementación es un grafo de nodos conectados por
asociaciones de comunicación. Un nodo puede contener instancias de componentes
software, objetos, procesos (un caso particular de un objeto). Las instancias de
componentes software pueden estar unidas por relaciones de dependencia,
posiblemente a interfaces.

Un ejemplo de diagrama de ejecución es el siguiente:

2.4 PLANTEAMIENTO DEL PROBLEMA.

Antes de poder iniciar con cualquier tipo de análisis y/o modelado, es necesario
realizar el planteamiento del problema. El planteamiento consiste en obtener la
información necesaria para poder tener una visión clara de la situación y de esa
forma conseguir realizar un análisis efectivo.

Para el planteamiento del problema es necesario recopilar información de las

siguientes 4 categorías:

De negocio: El tipo de información que se requiere aquí es toda la relacionada a

como el negocio funciona, incluyendo información acerca de los objetivos, productos,
servicios y definición de los procesos críticos del negocio.

De aplicación: Esta información comprende la forma en como funciona el negocio

a través de toda la organización, identificando a los tipos de usuarios, así como las
diferentes actividades que se realizan para llevar a cabo los procesos del negocio.
Aquí se identifican todas las tareas manuales y automáticas, además de las
diferentes herramientas (programas, utilerías, etc.) que se usan para determina
acción.

De operación: Toda la información referente a los datos que necesita la

organización para realizar sus procesos de negocio, incluyendo modelo de datos,
políticas para el manejo de datos, identificación de los patrones de consumo de
información. Es importante identificar quien origina la información, quien es el
propietario y quien la consume, además de la relación que esta tiene con los
procesos clave de la organización.

De tecnología: Aquí se definen todos los servicios técnicos necesarios para soportar
la actividad del negocio, desde topologías de red, ambientes de desarrollo, interfaces
de programación, seguridad, servicios de redes, servicios de base de datos,
hardware, sistemas operativos, etc.
2.4.1 Analizar el enunciado.

El proceso de análisis inicia cuando consideramos que tenemos suficiente

información por parte del cliente. Como primer paso se debe de sintetizar la
información obtenida para obtener una visión que detalle el estado actual del
negocio.

En este paso se determinan la información inicial para la elaboración del

programa. Es donde se determina qué es lo que debe resolverse con el sistema, de
qué presupuestos se debe partir; en definitiva, el planteamiento del problema.

Se requieren cinco tareas:

a) Determinación de objetivos del programa. Debe definirse claramente los
problemas particulares que deberán ser resueltos o las tareas que hay que
realizar, esto nos permitirá saber qué es lo que se pretende solucionar y nos
proporcionará información útil para el planeamiento de la solución.
b) Determinación de la salida deseada. Los datos seleccionados deben ser
arreglados en una forma ordenada para producir información. Esta salida
podría ser una salida de impresión o de presentación en el monitor.
c) Determinación de los datos de entrada. Una vez identificada la salida que se
desea, se pueden determinar los datos de entrada y la fuente de estos datos.
Los datos deben ser recolectados y analizados.
d) Determinación de los requerimientos de procesamiento. Aquí se definen las
tareas de procesamiento que deben desempeñarse para que los datos de
entrada se conviertan en una salida.
e) Documentación de las especificaciones del programa. Es importante disponer
de documentación permanente. Deben registrarse todos los datos necesarios
para el procesamiento requerido. Esto conduce al siguiente paso del diseño
del programa.
 Conforme se sintetiza y analiza la información es necesario identificar si hay
alguna discrepancia o alguna omisión en la información coleccionada, de ser así es
necesario recolectar esa parte de información antes de proseguir.

2.4.2 Identificar funciones del sistema.

Ya que se sintetizo la información obtenida, se procede a desarrollar los casos de

uso a alto nivel y los escenarios de uso; para los procesos de negocio, los
requerimientos de negocio y de los usuarios.

El propósito de los casos de uso es identificar todos los procesos de principio a

fin, documentar el contexto y el ambiente en que se desarrollan los procesos, así
como describir las necesidades y requerimientos. Obteniendo como beneficio la
facilidad de entendimiento de los procesos y sus requerimientos.

Los escenarios de uso nos permiten ver a un alto nivel la forma en como
interactúan los individuos y el sistema, además de proveer información adicional de
las actividades y la secuencia de las mismas para constituir un proceso.

2.5 ANALISIS.

En esta etapa se analiza el problema, sobre qué se quiere solucionar, cómo se va

a solucionar, además analizamos el factor que lo produjo o que lo esta produciendo y
darle una posible solución, tomando en cuenta el estudio de factibilidad.
2.5.1 Descubrir Objetos

Si se observa alrededor en una habitación, existen un conjunto de objetos

físicos que pueden ser fácilmente identificados, clasificados y definidos (en términos
de atributos y operaciones). Pero cuando se “observa” el espacio de un problema en
una aplicación de software, los objetos pueden ser más difíciles de identificar. Se
puede empezar a identificar objetos examinando el planteamiento del problema o
realizando un “análisis sintáctico gramatical” en la narrativa del sistema que se va a
construir.

Los objetos se determinan subrayando cada nombre o cláusula nominal e

introduciéndola en una tabla simple. Los sinónimos deben destacarse. Si se requiere
del objeto que implemente una solución, entonces éste formará parte del espacio de
solución; en caso de que el objeto se necesite solamente para describir una solución,
éste forma parte del espacio del problema. Los objetos se manifiestan de alguna de
las formas siguientes:
 Entidades Externas que producen o consumen información a usar por un
sistema computacional. Por ejemplo: otros sistemas, dispositivos, personas.
 Cosas que son parte del dominio de información del problema. Por ejemplo:
informes, presentaciones, cartas, señales.
 Ocurrencias o Sucesos que ocurren dentro del contexto de una operación del
sistema. Por ejemplo: una transferencia de propiedad o la terminación de una
serie de movimientos en un robot.
 Papeles o Roles desempeñados por personas que interactúan con el sistema.
Por ejemplo: director, ingeniero, vendedor.
 Unidades Organizacionales que son relevantes en una aplicación. Por
ejemplo: división, grupo, equipo.
 Lugares que establecen el contexto del problema y la función general del
sistema. Por ejemplo: planta de producción o muelle de carga.
  Estructuras que definen una clase de objetos o, en casos extremos, clases
relacionadas de objetos. Por ejemplo: sensores, vehículos de cuatro ruedas o
computadoras.

En general, un objeto nunca debe tener un nombre procedimental imperativo.

imperativo
Coud y Yourdon sugieren seis características de selección a usar cada vez que un
analista considera si incluye o no un objeto potencial en el modelo de análisis:
1. Información retenida el objeto potencial será de utilidad durante el análisis
solamente si la información acerca de él debe recordarse para que el sistema
funciones.
2. Servicios necesarios el objeto potencial debe poseer un conjunto de
operaciones identificables que pueden cambiar de alguna manera el valor de
sus atributos.
3. Atributos múltiples durante el análisis de requisitos, se debe centrar la
atención en la información principal (un objeto con un solo atributo puede, en
efecto, ser útil durante el diseño, pero seguramente será mejor presentado
como un atributo de otro objeto durante la actividad de análisis).
4. Atributos comunes puede definirse un conjunto de atributos para el objeto
potencial, los cuales son aplicables a todas las ocurrencias del objeto.
5. Operaciones comunes puede definirse un conjunto de operaciones para el
objeto potencial, las cuales son aplicables a todas las ocurrencias del objeto.
6. Requisitos esenciales entidades externas que aparecen en el espacio del
problema y producen o consumen información esencial para la producción de
cualquier solución para el sistema, serán casi siempre definidas como objetos
en el modelo de requisitos.

Para ser considerado un objeto válido a incluir en el modelo, un objeto potencial

debe satisfacer todas (o casi todas) las características anteriores. La decisión de
incluir objetos potenciales en el modelo de análisis es algo subjetivo, y una
evaluación posterior puede llegar a descartar un objeto o reincluirlo. Sin embargo, el
primer paso del Análisis Orientado a Objetos debe ser la definición de objetos, y la
consiguiente toma de decisiones (incluso subjetivas).

2.5.2 Identificar Atributos de los Objetos.

Los atributos describen un objeto que ha sido seleccionado para ser incluido
en el modelo de análisis. En esencia, son los atributos los que definen al objeto, los
que clarifican lo que representa el objeto en el contexto del espacio del problema.

Por ejemplo, si se tratara de construir un sistema de estadísticas para jugadores

profesionales de béisbol, los atributos del objeto Jugador serían muy diferentes de
los atributos del mismo objeto cuando se use dentro del contexto de un sistema de
pensiones para jugadores profesionales. En el primero, atributos tales como nombre,
posición, promedio de bateo, porcentaje de estancia en el campo de juego, años
jugados y partidos jugados pueden ser relevantes. En el segundo caso, algunos de
estos atributos serían relevantes pero otros serían reemplazados (o potenciados) por
atributos como salario medio, crédito total, opciones elegidas para el plan de
pensión, dirección postal, etc.

Para desarrollar un conjunto significativo de atributos para un objeto, el analista

puede estudiar de nuevo la narrativa del proceso (o descripción del ámbito del
alcance) para el problema y seleccionar aquellos elementos que razonablemente
“pertenecen” al objeto. Además, para cada objeto debe responderse el siguiente
interrogante: “¿Qué elementos (compuestos y/o simples) definen completamente al
objeto en el contexto del problema actual?”.
2.5.3 Identificar métodos en los Objetos.

A partir de tener completo el análisis realizado en los 2 pasos anteriores, es

posible identificar los métodos para nuestros objetos. Los métodos representan las
acciones que un objeto determinado puede llevar a cabo, estas acciones permiten a
los objetos interactuar entre si. Los métodos tienen los mismos tipos de visibilidad
que los atributos. A los métodos identificados es posible indicar que parámetros
requieren así como el tipo de los mismos, además de poder indicar si alguno de los
métodos regresa algún valor de tipo específico.

Los métodos u operaciones pueden ser clasificados entre tres grandes

categorías:
 Operaciones que manipulan datos
 Operaciones que realizan algún Cálculo
 Operaciones que monitorizan un objeto frente a la ocurrencia de un sistema
de control (evento).

Para la identificación de objetos debe tenerse en cuenta el ciclo de vida de un

objeto, ya que con esto en mente se nos facilitara la identificación de los métodos
requeridos. Dicho ciclo de vida puede resumirse de la siguiente manera:
 Creación el objeto
 Modificación del objeto
 Manipulación del objeto
 Destrucción del Objeto

2.6 INTRODUCCIÓN AL DISEÑO DE LA SOLUCIÓN

Durante el proceso de análisis se llega a tener un modelo que de forma estática

define como debe de ser nuestro sistema, pero para la etapa de diseño, es posible
que este modelo no sea suficiente para expresar el comportamiento y estado que el
sistema debe de tener bajo ciertas condiciones que son parte de los procesos que el
sistema debe realizar. Para tales situaciones el UML entra nuevamente en acción
mediante la utilización de los diagramas de secuencia, los diagramas de estado y los
diagramas de actividad.

Recordémoslos un poco:
 Con el uso de los diagramas de secuencia podemos ilustrar los mensajes con
los que se deben de comunicar los objetos, así como el orden en que estos se
deben de llevar a cabo para determinado proceso.
 Los diagramas de estado son útiles para saber como va a ser el
comportamiento de un objeto con relación a los mensajes que recibe.
 Los diagramas de actividad, los cuales representan desde el punto de vista de
programación orientada a objetos los diagramas de flujo. Los diagramas de
actividad son utilizados para diseñar operaciones complejas, todo un caso de
uso o varios, así como los procesos de negocio.

2.6. Representación gráfica de una clase

Las clases son representadas con los diagramas de clases de UML que
explicamos anteriormente que representan un conjunto de elementos del modelo que
son estáticos, como las clases y los tipos, sus contenidos y las relaciones que se
establecen entre ellos.

2.6.2 Diagramas de Iteración entre aplicación y clase

Los diagramas de interacción (también tratados anteriormente) indican el flujo de

mensajes entre elementos del modelo, el flujo de mensajes representa el envío de un
mensaje desde un objeto a otro si entre ellos existe un enlace. Los mensajes que se
envían entre objetos pueden ser de distintos tipos, también según como se producen
en el tiempo; existen mensajes simples, síncronos y asíncronos. Durante la ejecución
de un diagrama de colaboración se crean y destruyen objetos y enlaces. En los
diagramas de interacción se muestra un patrón de interacción entre objetos. Hay dos
tipos de diagrama de interacción, ambos basados en la misma información, pero
cada uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas
de Colaboración (mencionados con anterioridad).

2.6.3 DIAGRAMAS DE ESTADO DE UNA CLASE

Los diagramas de estado son útiles para saber como va a ser el

comportamiento de un objeto con relación a los mensajes que recibe. Generalmente
el diagrama de estado es utilizado para comprender el comportamiento de un objeto
cuyo funcionamiento es complejo. Representan la secuencia de estados por los que
un objeto o una interacción entre objetos pasa durante su tiempo de vida en
respuesta a estímulos (eventos) recibidos. Representa lo que podemos denominar
en conjunto una máquina de estados. Un estado en UML es cuando un objeto o una
interacción satisfacen una condición, desarrolla alguna acción o se encuentra
esperando un evento.

2.6 INTRODUCCIÓN AL DISEÑO DE LA SOLUCIÓN

Una computadora no tiene capacidad para solucionar problemas más que cuando
se le proporcionan los sucesivos pasos a realizar, esto se refiere a la obtención de un
algoritmo que resuelva adecuadamente el problema. En caso de obtenerse varios
algoritmos, seleccionar uno de ellos utilizando criterios ya conocidos.

Esta etapa incluye la descripción del algoritmo resultante en un lenguaje natural,

de diagrama de flujo o natural de programación. Como puede verse, solo se
establece la metodología para alcanzar la solución en forma conceptual, es decir; sin
alcanzar la implementación en el sistema de cómputo.

Los problemas complejos se pueden resolver más eficazmente por la

computadora cuando se dividen en subproblemas que sean más fáciles de
solucionar.