Apunte Ingeniería de Software I - 2015 - U07 Análisis Orientados A Los Objetos (OMT)

Contenido
Tema 7: Análisis Orientados a los Objetos (OMT)...................................................................................................4

Herramientas del Análisis y Diseño Orientado a Objetos........................................................................................4
Análisis de la estructura de objetos (AEO)..........................................................................................................4
Asociaciones de Objetos.................................................................................................................................4
Estándares recomendados de diagramación..................................................................................................4
Jerarquía de generalización............................................................................................................................8
Subtipos y Supertipos......................................................................................................................................8
Diagramas de Ramificación.............................................................................................................................8
Jerarquías Compuestas...................................................................................................................................9
Tipos de objetos derivados.............................................................................................................................9
Diagramas de relación entre objetos..............................................................................................................9
Análisis de comportamiento de objetos (ACO).................................................................................................10
Estado de un objeto......................................................................................................................................10
Eventos.........................................................................................................................................................10
Tipos de Eventos...........................................................................................................................................10
Ciclo vital de un objeto..................................................................................................................................11
Interacciones entre tipos de objetos.............................................................................................................12
Operaciones..................................................................................................................................................13
Reglas de activación......................................................................................................................................14
Condiciones de control.................................................................................................................................14
Subtipos y supertipos de eventos.................................................................................................................15
Aislamiento de la causa y el efecto...............................................................................................................16
Diagramas de flujo de objetos.......................................................................................................................16
Diseño de la estructura y comportamiento de un objeto.................................................................................17
Clase..............................................................................................................................................................17
Herencia de clase..........................................................................................................................................18
Selección del método....................................................................................................................................18
Polimorfismo.................................................................................................................................................19
Metodología OMT.............................................................................................................................................19
Modelo de Objetos.......................................................................................................................................19
Fundamentos del AEO y del ACO..........................................................................................................................26
Análisis de la estructura de Objetos (AEO)........................................................................................................26
Conceptos y Objetos.....................................................................................................................................26
Conceptos sin Objetos..................................................................................................................................27
Objetos sin conceptos...................................................................................................................................27
Intensidad y extensión del objeto.................................................................................................................27
Administración de la complejidad de un objeto............................................................................................27
Abstracción...................................................................................................................................................27
Generalización..............................................................................................................................................27
Jerarquía de Conceptos.................................................................................................................................27
CARRERA: LICENCIATURA EN SISTEMA DE INFORMACION
LIC. EN TECNOLOGIAS DE LA INFORMACION
CATEDRA: INGENIERIA DE SOFTWARE 1
PROFESOR: LIC. CRISTIAN FERNANDO CERQUAND
AÑO: 2015
Composición.................................................................................................................................................27
Composición Inmutable................................................................................................................................28
Concepto y la Composición Inmutable..........................................................................................................28
Relaciones n-adas o de n-lugares..................................................................................................................29
Tipos de Objetos y Asociaciones...................................................................................................................29
Funciones......................................................................................................................................................29
Objetos y Tipos de Objetos...........................................................................................................................30
Asociaciones de Objetos...............................................................................................................................30
Jerarquías de Generalización........................................................................................................................30
Jerarquías Compuestas.................................................................................................................................30
Particiones de tipos.......................................................................................................................................30
Niveles de partición.......................................................................................................................................31
Subtipos de una relación...............................................................................................................................32
Especialización por subconjuntos de una relación........................................................................................33
Especialización mediante restricciones de Cardinalidad...............................................................................33
Análisis del Comportamiento de Objetos..........................................................................................................34
Reglas de activación Condiciones de Control Subtipos y Supertipos de Eventos..........................................34
Estados de un Objeto....................................................................................................................................34
Eventos.........................................................................................................................................................34
Estados..........................................................................................................................................................35
Representación combinada...........................................................................................................................36
Operaciones..................................................................................................................................................37
Fuentes externas de eventos........................................................................................................................37
Reglas de activación......................................................................................................................................37
Condiciones de Control.................................................................................................................................37
Subtipos y Supertipos de Eventos.................................................................................................................38
Análisis del comportamiento de objetos mediante esquemas de eventos...................................................39
Paso 1. Aclaración del tipo de evento...........................................................................................................40
Nivelación de los resultados..........................................................................................................................44
Eventos y análisis de objetos.........................................................................................................................45
Diagrama de flujo de objetos........................................................................................................................46
Actividades....................................................................................................................................................48
Productos y productos derivados..................................................................................................................49
Productos consumidos..................................................................................................................................49
Nivelación de la actividad..............................................................................................................................50
Nivelación de los diagrama de flujo de objetos y esquema de eventos........................................................50
Actividades como tipos de objetos...............................................................................................................50
Metodología OMT.................................................................................................................................................51
El Modelo de Objetos........................................................................................................................................51
Objetos y Clases............................................................................................................................................51
Clase:.............................................................................................................................................................51
2
AÑO: 2015
Diagrama de Objetos....................................................................................................................................51
Notación de clases y objetos Atributos.........................................................................................................52
Notación de atributos Operaciones y Métodos............................................................................................52
Notación de operaciones y métodos.............................................................................................................52
Enlaces y Asociaciones..................................................................................................................................52
Multiplicidad.................................................................................................................................................53
Atributos de los enlaces................................................................................................................................53
Modelando una Asociación como una Clase.................................................................................................53
Roles.............................................................................................................................................................54
Ordenación...................................................................................................................................................54
Cualificadores................................................................................................................................................54
Agregación....................................................................................................................................................55
Generalización y herencia.............................................................................................................................55
Agregación vs. Generalización......................................................................................................................56
Clases abstractas...........................................................................................................................................56
Herencia múltiple..........................................................................................................................................56
Metadatos.....................................................................................................................................................56
Características de clase.................................................................................................................................56
Claves candidatas..........................................................................................................................................57
Restricciones.................................................................................................................................................57
Homomorfismo.............................................................................................................................................57
Modelo de Datos vs Modelo de Objetos.......................................................................................................57
Resumen del Modelo de Objetos..................................................................................................................57
Diferencias entre el Modelo de Datos y el Modelo de Objetos.....................................................................57
Cambios introducidos por OMT-2.................................................................................................................58
El Modelo Dinámico..........................................................................................................................................58
Introducción..................................................................................................................................................58
Sucesos y Estados..........................................................................................................................................58
Operaciones..................................................................................................................................................60
Diagrama de Estado anidados.......................................................................................................................60
Generalización de Estados............................................................................................................................60
Generalización de Sucesos............................................................................................................................61
Concurrencia.................................................................................................................................................61
Relación entre Modelo de Objetos y Modelo Dinámico...............................................................................63
Consejos prácticos........................................................................................................................................64
El Modelo Funcional......................................................................................................................................64
Diagrama de Flujo de Datos..........................................................................................................................64
3
AÑO: 2015
Tema 7: Análisis Orientados a los Objetos (OMT)
Herramientas del Análisis y Diseño Orientado a Objetos

Análisis de la estructura de objetos (AEO)
Define las categorías de los objetos que percibimos y las formas en que las asociamos. En esta etapa
identificamos:
 Que son los tipos de objetos y como se asocian?
Se representan mediante esquemas de objetos. Sirve para guiar en la definición de clases y estructuras de
datos.
 Como se organizan los tipos de objetos en subtipos y supertipos?
Se organizan en diagrama e indican las direcciones de herencia.
 Cuál es la composición de los objetos complejos?
Se elaboran diagrama de jerarquía y quien en la definición de mecanismos que controlen adecuadamente a los
objetos dentro de otro objetos.
Asociaciones de Objetos
También es importante modelar la forma como los objetos se asocian entre si.-
En el análisis, es útil nombrar alguna forma a las asociaciones e indicar la cantidad de objetos de un tipo dado
que se debe asociar con los objetos de otro tipo, puesto que esto le da significado y aumenta la comprensión
de la asociación.
Aunque en la figura 6-01 ilustra las asociaciones entre dos tipos de objetos , no se indica el significado de la
asociación. Además del significado, tampoco se indica la cantidad de objetos con los que un objeto dado puede
y debe asociarse. En el análisis, es útil nombrar de alguna forma las asociaciones e indicar la cantidad de
objetos de un tipo dado que se deben asociar con los objetos de otro tipo puesto que esto le da significado y
aumenta la comprensión de la asociación, véase la figura 06-02.
Figura: 6.1: Los objetos de un tipo se asocian con los objetos de otros tipos.
Figura: 6.2: Asociación con objetos determinados y restricciones
Estándares recomendados de diagramación

Los diagramas deben aparecer en las herramientas CASE OO, estas herramientas deben recoger la información
suficiente para impulsar a un generador de códigos a producir un código libre de errores de sintaxis. Por lo
tanto, los diagramas deben tener una precisión del tipo de la ingeniería.
4
AÑO: 2015
Los diagramas convencionales se utilizan ampliamente en as herramientas CASE. En la medida de lo posible, los
diagramas para las técnicas OO deben incorporar los empleados en las técnicas convencionales.
Los diagramas que utilizamos para los procesos complejos son una forma de lenguaje.
Con las computadoras, creamos procesos más complejos que los que llevamos a cabo en forma manual. Los
diagramas adecuados nos ayudan a visualizar e idear esos procesos.
Si solo una persona desarrolla el diseño de un sistema o de un programa, los diagramas que utiliza le ayudan a
aclarar su pensamiento. Una mala elección en las técnicas de diagramación llega a inhibir el pensamiento; en
cambio, una buena elección puede acelerar el trabajo y mejorar los resultados.
Cuando varias personas trabajan en un sistema o en un programa, los diagramas son herramienta esencial para
la comunicación. Además, al modificarse los sistemas, los diagramas claros pueden facilitar el mantenimiento.
Un reto vital para los sistemas de información de la actualidad es mejorar la comunicación entre profesionales
de los sistemas y los empresarios. Los profesionales de los sistemas deben comprender la empresa e idear la
forma en que debe cambiar. Los empresarios deben pensar en forma más clara acerca de los sistemas y la
automatización.
Los diagramas y su manejo mediante computadora son una forma de proceso del pensamiento.
El analista, el diseñador, el programador, el usuario y el ejecutivo necesitan una familia de tipos de diagramas
que les ayuden a pensar con claridad, estos diagramas deben ser claros y sencillos, y deben ser lo bastante
completos y rigurosos como para servir de base a la generación de código, así como para la conversión
automática de un tipo de diagrama en otro. Los diagramas son la documentación de los sistemas (junto con los
depósitos, que almacenan el significado de los diagramas y la información adicional recolectada cuando fueron
trazados).
Los diagrama para el diseño de sistemas son un lenguaje de comunicación. Las buenas herramientas CASE
obligan a la precisión de este lenguaje. Como en los otros lenguajes, se deben aplicar estándares de modo que
se puedan comunicar las diversas partes.
Los diseñadores deben evitar idear sus propias formas de diagramación. Los investigadores deben utilizar las
técnicas de diagramación existentes cuando sean aplicables. La diagramación incompatible es una barrera para
la comunicación.
Se cuenta con una gran cantidad de símbolos de uso común en los diagramas con herramientas CASE que
utilizan técnicas convencionales, como también símbolos que se utilizan para el análisis y diseño orientado a
objetos y que amplían el conjunto de símbolos.
Normalmente los nodos que representan datos se dibujan como rectángulos con esquinas rectangulares
(c(campos, tipo de ente, etc.) y los cuadros que representan actividades, se dibujan con cuadros con esquinas
redondeadas (procedimientos, procesos, módulos de programas, etc.).
Del mismo modo se recomienda que las clases y los tipos de objetos se representen con cuadros de esquinas
rectangulares y las actividades con cuadros de esquinas redondeadas.
Figura: 6.3: a) Clase, objeto o dato b) Proceso u operación

Para representar la realidad en si en los diagramas, por ejemplo para representar objetos físicos que se
trasladan de un proceso a otro se utilizan cuadros tridimensionales u otras figuras que representen el objeto.
Los objetos y las operaciones externas al sistema, pero que afectan al mismo, se dibujan como cuadros
sombreados.
Figura: 6.4: Representan la realidad (Objetos físicos)
5
AÑO: 2015
Figura: 6.5:
Operaciones externas
Las líneas que unen los nodos representan conceptos como asociaciones, descomposición, flujo, dependencia
del tiempo y reglas de activación.
A veces indican la dirección del procesamiento. Por ejemplo en un evento puede indicar que una operación
debe ocurrir antes que otra, o en un diagrama de activación indica que la ocurrencia de un evento es anterior a
una operación y causa el llamado de una operación.
En un caso es precedencia, en el otro indica causalidad.
Cuando un nodo queda asociado con uno y solo un grupo de nodos se denomina exclusividad mutua y se
representa mediante una línea de ramificación con un círculo relleno en esa ramificación.
La exclusividad mutua también puede ser representado como una caja con divisiones.
Esta forma de representación de la exclusividad mutua se capitaliza para la representación de la generalización,
desde el punto de vista OO.
Por ejemplo, si colocamos bienes y servicios en una partición, indicamos con ello que estos tienen atributos y
operaciones comunes. Por ejemplo, todos los productos tienen un clave única (identificación del producto) y
participan en las operaciones de procesamiento de pedidos. Si no identifica un supertipo común, el analista
corre el riesgo de definir atributos y operaciones redundante..
El termino restricciones de cardinalidad se refiere a la restricción de la cantidad de elementos que se pueden
asociar con otro.
Uno a Muchos. La pata de gallo indica que una o mas instancias de B se pueden asociar con una instancias de A.
Uno a uno. Uno instancia de B se asocia con uno instancia de A.
Figura: 6.6:
Figura: 6.7:
Exclusividad mutua
Cardinalidad nula. Un cero como parte del símbolo de restricción de Cardinalidad indica que una instancia de
un tipo de objeto no queda asociado con una instancia de otro tipo. En otras palabras, un objeto de un tipo
puede tener asociaciones nulas con los objetos de otro tipo.
Cardinalidad máxima y mínima. El máximo se coloca siempre junto a la caja (rectángulo) a la que se refiere.
Cuando el máximo y el mínimo son iguales a 1, se colocan dos barras ! en la línea, estas indican uno y solo uno.
La figura siguiente muestra objetos y sus asociaciones con Cardinalidad.
6
AÑO: 2015
Figura: 6.8:
Casos de cardinalidad
El etiquetado de líneas. En algunos diagramas las líneas tienen una etiqueta. Las líneas entre los tipos de
eventos y las operaciones son unidireccionales. Por otro lado, las líneas entre las cajas de los tipos de objetos
son por lo general bidireccionales.
La línea se puede leer en cualquier dirección. Solo se necesita etiquetar las líneas en una dirección, aunque se
recomienda etiquetar todas las asociaciones entre los tipos de objetos.
Una etiqueta sobre una línea horizontal es el nombre de la asociación, cuando se lee de izquierda a derecha.
Una etiqueta debajo de una línea horizontal es el nombre de la asociación, cuando se lee de derecha a
izquierda.
Figura: 6.9: Forma

de lectura de las asociaciones
Cuando los diagramas se tornas complejos se utiliza el anidamiento de los mismos.
Varios bloques o líneas adyacentes pueden comprimirse en un bloque o línea.
También se pueden utilizar ventanas para cuando se utilizan distintos tipos de ideas o representaciones. Es
decir combinar diagramas de eventos con diagramas de objetos o viceversa.
7
AÑO: 2015
Jerarquía de generalización
Una de las vías de sentido común por lo que el hombre organiza su volumen de conocimiento es el de las
jerarquías, de lo mas general a lo mas especifico.
Un tipo de objeto puede tener subtipos, sub-subtipos, etc. Normalmente cada tipo no tiene mas de un
supertipo (ver figura 06-11), sin embargo también podemos encontrar que un tipo tenga varios supertipo, lo
que implica que la jerarquía de generalización no necesariamente debe ser una jerarquía de árbol.
Las jerarquías de generalización son importantes para el desarrollador OO por dos razones. La primera es que el
uso de supertipos y subtipos proporciona una herramienta útil para describir el mundo del sistema de
aplicación. La segunda es que indica las direcciones de herencia entre las clases en los lenguajes de
programación.
Figura: 6.10: Jerarquía de Generalización
Subtipos y Supertipos
Como ya se ha dicho, los tipos de objetos pueden tener tipos más particulares, llamados subtipos y tipos más
generales, llamados supertipos.
Una partición de subtipos puede ser una partición completa si contiene todos los subtipos posibles; o bien, una
partición incompleta si hay más subtipos. Un área vacía en la parte inferior de la caja de partición indica una
partición incompleta.
Figura: 6.11:
Supertipo/Subtipo
Un tipo de objeto puede tener muchos subtipos diferentes.
Diagramas de Ramificación
La generalización se representa, como ya hemos visto, por lo común, mediante un diagrama de ramificación,
como en la figura 06-14. Este diagrama avanza de izquierda a derecha y, por lo general no tienen flechas.
Puesto que la herencia se basa en la generalización, los diagramas son útiles, ya que indican la dirección de la
herencia. Sin embargo, no muestran lo que se hereda ni cómo funcionará el mecanismo de herencia dentro de
un lenguaje de programación OO dado. Por lo tanto, los diagramas que muestran la jerarquía de tipo/subtipo se
llaman jerarquías de generalización en vez de jerarquías de herencia.
Algunas veces un diagrama de ramificación muestra instancias de objetos. La instancias
se unen a su tipo de objeto mediante líneas punteadas.
8
AÑO: 2015
Figura: 6.12:
Diagramas de Ramificación
Jerarquías Compuestas
Algunos tipos de objetos se consideran complejos, por que queremos indicar que determinados objetos están
formados por otros.
En el análisis OO, la composición de un objeto nos ayuda a describir el echo de que los dibujos están formados
por determinada configuración de símbolos, los trabajos lo están por tareas especificas, las organizaciones por
otras organizaciones, y así sucesivamente.
En los sistemas de tecnología avanzada, el analista describe la forma en que un pedido no solo puede constar
de elementos en cada renglón, sino contener también instrucciones verbales del cliente o un diagrama hecho a
mano, los pedidos de este tipo se llaman objetos complejos.
Cada pedido se puede controlar como un objeto único que conste de otros, los cuales, a su vez, se pueden
controlar de forma independiente, en caso necesario.
Las estructuras de árbol y de red pueden mostrar más que generalización y la herencia.
También se llegan a utilizar para indicar que un objeto está compuesto por otros. El diagrama de composición
de los objetos se debe dibujar de modo que se distinga de inmediato de un diagrama de generalización. Esto se
logra al colocar flechas huecas (perfiladas) en el diagrama de composición y flechas sólidas (llenas), en el
diagrama de generalización.
La expresión de las restricciones de cardinalidad en las asociaciones por composición es importante, puesto que
un objeto compuesto puede estar formado por cero, uno o muchos objetos de distintos tipos.
Los símbolos de restricción de cardinalidad no se muestran en los diagramas de generalización.
En ciertos casos, la generalización y la composición se muestran en el mismo diagrama.
Esto puede llegar a confundir a principiantes en el análisis OO.
Tipos de objetos derivados

Las instancias de un tipo de objeto suelen quedar determinadas si alguien hace una afirmación, sin embargo, el
conjunto de instancias de muchos tipos de objetos pueden ser derivado. Por ejemplo el conjunto de todas las
personas adultas se deriva del conjunto de personas que han llegado a la edad de 18 años. Para simbolizar que
se trata de instancias derivadas de otra se simboliza con un barra en la caja.
Figura: 6.13: Objeto derivado
Diagramas de relación entre objetos

Un diagrama de relación entre objetos es esencialmente igual a un diagrama de relación entre entidades.
Cada cuadro puede ser un tipo de objeto en el análisis de la estructura de objetos.
Normalmente se presenta el diagrama de jerarquía y el diagrama compuesto, todo junto en un mismo
diagrama que recibe el nombre de esquema de objetos.
9
AÑO: 2015
Análisis de comportamiento de objetos (ACO)

Aquí realizamos esquemas de eventos que muestran eventos, la secuencia en que ocurren y como los eventos
cambian el estado de los objetos. Por lo tanto, una herramienta CASE para el análisis orientado a objetos debe
permitir construir esquemas de objetos y de eventos y mantener la relación entre ellos.
Estado de un objeto
Un objeto puede existir en varios estados.
Ejemplo 6.1 Objeto: reservación aérea puede ser una instancia de los siguientes tipos de objetos;
Ejemplo 6.2 reservación solicitada, reservación confirmada, reservación cancelada, reservación satisfecha,
reservación archivada, etc.
En el análisis del comportamiento de objetos identificamos la siguiente información:
 En qué estado puede estar un objeto?
 Que transiciones de estado se puede dar?
 Que eventos ocurren?
 Que operaciones se llevan a cabo?
 Que interacciones ocurren entre objetos?
 Cuáles son las reglas de activación que se utilizan para reaccionar ante el evento?
 Como se representan las operaciones en los métodos?
Un objeto puede ser al mismo tiempo una instancia de varios tipos de objetos.
Ejemplo 6.3 Reservación totalmente pagada, este objeto, al mismo tiempo podría ser una instancia: reservación
de cierta compañía.
El estado de un objeto es la colección de los tipos de objeto que se aplican a él.
Al implementarlo en un lenguaje de programación OO, el estado se registra en los datos almacenados con
relación al objeto. Se determina mediante las clases y valores de los campos de los estados asociados con el
objeto. Así, en general, los programadores OO utilizan otra definición de estados.
El estado de un objeto es la colección de asociaciones que tiene un objeto.
Eventos
Nuestro mundo esta lleno de eventos (un elefante tiene elefantitos). Un evento es un cambio en el estado de
un objeto.
Es necesario saber de los cambios de estado, notar que ocurren, para ello los eventos sirven como indicadores
de los instantes en que ocurren los cambios. En un mundo sin eventos, podríamos construir base de datos sin
preocuparnos por actualizarlas, sin embargo, en la mayoría de las aplicaciones, si debe cambiar el contenido de
las bases, y nosotros deseamos saber de esos cambios y reaccionar en forma adecuada ante ellos, para lo cual
debemos entender y modelar dichos eventos.
El analista no necesita conocer cada evento que ocurra, tan solo los tipos de eventos y de las instancias de tipos
de eventos.
Tipos de Eventos
Los tipos de eventos indican los cambios sencillos en el estado de un objeto.- Los tipos de
eventos describen las siguientes formas de cambio de estado:
 Un objeto se crea
 Un objeto se termina
 Un objeto se clasifica como instancia de un tipo de objeto
 Un objeto se descalifica como una instancia de un tipo de objeto
 Un objeto cambia de clasificación
 El atributo de un objeto se cambia
10
AÑO: 2015
Figura: 6.14:
Evento
Los objetos pueden asociar un objeto con otro.
Ejemplo 6.4 En la mayoría de las organizaciones, cuando un objeto se clasifica como empleado, debe estar
asociado con un departamento. Un evento clasificara al objeto como empleado. Otro evento creará una
asociación entre el objeto empleado, y un objeto Departamento.
Algunos eventos requieren que antes ocurran otros eventos. Otras veces un evento puede provocar la creación
en cadena de otros eventos.
Una operación hace que los eventos ocurran. Dibujamos la operación como un cuadro con esquinas
redondeadas, puesto que los eventos indican los puestos en el tiempo en que se da el cambio de estado de un
objeto. Los tipos de eventos se representan como triángulos negros llenos, generalmente unidos a las cajas de
operación.
Figura: 6.15:
Más de un evento
Según el área que se modele, puede ocurrir más de un evento al terminar una operación, y cada uno de éstos
puede activar operaciones independientes.
Ciclo vital de un objeto

La mayoría de los objetos tienen un ciclo vital en el que una sucesión de eventos pueden ocurrirle y cada uno
de estos modifica su estado.
Al crear por primera vez el objeto reservación aérea, puede pasar por los estados reservación solicitada,
reservación en lista de espera, reservación confirmada, reservación cumplida y reservación archivada. Otros
eventos puede hacer que se convierta en reservación denegada o reservación cancelada.
11
AÑO: 2015
En el análisis orientado a objeto, dibujamos un diagrama que muestra el ciclo vital de un objeto. Además de
mostrar los estados posibles de los objetos, el diagrama también muestra los cambios de estado permisibles, a
este tipo de diagramas denominamos diagramas de estados.
Figura: 6.16:
Diagrama de Estados
Las transiciones se representan mediante líneas verticales, los cuales unen a los estados.
Podemos colocar un signo ”+” en algún estado que se quiera descomponer en subestados.
También podemos registrar en los cambios estados que ocurren bajo ciertas condiciones, esto lo simbolizamos
con un circulo al vacío al inicio de cada cambio de estado.
También podemos reflejar cardinalidad en los cambios de estados.
Un objeto puede tener muchos estados permisibles. Si los subestados de un estado en particular no se
muestran en un diagrama, aparecen puntos suspensivos () o un símbolo ”+” al lado del estado.
Un evento es un cambio en el estado de un objeto, de tal forma que podemos interactuar con los diagramas de
transición de estados a partir de eventos, como también podemos hacerlo desde un cambio de estado de un
diagrama de estado asociarlo con un esquema de eventos.
También podríamos reflejar los cambios de estados en los esquemas de eventos con una línea al costado de
una regla de activación entre un evento y una operación.
Interacciones entre tipos de objetos

Los diagramas de transiciones de estado son útiles para expresar el ciclo vital de un objeto particular. Sin
embargo, la mayoría de los procesos requieren la interacción de varios objetos.
12
AÑO: 2015
Figura: 6.17:
Diagrama de Red
El diagrama de red muestra como los distintos tipos de objetos cambian de estado y pueden solicitar a otros
objetos que cambien su estado en el proceso.
Los tipos de objetos se implantan como clases y las operaciones se convierten en operaciones del programa
OO. Si, durante el análisis, el usuario puede expresar los requisitos de procesamiento de esta forma, se facilita
el trabajo del diseñador de LPOO (lenguaje de programación orientada a objetos).
Sin embargo, muchos usuarios no piensan en el procesamiento de aplicación en términos de tipos de objetos,
saturados de operaciones que hacen distintos tipos de solicitudes. Es preferible un formato guión cuando se
dan eventos que activan operaciones, las cuales, a su vez, producen eventos que activan otras operaciones, etc.
En otras palabras, este formato de guión (llamado esquema de eventos) representa los cambios en el ciclo vital
de un objeto particular, el cal activa cambios en el ciclo vital de otro objeto.
Operaciones
En el análisis OO, el termino operación se refiere a una unidad de procesamiento que puede ser solicitada. El
procedimiento se implanta mediante un método. El método es la especificación de como llevar a cabo la
operación. Es el guión de la operación. A nivel programa, el método es el código que implanta la operación.
Las operaciones se invocan. Una operación invocada es una instancia de una operación.
Una operación puede o no cambiar el estado de un objeto. Si lo cambiara, ocurrirá un evento.
Figura: 6.18: Gráfica de Operación

Las operaciones se representa mediante cuadros con esquinas redondeadas. Los tipos de eventos se
representan mediante triángulos sólidos negros conectados en la caja.
Fuentes externas de eventos: los eventos son cambios de estado a los que un sistema debe conocer, y
reaccionar ante de ellos de algún modo. Muchas de las operaciones que producen estos eventos suelen ser
externas al sistema. En estos casos, el símbolo de operación se dibuja como una caja sombreada con esquinas
redondeadas.
13
AÑO: 2015
Figura: 6.19:
Fuentes externas de eventos
Un reloj externo es una forma particular de fuente externa. Indica que un proceso externo emitirá señales d
reloj con cierta frecuencia determinada con anterioridad: al final de cada día, al principio de cada mes, etc.
Reglas de activación
Cuando ocurre un evento, lo usual es que el cambio de estado active el llamado a una o mas operaciones.
Ejemplo 6.5 Si se retiran bienes de un almacén y la cantidad conservada en éste baja de cierto nivel, ello puede
activar una operación para volver a realizar un pedido.
Así, las reglas de activación definen la relación entre la causa y el efecto. Siempre que ocurran un evento de
cierto tipo, la regla de activación invoca a una operación ya definida.
Un tipo de evento puede tener varias reglas de activación, cada una de las cuales invoca a su operación en
paralelo. Las operaciones paralelas pueden producir diferentes cambios de estado en forma simultánea..-
Además, una operación puede ser invocada por varias reglas de activación.
Figura: 6.20: Reglas de Activación

Una línea con una flecha dirigida hacia una caja de operación indica que la operación es activada por la
ocurrencia de un evento anterior. La línea de la regla de activación indica la asociación de un tipo de evento con
la operación llamada. Además, puede indicar la ruta mediante la que se proporcionan los objetos necesarios
para la operación. De esta forma, la regla de activación define una relación de causa entre el evento y la
operación, así como una forma de flujo de datos. Así, las líneas de activación indican dos cosas. La primera es
que ligan la causa (evento) con el efecto (operación). En otras palabras, al ocurrir un evento, una activación
llama a una operación. La segunda es que determina los objetos necesarios como argumentos de la operación
que llama la forma de activación.
Por lo tanto, estas líneas definen las reglas para activar una operación cuando se da un tipo particular de
evento. Por eso, se les llama reglas de activación.
Condiciones de control
Una operación puede ser invocada por una o varias reglas de activación, sin embargo, antes de invocar, se
verifica se puede verificar su condición de control. Si los resultados de evaluación de la condición son
verdaderos, se invoca a su operación. Si son falsos, no se invoca a la operación.
14
AÑO: 2015
Siempre que haya que verificar una condición de control antes de invocar a una operación, esta se representa
mediante un símbolo de forma de rombo antes de la operación.
Las condiciones de control garantizan que un conjunto de eventos esta completo antes de proceder con una
operación.
Las condiciones de control no necesariamente son condiciones y. Pueden ser condiciones elaboradas con y y o.
Siempre se espera que las operaciones, una vez activadas, completen un evento. Cuando se determinan las
condiciones de control, la operación podría no ser llamada hasta que sus condiciones de control sean
verdaderas.
Figura: 6.21: Condiciones de Control

En ciertas ocasiones una línea dirigida hacia una caja de operación indica que la operación no se puede llevar a
cabo hasta que se presente determinado evento. En este caso se puede colocar el símbolo internacional NO
HACERLO o PROHIBIDO en la línea.
Esto se conoce como guardia.
Figura: 6.22:
Guardias
Las líneas conectadas con una caja de operación pueden incluir formas de activación y guardias.
Subtipos y supertipos de eventos

Los tipos ajenos se expresan en este libro mediante particiones de tipo. Por ejemplo, en un ventana
independiente, como lo muestra la figura 06-23, indica que estos dos tipos de eventos son mutuamente
excluyente, puesto que tarea aceptada y tarea rechazada están contenidos dentro de la misma caja de
partición.
La palabra partición implica que algo se divide en subconjuntos ajenos. En las técnicas OO, ese algo se llama
supertipo.
Así, tarea revisada es un supertipo de evento divido en dos tipos de eventos ajenos.
Por lo tanto, el método definido en revisar tarea tiene como objetivo que se revise una tarea. Además, para
lograr este objetivo, se requiere alcanzar alguno de los subobjetivos, aceptar o rechazar la tarea en revisión. En
otras palabras, las particiones de eventos no son operaciones independientes que coordinan las condiciones de
bifurcación para las formas de activación ajenas, sino que indican los objetivos y distintos sub-objetivos de las
operaciones a las que están asociadas.
15
AÑO: 2015
Figura: 6.23: Subtipo/Supertipo de eventos

La operación que hace que ocurra un evento puede ser compleja. La acción de poner en marcha un automotor,
pareciera sencillo, pero desde el punto de vista interno, el encendido de un automotor requiere de todo un
conjunto de operaciones y eventos.
Con lo que representarlo podría ser complejo. Para ello podemos utilizar una descomposición jerárquica de los
esquemas de eventos. Se pueden colocar fronteras en torno a un esquema complejo de eventos y considerarlo
como una operación de alto nivel. Así, el esquema de eventos de bajo nivel se convierte en el método para la
operación que se descompone.
Aislamiento de la causa y el efecto

Cada operación lleva a cabo su tarea sin importar lo que ocurre en otra parte. Una operación es invocada por
varios mecanismos de activación, ejecuta su método y se espera que este modifique el estado de un objeto. La
operación no sabe que evento lo activo ni por qué. Además, no sabe se activaran otras operaciones a parir de
su evento. En resumen, no reconoce su causa o efecto, solo sabe que es invocada para producir un cambio de
estado en un objeto dado. Este aislamiento de las consideraciones de causa y efecto es necesario para que la
operación pueda volver a utilizarse en muchas otras aplicaciones.
Un esquema de objetos expresa el tipo de objetos y sus asociaciones en un sistema dado. Un esquema de
eventos expresa un guión de procesamiento que cambia los estados de los objetos.
Por lo tanto, una herramientas CASE para el análisis orientado a objetos debe permitir a sus usuarios construir
esquemas de objetos y esquemas de eventos, además de mantener la estrecha relación que hay entre estos
tipos de representación.
Diagramas de flujo de objetos

Los esquemas de eventos son adecuados para descripción de procesos en términos de eventos, de reglas de
activación, de condiciones y de operaciones. Sin embargo, podría no ser adecuado expresar así procesos
grandes y complejos.
En situaciones como ésta es cuando es útil un diagrama de flujo de objetos.
Los diagramas de flujo de objetos (DFO) son parecidos a los diagramas de datos (DFD), puesto que muestran
actividades que interactúan con otras. En los DFD, una interface transfiere datos. En las técnicas OO, no se
limita a la transferencia de datos, sino que el diagrama debe representar cualquier tipo de cosa que se
transfiera de una actividad a otra, ya sean pedidos, partes, artículos, diseños, servicios, hardware, software, o
datos. En resumen, el DFO indica los objetos que se producen y las actividades que los producen e
intercambian.
Las actividades se representan con cajas con esquinas redondeadas, las cajas sombreadas son agentes
externos. En lugar del símbolo de almacenamiento de datos (dos líneas paralelas), se utiliza una caja
tridimensional, esto indica que dl DFO representa el hecho de que los objetos de la vida real fluyen entre las
actividades.
16
AÑO: 2015
Figura: 6.24:
Diagrama de Flujo de Objetos Típico
Los DFO describen los objetos y como se producen y se consumen.
El producto es el resultado final que satisface el propósito de la actividad. Las actividades se pueden
descomponer en DFO. Sin embargo, en un nivel más detallado del análisis del comportamiento, también es
correcto expresar los aspectos dinámicos de los esquemas de eventos. Una actividad se puede expresar en
términos de un DFO, un esquema de eventos, o ambos.
Para expresar un proceso de manera más rigurosa y poder generar un código, lo adecuado es un esquema de
eventos. Un diagrama de flujo de objetos es útil para representar las estructuras básicas de control y el flujo del
procesamiento, cuando no se entienda totalmente la dinámica de los eventos y las claves de activación.
En resumen, el análisis del comportamiento de objetos puede utilizar una gran variedad de puntos de vista de
diagramación.
Figura: 6.25:
Componentes de un DFO
Diseño de la estructura y comportamiento de un objeto

También en el diseño realizamos la misma división que del análisis: el diseño de la estructura de objetos (DEO) y
el diseño del comportamiento de objetos (DCO). Los lenguajes de programación OO tienen estructuras de datos
y métodos, ambos sujetos a herencia y combinados en unidades llamadas clases. Por esto, el DEO y el DCO
están entrelazados, y se describirán en forma conjunta.
En el diseño de la estructura y comportamiento de objetos se identifican los componentes siguientes:
 ¿Que clases se implantaran?
 ¿Que estructuras de datos utilizara cada clase?
 ¿Que operaciones ofrecerá cada clase y cuáles serán sus métodos?
 ¿Cómo se implantara la herencia de clases y cómo afectará ésta las especificaciones de los datos y las
operaciones?
 ¿Cuales son las variantes de las clases?
Clase
En el análisis de estructura de objetos, identificamos los tipos de objetos; en el diseño de estructura de objetos
nos centramos en la implantación de esos tipos de objetos.
17
AÑO: 2015
Clase es la implantación de un tipo de objeto. Especifica la estructura de datos y los métodos operativos
permitidos que se aplican a cada uno de sus objetos.
La clase especifica la estructura de datos de cada uno de sus objetos y las operaciones que se utilizan para tener
acceso a los objetos. La especificación de como se llevan a cabo las funciones de una clase se llama método. Los
objetos se pueden utilizar exclusivamente con métodos específicos.
Los datos del objeto se almacenan dentro de él y se tiene acceso a ellos y se les modifica solo mediante las
operaciones permisibles. Esta restricción al acceso se debe al encapsulado. El encapsulado protege los datos del
uso arbitrario o no pretendido. El acceso o la actualización directa de los datos de un objeto por parte del
usuario violaría el encapsulado.
Figura: 6.26:
Implementación de una Clase
Los usuarios observan el comportamiento del objeto en términos de las operaciones que se pueden aplicar a
los objetos, así como los resultados de tales operaciones. Estas operaciones forman la interface del objeto con
sus usuarios. ¿Cuál es la diferencia ente operación y método?
Las operaciones son procesos que se pueden solicitar como unidades.
Los métodos son especificaciones del procedimiento de una operación dentro de una clase. Es decir, operación
es el tipo de servicio solicitado, y el método es su código de programación.
Una operación es un proceso que se puede solicitar como unidad.
Un método es la especificación de una operación.
Los métodos de una clase controlan solamente a los objetos de esa clase. No pueden tener acceso directo a las
estructuras de datos de un objeto en una clase distinta. Para utilizar las estructuras de datos en una clase
diferente, deben enviar una solicitud a ese objeto.
Herencia de clase
La herencia de clase (que solo se conoce como herencia) es una implantación de la generalización.
La generalización establece que las propiedades de un tipo se aplican a sus subtipos. La herencia de clase hace
que la estructura de datos y operaciones sean disponibles para su reutilización por parte de sus subclases. La
herencia de las operaciones de una superclase permite que las clases compartan el código (en lugar de volverlo
a definir).
La herencia de estructura de datos permite la reutilización de la estructura.
En la herencia múltiple, una clase puede heredar estructuras de datos y operaciones de más de una superclase.
La herencia de clase implanta la jerarquía de generalización, y permite así que una clase comparta la estructura
de datos y operaciones de otra clase.
La herencia simple es aquella en la que una clase puede heredar la estructura de datos y operaciones de una
superclase.
La herencia múltiple se da cuando una clase puede heredar la estructura de datos y operaciones de más de una
superclase.
18
AÑO: 2015
Selección del método

Cuando se envía una solicitud a un objeto, el software selecciona los métodos por utilizar.
Ya hemos comentado que el método no se almacena en el objeto, puesto que esto causaría replica múltiple. En
vez de esto, el método se asocia con la clase. El método no puede estar en la clase de la que el objeto es una
instancia, sino en una superclase.
Así, la herencia permite que una clase reutilice las características de sus superclases.
De esta forma, los usuarios solo deben especificar lo que se debe hacer, dejando que sea el mecanismo de
selección el que determine la forma de localizar la operación y la ejecute.
El mecanismo de selección deja en manos de la aplicación OO el problema de localizar la operación correcta a
partir de la fuente de la solicitud.
Polimorfismo
Uno de los objetivos principales de las técnicas OO es utilizar otra vez el código. Sin embargo, algunas de las
operaciones requieren adaptación para resolver necesidades particulares.
Definición 1 En una clase Empleado se define una operación de retiro. En las implantaciones OO todas las
subclases empleado heredan esta operación en forma automática. Sin embargo, las organizaciones pueden
tener distintos métodos para retirar a un ejecutivo y a un empleado (subclases). Aunque los métodos sean
distintos, llevan a cabo el mismo propósito operativo. Este fenómeno se conoce como Polimorfismo. La palabra
Polimorfismo se aplica a una operación que adopta varias formas de implantación, tanto si el objeto es un
empleado o un ejecutivo.
Una de las ventajas del Polimorfismo es que se puede hacer una solicitud de una operación sin conocer el
método que debe ser llamado. Estos detalles de la implantación quedan ocultos para el usuario; la
responsabilidad descansa en el mecanismo de selección de la implantación OO.
Igual que, excepto... La reutilización practica requiere en su mayoría que el implantador modifique el
componente reutilizables.
Las técnicas orientadas a objetos deben permitir la adaptación de las clases. Ud. Debe poder tomar una clase
de un deposito y adaptarla a sus necesidades.
Las clases se vuelven muy complejas. Por lo tanto, hay que diseñar las clases de modo que se pueda adaptar
con facilidad en una pantalla de herramientas CASE. Las buenas herramientas CASE, que permiten el uso del
diseño OO a partir de un depósito, permiten también adaptar estos diseños.
Los diseñadores deben prever los aspectos de un diseño que los usuarios desearán modificar, así como los
medios sencillos para la adaptación. Este es un aspecto fundamental de las herramientas CASE OO. El hecho de
lograr una máxima reutilización también es parte esencial de las metodologías para el desarrollo de sistemas
que se basan en técnicas OO.
El analista o el diseñador que genere una clase debe preguntarse: ¿ Cómo se utilizará esta clase en el futuro?.
Debe crear la clase de forma que se pueda adaptar con facilidad a las necesidades futuras. En un ambiente OO
bien administrado, todo se construye a partir de clases ya existentes o se crean nuevas clases que serán
utilizadas de nuevo en el futuro. Todo se relaciona con el rehusó en el pasado o en el futuro.
Metodología OMT
Modelo de Objetos
El modelado de objetos captura la estructura estática del sistema, mostrando los objetos del sistema, las
relaciones entre ellos, y los atributos que caracterizan a cada clase. El modelo de objetos es el mas importante
en esta metodología.
Objetos y Clases
Un objeto es, sencillamente, algo que tiene sentido en el contexto de la aplicación.
Se definirá un objeto como un concepto, abstracción o cosa con limites bien definidos y con significado a
efectos del problema que se tenga entre manos. Los objetos tienen dos propósitos: promover la comprensión
del mundo real y proporcionar una base práctica para la implementación por computadora.
La descomposición de un problema en objetos depende del juicio y de la naturaleza del problema, es decir no
existe una única representación correcta.
Todos los objetos poseen su propia identidad y se pueden distinguir entre si. Dos manzanas del mismo color y
la misma forma siguen siendo manzanas individuales. El termino identidad significa que los objetos se
distinguen por su existencia inherente y no por la propiedades descriptivas que puedan tener.
En algunas ocasiones, objeto significa una sola cosa, en otras se refiere a un grupo de cosas similares. Cuando
se desea ser preciso y aludir a una cosa exactamente se utiliza la frase instancia de objeto y la expresión clase
de objetos para aludir a un grupo de cosas similares.
Clases
Una clase de objetos describe a un grupo de objetos con propiedades (atributos) similares, con relaciones
comunes con otros y con una semántica común.
Ejemplo 6.6 Organización, Proceso, Persona y Animal.
19
AÑO: 2015
Los objetos y sus clases suelen aparecer como sustantivos en la descripción de los problemas.
Los objetos de una clase tienen los mismos atributos y los mismos patrones de comportamiento.
Los objetos de una clase comparten un propósito de semántica común, más allá de que los requisitos de
comunidad de atributos y de comportamiento. La interpretación de la semántica depende del proceso de cada
aplicación y de nuestro propio juicio.
Ejemplo 6.7 Si consideramos un automóvil y un departamento tan solo como propiedad de un individuo,
podrían pertenecer a una misma clase. Si consideramos que el automóvil es un medio de transporte y el
departamento un lugar para habitar entonces tendrán que ser modelados en clases diferentes.
Es necesario preocuparnos por el concepto de clases, mas allá de que lo que estamos modelando son objetos,
por la noción de abstracción. Al agrupar a los objetos en clases se abstrae el problema. La abstracción da al
modelado su potencia y capacidad para generalizar, partiendo de unos pocos casos específicos, hasta llegar a
una multitud de casos similares.
Las definiciones de nombres de atributos y nombres de clases se almacén una sola vez con la clase. Las
operaciones se pueden escribir una sola vez para cada de tal manera que, todos los objetos de la clase se
beneficien de la reutilización del código.
Diagramas de objetos
Como ya hemos visto, los diagramas de objetos proporcionan una notación gráfica formal para el modelado de
objetos, clases y sus relaciones entre si, son útiles, tanto para el modelado abstracto como, para diseñar
programas reales. Son concisos, fáciles de entender y funcionan bien en la práctica.
La metodología propone dos diagramas de objetos: diagramas de clases y diagramas de instancias.
Diagramas de clases
Es un esquema, patrón o plantilla para describir muchas instancias de datos posibles. Los diagramas de clases
describen clases de objetos. En la metodología es un cuadro con el nombre de la clase.
Diagrama de Instancias
Un diagrama de instancias describe la forma en que cierto conjunto de objetos se relaciona entre si. Un
diagrama de instancias describe instancias de objetos. Son útiles para documentar casos prácticos y para
describir ejemplos. Un diagrama de clase se corresponde con un conjunto infinito de diagramas de instancias.
Son cuadros con esquinas redondeadas donde se escribe el nombre de la clase en la parte superior y los
nombres de los objetos.
Figura: 6.27:
Diagrama de Clases
Los diagramas de clases se utilizan para modelar el sistema, los diagramas de instancias para casos de ejemplos.
La diferencia entre ambos es artificial.
Atributos
Un atributo es un valor de un dato que se esta almacenando en los objetos de una clase.
Cada atributo tiene un valor para cada instancia del objeto.
Ejemplo 6.8 El atributo salario mensual tiene el valor de $ 1.200,00 en el objeto Liquidación de Mauricio
Vallejos.
Las instancias distintas de un cierto objeto pueden tener el mismo valor o valores distintos para un atributo
dado. El nombre del atributo es único dentro de la clase.
Ejemplo 6.9 Las clase Organización y Institución Educativa puede tener ambas un atributo llamado e-mail.
Los atributos deberán ser valores puros de datos y no objetos.
Ejemplo 6.10 Todas las apariciones de la cadena de caracteres Argentina. El país Argentina es un objeto cuyo
atributo nombre tiene el valor Argentina (cadena de caracteres).
La capital de Argentina es un objeto del tipo ciudad y no debería modelarse como atributo, sino más bien como
una asociación entre un objeto del tipo país y un objeto del tipo ciudad.
Los atributos se enumeran en la segunda parte del cuadro de clase. El nombre puede ir seguido por detalles
opcionales (tipo, valor, etc.). También se pueden omitir los atributos en el diagrama de clases, todo depende
del grado de detalle que se desee. Los cuadros de clases tienen una línea entre el nombre de la clase y los
atributos. Los cuadros de objetos no tienen esta línea.
20
AÑO: 2015
Figura: 6.28: Especificación de atributos en una clase

No es necesario y no se deberían enumerar explícitamente los identificadores, estos son un artefacto de la
computadora y no tienen un significado intrínseco más allá de la identificación de un objeto. Los identificadores
son una comodidad de implementación y no tienen significado en el dominio del problema.
Operaciones y métodos
Una operación es una función o transformación que se puede aplicar o que puede ser aplicada por los objetos
de una clase.
Ejemplo 6.11 Ocultar, mostrar, Abrir, Calcular, etc.
Todos los objetos de una clase comparten las mismas operaciones.
Cada operación tiene un objeto blanco como argumento implícito. El comportamiento de la operación depende
de la clase de su blanco. Todo objeto conoce su clase y, por tanto, la implementación correcta de la operación.
Una misma operación puede aplicarse a muchas clases distintas. Tal operación será polimórfica; esto es, una
misma operación adopta distintas formas en distintas clases. Un método es la implementación de una
operación para una clase.
Una operación puede poseer argumentos además del objeto destino blanco. Tales argumentos parametrizan la
operación pero no afectan a la elección del método. Los métodos solamente dependen de la clase del objeto
blanco.
Cuando una operación posee métodos aplicables a distintas clases es importante que todos los métodos tengan
la misma signatura: este número, los tipos de los argumentos y el tipo del valor del resultado.
Las operaciones se enumeran en el tercio inferior del cuadro de clase. El nombre de cada operación puede ir
seguido por detalles opcionales, tales como la lista de argumentos y el tipo de resultado. Una lista de
argumentos se escribirá entre paréntesis a continuación del nombre; los argumentos irán separados por comas.
El nombre y el tipo de cada argumento pueden indicarse también. El tipo y el resultado viene precedido por dos
puntos y no debería omitirse porque es importante distinguir aquellas operaciones que proporcionan valores
de las que no. Una lista de argumentos vacía entre paréntesis muestra explícitamente que no hay argumentos.
Las operaciones se pueden omitir en los diagramas de alto nivel.
Figura: 6.29: Descripción de Operaciones en una Clase

Durante el modelado resulta útil distinguir aquellas operaciones que tengan efectos laterales de las que
únicamente calculan un valor funcional sin modificar ningún objeto.
Este último tipo de operación se denomina consulta. La consultas sin argumentos, salvo el objeto destino, se
pueden considerar atributos derivados. Un atributo derivado es como un atributo en tanto en cuanto es una
propiedad del objeto en si y calcularlo no va a cambiar el estado del objeto.
El modelo de objetos debería distinguir, generalmente, los atributos base independientes de los atributos
derivados dependientes.
21
AÑO: 2015
Figura: 6.30: Asociaciones

Enlaces y asociaciones
Los enlaces y asociaciones son los medios para establecer relaciones entre objetos y clases.
Un enlace es una conexión física o conceptual entre instancias de objetos. Un enlace es una instancia de una
asociación.
Una asociación describe un grupo de enlaces con estructura y semántica comunes.
Todos los enlaces de cada asociación conectan objetos procedentes de las mismas clases.
Las asociaciones y los enlaces suelen aparecer como verbos en la definición del problema.
Las asociaciones describen un conjunto de enlaces potenciales del mismo modo que las clases describen un
conjunto de objetos potenciales.
Las asociaciones son inherentemente bidireccionales. El nombre de una asociación binaria suele leerse en un
cierto sentido, pero la asociación binaria se puede recorrer en ambas direcciones. La dirección implicada por el
nombre es la dirección hacia delante; la dirección opuesta es la dirección hacia atrás.
Las asociaciones suelen implementarse en los lenguajes de programación como punteros que van desde un
objeto hasta otro.
La implementación de asociaciones en forma de punteros es perfectamente admisible, pero las asociaciones no
deberían modelarse de esta manera.
Aun cuando las asociaciones se modelan como si fueran bidireccionales, no es necesario implementarlas en
ambos sentidos.
Los nombres de las asociaciones se ponen en cursiva. El nombre de la asociación se puede omitir si una pareja
de clase tiene única asociación cuyo significado sea obvio.
Las asociaciones pueden ser binarias, ternarias o de orden superior. En la práctica, la inmensa mayoría van a ser
binarias o calificadas.
La figura siguiente muestra una asociación ternaria.
Figura: 6.31: Asociación Ternaria
Figura: 6.32:
Multiplicidad
Ejemplo 6.12 Los programadores utilizan lenguajes de computación aplicados a proyectos.
El símbolo de OMT para asociaciones generales ternarias y n-arias es un rombo con líneas que lo conectan con
las clases relacionadas. El nombre de la asociación es escribe al lado del rombo.
Los nombres de las asociaciones son opcionales y es una cuestión de juicio personal en el momento del
modelado. Las asociaciones suelen dejarse sin nombre cuando es posible identificarlas fácilmente por sus
clases. Esta convención no funciona si existen múltiples asociaciones entre las mismas clases.
22
AÑO: 2015
Multiplicidad
La multiplicidad especifica el número de instancias de una clase que pueden estar relacionadas con una única
instancia de una clase asociada. La multiplicidad limita el número de objetos relacionados.
Existen terminadores de línea que indican ciertos valores frecuentes de multiplicidad.
Un circulo negro es el símbolo OMT de denota muchos, lo cual quiere decir cero o más
Un circulo blanco indica opcional, lo cual quiere decir cero o uno. Una línea sin símbolos de multiplicidad
denota una asociación uno a uno.
La multiplicidad depende de suposiciones y de la forma en que se definan los límites del problema. No hay que
preocuparse por la multiplicidad en la fase inicial del desarrollo de sistemas.
Atributos de los enlaces
Un atributo de enlace es una propiedad de los enlaces de una asociación. En la figura siguiente, permiso de
acceso es un atributo de Puede Acceder. Todo atributo de enlace tiene un valor para cada enlace según se
ilustra mediante los datos dados como ejemplo en la parte inferior de la figura.
La notación OMT para un atributo de enlace es un cuadro ligado a la asociación mediante un lazo; puede
aparecer uno o más atributo de enlace en la segunda región del cuadro.
Modelado de una asociación en forma de clase: Clase asociación
En algunos ocasiones resulta útil modelar las asociaciones como clases. Cada enlace pasa
a ser una instancia de la clase (similar al objeto asociativo en el AS/DS).
Resulta útil modelar las asociaciones como clases cuando los enlaces pueden participar en asociaciones con
otros objetos o cuando están sometidos a operaciones.
Figura: 6.33:
Descripción de atributos de Enlaces
Nombre de rol
Un rol es un extremo de una asociación. Una asociación binaria posee dos roles, cada uno de los cuales puede
poseer un nombre de rol. Un nombre de rol es un nombre que identifica de forma única un extremo de una
asociación. Los roles proporcionan una forma de visualizar las asociaciones binarias como un recorrido desde
un objeto hasta un conjunto de objetos asociados.
El nombre del rol es un atributo derivado cuyo valor es un conjunto de objetos relacionados.
Los roles suelen aparecer como sustantivo en las descripciones de problemas.
Los nombres de rol son necesarios para las asociaciones entre dos objetos de la misma clase.
Dado que los nombres de rol sirven para distinguir entre los objetos que están directamente conectados con un
objeto dado, todos los nombres de rol extremo final de las asociaciones asociadas a una clase deben ser únicos.
Aun cuando el nombre del rol se escribe junto al objeto de destino de una asociación, se trata en realidad de un
atributo derivado de la clase fuente y debe ser único dentro de ella. Por la misma razón ningún nombre de rol
debería ser igual a un nombre de atributo de la clase origen.
Clasificación
Normalmente, los objetos del lado muchos de una asociación no tienen orden explícito y se pueden considerar
como un conjunto. Sin embargo, en algunas ocasiones los objetos están ordenados explícitamente.
Un conjunto ordenado de objetos en el extremo muchos de la asociación se indica escribiendo {ordenado} al
lado del símbolo de multiplicidad correspondiente al rol.
La clasificación es una clase especial de restricción.
23
AÑO: 2015
Figura: 6.34:
Asociación en forma de Clase
Figura: 6.35:
Ejemplo de nombre de Rol
Cualificación
Una asociación cualificada o calificada relaciona dos clases de objetos y un cualificador. El cualificador es un
atributo especial que reduce la multiplicidad efectiva de una asociación.
Las asociaciones uno a muchos y muchos a muchos pueden ser cualificados. El cualificador distingue entre el
conjunto de objetos que se encuentra en el extremo muchos de la asociación. Una asociación cualificada
también se puede considerar como una forma de asociación ternaria.
Un cualificador se dibuja en la forma de un cuadro pequeño en el extremo de la línea de asociación que se
encuentra más próximo a la clase a la cual califica.
Figura: 6.36:
Figura: 6.37:
Uso de Cualificadores
Agregación
Una agregación es la relación parte-todo o una-parte-de en la cual los objetos que representan los
componentes de algo se asocian a un objeto que representa el ensamblaje completo.
24
AÑO: 2015
Figura: 6.38:
Gráfica de agregación
La agregación es una forma fuertemente acoplada de asociación, con una cierta cantidad de semántica
adicional.
Las propiedades más significativas son:
 Transitividad, esto es, A es parte de B y B es parte de C, entonces A es parte de C.
 Antisimétrica, esto es, si A es parte de B, entonces B no es parte de A.
Las agregaciones se dibujan igual que las asociaciones, salvo por un pequeño rombo que indica el extremo de
ensamblaje de la relación.
La agregación puede poseer un número arbitrario de niveles.
Generalización y Herencia
La generalización y la herencia son potentes abstracciones para compartir similitudes entre clases al mismo
tiempo que se mantienen sus diferencias.
La generalización es la relación entre una clase y una o más versiones refinadas de esa misma clase. La que se
está refinado se denomina la superclase y cada versión refinada se denomina subclase.
Los atributos y operaciones comunes a un grupo de subclase se asocian a la superclase y son compartidos por
todas las subclases. Se dice que cada subclase hereda las características de su superclase.
La generalización y la herencia son transitivas a través de un número arbitrario de niveles. Los términos
ascendente y descendente hacen alusión a la generalización de clases a través de niveles múltiples. Una
instancia de una subclase es simultáneamente una instancia de todas sus clases antecesoras.
Toda operación aplicable a una clase antecesora podrá ser aplicada a una instancia suya. Toda subclase hereda,
no solamente todas las características de sus antecesoras sino que además añade sus propios atributos y
operaciones específicos.
Figura: 6.39:
Uso de Generalización y Herencia
La notación para la generalización es un triángulo que conecta una superclase con sus subclases. La superclase
se conecta mediante una línea a la parte superior del triángulo.
25
AÑO: 2015
Las subclases se conectan mediante líneas a una barra horizontal asociada a la base del triángulo. Por
comodidad, se puede invertir el triángulo y se pueden conectar las subclases tanto a la parte superior de la
barra como a la parte inferior pero, si es posible, la superclase debería dibujarse en la parte superior y las
subclases en la parte inferior.
Los puntos suspensivos de clase dependientes (tres puntos) indica que existen subclase adicionales que no se
muestran en el diagrama, quizá porque no haya sitio en el folio y se muestran en otro lugar o a lo mejor,
porque la enumeración de subclases todavía no está completa.
Las palabras que se escriben al lado de los triángulos en un diagrama son discriminadoras.
Un discriminador es un atributo de enumeración de tipo que indica que propiedad del objeto esta siendo
abstraída por una relación de generalización en particular. Solamente se debe discriminar una propiedad de
cada vez.
El discriminador es, simplemente, un nombre para la base de la generalización. Los valores del discriminador
están inherentemente en correspondencia uno a uno con la subclases de la generalización. El discriminador, es
una parte opcional de la relación de generalización; si se incluye un discriminador, deberá ser dibujado al lado
del triángulo de generalización.
No se deben anidar las subclases con demasiada profundidad. Las subclases muy anidadas pueden ser difíciles
de entender, al igual que los bloques de código profundamente anidados de un lenguaje basado en
procedimientos.
En la práctica, el que una subclase esté o no demasiado anidada depende del juicio y de los detalles particulares
del problema considerado.
Los términos herencia, generalización y especialización se refieren a aspectos de la misma idea y suele ser
posible utilizarlos de forma intercambiable. Se utilizará generalización para hacer alusión a la relación entre
clases, mientras que herencia aludirá al mecanismo empleado para compartir atributos y operaciones
empleando la relación de herencia. La generalización y la especialización son dos puntos de vista distintos de la
misma relación vista desde la superclase o desde las subclases. La palabra generalización proviene del hecho
consistente en que la superclase generaliza a las subclases. La especialización hace alusión al hecho consistente
en que las subclases refinan o especializan a la superclase.
Fundamentos del AEO y del ACO

Análisis de la estructura de Objetos (AEO)
Conceptos y Objetos
El análisis orientado a objetos no es un enfoque que modela la realidad. En lugar de esto, modela la forma en
que las personas comprenden la realidad.
Conceptos
Definición 7.1 Un concepto es una idea o noción compartida que se aplica a determinados objetos en forma
consiente.
Cada concepto es una idea particular o nuestra forma de comprender el mundo. Sabemos que tenemos un
concepto cuando lo podemos aplicar con éxito a las cosas que nos rodean.
Ejemplo 7.1 Decir que tenemos el concepto de automóvil solo requiere que podamos identificar una instancia
de este.
Conceptos como dispositivos de reconocimiento
Los conceptos que formamos y utilizamos pueden variar, puesto que nosotros los elegimos.
Algunos, según lo apreciamos en las siguientes tablas, pueden ser:
Los conceptos que formamos nos proporcionan una especie de lentes mentales que nos sirven para razonar
acerca de los objetos que nos rodean.
CONCEPTO INTANGIBLE PAPELES JUICIOS
Persona Tiempo Doctor Trabajo Productivo
Lápiz Calidad Paciente Salario Alto
Tabla 7.1: Tabla de concepto

POR RELACIÓN EVENTOS DESPLEGABLES OTROS
Matrimonio Venta Cadena Imagen
Sociedad Compra Entero Señal
Tabla 7.2: Tabla de concepto
26
AÑO: 2015
Conceptos sin Objetos

También podemos formar conceptos para los que no tiene objeto. Hay personas que comparten el mismo
concepto de hombre perfecto, pero ningún objeto ha pasado la prueba de ese concepto.
Objetos sin conceptos

En la conciencia de las personas no puede haber objetos sin conceptos aplicables. En otras palabras, cierto
objeto existe para ciertas personas que tienen el concepto aplicable a esos objetos, y es posible que hayan
personas para las que no exista ese objeto ya que no cuentan con el concepto que puedan aplicar a este objeto.
Intensidad y extensión del objeto

Los conceptos se utilizan como unidades de conocimiento. El concepto como unidad de reconocimiento,
soporta definiciones discretas de nuestras pruebas de reconocimiento (la intensidad) y la identificación de
aquellos objetos a los que se le aplica o no una definición (extensión). La intensidad y la extensión son dos
aspectos de los conceptos.
Administración de la complejidad de un objeto

Vivimos en un mundo complejo donde hay que tener en cuenta las herramientas que nos ofrece el medio para
poder ver las cosas con menos complicaciones. La programación OO posee herramientas como la abstracción,
generalización y la jerarquización.
Abstracción
Definición 7.2 La abstracción es el acto o resultado de eliminar diferencias entre los objetos, de modo de poder
apreciar sus aspectos más comunes.
Todo objeto es único. Sin embargo, la abstracción elimina algunas distinciones entre los objetos para que
podamos ver sus aspectos más comunes. Sin la abstracción solo sabríamos que los objetos son distintos de
otros. Con la abstracción se omiten de manera selectiva varias características distintivas de uno o más objetos,
lo que permite concentrarnos en sus puntos en común.
Computadoras
Generalización
La generalización nos permite percibir que todas las instancias de un concepto más especifico son también
instancias de un concepto mas general, pero no necesariamente al
revez.
Figura: 7.1: Ejemplo de abstracción

Definición 7.3 La generalización es el acto o resultado de distinguir un concepto que es más general que otro.
Figura: 7.2: Ejemplo de Generalización
Jerarquía de Conceptos
Con la generalización podemos construir jerarquías de conceptos, para formar conceptos más generales que
otros.
Lo opuesto a la generalización es la especialización (o particularización). La generalización no se limita a las
estructuras de árbol, puesto que un concepto puede tener varios subconceptos.
Figura: 7.3:
Ejemplo de jerarquía de conceptos
Composición
La composición es un mecanismo para formar un todo a partir de partes componentes.
27
AÑO: 2015
Además, las partes componentes pueden a su vez, tener sus propias partes componentes.
La composición reduce la complejidad al tratar muchas cosas como una sola.
Figura: 7.4: Composición

Definición 7.4 La composición es el acto o resultado de formar un objeto mediante sus partes componentes.
Composición Inmutable
Una composición inmutable es el resultado de tratar a una o más cosas relacionadas entre sí como
componentes inmutables de una sola.
Figura: 7.5:
Composición Inmutable
Esta forma invariante de la composición podemos apreciar en el ejemplo siguiente.
Ejemplo 7.2 En los matrimonios, si se sustituye uno de los objetos por otro, el matrimonio no sería el mismo. Si
se elimina uno de los objetos se destruye la pareja. Así cada uno de los matrimonios está formado de manera
inmutable en base de dos objetos específicos.
Concepto y la Composición Inmutable

Cada matrimonio es un objeto en sí. El conjunto de todos los objetos matrimonio son instancias del concepto
llamado MATRIMONIO. Sin embargo, MATRIMONIO es un tipo especial de concepto, una relación BINARIA. Una
relación binaria es un concepto cuyos objetos están compuestos por de manera inmutable por dos objetos
componentes.
28
AÑO: 2015
Figura: 7.6: Composición Inmutable
Relaciones n-adas o de n-lugares

Las relaciones se pueden extender mas allá de las relaciones binarias y terciarias a las relaciones de n-adas o de
n-lugares. Un objeto complejo puede ser una composición inmutable de una cantidad arbitraria de objetos. Los
objetos definidos de esta manera se llaman n-adas.
Definición 7.5 Una n- ada es un objeto compuesto por otros objetos que son inmutables.
Ejemplo 7.3 Un objeto podría ser una n-ada consistente en un objeto proveedor, un objeto cliente, y uno o más
objetos productos. La relación de n-lugares estaría dada por contrato.
Tipos de Objetos y Asociaciones

Las asociaciones nos permiten ligar o conectar los distintos tipos de objetos. Sin esta capacidad de asociación,
parecería que todos los objetos estuvieran solos.
Asociaciones
Las asociaciones proporcionan una forma de ligar los objetos de manera significativa por medio de sus tipos de
objetos. Las asociaciones, por otro lado, se presentan por lo general mediante líneas.
Aunque los tipos de objetos se refieren a conjuntos de objetos, las asociaciones implicas conexiones de objetos
entre los conjuntos. Como tal, este conjunto de conexiones forma una clase especial de tipo de objeto.
Relaciones
Las instancias de los tipos de objetos son objetos, por definición. Las relaciones son tipos de objetos
especializados. Son tipos de objetos cuyas instancias son n-adas.
Las líneas suelen utilizarse para representar relaciones, sobre todo en las binarias. Sin embargo, este tipo de
representación, para las relaciones con mas de dos lugares, puede dificultar su lectura y comprensión.
Mediante el mecanismo de composición, cada n-ada es un tipo de objeto en sí. Además para preservar la
estructura de componentes inmutables, se colocan los triángulos y las I, que indican su condición de inmutable.
Figura: 7.7:
Ejemplo de Relación
Empleado por: Emplea a: ...
NEC Susana
NASA Pablo
NASA Pedro
Tabla 7.3: Tabla de un Ejemplo de Relación
Funciones
Supongamos los objetos de un tipo de objeto; una función los asocia con objetos de otro tipo de objeto. Pensar
esto como una asociación es muy útil.
Una función es un proceso que, dado un objeto, regresa un conjunto que tiene cero o más objetos.
Una función que siempre regresa un conjunto con un solo objeto se llama uní valuada.
Las funciones que son multivaluadas regresan un conjunto con un número no determinado de objetos.
29
AÑO: 2015
Definición 7.6 Una función es un proceso de asociación que, dado un objeto dentro de un tipo de objeto,
regresa con un número no determinado de objetos de otro tipo de objeto.
Las funciones tienen dirección. La función X asocia un tipo de objeto hacia otro tipo de objeto B. La dirección
contraria es una función diferente, la inversa de X.
La tabla siguiente representa la Relación
La tabla siguiente representa una Función
Objetos y Tipos de Objetos

En el análisis se trata de identificar los tipos de objeto más que los objetos individuales en un sistema. Los tipos
de objetos se definen en base a la comprensión del analista de nuestro mundo. Un objeto puede categorizarse
de variadas formas.
Argumento Resultado
IBM Juan
NEC Susana
NASA Pedro
Tabla 7.4: Tabla de un Ejemplo de Función
Es importante modelar la forma como los objetos se asocian entre sí. Además es necesario identificar el
significado de la asociación y la cantidad de objetos con los que un objeto dado puede y debe asociarse
(cardinalidad).
Figura: 7.8:
Representación para la Asociación entre dos Tipos de Objetos. Un objeto del tipo persona posee cero o muchos
objetos del tipo vehículo. Un objeto del tipo vehículo es de un y sólo un objeto del tipo persona.
Jerarquías de Generalización
Una de las vías de sentido común por las que el hombre organiza su volumen de conocimiento es el de las
jerarquías, de lo más general a lo más específico.
En las jerarquías se habla de subtipo o especialización de un supertipo o generalización.
En el caso anterior, persona es el supertipo para Empleado y Estudiante, que son sus subtipos. Por otra parte,
Empleado es el supertipo para los subtipos Ejecutivo y Vendedor.
Los subtipos (niveles inferiores de la jerarquía) heredan las características de sus supertipos, además, cada
instancia de un tipo de objeto lo es también de sus supertipos.
Jerarquías Compuestas
Un objeto se denomina complejo si está formado por otros. Las jerarquías Compuestas permiten realizar
agregaciones de objetos.
Un objeto del tipo edificio se compone de al menos un objeto del tipo piso. A su vez un objeto del tipo piso se
compone de al menos un objeto del tipo pasillo, podría tener varios (o ninguno) objetos del tipo baño y oficina.
Particiones de tipos
Las particiones de tipos dividen un tipo en subtipos ajenos.
Definición 7.7 Una partición de tipo es una división (o partición) de un tipo de objeto en subtipos ajenos.
30
AÑO: 2015
Figura: 7.9:
Jerarquía Compuesta
Particiones múltiples
Figura: 7.10:
Particiones
Niveles de partición
La partición de tipos en un determinado número de niveles permite al analista, describir en mayor profundidad
áreas específicas del análisis, mediante la generalización (expresando aspectos de alto nivel) o mediante la
especialización (detallando particularidades específicas).
Estos niveles de particiones permiten también especificar el significado de las asociaciones, mejorando la
comprensión, en el proceso de análisis.
31
AÑO: 2015
Figura: 7.11:
Partición en Niveles
Figura: 7.12:
Gráfica mucho mas especifica de la partición
Como se aprecia en la figura 7-11.
Subtipos de una relación

Podemos pensar a los subtipos como conjuntos de objetos dentro de otros conjuntos más grandes, dado que
las relaciones también tienen conjuntos de objetos, llamados n-adas, estos también se pueden subtipificar.
Estas n-adas son instancias de una relación entre Empleado y Herramienta, llamada (1) Herramientas que tiene
el Empleado, pero solo algunas de estas herramientas son usadas por el empleado, y este subconjunto se llama
(2) Herramientas usadas por el Empleado, que también es parte de la n-ada Herramientas que tiene el
Empleado, entonces (2) es un subtipo de (1).
32
AÑO: 2015
Figura: 7.13:
Subtipo de una Relación
Especialización por subconjuntos de una relación

Diagrama especializado para indicar que todos pueden enviar un mensaje a un funcionario, pero solo los
funcionarios pueden recibirlos
Figura: 7.14:
Especialización por Subconjuntos
Los subconjuntos de una relación definen subconjuntos de asociaciones
Especialización mediante restricciones de Cardinalidad

Otra situación en la que podemos utilizar subtipos de relaciones, es cuando queremos limitar las restricciones
de cardinalidad. La limitación de estas restricciones de Cardinalidad significan que el subconjunto que se asocia
debe ser menor o igual que la Cardinalidad máxima y mayor o igual que la cardinalidad mínima.
33
AÑO: 2015
Figura: 7.15:
Especialización mediante restricciones de cardinalidad
Análisis del Comportamiento de Objetos

Reglas de activación Condiciones de Control Subtipos y Supertipos de Eventos
Los objetos son susceptibles de ser vistos desde dos puntos de vista, complementarios, por tanto decimos que
podemos verlos en su estado estático (su estructura) o en su estado dinámico (su comportamiento en relación
al factor tiempo); por esto en el análisis del comportamiento de objetos (ACO) realizamos esquemas de eventos
que muestran eventos, la secuencia en que ocurren y cómo los eventos cambian el estado de los objetos.
Estados de un Objeto
Un objeto puede existir en varios estados. Por ejemplo, un objeto reservación aérea puede ser una instancia de
alguno de los siguientes tipos de objeto:
 Reservación solicitada
 Reservación en lista de espera
 Reservación confirmada
 Reservación cancelada
 Reservación satisfecha
 Reservación archivada
Tales tipos de objetos suelen percibirse como estados posibles del ciclo de vida de un objeto.
Sin embargo, un objeto puede tener una gran variedad de perspectivas de ciclos de vida. Por ejemplo, el mismo
objeto reservación aérea también puede tener los siguientes estados relacionados con el pago:
 Reservación no liquidada
 Reservación con un pago de depósito
 Reservación totalmente pagada
 Reservación reembolsada
Así, el estado de un objeto es la colección de asociaciones que tiene un objeto.
Eventos
El mundo está lleno de eventos: ganamos la lotería, chocamos el auto, Windows se cuelga, se presiona una
tecla, se inicia la descarga de un archivo, etc.
En el análisis orientado a objetos el mundo se describe en términos de los objetos y sus estados, así como los
eventos que modifican esos estados.
Un evento produce un cambio en el estado de un objeto. Los eventos sirven como indicadores de los instantes
en que ocurren los cambios de estado.
Para saber de los cambios y reaccionar adecuadamente ante estos, debemos entender y modelar los eventos.
Tipos de Eventos
El analista no necesita conocer cada evento que ocurra en una organización: sólo los tipos de eventos.
Ejemplo 7.4 El tipo de evento reservación en lista de espera confirmada es la colección de eventos donde un
objeto cambia de una reservación en lista de espera a una reservación confirmada.
Los tipos de eventos indican los cambios sencillos en el estado de un objeto.
34
AÑO: 2015
Ejemplo 7.5 Cuando se deposita dinero en una cuenta bancaria o se actualiza la lectura de un censor.
Básicamente, los tipos de eventos describen las siguientes formas de cambios de estado:
 ² Un objeto se crea
 ² Un objeto se termina
 ² Un objeto se clasifica como una instancia de un tipo de objeto
 ² Un objeto se desclasifica como una instancia de un tipo de objeto
 ² Un objeto cambia de clasificación
 ² Un atributo de un objeto se cambia
 ² Un objeto se fusiona con objetos distintos, convirtiéndose en un solo objeto más general
 ² Un objeto se descompone, en objetos más específicos.
Los objetos pueden asociar un objeto con otro.
Ejemplo 7.6 En la mayoría de las organizaciones, cuando un objeto se clasifica como empleado, debe estar
asociado con un departamento.
Un evento clasificará al objeto como empleado. Otro evento creará una asociación entre el objeto empleado y
un objeto Departamento (las asociaciones son objetos como los demás).
Algunos eventos requieren que antes ocurran otros. Por ejemplo, antes de cerrar un departamento, todos los
empleados deben ser asignados a otra parte, las oficinas que ocupaban deben tener otro uso, etc.
Algunas veces, un evento puede provocar la reacción en cadena de otros eventos. Por ejemplo, el cambio de
circuito a las conexiones de un avión, puede exigir cambios a varios otros objetos.
Una operación hace que los eventos ocurran. Dibujamos la operación como un cuadro con esquinas
redondeadas, dado que los eventos indican los puntos en el tiempo en que se da el cambio de estado de un
objeto. Los tipos de eventos se representan como triángulos negros llenos, generalmente unidos a la caja de
operación.
Figura: 7.16: Tipos de Eventos

Según la parte que se modele, puede ocurrir más de un evento al terminar una operación, y cada uno de estos
puede activar operaciones independientes.
Estados
La mayoría de los objetos tienen un ciclo de vida, en el cual pueden ocurrirle una sucesión de eventos y cada
uno de éstos eventos modifica su estado.
Se utiliza para modelar, este aspecto, un diagrama que muestra el ciclo de vida de un objeto, incluyendo los
estados posibles de los objetos, además de los cambios de estados permisibles. Este se denomina diagrama de
reja.
35
AÑO: 2015
Figura: 7.17: Tipo de Eventos
Figura: 7.18: Tipo de Eventos

Diagrama de reja que muestra los estados posibles de un objeto reservación aérea.
Las líneas horizontales representan estados y las verticales muestran las transiciones entre estados.
Ejemplo 7.7 Un estado de un objeto (o un estado) es la colección de todos los tipos de objeto que se aplican a
un objeto dado.
Representación combinada
El cambio de estado de un objeto es el cambio de la colección de tipos de objetos que se aplican a dicho objeto,
por tanto cuando cambia de estado un objeto deben identificarse los tipos aplicables a el, así el
comportamiento del objeto se define mediante su proceso de cambio de estado respecto a su estructura.
36
AÑO: 2015
Figura: 7.19:
Representación Combinada
Operaciones
En el análisis OO, una operación se refiere a una unidad de procesamiento que puede ser solicitada. El
procedimiento se implanta mediante un método. El método es la especificación de cómo llevar a cabo la
operación. A nivel de programa, el método es el código que implanta la operación.
Las operaciones se invocan. Una operación invocada es una instancia de una operación.
Una operación puede o no cambiar el estado de un objeto, si lo cambiara ocurriría un evento.
Fuentes externas de eventos

Los eventos son cambios de estado que un sistema debe conocer y reaccionar ante ellos de algún modo.
Muchas de las operaciones que producen estos eventos son externas al sistema.
Figura: 7.20: Fuentes Externas de tipos de eventos
Reglas de activación
Cuando ocurre un evento, lo normal es que el cambio de estado active el llamado a una o más operaciones. Por
ejemplo, si se retiran bienes de un almacén y la cantidad baja de cierto nivel, ello puede activar una operación
para volver a realizar un pedido.
Las reglas de activación definen la relación entre la causa y el efecto. Siempre que ocurra un evento de cierto
tipo, la regla de activación invoca a una operación ya definida.
Un tipo de evento puede tener varias reglas de activación, cada una de las cuales invoca a su operación en
paralelo. Las operaciones paralelas pueden producir diferentes cambios de estado en forma simultánea.
Condiciones de Control
Una operación puede ser invocada por una o varias reglas de activación. Sin embargo, antes de invocar de
hecho a la operación se puede verificar una condición de control. Si el resultado de evaluación de la condición
es verdadera se invoca su operación, en otro caso no.
Operación
37
AÑO: 2015
Figura: 7.21: Condición de Control

Las condiciones de control también pueden actuar como puntos de sincronización para el procesamiento en
paralelo, pues garantizan que un conjunto de eventos esté completo antes de proceder con una operación.
Subtipos y Supertipos de Eventos

Los eventos pueden dividirse en subtipos mediante diagramas independientes; o bien, es posible expresar la
misma información en un diagrama ampliado.
La operación revisar tarea produce dos eventos: tarea aceptada o tarea rechazada. Sólo se puede dar uno de
estos tipos de evento al revisar una tarea.
Aquí tarea revisada es un supertipo de tarea aceptada y tarea rechazada, que son los subtipos. Siempre se
entiende que existe una relación de exclusividad entre los subtipos.
Las particiones de eventos no son operaciones independientes que coordinan las condiciones de bifurcación
para las formas de activación ajenas, sino que indican los objetivos y distintos subobjetivos de las operaciones a
las que están asociadas.
Figura: 7.22:
Subtipos / Supertipos
38
AÑO: 2015
Figura: 7.23: Una tarea que produce dos eventos
Análisis del comportamiento de objetos mediante esquemas de eventos

Se presentaron con anterioridad los elementos de los esquemas de eventos. El método detallado para su
construcción se resume en la figura siguiente.
Paso 0. Definición del enfoque del análisis
Al construir un esquema de eventos, el esfuerzo del análisis debe iniciarse examinando lo que se desea (y lo
que no se desea) modelar. En pocas palabras, el analista y el experto deben definir el enfoque del esquema.
Paso 0a. Identificar el dominio del problema
El análisis orientado a objetos especifica la estructura y el comportamiento de los objetos relevantes a un
dominio de interés. Cada dominio define un universo particular de objetos a modelar, proporciona un marco de
referencia. Los dominios también reciben el nombre de universos y espacios. De esta forma, el dominio podría
ser el control de stock, la facturación, la fabricación de un producto, etcétera.
Figura: 7.24:
Ciclo de desarrollo de esquemas de Eventos
Dominio Tipos de Evento Objetivo
Liquidación de sueldo Empleado Pagado
Administración de Pedidos Pedido Terminado
Facturación Factura Emitida
Tabla 7.5: Tabla de identificación de tipo de evento
39
AÑO: 2015
Al considerar la especificación de un dominio particular, tanto el analista como el experto tendrán un área
controlable en la cual centrar sus esfuerzos de análisis. Así, el analista decide el nivel de detalle del análisis.
Paso 0b. Identificar el tipo de evento objetivo
Una vez identificado el dominio, hay que expresar su propósito u objetivo. Por ejemplo, algunos dominios y sus
tipos de eventos objetivos podrían ser como se describen en la tabla siguiente
La identificación de estos tipos de evento objetivo es crucial para el método. Sin un objetivo, el dominio
seleccionado no tiene un propósito claramente comprendido. En situaciones semejantes pueden ayudar los
diagramas de flujo de objetos.
El tipo de evento inicial también es importante. Al conocer el principio y el fin de su dominio, la especificación
tiene límites de modo que el analista y el usuario final puedan encerrar su trabajo.
Paso 1. Aclaración del tipo de evento

Este paso permite al analista definir el significado subyacente del tipo de evento y nombrarlo.
Paso 1a. Identificación del tipo de evento básico
Como se analizó anteriormente, los tipos básicos de eventos crean, terminan, clasifican, desclasifican,
reclasifican, sustituyen n-adas, etcétera. En este paso, el analista identifica la clase de evento a la que se adecúa
el tipo de evento elegido.
Figura: 7.25: Identificación del Incicio y Final de tipos de Eventos

Tipo de Evento Ejemplo de Evento Preestados Postestados
Crear Venta iniciada No existe objeto Venta
Terminar Venta terminada Venta No existe objeto
Clasificar Clasifica como Persona NO Empleado Persona Empleado
Empleado
Desclasificar Desclasifica como Persona Y Empleado Persona NO Empleado
Empleado
Reclasificar Persona Casada Persona NO casada Persona Casada
Sustitución n-adas Domicilio Cambiado Domicilio Domicilio (n-ada #)
Tabla 7.6: Tabla de identificación de preestados y postestados

Asociados a cada clase básica de evento están los tipos de objetos preestado y postestado, que también son
identificados en este paso, como se puede apreciar en la tabla siguiente.
El hecho de nombrar de alguna forma a los tipos de eventos proporciona mayor comprensión al leer los
esquemas de eventos, a la vez que la formalización del cambio de estado real proporciona exactitud.
Paso 1b. Dar nombre al tipo de evento
Los nombres de los tipos de eventos proporcionan un significado eficaz si se incorporan dos características. La
primera es que el nombre debe documentar uno o ambos nombres del tipo de objeto preestado y del
postestado. Por ejemplo, cuenta abierta indica una operación en el tipo de objeto cuenta. Empleado ascendido
a gerente indica una reclasificación de empleado a gerente. En segundo lugar, el nombre debe dar una
indicación del proceso que representa. Puesto que un evento es la terminación exitoso de una operación, lo
adecuado es nombrar el tipo de evento en tiempo pasado.
Uno se puede apartar un poco de estos principios para proporcionar una mayor claridad al esquema. Por
ejemplo, la operación pagar empleado podría contar con un tipo de evento llamado empleado pagado. Sin
embargo, el tipo de objeto subyacente en este evento podría no ser empleado, sino pago del empleado. En
este caso, el nombre del evento sería pago del empleado creado, si se obligara a utilizar los estándares. No es
necesario que los nombres sean estándar, pero sí debe sérlo el significado subyacente. Esta es la razón de la
importancia vital de la formalidad del paso 1a.
Paso 2. Generalizar el tipo de evento
40
AÑO: 2015
Una vez aclarado el significado subyacente, debe examinarse el tipo de evento elegido en busca de tipos de
eventos más generales. La finalidad aquí es doble. En primer lugar, ayuda al analista a determinar si el análisis
se realiza en el nivel de abstracción adecuado.
En segundo lugar, apoya la integración con otros esfuerzos de análisis más generales.
Paso 2a. Generalizar el tipo de evento y elegir nivel
La generalización de un evento requiere que el analista vea por encima de los detalles inmediatos de un
sistema y que explore en forma momentánea un panorama más amplio.
Por ejemplo, un analista podría especificar un sistema para el pago de la gerencia. Un evento clave en este
sistema será gerente pagado. Como se muestra en la figura, una forma más general de esto es empleado
pagado. Al considerar las creaciones de pago en una forma más general, el tipo de evento pago realizado podría
describir el siguiente nivel de abstracción. La generalidad límite es objeto creado.
Figura: 7.26: Ilustra la generalización y nivel de un tipo de evento

Una vez explorados los posibles niveles de abstracción, el analista debe elegir el nivel adecuado para el sistema
en cuestión y cambiar el tipo de evento elegido, en caso necesario.
Sin el paso de generalización, el analista podría no considerar esta posibilidad.
Una técnica útil para la identificación de las posibles generalizaciones es expresar el tipo de evento junto con
sus preestados y postestados, como en el ejemplo de la figura. Al generalizar esto, el tipo de evento también se
generaliza. Abstracciones como éstas hacen que el analista contemple sistemas más generales.
Paso 2b. Integrar el tipo de evento
Los resultados de la generalización también ayudan a la integración del sistema. Después de generalizar el tipo
de evento, se verifica si ya ha sido especificado. En caso afirmativo, el evento generalizado podría ser parte de
un sistema en proceso o de uno ya terminado. En este caso, se ha identificado un punto de integración que se
debe administrar en la forma correspondiente..
Tipo de Evento Preestado Postestado
Objeto recalificable Concepto Concepto
… … …
Objeto registrado para salida Objeto disponible Objeto registrado para salida
Objeto biblioteca registra Objeto biblioteca disponible Objeto biblioteca registra p/
p/salida salida
Libro registrado para salida Libro disponible Libro registrado para la salida
Tabla 7.7: Tabla de integración de tipo de Evento

Paso 3. Definir las condiciones de operación
En este punto, es necesario tener bien entendido el tipo de evento. Ahora hay que tomar en cuenta la
operación y sus condiciones de activación.
Paso 3a. Identificar la operación
41
AÑO: 2015
Para producir el cambio de estado especificado en el paso 2, se necesita una operación.

Este paso identifica la operación que, al ser aplicada, producirá el tipo específico de evento.
Por ejemplo, un evento pedido entregado es el resultado de una operación entregar pedido.
Paso 3b. Determinar si la operación es interna o externa Como se estableció, las operaciones pueden ser
internas o externas. En este paso, el analista elige una de las formas de representación que se muestran en la
figura.
Una operación interna es aquella cuyo procesamiento ocurre dentro del dominio (definido en el paso 0).
Además, puesto que su proceso es interno, su método se puede expresar como otro esquema de eventos.
Una operación externa es aquella cuyo procesamiento ocurre fuera del dominio analizado.
Puesto que su método de procesamiento y las causas no son dirigidas por este esquema, no se realizan más
pasos para el análisis de esta operación.
Figura: 7.27: Gráfica Operación Externa e Interna

Paso 3c. Identificar las condiciones de control
Una operación es llamada por una o varias activaciones. Sin embargo, tal vez sean
necesarias ciertas condiciones preexistente, llamadas condiciones de control, antes de que
una operación pueda comenzar realmente su proceso. Consideramos, por ejemplo, la
operación terminar pedido. El analista debe preguntar primero al usuario experto: ¿Bajo
qué condiciones se permite terminar el pedido?.
La respuesta de un experto será un enunciado en su propio lenguaje. Se deben exigir estos enunciados, ya que
el analista necesita analizar el mayor conocimiento experto posible. Por lo tanto, el usuario debe poder hablar
sin restricciones mediante términos familiares.
Figura: 7.28: Ilustra la terminación de una operación bajo ciertas condiciones

Paso 3d. Normalizar las condiciones de control
Aunque los enunciados expertos de la condición de control son vitales para el análisis del sistema, necesitan
transformarse en un arreglo sencillo y estándar de enunciados condicionales.
Una forma de expresar esto se llama Forma Normal Disyuntiva (FND). La FND suele ser una forma conveniente
con la cual escribir expresiones booleanas. En la FND, las condiciones que deben ocurrir al mismo tiempo se
agrupan y prueban en forma independiente.
Si uno de cualquiera de estos grupos es verdadero, toda la cláusula condicional es verdadera, con lo que se
justifica el cambio de estado.
La expresión inicial en FND se refina para lograr una mejor expresión de las condiciones.
Paso 4. Identificar las causas de la operación
En el paso anterior se definieron las condiciones de control para el procesamiento. Ahora, el analista debe
determinar cuándo se debe evaluar una condición de control, establecer los eventos que deben ocurrir para
que una o varias condiciones sean ciertas, de modo que pueda ocurrir otro evento. El analista también debe
establecer la naturaleza de sus mecanismos de activación.
Paso 4a. Identificar los tipos de eventos para la activación
La condición para el procesamiento suele ser muy sencilla, en muchos casos sólo se requiere que exista el
objeto sobre el que se realiza la operación.
42
AÑO: 2015
Cuando la cláusula condicional es más compleja, podrían necesitarse varios eventos para poder evaluar la
veracidad de una condición de control. El ejemplo de la figura requiere tres tipos de eventos.
Este paso pregunta en primer lugar por los eventos que deben ocurrir para evaluar la condición de control.
Luego determina cuáles de estos eventos deben activar realmente la evaluación.
Paso 4b. Indicar las condiciones complejas de control
Con frecuencia una condición de control sólo se limita a pedir que un evento u otro ocurran antes de que
pueda comenzar un proceso. En estas situaciones de diagramación, el rombo correspondiente a la condición de
control no se debe desplegar.
El rombo se reserva para aquellas operaciones que no se inicien automáticamente después de su activación,
porque indica que en primer lugar la operación debe evaluar su condición de control. Estas operaciones se
identifican porque no sólo necesitan que comiencen ciertas condiciones CUANDO, sino que existe una
necesidad compleja SI... Y...
Figura: 7.29: Tarea activada de acuerdo a la evaluación de ciertos eventos

O.
Paso 4c. Normalizar los tipos de eventos de activación
En el paso 3d anterior se ordenaron las condiciones en forma normal disyuntiva (FND) de modo que si
cualquiera de los grupos es verdadero, toda la cláusula condicional será cierta. El diagrama de la figura muestra
una condición de control cuya cláusula de condición se expresa en FND. Si cada uno de los eventos de la figura
necesitara de una evaluación de toda la condición de control, la figura seguiría igual.
Figura: 7.30:
Normalización de activación de tipos de eventos
Sin embargo, el primer grupo de condiciones se debe evaluar sólo cuando ocurran dos tipos de eventos; la
segunda, sólo cuando ocurra un tipo de evento. Por lo tanto, la condición de control se debe expresar como dos
condiciones de control, cada una correspondiente a un grupo de condición distinto. De esta forma, cada
condición de control se activa solamente con los eventos adecuados al grupo de condiciones.
Algunos analistas opinan que la notación de la figura necesita un tratamiento especial, representando cada
condición de control con su propia operación. Expresada de otra forma, cada nueva operación produciría un
evento que sólo ocurre cuando su condición de control es cierta. En otras palabras, el evento sólo indicaría que
ha ocurrido una evaluación correcta.
43
AÑO: 2015
En resumen, para estar en FND, las reglas de activación pueden necesitar un reagrupamiento, ya que
determinados eventos sólo se aplican a determinados grupos de condiciones.
Cuando esto ocurre, la condición de control original necesita dividirse de manera acorde. La división se puede
representar como varios rombos de condiciones sobre la misma operación, o bien, cada condición de control
puede expresarse con su propia operación particular.
Paso 4d. Especificar las reglas de activación
Ahora que los eventos de activación normalizados están determinados, el analista debe concluir la
especificación de las causas de la operación, identificando con exactitud los objetos necesarios para llamar a la
operación, es decir, determinar los argumentos necesarios para activar la operación y las funciones necesarias
para realizar la asociación adecuada.
Paso 5. Refinar los resultados del ciclo
Los pasos 1 a 4 guían al analista que trabaja con determinado evento, formalizándolo y determinando a qué lo
conduce. Este ciclo ya está terminado, básicamente. Sin embargo, antes de pasar al siguiente ciclo, son muy
útiles algunos refinamientos.
Paso 5a. Generalizar el tipo de evento de activación
Los tipos de evento de activación se pueden definir en términos de un tipo de evento más general. En el
ejemplo de la figura, se pueden generalizar dos de los tipos de eventos de activación, venta terminada con éxito
y venta cancelada, el supertipo de evento recibe el nombre de venta finalizada. Esta es otra forma de decir que
un evento venta finalizada es una ocurrencia mutuamente exclusiva tanto de venta terminada con éxito como
de venta cancelada. La generalización proporciona la conveniencia de la homogeneidad.
Paso 5b. Particularizar el tipo de evento objetivo
En contraste con el paso 5a, a veces las operaciones se especifican en forma demasiado abstracta. Si éste es el
caso, la especialización se puede expresar mediante subtipos de eventos.
La especificación de los tipos de eventos objetivo suele aclarar el significado, aunque no siempre es necesaria,
ya que la especialización se expresa de un modo u otro, si no es en el esquema de objetos, en la especificación
del método. La elección del nivel queda a cargo del analista y el experto.
Paso 5c. Verificar los eventos duplicados
Otra situación por analizar es la de un tipo de evento de activación que es igual a una subclasificación del tipo
de evento objetivo.
Como resultado del paso 5c, el esquema de eventos del ejemplo analizado se modifica, eliminando el tipo de
evento venta terminada (y su operación asociada). La razón es que su ocurrencia es igual a la de venta
finalizada. Por lo tanto, una venta finalizada no activa una operación para completar una venta; ya es una venta
terminada.
Figura: 7.31:
Generalizar el tipo de evento de activación
Siguiente paso
A partir de un evento objetivo, los pasos 1 a 5 guían al analista en la formalización del evento, la especificación
de sus causas y la realización de refinamientos al esquema resultante. En el siguiente paso, se toman los tipos
de eventos de activación de más reciente identificación y, considerando a cada uno como un tipo de evento
objetivo, se continúa de nuevo con el paso 1. Mientras haya eventos internos, este ciclo de exprimir los eventos
continúa. Se detiene cuando sólo permanezcan las operaciones externas y se haya alcanzado el tipo de evento
inicial.
Nivelación de los resultados

Cuando se termina el esquema de eventos se plantea la pregunta: ¿ha terminado el análisis o debe llevarse al
siguiente nivel de detalle? La respuesta depende de la naturaleza de cada operación del esquema de eventos, la
finalidad del proyecto de análisis y la experiencia disponible:
44
AÑO: 2015
 Para operaciones que están en el nivel básico, no existe el siguiente nivel de detalle del modelo. Esto se
aplica a aquellas operaciones cuya única tarea es crear, terminar, clasificar, desclasificar, reclasificar,
etcétera.
 Cuando una operación no es del nivel básico, se puede especificar en el siguiente nivel de detalle. Esta
especificación más detallada se llama especificación del método.
 La decisión de expresar las operaciones con el siguiente nivel de detalle pertenece al analista, al
experto y al gerente. El gerente podría determinar que la búsqueda de mayor detalle en un área
particular está fuera del alcance del proyecto en ese momento. El analista podría determinar que el
siguiente nivel no se puede diagramar sin tomar decisiones de implantación. En estos casos, un equipo
de diseño debe continuar su trabajo. Por otro lado, el experto y el analista pueden determinar que se
necesita mayor detalle para aclarar su esfuerzo del modelo. De cualquier forma, si algo se va a
automatizar, se tendrá que definir el método en algún momento.
Figura: 7.32:
Esquema de Evento y más en detalle un método de Operación
Los puntos anteriores proporcionan una razón para la descomposición de operaciones de manera descendente.
Sin embargo, el esquema de eventos producido con los pasos anteriores también define un subdominio para un
esquema de eventos de mayor nivel.
En otras palabras, el esquema de eventos se puede utilizar también para el análisis en forma ascendente. Un
punto de vista de este tipo es muy práctico al inicio del proyecto de análisis, cuando hace falta un alto nivel de
comprensión. El análisis siempre debe comenzar en el nivel de la habilidad del experto. Si se rebasa este nivel,
se desafía la precisión del proyecto de análisis.
Eventos y análisis de objetos

La especificación orientada a objetos se suele dividir en enfoques estructural y de comportamiento.
El enfoque estructural es una metáfora visual, espacial, que proporciona una visión estática de la distribución
de las cosas en el espacio. Al contrario, el enfoque mediante el comportamiento describe lo que hace una cosa.
El método presentado es un método dirigido a los objetivos, controlado por el comportamiento, que incorpora
las definiciones estructurales.
Al utilizar los pasos del análisis de eventos descritos anteriormente, el analista cuenta con una forma muy
buena de encontrar e identificar los tipos de objetos. De hecho, se identifican todos los tipos de objetos
necesarios. Los pasos del método se reiteran para añadir la parte estructural.
 Paso 1. Aclaración del tipo de evento En el paso 1, se especifican los preestados y postestados del
evento en términos de los tipos de objetos.
Ejemplo 7.8 Un evento persona clasificada como empleado identifica dos tipos de objetos que deben
estar en el esquema de objetos: persona y empleado.
 Paso 2. Generalizar el tipo de evento
Si se identifica un tipo de evento más general para que forme parte de este esquema de eventos,
deben identificarse nuevos preestados y postestados de eventos, como en el paso 1 anterior, de lo que
se obtienen tipos de objetos más generales.
 Paso 3. Definir las condiciones de operación
Las condiciones definidas en este paso contienen términos. Cada término requiere un tipo de objeto
válido, que debe expresarse en el esquema de objetos, para poder verificar la condición.
 Paso 4. Identificar las causas de la operación
45
AÑO: 2015
Especifica las reglas de activación para el esquema de eventos. Cada una contiene una función que
asocia un objeto de un tipo de objeto con uno de otro tipo. De esta forma, estos tipos de objeto y sus
funciones también deben estar en el esquema de objetos.
 Paso 5. Refinar los resultados del ciclo
Durante el refinamiento, tanto los tipos de objetos como las funciones se pueden generalizar,
especializar e incluso eliminar. Estos cambios también se deben reflejar en el esquema de objetos.
Diagrama de flujo de objetos

Los métodos que modelan el comportamiento, como el análisis de eventos, son adecuados para describir los
procesos en términos de activaciones, eventos, condiciones de control y operaciones. Sin embargo, para
procesos complejos, como compañías y organizaciones de gran tamaño, no siempre es posible o adecuado
especificar la dinámica de los eventos, activaciones y condiciones de control. En estos casos, se debe seguir un
método de representación diferente.
Los diagrama de flujo de objetos presentan un enfoque a nivel estratégico de cómo modelar los procesos,
compatible con la diagramación de eventos y la planeación estratégica.
Una visión funcional de alto nivel
Es muy importante contar con un método que aclare los procesos complejos. Específicamente, esta perspectiva
de alto nivel es muy útil en las siguientes situaciones:
 Al analizar una organización, suele suceder que el dominio del problema sea muy vasto e intrincado
para ser comprendido mediante las técnicas del comportamiento (al menos en un principio). La
separación de los procesos complejos en partes manejables es un aspecto crítico para entender bien las
situaciones complejas.
 La comprensión de alto nivel antes lograda es útil de inmediato para el administrador del conocimiento.
Los tipos de objetos y procesos identificados forman el comienzo de un modelo de empresa que
proveerá los estándares para el ulterior trabajo de análisis. Las simplificaciones inherentes a esta
orientación de alto nivel inspiran con frecuencia la creación de componentes de uso más general que
los reconocidos en un principio. Planeación, distribución y contabilidad son ejemplos de procesos de
alto nivel, puesto que se aplican a muchos tipos de objetos de la empresa: personas, dinero, bienes,
etcétera. La reutilización se amplifica a través de abstracciones como éstas.
 Los esquemas de procesos existentes se pueden expresar en términos de conceptos de procesamiento
más generales. Al eliminar los detalles de la dinámica evento / activación / condición, el analista puede
concentrarse en la representación de los flujos de control de actividades y los protocolos. Así se pueden
identificar componentes de uso más general.
 La planeación estratégica requiere una visión general del funcionamiento de una organización. Sin esta
perspectiva, la planeación y la ejecución del plan carecen de coherencia. Para los modelos a nivel
estratégico, no es necesaria ni útil la dinámica de un modelo de comportamiento. En este caso, el
conjunto de actividades de una empresa y sus interacciones son el punto importante. La serie de
funciones empresariales define la base del modelo de empresa.
La función de un proceso
El analista OO necesita un método para el análisis de los procesos complejos, como compañías y organizaciones
de gran tamaño, en términos de su funcionamiento. En este caso, una función de la empresa se refiere a la
finalidad de un proceso. Así, esta función o finalidad determina las actividades esenciales que controlan las
operaciones y recursos de una organización. Como tal, los modelos a nivel estratégico no especifican la
dinámica, sino que describen la interacción entre los procesos. Las actividades presentadas pueden existir en
paralelo, ocurrir en diferentes lugares y no estar sincronizadas entre sí.
Diagrama de flujo de datos
Una forma de modelar a nivel estratégico es mediante los diagrama de flujo de datos (DFD).
Los DFD muestran el sentido de descomposición y flujo de información del modelo a nivel estratégico. Los datos
pueden fluir sin que haya que definir si deben o no hacerlo, cuándo lo harán, con qué frecuencia o bien si el
flujo lo iniciará la actividad anterior o lo solicitará la siguiente.
Describe el flujo posible de información y la descomposición de actividades. Sin embargo, no indica nada
relacionado con el control de estas actividades o el de sus entradas y salidas.
Diagrama de flujo de objetos
En lugar de limitarse sólo al flujo de datos, los modelos a nivel estratégico OO indican el flujo de cualquier tipo
de objeto entre las actividades. Los diagrama de flujo de objetos representan las necesidades de procesamiento
de manera que los planificadores de la empresa puedan comprenderlo y aplicarlo a los proyectos de planeación
estratégica, no sólo a proyectos de información.
46
AÑO: 2015
Figura: 7.33: Diagrama de

Flujo de Objetos
Los diagrama de flujo de objetos tienen dos elementos principales: actividades y productos.
Una actividad produce un producto, y su producto es consumido por una o más actividades.
Los productos se consideran consumidos, puesto que, de alguna manera, forman parte integral del producto
final.
Productos
Los productos reflejan el propósito de las actividades que el analista espera comprender y modelar. El enlace
con el propósito es una técnica muy importante en el modelado de una empresa. Los productos son la
manifestación de ese propósito. Al buscar el mejoramiento de la productividad o la reducción de los costos, el
analista de la empresa debe identificar en primer lugar los productos. Los productos justifican los procesos. Al
diseñar sistemas para el procesamiento de datos, estos productos serán la guía de la base de datos.
Definición 7.8 Un producto es el resultado final que cubre el propósito de una actividad.
La identificación correcta de los productos es vital para la dirección de la compañía.
Los productos deben satisfacer dos criterios: ser rentables y tener una magnitud y una calidad cuantificables.
Rentabilidad de un producto
Una actividad puede tener muchas salidas. Sin embargo, al garantizar que los productos son real o
potencialmente rentables, el esfuerzo de modelado adquiere una perspectiva dirigida hacia la empresa.
Aunque no se necesita que todos los productos se vendan, al menos deben ser potencialmente rentables.
Además, estas actividades de producción podrían ser externas a la compañía, y se debería pagar por sus
productos.
Medida del producto
Además de su valor, un producto debe poderse cuantificar y su calidad debe poderse medir.
A menos que el producto pueda ser contado o calificado, la razón para su producción y consumo es
cuestionable. Por ejemplo, si una agencia de publicidad promete atraer clientes potenciales a una compañía,
ésta desearía saber su número y condición, además del momento en que llegarán. Si la firma no puede
proporcionar estas respuestas, no hay forma de saber si tienen o no un producto.
Productos sin valor
No siempre es adecuado pedir estrictamente que un producto sea vendible. Por ejemplo, los informes y las
facturas producidas por funciones de contabilidad y no son productos que se puedan vender a actividades
pagables. Sin embargo, se consumen en la actividad de la empresa, y el producto final es mejor y más útil para
cierta actividad de consumo.
No todos los productos se deben vender, sin embargo, todos los productos deben ser, al menos, bienes útiles;
lo bastante valiosos como para ser consumidos por otra actividad, de la cual se obtenga como resultado algo
más importante y útil.
Productos y objetivos
Los productos y objetivos se llegan a confundir, ya que los dos son producto de una actividad. Por ejemplo, en
respuesta a la pregunta del analista ¿Cuál es el producto de esta organización?, una respuesta podría ser Una
buena ganancia. Sin embargo, las compañías no venden buena ganancia. Aunque una buena ganancia es un
punto importante de las ventas, no es un producto: es un objetivo.
Las actividades producen productos y soportan metas. La flecha que parte de una actividad representa la
producción; el rectángulo, su producto. Se necesita diseñar una técnica diferente para representar el soporte
de objetivos, como la que se presenta en la figura.
Un error común es incluir los enunciados de los objetivos como parte del nombre del producto. Un ejemplo de
este tipo establece que el producto de un fabricante de televisores es la mejor calidad posible de televisores
con la mejor ganancia. Este nombre confunde qué se produce con por qué se produce. Aunque los dos son
inmensamente importantes para la planeación estratégica, tienen diferentes significados y usos. Por lo tanto,
los productos y los objetivos requieren representaciones independientes.
47
AÑO: 2015
Figura: 7.34: Error común al incluir el objetivo como nombre del producto
Relaciones productor / consumidor
Cada producto se elabora con la hipótesis de tener al menos un consumidor. Cada producto intercambiado
entre la actividad de un productor y la actividad de un consumidor establece una relación. Tal relación sólo
ocurre cuando dos actividades llegan a un acuerdo sobre un producto intercambiado. Así, los productos son el
tema de discusión de los productores y los consumidores.
Cada parte es libre de desarrollar y modificar los aspectos internos de sus actividades, en tanto no afecte la
interface.. Si la interface se modifica, debe hacerlo con el acuerdo de ambas partes. Se debe utilizar un lenguaje
para expresar los productos en forma clara y formal, para que estos acuerdos entre productor / consumidor no
se vean afectados por cambios en la actividad. Una forma es la representación mediante esquemas de objetos.
Productos como tipos de objetos
Cada producto es en sí un tipo de objeto. Los objetos a los que se aplica un producto reflejan la finalidad (o
función) de una actividad específica. Como tales, los productos se pueden modelar como cualquier tipo de
objeto.
Ejemplo 7.9 Los productos pueden definir subtipos o supertipos de productos. En la figura, ventas de hardware,
ventas de software y servicio técnico son subtipos del producto ventas de una casa de computación.
Figura: 7.35: Producto como Tipo de Objetos
Actividades
Cada actividad cumple una función, a saber, producir cierto producto. En el proceso de creación de sus
productos, lo usual es que una actividad consuma productos creados por otras actividades.
Una actividad es un proceso cuya producción y consumo están especificados.
En otras palabras, las actividades son procesos cuya dinámica no está especificada. Si se conoce la dinámica de
los eventos, activaciones y condiciones de control y su utilidad, el proceso se puede representar mediante un
esquema de eventos.
Persistencia de una actividad
Debido a su naturaleza de alto nivel, las actividades generalmente se consideran como procesos continuos.
Cada actividad se puede ver como una pequeña empresa en sí: mantiene su propio mundo, su caja negra
interna, sin indicar cuándo es activada o cuándo termina.
Sólo se sabe que consumen y emiten un producto.
48
AÑO: 2015
Las actividades se pueden expresar en forma continua, sin que el mundo externo conozca la forma en que
ocurre dicho procesamiento. Aunque las actividades deben reaccionar y emitir, sus procesos son desconocidos,
de ahí el término caja negra. Tales cajas de proceso son opacas, a menos que un analista opte por examinar su
contenido.
Cadenas de valor
Una actividad toma los productos de otras y aumenta su valor al transformarlos. Los productos transformados
se convierten entonces en un producto utilizado por otras actividades.
Estas transformaciones de valor agregado forman cadenas de valor. El análisis de las cadenas de valor examina
el valor de los productos consumidos, el costo de su transformación y el valor del producto obtenido.
Figura: 7.36: Cadena de Valor

Parejas actividad-producto
Cada actividad produce exactamente un producto y cada producto es producido exactamente por una
actividad. Esto no sólo mantiene los diagrama de flujo de objetos orientados hacia los productos, sino que
apoya un modelo claro y directo de la empresa. Además, esta orientación al producto conduce a la orientación
a objetos.
Para aclara la complejidad subyacente de actividades que aparentemente crean dos o más productos, es
necesario descomponer tales actividades en dos o más. Cada actividad producirá un producto discreto.
Otra una situación diferente se presenta cuando un producto se obtiene de más de una actividad. En este caso,
no es clara la medida en que se produce en forma independiente para cada actividad. No es posible realizar un
análisis de a cadena de valores de manera precisa.
Productos y productos derivados

La asociación de una actividad con un producto es una guía sólida para el análisis. La única excepción ocurre
cuando el producto es un producto derivado natural. Los productos derivados surgen como una adición
inherente al producto principal de una actividad. Son producto de un proceso invisible dentro de una actividad.
El producto derivado se indica mediante una línea punteada.
Figura: 7.37: Producto derivado
Productos consumidos
Los diagrama de flujo de objetos sólo muestran los elementos consumidos para agregar valor, no cualquier tipo
de objetos que fluya dentro de una actividad. Este enfoque de la representación del flujo de objetos no es tan
restrictivo, si se hace en la forma adecuada.
De este modo, el flujo se dirige a su nivel relevante de abstracción.
Sólo se representan los productos adecuados para el nivel de abstracción correspondiente.
49
AÑO: 2015
Nivelación de la actividad
Hasta ahora las actividades han sido presentadas como cajas negras. Este método proporciona un enfoque
manejable para las personas, a la vez que promueve el pensamiento modular reutilizable. Sin embargo, en
determinado momento, el analista desearía examinar la labor interna en una actividad.
Las actividades están compuestas por unidades de procesos. Al establecer una nivelación descendente, una
actividad puede descomponerse funcionalmente en sus componentes de procesos adecuados. Por el contrario,
con la nivelación ascendente, se puede definir un grupo de procesos relacionados entre sí como una actividad
de más alto nivel.
Cada nivel de una jerarquía establece su propio espacio independiente de proceso, o dominio. Cada dominio de
un proceso está sujeto a su propio esquema de objetos, con su propio comportamiento. El dominio de un
proceso de una actividad no es visible para su superdominio, hasta que se emite un producto o se le inyectan
productos consumidos.
Esta modularidad hace más sencillos los procesos de gran tamaño. Algunos objetos sólo serán conocidos dentro
de cierto dominio, en tanto que otros podrán ser conocidos en forma externa.
Al hacer la nivelación descendente, el análisis de la actividad no es completamente preciso, porque no se
conoce lo suficiente del detalle que abarca. Sin embargo, el hecho de contar con una visión estratégica y de alto
nivel aproximadamente correcta ya es un punto de ventaja para la planeación y coordinación del proceso de la
empresa.
Nivelación de los diagrama de flujo de objetos y esquema de eventos

Como las actividades representan procesos, cada una se puede descomponer en una representación de un
esquema de eventos. En el análisis descendente, los diagrama de flujo de objetos se descomponen por lo
general en otros diagrama de flujo de objetos, lo suficiente como para representar un proceso como un
esquema de eventos. Sin embargo, esto no es necesariamente así. Los diagrama de flujo de objetos son una
forma de describir los procesos y los esquemas de eventos son otra. Por lo tanto, un diagrama de flujo de
objetos se puede descomponer en cualquiera de estas descripciones, según las necesidades del analista.
Figura: 7.38: Nivelación de Diagramas de Flujo de Objetos

Además, los diagrama de flujo de objetos no son necesariamente para el análisis descendente.
También se pueden utilizar para componer descripciones ascendentes. En muchos casos, un analista deseará
hacer los dos. Un enfoque del análisis podría comenzar con el enfoque descendente, seguido de un
refinamiento ascendente, una vez mejor comprendidos los detalles.
Actividades como tipos de objetos

Como los productos, las actividades también son tipos de objetos. Cada objeto actividad es un dominio de
proceso en ejecución. Este dominio consume objetos de productos específicos y produce objetos para un
producto específico. Como tales, las actividades se pueden modelar como un tipo de objeto.
En el ejemplo de la casa de computación, la figura representa servicio técnico dividido en dos actividades más
específicas. En este caso, la ejecución de servicio técnico de software o servicio técnico de software es también
una ejecución de servicio técnico.
50
AÑO: 2015
Figura: 7.39: Actividades como Tipo de Objetos

Así, los subtipos de actividad proporcionan una jerarquía de generalización y especialización de actividad, que
se puede utilizar durante el análisis de actividades.
Cada actividad es un proceso que se lleva a cabo para lograr un fin determinado.
Un producto es el resultado final de este propósito. Cada producto es potencialmente rentable. Las actividades
consumen estos objetos reutilizables, añaden valor a los objetos y producen un nuevo producto.
Como corolario del tema podemos decir que los diagramas de flujo de objetos indican cadenas de relaciones
producto/consumidor, al mostrarlos en forma de una serie de actividades y productos intercambiados. Tal
relación sólo ocurre cuando dos actividades llegan a un acuerdo sobre un producto intercambiado y entonces el
producto es el tema de sus comunicaciones.
Metodología OMT
El Modelo de Objetos
Captura la estructura estática del sistema, mostrando:
 objetos
 relaciones entre objetos
 atributos
 operaciones
 Es el más importante, puesto que el sistema se construye alrededor de los objetos.
 Conceptos, notación y ejemplos.
Objetos y Clases
Concepto, abstracción o cosa con fronteras definidas y significado para nuestro problema.
Permite una mejor comprensión del mundo y proporciona la base para una implementación sobre el
ordenador.
No existe una representación exacta.
Todos los objetos tienen una identidad y son distinguibles.
Clase:
Describe grupos de objetos con propiedades (atributos) similares, comportamiento (operaciones)
comunes, relaciones con otros objetos y semántica común.
Cada objeto sabe cuál es su clase, ya que es una instancia de la misma.
Elemento esencial para la abstracción y generalización.
Diagrama de Objetos
Notación gráfica para modelar los objetos, clases y sus relaciones.
Dos clase de diagrama:
 De clases
 De objetos (instancias)
Diagrama de clases
Esquema, patrón o plantilla para describir muchos casos posibles de datos. Describe clases de objetos.
Diagrama de objetos
51
AÑO: 2015
Describe cómo se relacionan un grupo particular de objetos entre sí.
Notación de clases y objetos Atributos

Valor de un dato dentro de un objeto. Cada atributo tiene un valor para cada objeto. El nombre de un atributo
es único dentro de una clase.
Debería ser un dato puro, no un objeto (no tiene identidad). Si un objeto necesita otro objeto habrá que
modelarlo como asociación.
Además del nombre podemos especificar el Tipo y el Valor por defecto.
Los identificadores de objetos explícitos no se necesitan en el Modelo de Objetos.
Figura: 8.1:
Notación de Clases y Objetos
Notación de atributos Operaciones y Métodos

Función o transformación que se aplica a o por los objetos en una clase. Tienen un objeto destino como
argumento implícito (el objeto actual).
Polimorfismo: la misma operación puede aplicarse a clases diferentes dentro de una jerarquía de herencia.
Método: implementación de una operación para una clase. Las operaciones con métodos en varias clases
deben compartir la misma signatura (tipos de sus argumentos y valor que devuelven).
Notación de operaciones y métodos

Se describe en el primer cuadrante el Nombre de la Clase, luego, en el segundo, los atributos
de dicha clase, finalmente, en el ultimo se detallan las operaciones que intervienen en la
Clase. Como lo podemos apreciar en la figura siguiente.
Nombre de Clase
Nombre atgributo-1
Nombre atributo-2
Operación 1
Operación 2
Figura: 8.2: Notación de Clase, Atributos y Operaciones
Enlaces y Asociaciones
Enlace
Conexión física o conceptual entre objetos.
Asociación
Grupo de enlaces con la misma estructura y semántica común.
Sentido de una asociación:
 Inherentemente son bidireccionales.
 directa (forward) e inversa (inverse).
 Implementación común en los lenguajes de programación mediante punteros o referencias, aunque en
la fase de modelización no es recomendable esta práctica.
Las asociaciones pueden ser binarias, ternarias o de órdenes superiores y los nombres de las asociaciones son
opcionales en la notación (se escriben en cursiva).
Nombre
52
AÑO: 2015
Figura: 8.3:
Diagrama de Clase y de Casos
Multiplicidad
La multiplicidad especifica cuántos objetos de una clase pueden relacionarse con un único
objeto de una clase asociada.
Se especifica mediante:
 Un subconjunto (posiblemente infinito) de enteros no negativos: 0..n.
 Uno o varios intervalos no conexo: 1..4, 7.
 No debemos preocuparnos de ajustar la multiplicidad demasiado pronto en nuestro Modelo de
Objetos.
 En los Diagrama de Objetos la multiplicidad se especifica mediante símbolos especiales en los extremos
de las líneas de las asociaciones.
Figura: 8.4: Multiplicidad en OMT
Atributos de los enlaces

Las propiedades de los enlaces de una asociación son:
 Opcionales en los enlaces uno-a-uno y uno-a-muchos.
 Obligatorios en los enlaces muchos-a-muchos.
Modelando una Asociación como una Clase

Además de los atributos de un enlace, permite añadir un nombre y operaciones.
Son útiles cuando:
 Los enlaces pueden participar en asociaciones con otros objetos.
 Los enlaces están sujetos a operaciones.
53
AÑO: 2015
Figura: 8.5:
Atributos en los enlaces
Roles
Se lo coloca en uno de los extremos de una asociación. El Nombre de Rol identifica de forma única el final de
una asociación. Atributo derivado cuyo valor es un conjunto de objetos relacionados. Deben ser únicos en las
asociaciones de una clase.
Suelen aparecer como nombres en los enunciados de los problemas.
En relaciones n-arias se debe colocar un rol en cada extremo.
Figura: 8.6:
Nombres de Rol para una asociación
Los roles proporcionan una forma de ver las asociaciones como recorrido desde un objeto hacia otro conjunto
de objetos. Su uso es opcional. A veces resulta más claro su uso que los nombres de las asociaciones.
Normalmente son necesarios en las relaciones entre objetos de la misma clase, o cuando existe más de una
asociación entre el mismo par de clases.
Ordenación
Se utiliza en la parte de la multiplicidad muchos de una asociación en la que los objetos deben estar ordenados.
Cualificadores
Su función específica es describir una asociación cualificada, esta relaciona dos clases mediante un cualificador.
Puede considerarse como un tipo de asociación ternaria.
Cualificador: atributo especial que puede reducir la multiplicidad de una asociación.
Pueden utilizarse en asociaciones uno a muchos o muchos a muchos. Distinguen conjuntos de objetos
en el extremo muchos de la asociación.
Mejora la semántica y aumenta la visibilidad de caminos de navegación.
Se representa mediante un cuadro en el extremo más próximo a la clase a la que cualifica.
Ejemplo 8.1 Directorio + nombre de archivo.
Figura
: 8.7: Una asociación cualificada
Notación de cualificación
54
AÑO: 2015
Un directorio contiene más de un archivo.

El nombre del directorio más el nombre del archivo en el directorio, identifican de forma única al
archivo:
Una compañía tiene muchos empleados.
El cualificador descompone el conjunto total de los empleados en subconjuntos disjuntos (por cargo) de
más de un objeto.
Agregación
Relación parte-todo o parte-de, el ensamblaje se relaciona con sus componentes. Verifica las propiedades
transitiva y antisimétrica. También es común la agregación recursiva.
Cuando tenemos duda en la etapa de modelamiento, mejor es utilizar una asociación ordinaria.
Preguntas útiles para identificar agregaciones:
¿Se puede utilizar la frase parte de?
¿Se propagan algunas operaciones del todo a las partes de forma automática?
¿Se propagan algunos valores de los atributos del todo a alguna o todas de las partes?
¿Existe una asimetría intrínseca en la asociación, por la cual un objeto está subordinados otro (la
eliminación del todo implica la de las partes)?
Notación de agregación
 Agregados fijos: estructura fija, con el número y tipos de subpartes predefinidos..
 Agregados variables: tienen un número finito de niveles, pero el número de partes varía.
 Agregados recursivos: contienen, directa o indirectamente, un caso de la misma clase.
Propagación de las operaciones
Aplicación automática de una operación a una red de objetos cuando se aplica la operación a un objeto inicial.
La propagación de una operación a las partes es un buen indicador de agregación.
Figura: 8.8: Agregación
Generalización y herencia
Generalización: relación entre una clase (superclase) y una o más versiones refinadas de ella (subclases).
Relación se describe con la frase es un.
Las subclases heredan las características, atributos y operaciones de su superclase.
Una instancia de una subclase es una instancia de sus clases antecesoras o ascendientes.
Distinción entre generalización y herencia:
Generación: relación entre clases.
Herencia: mecanismo para compartir características.
Ascendientes y descendientes: generalización en múltiples niveles.
Discriminador: atributo de tipo enumerado, que indica la propiedad del objeto que se está abstrayendo
para una relación de generalización. Solo debería discriminarse una propiedad a la vez.
Ejemplo 8.2 Fichero. Contenido: de texto, binario, de datos; Acceso: secuencial, directo, indexado; Carácter:
ejecutable, no ejecutable.
Generalización como extensión y restricción
Una instancia de una clase es una instancia de todas sus clases ascendientes y no puede omitir o suprimir un
atributo de sus ascendientes.
Una subclase puede añadir nuevas características: extensión.
Una subclase puede redefinir una característica de sus ascendientes: restricción.
55
AÑO: 2015
Ejemplo 8.3 Limitar los valores en un rango menor (círculo es una elipse de a=b).
Agregación vs. Generalización.

La agregación relaciona instancias (relación y), la generalización relaciona clases (relación o).
Redefinición
Una subclase reemplaza una característica de su superclase definiendo una característica con el mismo
nombre.
Motivos para redefinir
Especificar un comportamiento que dependa de la subclase.
Aplicar de forma más rigurosa las especificaciones de una característica. Mejorar el rendimiento.
No se debe reemplazar la signatura de una característica.
Debe preservar:
 Tipos de los atributos.
 Número y tipos de argumentos de funciones.
 Tipo del valor devuelto por una operación.
Redefinir operaciones por:
 Extensión.
 Restricción.
 Optimización.
 Conveniencia.
Reglas prácticas:
 Todas las operaciones de consulta y actualización se heredan por todas las subclases.
 Las operaciones de actualización que modifiquen atributos o asociaciones restringidas, deben
mantener la misma restricción.
 Las operaciones heredadas se pueden refinar añadiendo un nuevo comportamiento.
Clases abstractas
Las clases abstractas sirven para definir un comportamiento y/o estructura común a un conjunto de subclases.
No es instanciable (no existen objetos de esa clase). Sin embargo, sus subclases pueden ser clases concretas
(que sí son instanciables). Organizan características comunes de varias clases.
Pueden definir el protocolo para una operación sin proporcionar un método correspondiente (operación
abstracta). Una clase concreta no puede contener operaciones abstractas.
La naturaleza abstracta de una clase es siempre provisional.
Herencia múltiple
Esta característica permite a una clase tener más de una superclase, y heredar las características de todos sus
padres.
Las principales ventajas son:
 Una mayor potencia a la hora de definir nuevas clases.
 Oportunidades adicionales de reutilización.
 Acercamiento a la forma natural de pensar.
Ejemplo 8.4 El triángulo relleno significa que las subclases no son disjuntas.
Las principales desventajas se encuentra en los:
 Problemas de implementación (por ejemplo, la herencia repetida de C++).
 Clase vínculo (join): clase con más de un padre.
 Herencia múltiple accidental.
Un instructor es inherentemente Profesor y Alumno, ¿cómo modelar un Profesor de una
Universidad que recibe clases en otra?
Metadatos
Son Clases de las Clases. Son datos que describen otros datos: los modelos son metadatos, definición de una
clase, p.e.
Los SGBDR también utilizan metatablas para almacenar las definiciones de las tablas (el catálogo).
Introducen confusión pues difuminan la diferencia entre el modelo y el mundo real.
Patrones y Metadatos:
 La instanciación relaciona una clase con sus instancias.
 La representación explícita del proceso de instanciación puede ser útil si tanto la clase como los objetos
han de ser manipulados como objetos.
Características de clase
Las clases pueden ser consideradas también como Metaobjetos.
Atributos de clase:
56
AÑO: 2015
 Describen un valor común para todos los objetos de la clase.

 Permiten almacenar información que puede usarse como valor por defecto en la instanciación.
 Permiten almacenar información sobre las instancias de la clase.
Operaciones de clase:
Operación que tiene lugar sobre atributos de la clase.
Se invoca sobre la clase y no sobre una instancia concreta.
Ejemplo 8.5 New.
Ejemplo 8.6 Smalltalk: x:= Dictionary new
Ejemplo 8.7 C++: en la declaración del objeto se llama al constructor de la clase
Claves candidatas
Una clave candidata es un conjunto mínimo de atributos que identifican un objeto o enlace.
El identificador de objeto (OID) es siempre una clave candidata. Es un concepto lógico
muy utilizado en el mundo de los SGBDR.
Se denotan en los diagrama de clases mediante corchetes.
Restricciones
Es una relación funcional entre entidades (clase, objeto, atributo, enlace o asociación) dentro del Modelo de
Objetos que limita los valores que la entidad puede tomar.
Restricciones sobre enlaces:
 Restricciones generales.
Se expresan mediante lenguaje natural o ecuaciones.
Se denota mediante una línea de puntos entre las clases implicadas y con la descripción entre llaves.
 Objetos, enlaces y atributos derivados.
Un objeto derivado se define como una función de uno o más objetos.
Es redundante, pero se introduce en el Modelo para facilitar la comprensión.
También existen enlaces y atributos derivados.
Homomorfismo
El homomorfismo es un tipo especial de asociación que supone una correspondencia entre dos asociaciones.
Aparecen en la práctica en aplicaciones complejas que tratan metadatos.
Modelo de Datos vs Modelo de Objetos

Una BD se desarrolla mediante un Modelo de Datos.
1. Se construye el Modelo de Datos sobre el dominio de la aplicación.
2. Se transforma del Modelo de Datos en un Diseño de la BD mediante la aplicación de una serie de
transformaciones estándar (normalización).
Un Sistema de Objetos se construye modelando mediante técnicas diferentes, pues las técnicas del Modelo de
Datos son bastante limitadas para soportar el Modelo de Objetos.
Consejos prácticos
 No comenzar construyendo diagrama de clases; primero, es necesario comprender el problema.
 Intentar mantener el Modelo sencillo.
 Seleccionar con cuidado los nombres.
 No introducir punteros o referencias a otros objetos como atributos.
 Intentar evitar asociaciones n-arias.
 No intentar establecer el grado de multiplicidad perfecto al principio.
 No introducir atributos de enlace dentro de la clase.
 Utilizar asociaciones cualificadas donde sea posible.
 Intentar evitar generalizaciones profundamente anidadas.
 Intentar asociaciones uno a uno.
 No se sorprenda si su modelo requiere una revisión.
 Documentar siempre los Modelos de Objetos.
Resumen del Modelo de Objetos

El Modelo de Objetos describe la estructura estática de las clases, los objetos y sus relaciones.
Conceptos de clase, atributo, objeto y operación.
Enlaces y asociaciones.
Agregación.
Generalización y herencia.
Características avanzadas: clases abstractas, herencia múltiple, metadatos, claves candidatas y
restricciones.
57
AÑO: 2015
Diferencias entre el Modelo de Datos y el Modelo de Objetos.

Glosario
agregación generalización método redefinición
asociación identidad módulo cualificación
atributo herencia multiplicidad rol
clase instancia objeto discriminador
enlace operación atributo de enlace clasificación
especialización clase abstracta restricción clase concreta
clase vínculo metadato metaclase clave candidata
propagación homomorfismo herencia múltiple
Cambios introducidos por OMT-2

OMT-2 introduce cambios en el modelo de objetos (compatibilidad con UML)
Notación de Objetos: Objeto como un rectángulo con la siguiente sintaxis
NombreObjeto : nombreClase
Multiplicidad: la multiplicidad muchos añade información al símbolo del círculo relleno, incorporando
información textual adicional.
Atributos de la relación: un atributo de la relación es un caso particular de una clase asociación.
Clase asociación: la notación es ahora una línea discontinua que une la clase asociación con la
asociación.
Generalización: la representación es aquí una flecha cuyo extremo ”toca” la clase más genérica. Puede
organizarse en árbol.
Símbolo de cruce: se introduce para evitar ambigüedades.
El Modelo Dinámico
Introducción
El Modelo Dinámico, modela los aspectos del sistema que tienen que ver con el tiempo y los cambios.
o modela el Control, aspecto del sistema que describe la secuencia de operaciones que ocurren como respuesta
a unos estímulos.
Conceptos principales del Modelo Dinámico:
 Sucesos o Eventos: representan los estímulos externos.
 Estados: representan valores de los objetos.
La notación a utilizar en este libro es la de David Harel, para dibujar los diagrama de estado estructurado,
empleando contornos anidados con objeto de mostrar la estructura.
Sucesos y Estados
El Suceso es estímulo individual de un objeto a otro. Ocurre en un determinado instante y no tiene duración.
El Estado son valores de los atributos y enlaces de un objeto en un instante dado.
Se representan con los Diagrama de Estado, que no es otra cosa que un patrón de sucesos, estados y
transiciones entre estados para una clase determinada.
El Modelo Dinámico consiste en múltiples diagrama de estado, uno por cada clase con comportamiento
dinámico significativo.
La definición de sucesos y estados depende del nivel de abstracción que se utilice.
Sucesos
Dos sucesos pueden darse consecutivamente de forma lógica (causa-efecto) o no (concurrentes).
Son un medio de transmisión de información de un objeto a otro, unidireccional.
Clase de sucesos: Indica estructura y comportamiento comunes. Pueden contener atributos para expresar la
información que manejan.
Ejemplo 8.8 Pulsación de un botón del ratón (botón, posición) o la salida de un vuelo (avión, número vuelo,
ciudad).
Escenarios y trazas de sucesos
El Escenario es una secuencia de sucesos que tienen lugar durante una ejecución particular del sistema.
58
AÑO: 2015
el locutor descuelga el tubo telefónico (receptor)

comienza el tono para el marcado del número
el locutor marca el número (seis dígitos, uno después de otro)
el teléfono llamado comienza a sonar
aparece la señal de llamada en el teléfono del locutor
el destinatario responde
el teléfono del destinatario deja de sonar
el tono de llamada desaparece en el teléfono del locutor
los teléfonos se conectan
se produce un tiempo de comunicación
el destinatario cuelga
los teléfonos se desconectan
el locutor cuelga
Figura: 8.9: Escenario para una llamada telefónica

En los Escenarios y trazas de sucesos pueden enviarse sucesos concurrentes.
La descripción de escenarios es el primer paso del modelo dinámico, al que debe seguir la identificación de los
objetos emisores y receptores de sucesos.
El Diagrama de traza de sucesos (DTS): especifican la secuencia de sucesos en el tiempo. En la etapa de diseño
hay que refinar los DTSs.
Estados
Abstracción de los valores de los atributos y enlaces de un objeto. Especifica la respuesta de un objeto a los
sucesos que llegan (acción/cambio de estado).Representan intervalos de tiempo. En su definición, se ignoran
los atributos que no intervienen en el comportamiento del objeto.
Caracterización de un Estado
Caracterización mediante la indicación de varias pautas que identifican al objeto y que pueden solaparse:
 Nombre: alarma sonando
 Descripción: la alarma en el reloj suena para indicar la hora seleccionada.
Secuencia de sucesos que producen el estado:
 Activar alarma (hora seleccionada)
 Cualquier secuencia excluyendo desactivar (alarma)
 Hora actual=Hora seleccionada
Condiciones que caracterizan el Estado:
 Alarma = sí, Hora selec. <= Hora actual <= Hora selec. + 20 segundos, y no botón pulsado desde Hora
selec.
Sucesos aceptados en el Estado:
 Suceso Acción Siguiente Estado
Ejemplo 8.9 Hora actual = Hora selec. + 20 iniciar(alarma) Normal
Ejemplo 8.10 Botón Pulsado (cualquiera) iniciar (alarma) Normal
Diagrama de Estado
Relaciona Sucesos y Estados.
El siguiente Estado depende del Suceso recibido y del Estado actual.
Las transiciones para abandonar un Estado deben corresponder a sucesos diferentes.
Si un Suceso no genera una transición que abandone el Estado, se ignora. Los Estados
no definen por completo todos los valores del objeto y pueden representar bucles continuos o ejecuciones no
repetitivo..
Los diagrama que representan ejecuciones no repetitivo:
 Tienen estados iniciales y finales
 Se utilizan como subrutinas referenciadas desde diversos diagrama de más alto nivel.
Condiciones
 Funciones lógicas sobre los valores de los objetos.
 Se indican entre corchetes.
 Válidas durante un intervalo de tiempo.
 Se pueden utilizar como guardas sobre las transiciones: se disparan sólo si se cumple la condición.
59
AÑO: 2015
Figura: 8.10: Diagrama de Estado para una línea telefónica
Operaciones
Están asociadas a las transiciones entre Estados.
Tipos:
Acciones: operación instantánea asociada a un suceso. También pueden representar operaciones de
control interno.
Actividades: operación con duración en el tiempo, asociada a un Estado.
Diagrama de Estado anidados

Los Diagramas de Estado se pueden estructurar de forma similar a la de los objetos.
 Generalización: actividades de anidamiento que permiten organizar los Estados y Sucesos de forma
jerárquica.
 Agregación: permite la descomposición de un Estado en componentes ortogonales, siendo equivalente
a la concurrencia de los Estados.
Anidamiento de Estados
Una actividad en un Estado puede expandirse como un Diagrama de Estado de nivel inferior, en el que cada
Estado representa una etapa de la actividad.
Los Sucesos también pueden expandirse en Diagrama de Estados subordinados.
Generalización de Estados
En general, los Estados en un Diagrama anidado pueden interactuar con otros Estados.
Los Estados pueden tener subestados que heredan sus transiciones, a menos que las ’reemplacen’ por otras
equivalentes.
60
AÑO: 2015
Figura: 8.11:
Anidamiento de diagramas de estados (máquina expendedora de dinero)
Figura: 8.12:
Diagrama de estado de la transmisión de un vehículo
Generalización de Sucesos
Los Sucesos pueden organizarse en una jerarquía de generalización en la que se heredan los atributos de los
Sucesos.
Permiten utilizar distintos niveles de abstracción en diferentes partes del Modelo.
Concurrencia
Un Diagrama de Estados para un sistema compuesto es una colección de diagramas, uno por cada componente.
La agregación implica Concurrencia. Los Diagramas de Estado de los componentes suelen ser independientes,
pero pueden interactuar (las guardas de las transiciones para un objeto en un determinado estado pueden
depender de otro objeto).
Concurrencia dentro de un objeto:
Podemos dividir un objeto en subconjuntos de atributos y enlaces, cada uno con su propio diagrama.
61
AÑO: 2015
Figura: 8.13:
Jerarquía parcial de sucesos (teclado)
Acciones de Entrada (Entry) y de Salida (Exit)
Acciones que se ejecutan cuando se entra o se sale de un Estado por cualquier suceso.
Estas acciones se simplifican cuando todas las transiciones impliquen esas mismas acciones para la entrada o la
salida.
Orden de ejecución de las acciones:
 Acciones en la transición que llega.
 Acciones de Entrada.
 Actividades.
 Acciones de Salida.
 Acciones en la transición de Salida.
Acciones internas
Un Suceso puede provocar que se ejecute una acción sin cambiar de Estado.
En la notación se refleja como suceso / acción
Transiciones automáticas y Envío de Sucesos
Transiciones automáticas:
62
AÑO: 2015
Figura: 8.14: Arriba: Acciones en la transiciones. Abajo: Acciones de entrada en los distintos estados
Figura: 8.15:
Resumen de la notación extendida para Diagramas de Estados
² Se disparan siempre que la actividad asociada con el Estado fuente ha terminado, y se cumplen las
condiciones de las guardas (transiciones lambda).
Envío de Sucesos:
 Los sucesos pueden dirigirse a un solo objeto o a un conjunto de ellos.
 La recepción concurrente de Sucesos de denomina condición de carrera. No es un error de diseño pero
en general no deseadas.
Sincronización de Actividades Concurrentes
A veces, un objeto puede realizar actividades de forma concurrente.
Los pasos internos de las actividades no han de estar sincronizados, pero to-das ellas han de completarse para
poder pasar al siguiente Estado:
 División del Control (split).
 Fusión del Control (merge).
Relación entre Modelo de Objetos y Modelo Dinámico

El Diagrama de Estados describe toda o una parte del comportamiento de un objeto de una clase. Los Estados
son los equivalentes a los valores de los atributos y enlaces de las clases. Los Sucesos se pueden representar
como operaciones en el Modelo de Objetos.
La estructura del Modelo Dinámico está relacionada y restringida por la del Modelo de Objetos (generalización
por restricción).
Un Estado Compuesto es el agregado de más de un subestado concurrente. En el Modelo de Objetos hay tres
fuentes de concurrencia:
 Concurrencia entre componentes: cada componente tiene su propio Estado independiente.
63
AÑO: 2015
 Concurrencia entre partes de un componente: agregación dentro de un objeto.

 Concurrencia del objeto: comportamiento concurrente de un objeto.
El Modelo Dinámico de una clase lo heredan sus subclases.
La jerarquía de Sucesos es independiente de la jerarquía de clases (pueden definirse a
través de diferentes clases de objetos, y son más expresivos que las operaciones).
Consejos prácticos
 Construir Diagrama de Estado sólo para las clases con comportamiento dinámico significativo.
 Utilizar escenarios.
 Considerar sólo los atributos relevantes.
 Verificar la consistencia de los diferentes Diagramas de Estado.
 Considerar las necesidades de la aplicación a la hora de decidir el grado de granularidad de los Sucesos
y Estados.
 Distinguir entre actividades y acciones.
 Poner acciones de entrada cuando todas las transiciones entrantes generen la misma acción. Ídem para
las de Salida.
 Utilizar Estados anidados cuando las mismas transiciones se apliquen a varios Estados.
 Intentar mantener los Diagramas de estados de las subclases independientes de los de las superclases.
 Tener cuidado con las posibles condiciones de carrera en los Diagramas de Estado.
Resumen del Modelo Dinámico
Representa la información de control, secuencia de sucesos, estados y operaciones que ocurren dentro de un
sistema de objetos.
Patrón para los posibles escenarios que se puedan presentar.
Notación: compromiso entre simplicidad y expresividad (donde no llegue la notación, lenguaje natural).
Suceso: señal de que ha pasado algo.
Estado: intervalo entre Sucesos que especifica el contexto en el que se interpretan los Sucesos:
Generalizaciones de restricción sobre una clase.
Una subclase hereda los diagramas de estado de su clase base.
Transición: respuesta a un suceso, incluido el siguiente estado, acciones posibles y sucesos enviados a
otros objetos
Transiciones automáticas: se disparan cuando se cumplen sus condiciones y se han realizado todas las
actividades dentro del Estado.
Las transiciones pueden dividir o juntar el flujo de control.
Acción: operación instantánea en respuesta a un suceso.
Acciones de Entrada y Salida: se pueden asociar con un Estado.
Acciones Internas que representan transiciones que no cambian de Estado.
Actividad: secuencia de acciones que requieren un tiempo para realizarse.
Sucesos y Estados pueden expandirse mediante Diagramas de Estados Anidados para mostrar mayor
detalle, y pueden organizarse en jerarquías de herencia.
Los objetos son inherentemente concurrentes. Los Diagramas de Estado muestran la concurrencia:
 como agregado de Estados Concurrentes
 como agregado dentro de un objeto
 mediante el comportamiento concurrente de los objetos.
El Modelo Funcional
El modelo funcional describe los cálculos existentes del sistema sin describir ni cómo ni cuándo se calculan. El
modelo funciona especifica lo que sucede, el modelo dinámico especifica cuando sucede y el modelo de
objetos especifica a que le sucede.
Diagrama de Flujo de Datos

El modelo funcional consta de múltiples diagrama de flujo de datos, que especifican el significado de las
operaciones y de las restricciones. Un diagrama de flujos de datos (DFD) muestra las relaciones funcionales
entre los valores calculados por un sistema, incluyendo los valores introducidos, los obtenidos, y los almacenes
internos de datos. Es un grafo que muestra el flujo de valores de datos desde sus fuentes en los objetos
mediante procesos que los transforman, hasta sus destinos en otros objetos. No muestra información de
control.
Un diagrama de flujo de datos contiene procesos que transforman datos, flujos de datos que los trasladan,
objetos actores que producen y consumen datos, y de almacenes de datos que los almacenan de forma pasiva.
La siguiente figura muestra un DFD típico.
64
AÑO: 2015
Figura: 8.16:
Diagramas de flujo de datos típico
Procesos
Un proceso transforma valores de datos. Los procesos del más bajo nivel son funciones puras, sin efectos
laterales. Un grafo completo de flujos de datos es un proceso de alto nivel. Los procesos pueden tener efectos
laterales si contienen componentes no funcionales, tales como almacenes de datos u objetos externos.
Los resultados de estos procesos dependen del comportamiento del sistema, según se especifique en el modelo
dinámico.
Los procesos se dibujan en forma de elipse que contienen una descripción de la transformación, normalmente
su nombre. Cada proceso tiene un número fijo de flechas de entrada y salida de datos, cada una de las cuales
lleva un valor de un tipo dado.
Las entradas y salidas se pueden rotular, para mostrar su papel en el cálculo, pero es frecuente que baste el
tipo de valor asociado al flujo de datos.
Figura: 8.17: Proceso

Actores
Un actor es un objeto activo que controla el grafo de flujo de datos produciendo o consumiendo valores. Los
actores están asociados a las entradas y salida del grafo del flujo de datos.
En cierto sentido, los actores yacen en la frontera del grafo, pero hacen que concluya el flujo de datos como
fuentes y sumideros de datos, así que en algunos casos se denominan terminadores.
Almacenes de datos
Un almacén de datos es un objeto pasivo dentro de un diagrama de flujo de datos que almacena datos para su
posterior utilización. Difieren con los atores en que no generan ninguna operación por si mismos, sino que se
limitan a responder a solicitudes de almacenamiento y acceso a datos.
Los almacenes se dibujan en forma de un par de líneas paralelas que contienen el nombre del almacén. Las
flechas de entradas indican información u operaciones que modifican los datos almacenados; esto incluye la
adición, modificación o el borrado de elementos. Las flechas de salidas indican información que se ha extraído
del almacén.
La figura siguiente muestra un almacén típico dentro de un DFD.
65
AÑO: 2015
Figura: 8.18: Almacén

Tanto los actores como los almacenes de datos son objetos. Se diferencian en que su comportamiento y
utilización suelen ser distintos, aun cuando en un lenguaje orientado a objetos ambos pudieran ser
implementados como objetos. También el almacén puede ser implementado como un fichero y el terminador
como un dispositivo externo.
Diagrama de flujo de datos anidados
Un DFD resulta especialmente útil para mostrar funcionalidad de alto nivel de un sistema, y su descomposición
en unidades funcionales más pequeñas. Un proceso se puede expandir en otro diagrama de flujo de datos.
Todas las entradas y salidas del proceso lo serán también del nuevo diagrama, también pueden tener
almacenes de datos que no se muestren en el diagrama de nivel superior.
Flujos de control
Un diagrama de flujo de control muestra todas las posibles vías de computación para los valores. No muestra
cuales son las vías que se ejecutan ni en que orden. Las decisiones y la secuencias son problemas de control,
que forman parte del modelo dinámico. Una decisión afecta a si una o más funciones llegan incluso a
ejecutarse, en lugar de proporcionarlos un valor. Aun cuando las funciones no poseen valores de entrada
procedentes de estas funciones de decisión, a veces resulta útil incluirlas en este modelo funcional, para que no
se olviden, y para que sea posible mostrar sus dependencias de datos. Esto se hace incluyendo flujos de control
en el diagrama de flujo de datos.
Un flujo de control es un valor booleano que afecta a si un proceso es o no evaluado.
Los flujos de control se muestran en los diagramas con una línea discontínua que va desde un proceso que
produce un valor booleano hasta el que se esta controlando.
Especificaciones de proceso
Toda operación se podrá especificar de diferentes maneras, entre las que se cuentan las siguientes:
 Funciones matemáticas, tales como las funciones trigonométricas;
 Tablas de valores de entrada y salida para pequeños conjuntos finitos
 Ecuaciones que especifican la salida en términos de la entrada
 Condiciones previas y posteriores
 Tablas de decisión
 Pseudocodigo
 Lenguaje natural
 Diagrama de flujos
 Diagrama de árboles
 etc.
Restricciones
Una restricción muestra la relación entre dos objetos al mismo tiempo (tal como la frecuencia y la longitud de
onda) o bien entre distintos valores del mismo objeto en instantes diferentes (tal como el número de acciones
de un fondo de pensiones). Las restricciones se pueden expresar como una función total o como una función
parcial.
Las restricciones pueden aparecer en todas las clases de modelo. Las restricciones de objetos especifican que
algunos objetos dependen entera o parcialmente de otros objetos.
Las restricciones dinámicas especifican relaciones entre los estados o sucesos de distintos objetos. Las
restricciones funcionales especifican limitaciones aplicables a operaciones.
66

Apunte Ingeniería de Software I - 2015 - U07 Análisis Orientados A Los Objetos (OMT)

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Apunte Ingeniería de Software I - 2015 - U07 Análisis Orientados A Los Objetos (OMT)

Caricato da

Copyright:

Formati disponibili

Contenido

Tema 7: Análisis Orientados a los Objetos (OMT)...................................................................................................4

Tema 7: Análisis Orientados a los Objetos (OMT)

Herramientas del Análisis y Diseño Orientado a Objetos

Figura: 6.2: Asociación con objetos determinados y restricciones

Estándares recomendados de diagramación

Figura: 6.3: a) Clase, objeto o dato b) Proceso u operación

Figura: 6.4: Representan la realidad (Objetos físicos)

Figura: 6.9: Forma

Figura: 6.10: Jerarquía de Generalización

Tipos de objetos derivados

Figura: 6.13: Objeto derivado

Diagramas de relación entre objetos

Análisis de comportamiento de objetos (ACO)

Ciclo vital de un objeto

Interacciones entre tipos de objetos

Figura: 6.18: Gráfica de Operación

Figura: 6.20: Reglas de Activación

Figura: 6.21: Condiciones de Control

Subtipos y supertipos de eventos

Figura: 6.23: Subtipo/Supertipo de eventos

Aislamiento de la causa y el efecto

Diagramas de flujo de objetos

Diseño de la estructura y comportamiento de un objeto

Selección del método

Figura: 6.28: Especificación de atributos en una clase

Figura: 6.29: Descripción de Operaciones en una Clase

Figura: 6.30: Asociaciones

Figura: 6.31: Asociación Ternaria

Fundamentos del AEO y del ACO

Tabla 7.1: Tabla de concepto

Tabla 7.2: Tabla de concepto

Conceptos sin Objetos

Objetos sin conceptos

Intensidad y extensión del objeto

Administración de la complejidad de un objeto

Figura: 7.1: Ejemplo de abstracción

Figura: 7.2: Ejemplo de Generalización

Figura: 7.4: Composición

Concepto y la Composición Inmutable

Figura: 7.6: Composición Inmutable

Relaciones n-adas o de n-lugares

Tipos de Objetos y Asociaciones

Objetos y Tipos de Objetos

Subtipos de una relación

Especialización por subconjuntos de una relación

Especialización mediante restricciones de Cardinalidad

Análisis del Comportamiento de Objetos

Figura: 7.16: Tipos de Eventos

Figura: 7.17: Tipo de Eventos

Figura: 7.18: Tipo de Eventos

Fuentes externas de eventos

Figura: 7.20: Fuentes Externas de tipos de eventos

Figura: 7.21: Condición de Control

Subtipos y Supertipos de Eventos

Figura: 7.23: Una tarea que produce dos eventos

Análisis del comportamiento de objetos mediante esquemas de eventos

Paso 1. Aclaración del tipo de evento

Figura: 7.25: Identificación del Incicio y Final de tipos de Eventos

Tabla 7.6: Tabla de identificación de preestados y postestados

Figura: 7.26: Ilustra la generalización y nivel de un tipo de evento

Tabla 7.7: Tabla de integración de tipo de Evento

Para producir el cambio de estado especificado en el paso 2, se necesita una operación.