Programación II UML Dr.

Mario Rossainz López

UNIDAD 2: Abstracción del Mundo real

Al Paradigma Orientado a Objetos

2.1. Principios básicos del Modelado de Objetos

Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que
resuelven un determinado problema, requieren ser automatizados. Como ejemplo
podemos citar a toda aquella empresa o negocio de ventas donde el proceso consistente
en que un cliente de dicha empresa llame por teléfono para solicitar la compra de un
producto y éste le sea llegado por medio de un determinado medio de transporte; pueda
ser automatizado. Si nosotros logramos de alguna forma la visualización de los
componentes de dicho proceso así como de las relaciones de esta simple transacción,
podremos entonces comprender el funcionamiento del proceso de una manera mucho
más simple y sencilla que si lo describiéramos en palabras.
El mapeo de los procesos del mundo real de un sistema software a una representación
gráfica (blueprint) nos proporciona una visión más clara de ese sistema computarizado. A
este mapeo se le conoce como el modelado visual.

Son muchos los beneficios del modelado visual, entre ellos están:

 La captura e identificación de procesos

 Los enlaces de Comunicación
 El manejo de la Complejidad
 La definición de arquitecturas software
 La reusabilidad disponible
Programación II UML Dr. Mario Rossainz López

2.1.1. CAPTURA DE PROCESOS

En la actualidad los procesos computacionales engloban una gran variedad de procesos

que se dan en las empresas o negocios. Es por eso que para entender un sistema
software es necesario definir aquellos requerimientos inmersos en la operación de dichos
procesos. Sin la definición de esos requerimientos el sistema o producto software no
podrá construirse. Cuando se crean los casos de uso, el modelado visual que se define en
esa parte captura los procesos de la empresa o negocio identificando los requerimientos
del sistema software desde una perspectiva del usuario. Esto precisamente da pauta a la
construcción del diseño y desarrollo de los procesos implicados.

2.1.2. COMUNICACIONES

Los analistas y expertos en dominios son comúnmente quienes definen los requerimientos
del sistema y las arquitecturas software. Por otro lado los desarrolladores son quienes
construyen el sistema basándose en esos requerimientos. Estos dos grupos pueden y
deben trabajar en equipo pero pueden existir diferencias, malos entendidos o
desacuerdos entre ellos en la terminología que puedan emplear por separado.

El modelado visual tiene una comunicación estándar y el UML en particular proporciona

una suave transición entre el dominio del problema y el dominio de la computadora.
Mediante la comunicación a través de un lenguaje común de modelado visual, todos los
grupos y miembros de un equipo de trabajo, en particular basados en el diseño, operan y
se comunican con la misma terminología minimizando así los desacuerdos o diferencias e
incrementando la eficiencia.
Programación II UML Dr. Mario Rossainz López
Programación II UML Dr. Mario Rossainz López

2.1.3. MANEJO DE LA COMPLEJIDAD

Es común que en empresas donde se realiza ingeniería de software los sistemas estén
conformados de cientos de clases. Dichas clases se organizan entonces para ser vistas
por muchos grupos diferentes de personas en base a las necesidades de cada uno de
ellos con una visión por tanto diferente. El modelado visual proporciona la capacidad de
mostrar elementos de modelado de varias formas de tal manera que dichos elementos
pueden ser vistos en diferentes niveles de abstracción. Un mismo modelo puede tener
varias vistas diferentes dependiendo de las necesidades o intereses del visor.

2.1.4. DEFINICION DE ARQUITECTURAS SOFTWARE

El modelado visual proporciona la capacidad de capturar la arquitectura lógica del

software independientemente del lenguaje de implementación que se quiera usar. En un
sistema donde se diseñan procesos, el lenguaje de implementación es una herramienta
determinada mientras que la arquitectura lógica de software es mapeada en una
arquitectura física. Esta forma de mapeo proporciona una gran flexibilidad en el diseño de
un producto software. Así por ejemplo si se decide cambiar la arquitectura del lenguaje
C++ al lenguaje JAVA, con el modelado visual la arquitectura lógica es la misma y sólo
necesita ser mapeada a la nueva implantación física.
Programación II UML Dr. Mario Rossainz López

2.1.5. REUSABILIDAD DISPONIBLE

El modelado visual proporciona el uso de la reusabilidad de partes de un producto

software o aplicación mediante la creación de componentes en el diseño del sistema.
Estos componentes pueden ser compartidos y reutilizados por equipos de proyectos y los
cambios pueden ser incorporados fácilmente dentro de aquellos proyectos existentes que
están siendo desarrollados aun. La reusabilidad de componentes hace más flexibles los
diseños.

2.1.6. QUE ES UML?

Usando UML se puede llevar a cabo el modelado y obtener los beneficios enunciados en
las secciones anteriores de éste capítulo. UML es el lenguaje estandar para la
visualización, especificación, construcción y documentación de los artefactos o
componentes de un producto o sistema software. Con UML:

 Se incrementa la productividad de una empresa.

 Se acorta el desarrollo de los ciclos de vida de un sistema software.
 Se adquiere una alta calidad del software que se construye.
Programación II UML Dr. Mario Rossainz López

2.1.7. EVOLUCION DEL UML

Programación II UML Dr. Mario Rossainz López

2.2. MODELADO DE CLASES

En esta sección se ilustra el modelado de los diagramas de clases para visualizar la

estructura de un sistema software.

2.2.1. DIAGRAMAS DE CLASES

La estructura de un sistema software surge cuando uno descubre los objetos que
intervienen en dicho sistema. Un diagrama de clases ilustra las clases existentes dentro
de un producto software así como las relaciones entre ellas. Por tanto, la naturaleza
estática de un sistema se representa mediante los diagramas de clases. Las
responsabilidades de los casos de uso se localizan en los objetos. La agrupación de
dichos objetos en clases ayuda a manejar la complejidad de un sistema. Una clase por
tanto, es una colección de objetos que comparten:

 una estructura común

 un comportamiento común
 unas relaciones comunes
 semánticas también comunes

En nuestro ejemplo, en base al caso de uso “Crear un nuevo mercado o comercio”

(Create New Trade) utilizamos objetos que forman parte de 5 clases:

La clase Trade (Comercio o Mercado)

La clase Trade Leg (Etapa de Comercio)
La clase Trade Administrator (Administrador de Mercado o comercio)
La clase Position Administrator (Posición del Administrador)
La clase Slate (lista de candidatos)
Programación II UML Dr. Mario Rossainz López

2.2.2. ASOCIACIONES

Las relaciones entre clases proporcionan un camino para la comunicación entre objetos.
Una asociación es un tipo de relación. Las asociaciones entre clases son modeladas con
líneas bidireccionales que establecen la relación entre clases. Los diagramas de
secuencia y/o colaboración se examinan para determinar las ligas que puedan existir
entre los objetos que se requieren existan para definir el comportamiento del sistema (por
ejemplo, cuando dos objetos necesitan comunicarse, se puede establecer una liga entre
ellos).

2.2.3. ROLES

Uno de los propósitos de un diagrama de clases es la comunicación. Para ello es

necesario añadir información a una relación de asociación. El establecimiento de
comunicación en una relación es un role. Un role describe el propósito o capacidad para
que una clase se pueda asociar con otra. El nombre de un role se coloca generalmente a
lo largo de la línea de asociación que lo define. En el ejemplo del sistema comercial, la
clase Trade Administrator (Administrador de mercado o comercio) juega el role de
manager en la asociación con la clase Trade (Comercio o Mercado).
Programación II UML Dr. Mario Rossainz López

2.2.4. AGREGACIONES

Una agregación es una forma especial de asociación. Las agregaciones ilustran la

relación que hay entre un todo y sus partes. Siguiendo con el ejemplo, La clase Trade
Leg (Etapa de Comercio) es una parte de la clase Trade (Comercio o Mercado). Esta
asociación a final de cuentas es una agregación.

2.2.5. MULTIPLICIDAD

Una vez establecidas las relaciones de asociación y agregación, será necesario conocer
cuantos (muchos, varios, uno, etc.) objetos pueden participar en dichas relaciones. La
multiplicidad es el número de instancias de una clase que están relacionadas con una
instancia de la otra clase de la relación que se define. Para cada asociación y agregación,
existe una multiplicidad formada por dos partes: una para cada extremo de la relación que
se define. Por ejemplo: En el sistema del comercio, un objeto de la clase Trade
Administrator (Administrador de Mercado o Comercio) se relaciona con cero o más
objetos de la clase Trade (Comercio o Mercado); y un objeto de la clase Trade es
asociado con exactamente un objeto de la clase Trade Administrator (Administrador de
Mercado o Comercio). Similarmente un objeto Trade se compone de uno o más objetos
Trade Leg y un objeto Trade Leg es parte de exactamente un objeto Trade.
Programación II UML Dr. Mario Rossainz López

2.2.6. NAVEGACIÓN

Las asociaciones y agregaciones son bidireccionales por default, pero puede ser deseable
restringir la navegación o flujo en una sola dirección. Si la navegación se restringe
entonces será necesario añadir al esquema gráfico una flecha que indique la dirección de
dicha navegación donde corresponda. En nuestro ejemplo, un Trade puede llamar a un
Trade Leg pero no a la inversa.
Programación II UML Dr. Mario Rossainz López

2.2.7. ESTRUCTURA Y COMPORTAMIENTO

Los diagramas de clase representan la estructura y comportamiento de cada clase que los
conforman. La estructura de una clase es descrita mediante un conjunto de atributos. Un
atributo es una definición de dato a través de un campo o variable que es utilizada a
través de instancias de clases. Estos atributos son definidos en el segundo
compartimiento de la representación gráfica de una clase en el diagrama de clases.
Por otro lado, el comportamiento de una clase es representado por sus operaciones. Una
operación es un servicio que puede ser utilizado por un objeto afectando su
comportamiento. Las operaciones son descritas en el tercer compartimiento de la
representación gráfica de una clase en el diagrama de clases .
En el ejemplo que hemos estado siguiendo, cada objeto Trade tiene un atributo llamado
Trader y una operación llamada constructLeg.

2.2.8. HERENCIA

La herencia es otro tipo de relación. La herencia define una relación de clases donde una
clase determinada comparte la estructura y/o comportamiento de una o más clases
distintas. Esta relación define una jerarquía de abstracciones en donde una subclase
hereda de una o más superclases.
En el ejemplo del sistema comercial un objeto Trade Administrator y un objeto Position
Administrator heredan de la clase Administrator. Esta relación por una parte define una
estructura común para estos objetos: comportamiento y/o relaciones de nivel
Administrator y por la otra define elementos únicos propios de la clase Trade
Administrator y de la clase Position Administrator. Con todos estos conceptos vistos
podemos entonces visualizar la estructura de la solución de un problema automatizado en
un sistema software.
Programación II UML Dr. Mario Rossainz López