Desarrollo de sistemas

Metodología de modelado orientado a objetos

Breve resumen de "Object-Oriented Modeling and Design", James Rumbaugh, Michael Blaha, William
Premerlani, Federick Eddy y William Lorensen; Prentice-Hall, 1991.

Este apunte está orientado a describir los conceptos, metodología de análisis y modelado de un sistema, y no a
su aplicación en algún lenguaje especifico.

Etapas de desarrollo de un sistema

1) Análisis: Empezamos con la definición del problema. El analista debe trabajar en conjunto con quien
requiere la solución porque, en general, la definición del problema está incompleta o es errónea. El análisis
consiste en una abstracción precisa de lo que debe hacer el sistema, pero no como lo hace. El análisis tiene
que ser entendido por no programadores. No debe incluir ninguna decisión de implementación.

2) Diseño del sistema: El diseñado del sistema toma las decisiones de alto nivel. El objetivo es dividir el
sistema en sub sistemas basado en el análisis, y la estructura propuesta. El diseñador del sistema decide que
características optimizar, elige las estrategias generales para atacar el problema y hace una tentativa del
manejo de recursos.

3) Diseño de Objetos: El diseñador de objetos hace el diagrama de clases basado en el análisis de la etapa
anterior, incluyendo detalles de implementación. El diseñador agrega detalles al diseño de acuerdo con las
estrategias establecidas durante el análisis y diseño del sistema. El foco del diseño de objetos es generar la
estructura de datos y los algoritmos necesarios para implementar cada clase. Se realiza el diagrama de clases,
diagrama de estados y diagrama de flujo de datos, contemplando estructuras de datos del lenguaje a utilizar.

4) Implementación: Las clases y sus relaciones desarrolladas durante el diseño de objetos, son finalmente
trasladadas a un lenguaje, base de datos o hardware específico. La programación debería ser la parte menor y
mecánica del ciclo de desarrollo de la aplicación, porque todas las decisiones estratégicas fueron tomadas
durante las etapas de diseño. El lenguaje de programación influye en las decisiones de diseño, pero el diseño
no debe depender de los detalles finos de la programación. Durante la implementación es necesario seguir
buenas prácticas de ingeniería de software, en trazabilidad del diseño a la implementación, robustez,
flexibilidad, etc.

Los tres modelos

La metodología de diseño orientado a objetos usa tres tipos de modelos para describir el sistema. Cada
modelo es aplicable a todas las etapas de desarrollo, adquiriendo mas detalles de implementación a medida
que progresa el desarrollo. Los tres modelos son parte de la descripción del sistema y están interrelacionados.
En conjunto sirven para describir que, cuando y como cambian las cosas en el sistema.

El modelo de objetos: Describe la estructura estática de los objetos en el sistema y sus relaciones. El modelo
de objeto incluye los diagramas de clases y sus relaciones.

El modelo dinámico: Describe los aspectos del sistema que cambian a lo largo del tiempo. El modelo dinámico
se usa para especificar e implementar aspectos de control del sistema. El modelo dinámico incluye diagramas
de estados y eventos.
El modelo funcional: Describe la transformación de los datos en el sistema. El modelo funcional incluye los
diagramas de flujo de datos.

Modelo de objetos
El propósito del modelo de objetos es describir objetos y sus relaciones. Por ejemplo Joe Smith, la compañía
Simplex, mi bicicleta, son objetos. Decir "Joe Smith trabaja para la compañía Simplex es una relación entre
objetos .

Objetos

Definimos objeto como un concepto, una abstracción, o cosa. Sirven para 2 propósitos: Promueve el
entendimiento del mundo real, y proveen una base práctica para la implementación. La descomposición del
problema en objetos depende de la naturaleza del problema. No hay una representación correcta o incorrecta.

Todos los objetos tienen identidad y son distinguibles. Dos manzanas rojas tiene la misma forma, color y
textura pero aún son dos manzanas individuales.

Clases

Las clases de objetos describen a un grupo de objetos con propiedades similares (atributos), comportamientos
comunes (operaciones) y relaciones con otras clases de objetos. Por ejemplo Persona es una clase, y Joe Smith
es una persona en particular, un objeto. Cada objeto es una instancia de su clase.

Cada objeto "sabe" de que clase es, la clase es una propiedad implícita en un objeto. Esto es válido mientras se
implemente en un lenguaje orientado a objetos.

Agrupar los objetos en clases permite una abstracción del problema, esto permite una solución más general y
no especifica para algunos casos.

Diagrama de Objetos

El diagrama de objetos provee una representación formal y grafica de los objetos, clases y sus relaciones. Los
diagramas son concisos y fácil de entender. Hay dos tipos de diagramas.

Diagrama de clases: Es un esquema o patrón de las clases de objetos y sus relaciones.

Diagrama de instancias: Es una representación de un juego especifico de objetos y sus relaciones. Es útil para
documentar casos de prueba, y discutir ejemplos.

El diagrama de clases describe el caso general, mientras que el de instancias un caso en particular. Eviten
mesclar objetos y clases en un mismo diagrama.

Atributos

Un atributo es un dato guardado por un objeto en una clase. Por ejemplo nombre, edad, peso son atributos de
la clase Persona. Cada atributo tiene un valor para cada objeto, diferentes objetos pueden tener el mismo o
diferente valor en algún atributo. Cada nombre de atributo debe ser único en la clase. Varias clases pueden
tener atributos con el mismo nombre. Por ejemplo una persona y una compañía pueden tener el atributo
dirección.

Un atributo solo puede tener un dato puro, no un objeto. Un dato puro no tiene identidad. Por ejemplo todos
los números "17" son indistinguibles entre sí, como todas las palabras "Canadá". El país Canadá es un objeto,
el atributo "nombre" tiene el valor "Canadá". La capital de Canadá es un objeto y no debe ser modelado como
un atributo, pero relacionado con el objeto país.

Cada objeto es único, pero el ID del objeto o identificador del objeto no debe ser modelado como un atributo
(es intrínseco de cada objeto). No confundir identificadores internos de la aplicación con identificadores del
mundo real como matricula del automotor, o DNI de la persona.

Operaciones o Métodos

Una operación es una función o transformación que puede ser aplicado a un objeto de una clase. Todos los
objetos de una clase comparten las mismas operaciones o funciones. Todas las operaciones tiene como
objetivo implícito, un objeto.

El comportamiento de cada operación depende del objeto al que se aplica. Diferentes clases pueden tener las
mismas operaciones conoce su clase. Un método es la implementación de una operación para una clase.

Una operación puede tener más argumentos, además del objeto al que apunta. Esos argumentos parametrizan
la operación, pero no afectan la elección del método. Una operación puede devolver uno o más valores.

Links y asociaciones

Links y asociaciones son formas de establecer relaciones entre objetos y entre clases.

Un link es una conexión física o conceptual entre objetos. Por Ejemplo Joe Smith trabaja en la compañía
Simplex.

Una asociación describe un grupo de links con una estructura y semántica común. Por ejemplo una persona
trabaja para una compañía. Asociaciones y links suelen aparecer como verbos en la descripción del problema.
Las asociaciones son inherentemente bidireccionales, aunque usualmente se lean en una dirección. Por
ejemplo "trabaja para" conecta una persona a una empresa. La inversa puede ser "es empleado de" y conecta
una empresa con una persona. Las dos establecen la misma relación, sólo el nombre establece la dirección.
Multiplicidad

La multiplicidad especifica cuantas instancias de una clase pueden relacionarse a un instancia de una clase
asociada. Multiplicidad suele describirse con "uno" o "muchos", pero de manera general puede ser cualquier
lista de números no negativos. En general la multiplicidad se anota en el diagrama de clases con símbolos
especiales, o un grupo de números como, "1" (exactamente 1), "1+" (uno o más), "3-5" (tres a cinco), "2,4,8"
(dos, cuatro u ocho). Por ejemplo un triangulo tiene exactamente 3 vértices. La multiplicidad restringe el
número de objetos relacionados.

La multiplicidad depende de supuestos y de cómo se definen los bordes del problema. Requerimientos vagos
crea incertidumbre en la multiplicidad. Primero determinen los objetos, clases y asociaciones, luego definan la
multiplicidad.

Propiedades en asociaciones

Igual que en las clases, las asociaciones pueden tener propiedades (atributos). Estos atributos no pueden
asociarse a ninguno de los objetos, pertenecen al link entre los dos objetos.

Agregación

Agregación es la relación "parte de un todo" o "parte de ...", representa la relación entre componentes y su
ensamblaje. Por ejemplo un auto está compuesto por grupo motor, chasis y carrocería; el grupo motor, por
motor, caja de cambios; carrocería por cuerpo, puertas, etc. Las propiedades más importantes son
transitividad, si A es parte de B y B es parte de C, entonces A es parte de C. La agregación es también
antisimétrica, si A es parte de B, B no es parte de A. Algunas propiedades del ensamblaje se propagan a sus
partes, posiblemente con alguna modificación local. Por ejemplo si un auto tiene cierta velocidad, o está en un
lugar, también lo están sus puertas y su motor.
Generalización

Generalización es una poderosa abstracción para compartir similitudes entre clases. Por ejemplo, todas las
piezas de equipamiento tiene un fabricante, peso y costo. Las bombas además tiene presión y velocidad de
flujo. Los tanques también tienen presión y volumen. Nosotros queremos definir las propiedades de
equipamiento y luego agregar detalles para las bombas y tanques.

Generalización es una relación entre una clase y una o más clases más refinadas de ella. La clase inicial se llama
superclase y las clases refinadas subclases. Por ejemplo equipamiento es una superclase, y tanque una
subclase. Los atributos comunes a un grupo de subclases son modeladas en la superclase. Cada subclase
hereda los atributos y operaciones de la superclase. Por ejemplo la bomba hereda las propiedades fabricante,
peso y costo de la clase equipamiento. La generalización algunas veces es llamada "es un" ("is-a" en ingles, y
abreviado como isa).

Modelo dinámico
Las relaciones temporales pueden ser difíciles de entender. El sistema se puede entender mejor si primero se
examina su estructura estática (diagrama de clases). Los aspectos del sistema que cambian con el tiempo
constituyen el modelo dinámico. El funcionamiento de un sistema se puede describir como una secuencia de
tareas que realiza (estados), y una descripción de los sucesos (eventos) que la hace cambiar de tarea.

Los valores de los atributos y links almacenados en un objeto son su estado. A lo largo del tiempo los objetos
estimulan a cada uno de los demás, resultando en una serie de cambios de estado. Un estímulo desde un
objeto se llama evento. La respuesta a un evento depende del estado del objeto que lo recibe.

El diagrama de Estados-Eventos es una representación gráfica de los diferentes estados que puede tomar un
sistema y los eventos que lo hacen cambiar de estado. Esta descripción se conoce como Modelo Dinámico.

Escenarios

Cada escenario es un listado de la secuencia de eventos durante una ejecución particular del sistema. Se trata
de un registro histórico y ordenado cronológicamente. El objetivo es explorar todos los escenarios posibles en
el sistema, incluyendo los de uso normal, poco frecuentes y fallas o desperfectos que el sistema debe
controlar. Por ejemplo:

 El sistema actualiza y muestra la temperatura.

 Se presiona el botón de encendido.
 El sistema enciende la resistencia.
 El sistema muestra la temperatura máxima configurada.
 Pasados 5 segundos.
 El sistema actualiza y muestra la temperatura.
 Se presiona el botón de encendido.
 El sistema apaga la resistencia.
 El sistema actualiza y muestra la temperatura.

Eventos

Los eventos son sucesos que ocurren en un momento en el tiempo y modifican el funcionamiento del sistema.
Los eventos tienen una duración instantánea. Ningún evento es realmente instantáneo, pero para la escala de
tiempo que se está analizando, pueden considerarse como instantáneos. Los eventos pueden no estar
relacionados, por ejemplo presionar el botón A o el botón B, o pueden estar relacionados (relación causal), por
ejemplo es necesario el evento tomar un colectivo, antes del evento bajar del colectivo.

Un evento es una transmisión de información en un sentido de un objeto a otro. Un objeto que envía un
evento a otro puede esperar una respuesta, pero la respuesta es un evento separado bajo el control del
segundo objeto, que puede elegir enviarlo o no. Por ejemplo:

 Presionar un botón.
 El sensor llega a determinado valor.
 Pasa un tiempo determinado.

Estados

Un estado es una abstracción de los valores y links de un objeto. Los estados especifican la respuesta de un
objeto a un evento dado. Un estado corresponde al intervalo entre dos eventos recibidos por un objeto.
Tienen una duración, ocurren en un intervalo de tiempo. Un estado puede estar asociado a una actividad
continua, o una actividad que lleve un tiempo completarse. Los eventos y estados dependen de la escala de
tiempo que se está analizando. Por ejemplo:

 El sistema actualiza y muestra la temperatura.

 la jarra calienta el agua.

Diagrama de Estados

El diagrama de estado es una representación gráfica de los estados y eventos de un sistema. Cada nodo
representa un estado, y las flechas que los unen son los eventos (transiciones de un estado a otro). Una
secuencia de eventos corresponde a un camino en el gráfico. El diagrama de estados-eventos depende de la
escala de tiempo y del nivel de abstracción que se está analizando. Se pueden realizar diversos diagramas del
total del sistema o de parte del mismo en diferente escala temporal o nivel de abstracción. Un estado en un
diagrama de estado puede convertirse en una serie de estados y eventos en otra escala de tiempo o de
abstracción. El diagrama de estados describe el comportamiento de una clase de objetos, todas las instancias
de esa clase comparten el mismo diagrama de estados.
Condiciones

Los eventos pueden tener condiciones, si se dispara un evento, se controla la condición antes de pasar al
nuevo estado. La condición deben ser evaluable como verdaderas o falsas. Por ejemplo:

 Temperatura <100.
 Nivel>10.

Operaciones

Las operaciones describen el comportamiento del sistema, se diferencian en actividades y acciones.

Actividades

Las actividades están asociadas a los estados del sistema, es decir solo los estados pueden tener actividades.
Las actividades toma tiempo en ser completada. Pueden ser continuas o de duración determinadas, también
pueden repetirse indefinidamente. Por ejemplo:

 Mostrar la temperatura en un display.

 mantener la velocidad de un motor entre ciertas velocidades.

Acciones

En general están asociadas a eventos, y son de duración instantánea. Cuando un evento se dispara, se puede
indicar que ejecuten una o más acciones. En algunos casos se puede hacer una o más acciones al entrar o al
salir de un estado. Por ejemplo:

 Encender un LED.
 Apagar un motor.

Representación

Cada estado se representa con un rectángulo redondeado. En su interior se coloca el nombre del estado, en la
sección hacer se indica las actividades que se realizan en dicho estado. En la sección entrada y salida se
colocan las acciones que se ejecutan al entrar en el estado, y al salir del mismo, estas secciones son
opcionales.

Cada evento se representa con una flecha que señala al estado que se pasa. Lleva el nombre del evento, que
describe la condición que dispara el evento. Entre corchetes se colocan otras condiciones que se deben
cumplir para disparar el evento, luego se separa con una barra las acciones que se ejecutan al dispararse la
acción, estas son opcionales.
Ejemplo de una jara eléctrica digital

Modelo funcional
El modelo funcional describe los cálculos del sistema, sin especificar cómo o cuándo son calculados. El modelo
funcional consiste en varios diagramas de flujo de datos.

Diagrama de flujo de datos

El diagrama de flujo de datos muestra la relación funcional entre los valores calculados por el sistema desde
entradas externas, a través de operaciones, almacenamiento interno, hasta salidas externas. No muestra
información de control, cuando el proceso es ejecutado, o decisiones de flujos alternativos de los datos, esta
información pertenece al modelo dinámico.

El diagrama de flujo de datos contiene: procesos, que transforman datos; actores, objetos que producen o
consumen datos; y almacenamiento de datos, objetos que guardan datos pasivamente.

Procesos: El nivel más simple de proceso es una función pura, por ejemplo sumar dos números, o una
equación. Un proceso más complejo puede tener componentes no funcionales como almacenamiento de
datos. Un diagrama de flujo de datos entero puede considerarse como un proceso en otra escala de
desagregación. Cada proceso tiene una cantidad fija de flujo de datos de entrada y de salida. Los cálculos
utilizados para obtener los datos de salida también tiene que ser especificados. Procesos complejos pueden
subdividirse en diagramas de flujo de datos, pueden describirse en lenguaje natural, o como ecuaciones
matemáticas. Finalmente los procesos son implementados como métodos dentro de objetos.

Flujo de datos: Un flujo de datos conecta la salida de un objeto o proceso con la entrada de otro objeto o
proceso. El fuljo de datos no cambia los valores. Un mismo dato puede enviarse a más de un proceso. Un dato
compuesto puede dividirse en datos simples que se dirigen a objetos o procesos distintos. Inversamente varios
datos simples pueden combinarse en uno complejo. Cada flujo de datos representa un dato intermedio en
algún punto del cálculo.

Actores: Un actor es un objeto activo que dirige el flujo de datos produciendo o consumiendo datos. Las
acciones de los actores al inicio o final del diagrama de flujo de datos (terminadores), esta fuera del alcance
del diagrama de flujo de datos, pero puede ser parte del diagrama dinámico. Los actores pueden ser objetos
del sistema o también pueden ser dispositivos del sistema, como un termostato, o un motor controlado por el
sistema (representados como objetos en el diagrama de objetos).

Almacenamiento de datos: Un almacenamiento de datos es un objeto pasivo que almacena datos para un uso
posterior. A diferencia de un actor no genera ninguna operación con los datos, solo responde a una petición de
guardar o leer datos. Un almacenamiento de datos se puede implementar como un archivo en disco, una base
de datos o almacenarse temporalmente en memoria.

Ambos, actores y almacenamiento de datos, pueden implementarse como objetos, se distinguen por su
comportamiento.

Complejidad del modelo

El modelo de objetos es importante para problemas con una estructura de datos no trivial. Un programa no
interactivo como un compilador tiene un modelo dinámico trivial, su propósito es calcular una función, el
modelo funcional describe mejor estos programas. Muchos programas interactivos, como un cajero
automático, tienen un modelo dinámico complejo. En contraste una base de datos tiene un modelo funcional
trivial, su propósito es organizar y guardar datos, no transformarlos.
Consejos
Algunos consejos al realizar los diagramas.

Modelo de objetos

 No construyan el modelo de objetos juntando clases, asociaciones y herencia. Primero deben

entender el problema a resolver. El contenido del modelo de objetos debe ser relevante para la
solución.
 Traten de mantener el modelo simple, eviten complicaciones.
 Elijan cuidadosamente los nombres, estos traen fuertes connotaciones. Los nombres deben ser
descriptivos, precisos y sin ambigüedad. Los nombres no deben basarse en un solo aspecto del objeto.
Elegir buenos nombres es la parte más difícil del modelo de objetos.
 No incluyan referencias a otros objetos como atributos de un objeto, modélelas como asociaciones.
Esto captura las intenciones y no una decisiones de implementación.
 Traten de evitar asociaciones ternarias o n-arias. Muchas de ellas puede descomponerse en
asociaciones binarias o asociaciones con atributos.
 No traten de obtener la multiplicidad perfecta muy temprano en el desarrollo del programa.
 No compacten los atributos de los links en clases.
 Eviten generalizaciones muy anidadas.
 Revisen las asociaciones uno-a-uno. A veces los objetos en una de las puntas es opcional, cero o uno
es más apropiado. Otras veces, uno a muchos es necesario.
 No se sorprendan si su modelo de objetos requiere revisiones. El modelo de objetos muchas veces
requiere múltiples iteraciones para aclarar nombres, reparar errores, agregar detalles y capturar
correctamente la estructura del problema. Algunos de los modelos de objetos complejos tienen solo
unas pocas hojas, pero requirieron media docena de iteraciones.
 Pidan a otros que revisen su modelo. El modelo de objetos sirve para que otros participen.
 Siempre documenten su modelo de objetos, el diagrama de clases especifican la estructura, pero no
las razones que hay detrás. Escribir una explicación guía al lector a través del modelo y explica las
razones más sutiles de por qué el modelo se estructuro de esa manera en particular
 No trate de usar todos los elementos de construcción del modelo. Muchos elementos son opcionales,
use solo los que necesite para el problema que tiene en la mano.

Modelo dinámico

 Solo construya el diagrama de estados de las clases con un significativo comportamiento dinámico. No
todos los objetos requieren diagrama de estados.
 Controle varios diagramas de estados por eventos compartidos, si es el caso, un diagrama de estados
completo puede ser más correcto.
 Usen escenarios como ayuda para empezar el proceso de construir el diagrama de estados.
 Solo considere los atributos que son relevantes para definir un estado. No necesitan usar todos los
atributos de un objeto en el diagrama de estados.
 Considere las necesidades de la aplicación cuando decida la granularidad de eventos y estados.
 Dejen a la aplicación distinguir entre actividades y acciones. Actividades duran un periodo de tiempo y
las acciones son instantáneas, comparadas con la escala de tiempo de la aplicación.
 Cuando un estado tiene múltiples eventos de entrada, y todos los eventos causan la misma acción,
coloque esta acción en la sección entrada del estado. Hagan lo mismo con los eventos de salida.
 Usen estados anidados cuando el mismo evento se aplica a múltiples estados.
 Las clases asociadas por agregación no tiene que ser expresada explícitamente en el diagrama de
estado. Use estados compuestos para expresar facetas independientes de cada objeto.
  Traten de realizar el diagrama de estados de subclases independiente del diagrama de la superclase. El
diagrama de la subclase debe concentrarse en los atributos únicos de la subclase.
 Estén atentos a condiciones inesperadas y raras. Condiciones raras pueden ocurren cuando un estado
acepta eventos desde más de un objeto.

Ultimas palabras
Es imposible resumir un libro de 500 páginas en un apunte, solo trato de resaltar una metodología para el
desarrollo de sistemas. Para más información les recomiendo leer el libro completo.

Por último, como menciona el libro, está metodología es independiente de la implementación, y puede
utilizarse incluso cuando se programe en un lenguaje que no sea orientado a objetos.