Objetos orientados a los negocios curso

LA METODOLOGÍA DE OBJETOS
ORIENTADA A LOS NEGOCIOS
ALEJANDRO DOMÍNGUEZ
18/01/199 1

Objetivos generales
• Proporcionar:
– los conceptos, terminología y características de los
objetos
– mostrar la relación de los objetos con el mundo de los
negocios
• Aprender a:
– identificar y entender aquellos objetos de negocios
que son relevantes para los intereses de las empresas
en cuanto a tecnologías informáticas y aspectos
transaccionales
– discernir cuándo es necesario contratar un consultor
sobre tecnología de objetos
18/01/199 2

Objetivos específicos (1)
• Proporcionar:
– Una perspectiva histórica de la orientación a objetos
– Una perspectiva general sobre la orientación a objetos
– Un marco conceptual sólido para el pensamiento en
objetos
– Algunas aplicaciones de la orientación a objetos a los
negocios
– Una perspectiva general de los diferentes tipos de modelos
– Los diferentes modelos existentes para la OO
– El modelo de empresas de Zachman
– Las diferentes categorías en las que la OMG divide a los
objetos
18/01/199 3

Objetivos específicos (2)
– un mecanismo para expresar los modelos de negocios
y así proporcionar una ayuda en los diseños e
implementaciones de software
– Criterios para decidir cuando se tiene o no se tiene
objetos de negocios
– una taxonomía para organizar nuestro
enetendimiento y discusión de los objetos de negocios
• Esta presentación no discutirá ...
– aspectos de tecnología
– programación OO (POO)
– metodologías de análisis y diseño OO (ADOO)
– productos comerciales
18/01/199 4

Temario (1)
• LA ORIENTACIÓN A OBJETOS
– Historia de la orientación a objetos
– ¿Por qué objetos?
– ¿Qué es un objeto?
– Conceptos clave y terminología
– Ejemplo práctico: modelado de una empresa
• EL PENSAMIENTO DE OBJETOS
– Modelos
– Modelos OO
– El modelado de las empresas: la arquitectura de las empresas
de Zachman
– Categorización de los objetos
– El pensamiento de objetos efectivo
18/01/199 5

Temario (2)
• OBJETOS DE NEGOCIOS
– El caso de negocios
– Problemas de los SI y la tecnología de objetos
– Definición de los BO’s
– Taxonomía de los BO’s
– Aplicaciones de los BO’s
– La arquitectura de Zachman y los BO’s
18/01/199 6

Temario (3)
• APLICACIONES DE LOS BO’s DE SISTEMAS
– El modelo de negocios: diseños ejecutables
– Cliente/servidor y los BO’s
– Aplicaciones heredadas y los BO’s
– Internet y los BO’s
– Resolviendo los problemas con los BO’s
– ¡Las buenas noticias!: los BO’s son reales
18/01/199 7

Temario (4)
• OBJETOS DE SERVICIOS DE APLICACIONES
• SELECCIÓN Y UTILIZACIÓN DE CONSULTORES
PARA LA TECNOLOGÍA OO
• APENDICES
– Caso de estudio: el “negocio” de acreditación
• Políticas
• Procedimientos
– La orientación a eventos
18/01/199 8

Bibliografía
• Graham, I. Métodos orientados a objetos. Addison-Wesley / Diaz de
Santos, 1996
• Ruble, D.A. Análisis y diseño práctico de sistemas cliente/servidor con GUI.
Prentice Hall Hispanoamericana S.A. México, 1998
• Object Management Group, Business Object Domain Task Force. Common
Business Objects.OMG Document bom/97-12-04. Version 1.5.
• Shelton, R.E. (http://www.openeng.com/WhitePapers.htm)
– Business Objects and E-Commerce, Object World Insider, 7/97
– Business Objects and OOBE, Nikkei Computer, 11/95
– Business Object Modeling with Business Patterns, Data Mgt. Review, 5/96
– Business Objects and Business Engineering, DB Expo, San Francisco, 1997
– Enterprise Re-Use, Distributed Computing Monitor, 9/95
– Zachman Framework Adapted to Business Objects
• http://www.cetus-links.org/oo_business_objects.html
18/01/199 9

LA ORIENTACIÓN A OBJETOS
HISTORIA DE LA ORIENTACIÓN A
OBJETOS
18/01/199 10

15 años de fama
• La experiencia nos dice que las tecnologías de
ingeniería de software (IS) mas populares tienen
el siguiente comportamiento:
– Pueden tomar algún tiempo en llegar a ser populares
– Tienen un periodo de florecimiento de 15 años
• Un ejemplo de lo anterior es la metodología
estructurada
– Empezó a ser popular alrededor de 1973-1975
– Alcanzó su pico de popularidad entre 1985 y 1989
18/01/199 11

La “vida media” para las tecnologías
de IS
• La vida media para las tecnologías indica el
punto medio en su ciclo de vida
• La vida media en la orientación a objetos
significa que:
– se ha utilizado esta tecnología por algún tiempo
en proyectos reales
– Será remplazada por otras tecnologías dentro de
un periodo de 7 a 10 años
18/01/199 12

Aspectos históricos (1)
• 1963: I. Sutherland diseña Sketchpad en el
cual se presentan gráficas e interfaces gráficas
de usuario OO; así como clases (masters) e
instancias
• 1966: Se introduce al mercado Simula, el
primer lenguaje de programación OO
• Finales de 1960’s: Alan Kay trabaja en la
máquina denominada FLEX, la precursora de
Dynabook, la Xerox Star, y la Apple Macintosh
18/01/199 13

• 1970: el término “orientado a objetos” se
introduce en la literatura. Muchas personas se
lo acreditan a Alan Kay
• 1972: Se desarrolla la primera versión de
Smalltalk
• 1980: Grady Booch introduce el “diseño
orientado objetos”
• 1980: Se introducen las primeras versiones de
“hardware OO”
18/01/199 14

• 1985: aparecen las bases de datos OO
• 1985: aparecen la bibliotecas de clases OO
• 1986: Se introducen las primeras versiones de
“análisis OO” y de “análisis de requerimientos
OO”
• 1988: “análisis del dominio OO” aparece en la
literatura
18/01/199 15

• 1980’s: Se desarrollan un gran cantidad de
aplicaciones OO
– Estas aplicaciones son principalmente
“aplicaciones de tiempo real”
– Literalmente, se producen millones de líneas de
código OO
• Finales de 1980’s: Aparece un gran número de
lenguajes de programación OO; incluyendo:
C++, Eiffel, CLOS, etc.
18/01/199 16

18/01/199 17
1960
1970
1980
1990
ALGOL 60 Lisp
Pascal
Object Pascal
Simula 67
Ada
C
Ada 9x
Eiffel
Objective C C con Clases
C++ 1.xx
C++ 2.xx
C++ 3.xx
C++ 4.xx
Smalltalk-76
Smalltalk-80
Smalltalk-72
Smalltalk-74
Common Lisp
CLOS
Flavors
LOOPS
New FlavorsCommon LOOPS

Mediados de los 1990’s (1)
• La MOO empieza a mostrar signos de
“vida media”:
– Literalmente cientos de millones de
líneas de código fuente OO se han escrito
• Algunos productos OO contienen alrededor
de 2 000 000 de líneas de código
– La tecnología de BDOO tiene un éxito sin
precedente
• La OMG hace un esfuerzo por estandarizar la
tecnología de BDOO
• El mercado de los sistemas de bases de datos
OO se duplica cada año
18/01/199 18

– Los desarrolladores de software
pueden elegir entre un gran número de
herramientas CASE OO
• Object International’s Object Tool
• Rational’s Rose
• Protosoft’s Paradigm Plus
– Existen muchos enfoques de desarrollo
de software OO: Booch, Rumbaugh,
Coad, Wirfs-Brock, Berard, Fusion,
Shlaer-Mellor, ...
18/01/199 19

– El término “orientado a
objetos” aparece de forma
regular en las publicaciones de
negocios: The Wall Street
Journal, Business Week, ...
– La comunidad de
administración de los SI
empieza a utilizar la tecnología
OO
18/01/199 20

En la actualidad
• Existe un crecimiento significante (y
explosivo) de tecnologías basadas en
la orientación a objetos; e.g.
“programación basada en
componentes”, “programación
basada en agentes”
• Existe una tendencia a estandarizar
las tecnologías orientadas a objetos;
e.g. UML, Business Objects
18/01/199 21

Lo que se ha aprendido (1)
• La tecnología OO es una oportunidad, no una
garantía; i.e., los proyectos orientados a
objetos pueden fallar
• La evidencia empírica muestra que, cuando
se compara con las mismas aplicaciones
desarrolladas utilizando enfoques
tradicionales, las soluciones OO
– son más pequeñas
– son menos complejas
– son más apropiadas para aplicaciones de tiempo
real
– toman menos tiempo en desarrollarse
18/01/199 22

• La tecnología OO hace mas énfasis en la reusabilidad
del software que los métodos tradicionales
– sin embargo muy pocas personas dentro de la comunidad
OO entiende lo que verdaderamente significa reusabilidad
• La tecnología OO tiene impacto en los dominios de:
– las practicas administrativas
– las metodologías del ciclo de vida
– la selección de herramientas
– el almacenamiento persistente
– los lenguajes de programación
18/01/199 23

• La tecnología OO es vasta;
e.g., mas amplia que lo
indicado en los lenguajes
de programación OO
18/01/199 24

¿PORQUÉ OBJETOS?
18/01/199 25

Ventajas estratégicas (1)
• Valor del dinero
– Ensamblaje de sistemas a partir de
componentes comerciales
• Amortización de los costos de las
componentes en la construcción de
varios sistemas
– Estandarización de la
infraestructura y las componentes
de negocios
• Gasto de dinero y tiempo en valores
agregados
18/01/199 26

Ventajas estratégicas (2)
• A tiempo para salida al mercado
– Minimiza la re-invención de lo que es común en
cada proyecto
– Construcción de nuevos sistemas a partir de los
datos y procesos ya existentes
• Retorno de las inversiones
– Integra (“envuelve”) sistemas heredados en nuevos
sistemas
– Estandariza en un ambiente “abierto” y comercial
18/01/199 27

Ventajas tácticas (1)
• Los objetos pueden ...
– representar cosas
reales
– ser paralelos a nuestras
estructuras de
pensamiento
– estar organizados tal
como la gente ve al
mundo y a sus partes
componentes
18/01/199 28

• Los objetos son una
alternativa para una visión
del mundo alrededor de
las computadoras
• Los objetos permiten a los
modeladores,
desarrolladores, y
usuarios comunicarse y
pensar con la terminología
del mundo real
18/01/199 29

• Los sistemas son un
reflejo de los negocios
– Integración natural de las
aplicaciones existentes
• Compatibilidad interna y
externa, reutilización
– Datos y procedimientos
del negocio
– Reglas de negocios e
integridad de las
restricciones
18/01/199 30

• Manejo de
diferencias y
cambios
– Colocan las reglas
divisionales/locales
de negocios en las
especializaciones
– Permanencia de las
definiciones, reglas y
datos corporativos
en lo general
18/01/199 31

Ventajas de negocios (1)
• Integración de los procesos de negocios
– Distribuye “flujos de trabajo” = workflow (objetos
de procesos) y recursos (objetos de entidades) a
diferentes niveles
– Integra los negocios con los clientes y
distribuidores a través de compartir los objetos de
negocios
18/01/199 32

Ventajas de negocios (2)
• Ingeniería de los procesos de negocios
– Plug-ins escalables que integran los procesos de
negocios entre empresas colaboradoras a través
de interfaces compartidas
– Integración inmediata de componentes de
negocios
18/01/199 33

¿QUÉ ES UN OBJETO?
18/01/199 34

Un objeto es ... (1)
• Existen dos puntos de vista:
– Punto de vista terrenal
• un objeto tiene el mismo significado
que un nombre o una frase nominal
– Es una persona o una cosa
– Punto de vista de la programación
• un objeto es un tipo de datos abstracto
al que se le han agregado algunos
mecanismos innovadores para la
compartición de código y reutilización
18/01/199 35

• Ejemplos típicos de objetos pueden ser
– Objetos físicos: Aviones, automóviles, casas
– Elementos de interfaces gráficas de
usuario:Ventanas, menús, objetos gráficos
(cuadrados, triángulos), teclado, cuadros de
dialogo, ratón
– Animales: animales vertebrados, animales
invertebrados
– Tipos de datos definidos por el usuario: datos
complejos, puntos de un sistema de
coordenadas
– Alimentos: Carnes, frutas, pescados, verduras,
pasteles
18/01/199 36

• Una representación de algo como si
fuera una componente bien definida
– Se enfoca a un único concepto
– Captura hechos acerca del concepto
– Encierra hechos con procedimientos,
reglas
– Presenta una interfaz bien definida
• Es una entidad que contiene
– los atributos que describen el estado del
objeto del mundo real
– las operaciones (acciones) que se asocian
con el objeto del mundo real
18/01/199 37
Nombre
Atributos:
Operaciones:

• Un paquete de datos,
procedimientos y
restricciones que
representan un concepto en
– el mundo de los negocios
– ambiente de computadoras
• Un módulo definido
alrededor de un dominio
conceptual y no sólo
estructuras de código
18/01/199 38
Procedimientos
Restricciones
Datos
Nombre
del objeto
Atributos:
Operaciones:

¿Dónde existen los objetos? (1)
• Los objetos son una
representación en ...
– el mundo real (i.e., negocios)
– computadoras (i.e., tecnología)
• Entonces los objetos existen en
...
– el modelado , análisis, y
reingeniería de negocios
– Análisis y diseño de sistemas
– Software
18/01/199 39
Procedimientos
Restricciones
Datos
Nombre:
silla
Atributos:
costo
dimensiones
peso
Operaciones:
comprar
vender
mover

¿Dónde existen los objetos? (2)
• Los objetos son
construcciones tanto para
el modelado de negocios
como para el modelado de
software
– Los objetos no son sólo una
forma de programar
18/01/199 40
Procedimientos
Restricciones
Datos
Nombre:
silla
Atributos:
costo
dimensiones
peso
Operaciones:
comprar
vender
mover

¿Por qué los objetos son diferentes?
• Sólo un conjunto de procedimientos y reglas actúan
sobre los datos
– Control en la integridad de los datos
– Datos, procesos y reglas compartidos
• Todos los procedimientos, datos y reglas acerca del
sujeto están atados a un paquete bien definido e
integrado
– Componentes de software
– Diseñar acorde a las especificaciones de las
componentes
• La frontera del modulo es el sujeto, no el programa
– Simplifica la reutilización
18/01/199 41

¿Por qué los objetos son familiares?
• Los objetos integran conceptos familiares como ...
– Procesos y control de procesos
– Procedimientos, actividades, tareas, acciones
– Datos
– Reglas, políticas, restricciones
– Relaciones
– Eventos, desencadenamientos, resultados
• Los objetos son módulos que representan
conceptos simples y bien definidos del dominio
18/01/199 42

Los objetos redefinen la modularidad
• La frontera del objeto determina su
dominio
– Separa el interior (el cómo) del
exterior (el qué) creando
modularidad
– Proporciona una interfaz bien
definida para otros objetos
– Oculta la complejidad de la
implementación
– Previene los conflictos en la
manipulación de atributos causados
por procedimientos y reglas
redundantes
18/01/199 43
Procedimientos
Restricciones
Datos
Nombre:
silla
Atributos:
costo
dimensiones
peso
Operaciones:
comprar
vender
mover

Los objetos son empaquetamiento
• Los objetos son paquetes auto-contenidos
• Los objetos se refieren al empaquetamiento
– a nivel conceptual (de pensamiento)
– a nivel de implementación (software)
• Los objetos re-empaquetan los objetos existentes
con nuevas características que hacen los conceptos
existentes fáciles de utilizar
– ¡Ojo! ... el empaquetamiento hace toda la diferencia
– El nuevo empaquetamiento cambia el paradigma
18/01/199 44

Los objetos son un paradigma
• ¿Qué es un paradigma?
– Un marco de referencia o un punto de vista bien
definido
– Una forma de visualizar el mundo en el cual están
bien definidas sus propias perspectivas y
consecuencias
• Los objetos son un paradigma porque ...
– Cambian nuestro punto de vista sobre la realidad
para proporcionarnos una perspectiva totalmente
diferente
• ... destacando diferentes enfoques (consecuencias)
• ... visualizando la realidad de una forma nueva
18/01/199 45

CONCEPTOS CLAVE Y TERMINOLOGÍA
18/01/199 46

El pensamiento de objetos se basa
en tipos (1)
• Un tipo o clase describe
un conjunto de objetos
con las mismas
propiedades
– El término “tipo” se utiliza
en el modelado de
negocios
– El término “clase” se utiliza
en el diseño/programación
de software
18/01/199 47
Procedimientos
Restricciones
Datos
Nombre:
silla
Atributos:
costo
dimensiones
peso
Operaciones:
comprar
vender
mover

en tipos (2)
• Un tipo se puede
considerar como una
plantilla para crear
objetos con las
mismas propiedades
• Un tipo es una
colección de objetos
similares
18/01/199 48
Procedimientos
Restricciones
Datos
Nombre:
silla
Atributos:
costo
dimensiones
peso
Operaciones:
comprar
vender
mover

El pensamiento de objetos se basa en
tipos (3)
• Algunos objetos
de la clase
cantantes de
rock
– Madonna
– Michael
Jackson
– Prince
– Macano
– Dire Straits
18/01/199 49

en tipos (4)
• Un tipo define los
atributos,
procedimientos y
restricciones de
todos los objetos de
ese tipo
18/01/199 50
Procedimientos
Restricciones
Datos
Nombre:
silla
Atributos:
costo
dimensiones
peso
Operaciones:
comprar
vender
mover

Los atributos de los tipos
• Un atributo representa un
responsabilidad para conocer
algo
• Los atributos pueden ser
– Públicos: Se pueden utilizar y
visualizar desde fuera de la
clase (“+” delante del nombre)
– Privados: no se puede acceder
al mismo desde otras clases (“-”
delante del nombre)
– Indefinidos
18/01/199 51
Procedimientos
Restricciones
Datos
Nombre:
silla
Atributos:
+costo
+dimensiones
-núm. de serie
Operaciones:
comprar
vender
mover

Las operaciones de los tipos
• Un método u operación
– representa una responsabilidad para hacer
algo
– se utiliza para manipular los atributos
– también tienen su visibilidad
• Las operaciones se dividen en 3 grupos:
– Operaciones que manipulan los datos de una
forma específica (agregar, borrar, cambiar)
– Operaciones que realizan un cálculo o proceso
– Operaciones que comprueban (monitorizan) u
objeto frente a la ocurrencia del algún suceso
de control
18/01/199 52
Nombre:
silla
Atributos:
+costo
+dimensiones
-num. de serie
Operaciones:
+comprar
+medir
-marcar serie

Las instancias almacenan datos (1)
• Instancia = un
miembro del tipo o
clase
• Una clase puede tener
varias instancias
– Las instancias tienen
diferentes valores
para sus atributos
– Los datos se
almacenan en las
instancias
18/01/199 53
Silla
Atributos:
+costo
+dimensiones
-num. de serie
Operaciones:
+comprar
+medir
-marcar serie
Mi silla:
Silla
Atributos:
+costo: 50.00
+dim:352
-num. serie:12
Operaciones:
+comprar
+medir
-marcar serie
Clase
Instancia

Las instancias almacenan datos (2)
• Todas las instancias
de una clase
– son del mismo tipo
– tienen el mismo
comportamiento
– tienen los mismos
atributos
18/01/199 54
Silla
Atributos:
+costo
+dimensiones
-num. de serie
Operaciones:
+comprar
+medir
-marcar serie
Mi silla:
Silla
Atributos:
+costo: 50.00
+dim:352
-num. serie:12
Operaciones:
+comprar
+medir
-marcar serie
Clase
Instancia

No todos los tipos tienen instancias
• Los tipos de objetos existen por dos razones:
– Para definir propiedades de otros tipos (i.e.,
especializaciones)
– Para crear instancias (i.e., son plantillas)
• Así, existen 2 tipos de tipos de objetos
– Tipos abstractos: aquellos que se dan por
definición
– Tipos concretos: aquellos que tiene instancias
18/01/199 55

Tipos abstractos (1)
• Los tipos abstractos son
importantes en ...
– Modelado de negocios y
reingeniería de procesos en
los negocios
– Diseño de servidores
– Mapeo de tablas en base de
datos
– Aplicaciones en análisis y
diseño
18/01/199 56

Tipos abstractos (2)
• Las tipos abstractos no tienen instancias
– Por ejemplo: integer, float, string
– Los tipos abstractos se crean para ...
• Generalizar características
• Facilitar cambios
• Crear oportunidades de re-utilización
• Eliminar redundancia
– Comúnmente los tipos abstractos son supertipos
en la jerarquía
• Definen propiedades en común para todas las subclases
18/01/199 57

Tipos concretos
• Tipos concretos pueden
tener instancias
– Por ejemplo: mobiliario
• Los tipos concretos se
crean para ...
– implementar un tipo de
objetos
– reflejar diferencias
– crear instancias
• Comúnmente los tipos
concretos son subtipos
de uno o mas tipos
abstractos. Así
– cumplen con las
propiedades del
supertipo
– agregar sus propias
propiedades
– crear instancias de su
tipo
18/01/199 58

Tipos + instancias = objetos
• Los tipos capturan la forma y carácter de lo que
representan
– Los tipos abstractos capturan las propiedades
comunes
– Las especializaciones capturan las diferencias
• Cada instancia captura los valores reales de las
propiedades de lo que representa
• Un objeto es un término que puede comprender
tanto tipos como instancias. Comúnmente se
utiliza cuando:
– no es necesario distinguir entre las clases y la instancia
– se refiere a un concepto de la realidad
18/01/199 59

Encapsulamiento
• Encapsulamiento
– Se refiere a la práctica de incluir
dentro de un objeto todo lo que se
necesita
– Esta inclusión es de tal manera que
ningún otro objeto necesite conocer
nunca la estructura interna de otro
– Proporciona el empaquetamiento que
hace que el objeto se comporte como
tal
– Se refiere a la visibilidad de las
instancias y las operaciones
18/01/199 60
Silla
Atributos:
+costo
+dimensiones
-num. de serie
Operaciones:
+comprar
+medir
-marcar serie

Relaciones
• Los diagramas de clases constan de clases y
las relaciones entre ellas
• Las relaciones son 4:
– Asociaciones: una conexión entre clases
– Generalizaciones: es una relación entre un
elemento general y otro más específico
– Dependencias: es una relación entre un
elemento dependiente y otro independiente
– Refinamientos: es una relación entre dos
descripciones de una misma cosa en diferentes
niveles de abstracción
18/01/199 61

Especialización y generalización (1)
• Especialización
– Modificable para nuevos usos y sin ningún
cambio al objeto original
– Basados en tipos de jerarquías
• La generalización contiene todas las
propiedades comunes
– Padre es más abstracto
18/01/199 62

Especialización y generalización (2)
• La especialización contiene la
diferencia en las propiedades
– Hijo es más concreto
• Cada especialización sirve para un
propósito específico
• Se pueden organizar en una jerarquía
o superjerarquía
18/01/199 63

¿Qué es jerarquía? (1)
• Una estructura de
especialización donde el hijo
puede tener al menos uno y
sólo un padre
– La estructura resultante es un
árbol
• La jerarquía facilita la
separación de lo general de lo
específico
– Las hojas del árbol representan
conceptos más especializados
que los nodos superiores
18/01/199 64
Cuenta
nombre, dirección,
estado, balance,
fecha de apertura,
fecha de cierre ...
sacar balance,
depositar, pedir
préstamo
Cuenta de
cheques
balance,
balance
mínimo, etc.
sacar balance,
depositar, pedir
préstamo
Cuenta de
ahorros
balance, balance
mínimo, tasa de
interés, etc.
sacar balance,
depositar, pedir
préstamo

¿Qué es jerarquía? (2)
• Se pueden hacer objetos
de otros objetos
• Esto se conoce como
agregación
• El comportamiento del
objeto más grande se
define por el
comportamiento de sus
partes componentes,
separadamente y en
conjunción con el otro
18/01/199 65
derecho o
izquierdo
Pie
patea
Mano
derecha o
izquierda
agarra, toma,
pasa por
atrás, lanza
Malabarista
El diamante indica que un objeto está
hecho de otros objetos. El número indica
´la cantidad de componentes
2 2

Los objetos están activos
• Los objetos mandan mensajes para obtener el
trabajo realizado por otros objetos
• Cualquier mensaje solicita un servicio
• El receptor exhibe su comportamiento en respuesta
al mensaje
• El formato del mensaje es a través de un protocolo
• El intercambio total es una interacción
18/01/199 66
Solicitante
(cliente)
Receptor
(servidor)
Mensaje

Herencia (1)
• Es una forma de generalización y
especialización
– Es una relación
– Es apropiada para el diseño y discusiones
de implementación
• Es un mecanismo para adquirir
propiedades
– aísla las propiedades comunes en el
padre, llamado superclase
– aísla las diferencias en el hijo, llamado
subclase
18/01/199 67

Herencia (2)
• Refleja la generalización
del mundo real y los tipos
de jerarquías
• Agrega propiedades a
través de tipos de
especialización
18/01/199 68

Herencia simple vs. Herencia múltiple
• Herencia simple: las propiedades adquiridas
provienen de un sólo padre
• Herencia múltiple: propiedades adquiridas de más
de un padre y se puede diferenciar o seleccionar
por origen
18/01/199 69

Polimorfismo
• Polimórfico significa “muchas formas”
– Describe cómo un comportamiento cambia cuando
se escala la herencia de la clase
– Describe cómo un simple comportamiento puede
evocar diferentes consecuencias en una
especialización más que en la generalización
• Ejemplo: la operación “add” se puede utilizar de la
siguiente forma add_line_item, add_to_balance,
all_new_employee
• Polimorfismo es un resultado de “generalización y
especialización” cuando se implementa por
herencia
18/01/199 70

Delegación (1)
• Delegación es:
– una forma de herencia sin clases que permite a los
objetos delegar permiso a otros objetos para
llevar a cabo operaciones de su parte
– es una forma de generalización y especialización
– (actúa como o toma el papel de) una relación
– es especialización por liberación de trabajo
• Es un mecanismo para adquirir propiedades
– aísla las propiedades comunes en el padre
– aísla diferencias en el hijo
– no aplica con términos de superclase y subclase
18/01/199 71

Delegación (2)
• Esta relación permite que los objetos
transformen su comportamiento sin
verse obligados por su relación de
clase
– no es necesario que los hijos hereden
la realización de sus padres
• Refleja un comportamiento del
mundo real
• Agrega propiedades a través del
comportamiento
18/01/199 72

Resumen: propiedades de los objetos
• Comportamiento,
servicios, métodos
– Los procedimientos o
funcionalidad que encapsula
un tipo
• Atributos
– Variables o estructura de
datos interna para el tipo de
objetos
• Protocolo
– Como el objeto presenta un
servicio al exterior
• Interacción, mensaje
– Un objeto solicita un
servicio a ser ejecutado por
otro objeto
• Relación
– Referencias estáticas de un
objeto con otro
– Asociaciones estructurales
entre padre e hijo
18/01/199 73

¿Por qué los “nuevos” términos?
• El pensamiento de objetos se enfoca
– al entendimiento de las cosas
– su contexto y sus fronteras
– su asociación con otras cosas en su contexto
• Es necesario un lenguaje para expresar esta
forma de pensar
– Los modelos convencionales del lenguaje
pueden expresar algunas partes
– El diseño/programación convencionales pueden
expresar algunas partes
– Los objetos juntan las partes
– Los objetos conectan el pensamiento de
negocios con la programación
18/01/199 74

EJEMPLO PRÁCTICO:
MODELADO DE UNA EMPRESA
18/01/199 75

El problema
• El problema se ubica en el departamento de
servicios administrativos de una empresa
• Uno de los problemas del departamento es la
opción de pasar a una publicación
completamente electrónica
– Ya estaban empleando sofisticadas técnicas de
impresión, pero la composición se efectuaba en
estaciones de trabajo anticuadas, y el pegado se
realizaba manualmente
18/01/199 76

La estructura del departamento
• La siguiente figura muestra la estructura de alto nivel del
departamento, así como sus interacciones con otros
departamentos, en forma de 7 capas
• Se muestra cada capa como un objeto, y los enlaces
representan el posible paso de mensajes
18/01/199 77
Proveedores
externos
Departamentos
usuarios
Departamentos
de ingeniería
Escritura
Gráficos
e impresión
Agencias
externas
Contabilidad

Vistas externa e interna (1)
• Las vistas externas e internas se pueden
definir para cada objeto
• La vista externa define el paso de mensajes
admisibles entre un objeto y los otros
• La vista interna indica que existen dos
subdivisiones, cada una de las cuales se
presentan como un objeto
18/01/199 78

18/01/199 79
DepartamentosDepartamentos
usuarios
AgenciasAgencias
externas
GráficosGráficos
e impresión
ContabilidadEscritura
Vista externa de gráficos e impresión

18/01/199 80
Gráficos
Fotocomposición
Artista gráfico
Creador de fotolitos
...
Hacer diapositivas
Hacer placas
Preparar placas
Pedir materiales
Despachar resultados
Hacer informes de costos
Hacer informes de progreso
...
Impresión
Almacenista
Operadores de máquina
Maquinaria
Almacen de papel
Trabajos en curso
...
Hacer impresión
Hacer reimpresión
Hacer informes de progreso
Emitir facturas
Pedir materiales
Hacer informes de costos
...
Vista interna de gráficos e impresión

Vista del objeto “gráficos” antes de la
tecnología
18/01/199 81
Director
Clasificar solicitudes
Asignar trabajos
Informar progresos
Fotocompositor
Informar de progresos
Componer textos
Hacer cambios
Artista gráfico
Hacer diapositivas
Hacer placas
Hacer ilustracionesEncargado de pegado
Pegar
Solicitar cambios
Hacer informe de progresos
Creador de placas
Hacer placas
Despachar

Vista del objeto “gráficos” después de
la tecnología
18/01/199 82
Director
Clasificar solicitudes
Asignar trabajos
Informar progresos
Responsable de autoedición
Informar de progresos
Producción de documentos
Artista gráfico
Hacer diapositivas
Hacer placas
Hacer ilustraciones
Creador de placas
Hacer placas
Despachar

Conclusiones
• La notación resulto ser muy expresiva y útil
para los aspectos de negocios
• La orientación a objetos del problema resultó
útil para clarificar los problemas y sus
soluciones, y, también, para comunicar los
resultados a la administración
• El modelo se realizó por completo sobre
papel, sin utilizar tecnologías sofisticadas
18/01/199 83

EL PENSAMIENTO DE OBJETOS
MODELOS
18/01/199 84

Abstracción y modelos
• Abstracción:
– es el proceso de centrarse en los detalles
esenciales (importantes) de una cosa o
situación
– ignora los detalles que no son esenciales
(no importantes) de esa cosa o situación
• Modelos:
– Cualquier representación de esos detalles
esenciales (importantes)
– son representaciones de lo que se
considera esencial (importante) acerca de
una cosa o situación
18/01/199 85

El contenido de los modelos
• Los modelos se pueden utilizar para capturar
representar información referente a:
– una cosa o situación individuales, o un sistema de cosas o
situaciones interrelacionadas o interactuando entre ellas
– las características estáticas (no cambiantes en el tiempo)
o dinámicas (cambiantes en el tiempo) de cosas o
situaciones, o un sistemas de cosas o situaciones
interrelacionadas o interactuando entre ellas
– puntos de vista simples o complejos de una cosa o
situación
– implementaciones diferentes de la misma cosa o
situación
18/01/199 86

La localización en los modelos
• Localización:
– es el proceso de ubicar cosas en la proximidad o
alrededor de otras otras cosas
• Los modelos
– funcionales localizan su información alrededor de las
funciones
– basados en datos localizan su información alrededor de
los datos y sus relaciones entre ellos
– orientados a objetos localizan su información alrededor
de los objetos y situaciones orientadas a objetos (e.g.,
objetos interactuando con otros, herencia, y
agregación)
18/01/199 87

Las 4 categorías de los modelos
• Modelos textuales
– son descripciones textuales de cosas o situaciones y
sistemas de cosas o situaciones
• Modelos gráficos
– representan gráficamente las características de cosas
o situaciones y sistemas de cosas o situaciones
• Modelos ejecutables
– Son modelos que son ejecutables en una
computadora
• Otros modelos
– Esta categoría genérica incluye todos los modelos que
no están dentro de las categorías anteriores
18/01/199 88

Confección de los modelos
• Las categorías anteriores pueden ser confeccionadas de
diferentes formas:
– mezcla de dos o mas modelos textual, gráfico, y ejecutable
– utilización de medios diferentes a los de papel para los
modelos textuales y gráficos (modelos de plástico o madera)
– medios mixtos: por ejemplo la utilización de papel,
resortes, tachuelas, etc.
– medios visuales y auditivos tales como vídeo grabadoras,
audio cassettes, películas, fotografía, etc.
– modelos de realidad virtual
18/01/199 89

Modelos múltiples
• A menudo es útil construir modelos múltiples para una
misma cosa o situación
– Estos modelos para una cosa o situación en el mismo nivel
de abstracción (nivel de detalle) permite un mejor
entendimiento
• Específicamente, un modelo puede mostrar algún detalle que otro
modelo no muestra o que es incapaz de mostrar
– Estos modelos para una cosa o situación en diferentes
niveles de abstracción (diferentes niveles de detalle)
permiten controlar cuánta información se desea mostrar
• Tales modelos permiten revelar progresivamente mas detalle acerca
de una cosa o situación como el entendimiento de ellos se
incrementa
18/01/199 90

La creación de mas de un modelo
• Si mas de un modelo de la misma cosa o situación se
desarrolla para el mismo nivel de abstracción, se debe
mantener en mente
– todos los modelos deben tener el mismo nivel de detalle
– cada modelo debe revelar alguna información que no
revelan los demás modelos
– la terminología debe ser consistente a través de todos los
modelos; e.g., la misma cosa o situación debe tener el
mismo nombre en todos los modelos
– los modelos deben ser consistentes entre ellos
18/01/199 91

MODELOS OO
18/01/199 92

Los modelos orientados a objetos
• Son modelos en los cuales su contenido de
información se localiza alrededor de los
objetos
• Permiten enfocarse a los objetos individuales
y las interacciones y/o interrelaciones entre
ellos
18/01/199 93

Modelos textuales OO
• Russel J. Abbot y Grady Booch sugieren que
tanto los objetos como los sistemas de objetos
se pueden modelar escribiendo un párrafo
que describa una solución al problema
• Existen algunos enfoques matemáticos, tales
como Z, OBJ, y VDM, que se han creado o
modificado para el modelado matemático de
los objetos y los sistemas de objetos
18/01/199 94

Ejemplo de un modelo contextual OO
(1)
• Reglas para el movimiento y
comportamiento de un
elevador
– Los elevadores deben pararse
en todos los pisos
correspondientes a los botones
que han sido presionados
– El primer elevador en llegar a
un piso en el cual su botón
haya sido presionado y que
vaya en la misma dirección de
los botones presionados debe
parar y responder a las ordenes
de esos botones
– Si un elevador está a su
máxima capacidad está exento
de la regla anterior
18/01/199 95

Ejemplo de un modelo contextual OO
(2)
– Si un elevador excede de su
capacidad no debe de abandonar
el piso en el que se encuentra
– Ningún pasajero debe esperar por
siempre por un elevador para
responder a su petición
– Un elevador continua su dirección
hasta que todos los destinos en esa
dirección sean satisfechos. Puede
entonces invertir su dirección para
satisfacer los otros destinos
– Cuando un elevador vació no tiene
mas destinos debe permanecer en
el último piso
– Cualquier elevador vacío puede ser
despachado para satisfacer las
peticiones
18/01/199 96

Casos de uso
• Los casos de uso es una técnica de modelado
textual de uso común y extendido
• La esencia de esta técnica es describir las
interacciones entre un objeto o sistemas de
objetos y un usuario externo
• Esta técnica de modelado tiene dos propósitos
– un mejor entendimiento de la cosa o situación que se
está modelando
– ayudar a identificar los candidatos de objetos
• A esta técnica Booch le denomino “análisis del
comportamiento de objetos”, y después Jacobson
la denominó “casos de uso”
18/01/199 97

Definición de los “casos de uso” (1)
• Jacobson describe el “modelo de casos de
uso” a través de actores y casos de uso,
donde:
– los actores representan aquellas cosas que
interactúan con un objeto o con sistemas de
objetos
• pueden ser software, hardware o recursos
humanos
• así, los actores se pueden pensar como “roles” que
deben ser llenados por personas o cosas
18/01/199 98

Definición de los “casos de uso” (2)
– los casos de uso describen los “diálogos” que un actor
puede tener con el objeto o sistema de objetos
• por diálogo se entiende la sucesión (normalmente ordenada)
de eventos que ocurren cuando:
– el actor y el objeto o sistemas de objetos interactúan
– la información es proporcionada por/a tanto el objeto (o
sistema) y el actor
– existe una descripción de cualquier transformación real o posible
de tanto el objeto (o sistema) y el actor
18/01/199 99

Modelos gráficos OO
• Entre los modelos gráficos existentes los mas
usuales son:
– redes semánticas
– diagramas de transición de estados
– redes de Petri
– diagramas de mensajes de objetos
– diagramas de tiempo
• El modelo gráfico que se utiliza como un
estándar es UML (unified modeling language)
18/01/199 100

Modelos ejecutables OO
• Existen en el mercado varias herramientas que
permiten crear modelos ejecutables
orientados a objetos; e.g., Smalltalk
• Smalltalk es un lenguaje con las siguientes
características
– Conceptualmente uniforme
– Posee un excelente entorno de ejecución
– Es más fácil de comprender y de ajustar el diseño
global que en los lenguajes convencionales
– Es muy difícil no escribir en un estado OO, por lo
que es una excelente herramienta pedagógica
18/01/199 101

Otros modelos OO
• Class-Responsability-Collaboration Cards (CRC
Cards) es un modelo que no se ajusta a ninguna de
las categorías de modelado antes mencionadas
• CRC Cards utiliza fichas de cartón como
herramienta CASE para documentar diseños OO y
también para la enseñanza de los conceptos
básicos
18/01/199 102
Clase: nombre de la clase (abstracta o concreta)
lista de superclases
lista de subclases
responsabilidad colaboración

EL MODELADO DE LAS EMPRESAS: LA
ARQUITECTURA DE LAS EMPRESAS
DE ZACHMAN
18/01/199 103

Antecedentes
• A principios de los años 80’s
– existía poco interés en el modelado
de las empresas
– la utilización de modelos y
formalismos estaba limitada a
algunos aspectos de desarrollo de
aplicación dentro de la comunidad
de los SI
• Lo anterior provocó llevar a cabo
investigaciones que resultaron en
el “MARCO DE TRABAJO PARA LA
ARQUITECTURA DE LOS SI”
18/01/199 104

El arquitectura de las empresas (1)
• El marco de trabajo evolucionó a el “MARCO
DE TRABAJO PARA LA ARQUITECTURA DE LAS
EMPRESAS”
• Zachman define:
– Una arquitectura es un conjunto de artefactos de
diseño, representaciones descriptivas, que son
relevantes para la descripción de un objeto que
puede ser producido acorde a requerimientos
(calidad) y sujeto a mantenimiento en un periodo
de tiempo de su vida útil (cambio)
18/01/199 105

El arquitectura de las empresas (2)
• Es una estructura lógica para clasificar y organizar las
descripciones representativas de una empresa que
son significantes para la administración de la empresa
misma y los desarrollos de SI empresariales
• Se derivó de estructuras análogas encontradas en
viejas disciplinas de arquitectura/construcción e
ingeniería/manufactura que clasifican y organizan el
diseño de artefactos creados sobre procesos de
diseño y producción de productos físicos complejos
(edificios o aeroplanos)
18/01/199 106

La gráfica de la arquitectura(1)
• Describe el diseño de artefactos que constituyen la
intersección entre
– los roles en el proceso de diseño
• dueño
• diseñador
• constructor
– las abstracciones del producto
• de qué (material) está hecho
• cómo (proceso) trabaja
• dónde (la geometría) se encuentran ubicadas las
componentes
• Adicionalmente se incluyen entidades que incluyen
los aspectos del alcance y visión (diseñador), así
como el de implementador (subcontratado)
18/01/199 107

18/01/199 108
OBJECTIVES/
SCOPE
ENTERPRISE
MODEL
MODEL
(LOGICAL)
SYSTEM
TECHNOLOGY
CONSTRAINED
DETAILED
REPRESEN-
TATIONS
FUNCTIONING
ENTERPRISE
DATA FUNCTION NETWORK
e.g. Data Definition
Ent = Field
Reln = Address
e.g. DATA
e.g. Physical Data Model
Ent =Segment/Table/etc.
Reln =Pointer/Key/etc.
e.g. Logical Data Model
Ent = Data Entity
Reln = Data Relationship
e.g. Semantic Model
Ent = Business Entity
Reln = Business Relationship
List of Things Important
to the business
ENTITY = Class of Business
Thing
List of Processes the
Business Performs
Process = Class of Business
Process
e.g. Application Architecture
I/O = User Views
Proc = Application Function
e.g. System Design
I/O = Data Elements/Sets
Proc = Computer Function
e.g. Program
I/O = Control Block
Proc = Language Statement
e.g. FUNCTION
e.g. Business Process Model
Proc = Bus Process
I/O = Bus Resources
List of Locations in which
the Business Opeerates
Node = Major Business
Location
e.g. Business Logistics
System
Node = Business Location
Link = Business Linkage
e.g. Distributed System
Node = I/S Function
(Processor, Storage, etc)
Link = Line Characteristics
e.g. System Architecture
Node = Hardware/Systems
Software
Link = Line Specifications
e.g. Network Architecture
Node = Address
Link = Protocol
e.g. NETWORK
Architecture
Planner
Builder
Designer
Sub-
Contractor
Owner
What How Where
MODEL
(PHYSICAL)
(OUT-OF-
CONTEXT)
(CONTEXTUAL)
(CONCEPTUAL)

• Adicionalmente se deben incluir las
interrogantes primitivas: quién, cuándo,
y porqué
• Estas interrogantes se muestran como
columnas adicionales que, en el caso de
las empresas, describen
– quién hace el trabajo
– cuándo las cosas deben suceder
– porqué existen varias formas de hacerlo
18/01/199 109

18/01/199 110
Builder
SCOPE
MODEL
ENTERPRISE
MODEL
Designer
SYSTEM
DETAILED
REPRESEN-
TATIONS
(OUT-OF-
CONTEXT)
Sub-
Contractor
FUNCTIONING
ENTEPRISE
MOTIVATIONTIMEPEOPLE
e.g. Rule Specification
End = Sub-condition
Means = Step
e.g. STRATEGY
e.g. Rule Design
End = Condition
Means = Action
e.g. Business Rule Model
End = Structural Assertion
Means = Action Assertion
e.g. Business Plan
End = Business Objective
Means = Business Strategy
List of Business Goals/
Strategies
Ends/Means = Major Business
Goals/Critical Success Factors
List of Events Significant
Time = Major Business Event
e.g. Processing Structure
Cycle = Processing Cycle
Time = System Event
e.g. Control Structure
Cycle = Component Cycle
Time = Execute
e.g. Timing Definition
Cycle = Machine Cycle
Time = Interrupt
e.g. SCHEDULE
e.g. Master Schedule
Time = Business Event
Cycle = Business Cycle
List of Organizations
People = Major Organizations
People = Organization Unit
Work = Work Product
e.g. Human Interface
People = Role
Work = Deliverable
e.g. Presentation Architecture
People = User
Work = Screen Format
e.g. Security Architecture
People = Identity
Work = Job
e.g. ORGANIZATION
Architecture
Planner
Owner
to the BusinessImportant to the Business
E1
E1.1
E2
A1
E1.2
E1.3
E1
E1.1
E2
A1
E1.2
E1.3
E1
E1.1
E2
A1
E1.2
E1.3
e.g. Work Flow Model
(LOGICAL)
(CONCEPTUAL)
(PHYSICAL)
TECHNOLOGY
MODEL

Características de la arquitectura (1)
• Es un esquema de clasificación genérica
para el diseño de empresas o artefactos;
i.e., descripciones de cualquier objeto
complejo
• El esquema permite centrarse en aspectos
selectos de un objeto sin perder el sentido
de perspectiva contextual u holística
18/01/199 111

• Adicionalmente permite:
– simplificar el entendimiento y
comunicación
– centrarse en variables independientes para
propósitos analíticos
– tener cuidado en las relaciones
contextuales que son significantes para
preservar la integridad del objeto
18/01/199 112

• En resumen arquitectura es:
– sencilla
• fácil de entender (no técnico y puramente lógico)
• contiene tres perspectivas (dueño, diseñador, constructor) y
tres abstracciones (material, funcionamiento, geometría)
• cualquier persona técnica o no técnica puede entenderlo
– entendible
• mantiene en perspectiva a toda la empresa
• cualquier situación puede ser mapeada a él para entender
donde se ajusta dentro de la empresa como un todo
– un lenguaje
• ayuda a concebir conceptos complejos y permite
comunicarlos con pocas palabras no técnicas
18/01/199 113

– una herramienta de planeación
• ayuda a hacer mejores elecciones de tal forma que nunca
permite hacer elecciones en el vacío
• permite ubicar objetos en el contexto de la empresa y ver un
rango total de alternativas
– una herramienta para la resolución de problemas
• permite trabajar con abstracciones
• simplifica y aísla variables sin perder el sentido de la
complejidad de la empresa como un todo
– neutral
• es independiente de herramientas y metodologías y por lo
tanto cualquier herramienta o metodología puede mapearse
a él con el fin de conocer que hacen y que no hacen
18/01/199 114

Conclusiones
• La arquitectura de las empresas
– no es “la respuesta”
– es una herramienta ... una
herramienta para pensar
– si se emplea con sabiduría, debería
de ser de gran ayuda para la
administración técnica y no técnica
de la complejidad y dinámica de la
era de la información empresarial
18/01/199 115

The Zachman framework
18/01/199 116
e.g.DATA
ENTERPRISEARCHITECTURE-AFRAMEWORK
Builder
SCOPE
(CONTEXTUAL)
MODEL
(CONCEPTUAL)
ENTERPRISE
Designer
SYSTEM
MODEL
(LOGICAL)
TECHNOLOGY
MODEL
(PHYSICAL)
DETAILED
REPRESEN-
TATIONS
(OUT-OF-
CONTEXT)
Sub-
Contractor
FUNCTIONING
ENTERPRISE
DATA FUNCTION NETWORK
e.g.DataDefinition
Ent=Field
Reln=Address
e.g.PhysicalDataModel
Ent=Segment/Table/etc.
Reln=Pointer/Key/etc.
e.g.LogicalDataModel
Ent=DataEntity
Reln=DataRelationship
e.g.SemanticModel
Ent=BusinessEntity
Reln=BusinessRelationship
ListofThingsImportant
totheBusiness
ENTITY=Classof
BusinessThing
ListofProcessesthe
BusinessPerforms
Function=Classof
BusinessProcess
e.g."ApplicationArchitecture"
I/O=UserViews
Proc.=ApplicationFunction
e.g."SystemDesign"
I/O=Screen/DeviceFormats
Proc.=ComputerFunction
e.g."Program"
I/O=ControlBlock
Proc.=LanguageStmt
e.g.FUNCTION
e.g.BusinessProcessModel
Proc.=BusinessProcess
I/O=BusinessResources
ListofLocationsinwhich
theBusinessOperates
Node=MajorBusiness
Location
e.g.LogisticsNetwork
Node=BusinessLocation
Link=BusinessLinkage
e.g."DistributedSystem
Node=I/SFunction
(Processor,Storage,etc)
Link=LineCharacteristics
e.g."SystemArchitecture"
Node=Hardware/System
Software
Link=LineSpecifications
e.g."NetworkArchitecture"
Node=Addresses
Link=Protocols
e.g.NETWORK
Architecture"
Planner
Owner
Builder
ENTERPRISE
MODEL
(CONCEPTUAL)
Designer
SYSTEM
MODEL
(LOGICAL)
TECHNOLOGY
CONSTRAINED
MODEL
(PHYSICAL)
DETAILED
REPRESEN-
TATIONS
(OUT-OF
CONTEXT)
Sub-
Contractor
FUNCTIONING
MOTIVATIONTIMEPEOPLE
e.g.RuleSpecification
End=Sub-condition
Means=Step
e.g.RuleDesign
End=Condition
Means=Action
e.g.,BusinessRuleModel
End=StructuralAssertion
Means=ActionAssertion
End=BusinessObjective
Means=BusinessStrategy
ListofBusinessGoals/Strat
Ends/Means=MajorBus.Goal/
CriticalSuccessFactor
ListofEventsSignificant
Time=MajorBusinessEvent
e.g.ProcessingStructure
Cycle=ProcessingCycle
Time=SystemEvent
e.g.ControlStructure
Cycle=ComponentCycle
Time=Execute
e.g.TimingDefinition
Cycle=MachineCycle
Time=Interrupt
e.g.SCHEDULE
e.g.MasterSchedule
Time=BusinessEvent
Cycle=BusinessCycle
ListofOrganizations
People=MajorOrganizations
e.g.WorkFlowModel
People=OrganizationUnit
Work=WorkProduct
e.g.HumanInterface
People=Role
Work=Deliverable
e.g.PresentationArchitecture
People=User
Work=ScreenFormat
e.g.SecurityArchitecture
People=Identity
Work=Job
e.g.ORGANIZATION
Planner
Owner
totheBusinessImportanttotheBusiness
What How Where Who When Why
Copyright-JohnA.Zachman,ZachmanInternational
SCOPE
(CONTEXTUAL)
Architecture
e.g.STRATEGY
ENTERPRISE
e.g.BusinessPlan
TM
ZachmanInstituteforFrameworkAdvancement-(810)231-0531

18/01/199 117

CATEGORIZANDO A LOS OBJETOS
18/01/199 118

Taxonomía de los objetos (1)
• La OMG ha organizado a los objetos en una taxonomía que
facilita su identificación, comunicación y sincronización
• La taxonomía es una jerarquía de tipos de objetos, y hasta
el momento no está completa del todo
• Los objetos están organizados en 3 categorías
– Objetos de negocios
– Objetos base
– Objetos de servicios de aplicación
• Cada categoría es una subtipo abstracto de objetos
18/01/199 119

Taxonomía de los objetos (2)
18/01/199 120
ObjetosObjetos
Objetos baseObjetos baseObjetos deObjetos de
negocios
Objetos deObjetos de
servicios de
aplicación

Definiciones (1)
• Objetos:
– Un modelo o paquete de software
con atributos encapsulados en
servicios
– Capaz de solicitar servicios de otros
objetos por medio del envío de
mensajes
– Capaz de ser especializado por
medio de mecanismos tales como
herencia o delegación
18/01/199 121

Definiciones (2)
• Objetos de negocios:
– Es un objeto de modelado de negocios (un objeto que
describe una cosa en el negocio mismo) o un objeto de
sistemas de negocios (un objeto de software que representa
un concepto de negocios en software)
• Objetos base:
– Un objeto que no captura un concepto de negocios per-se, y
que se puede representar como una construcción en un
lenguaje de programación
• excepto que necesite expresarse como un objeto para tomar ventaja
de las propiedades tales como herencia, especialización y métodos
– Ejemplo: decimal, descripción, fecha, tiempo
18/01/199 122

Definiciones (3)
• Objetos de servicios de
aplicaciones:
– Un objeto de diseño o de software
que proporciona las funciones
necesarias para muchas aplicaciones
– Aquellos conceptos de objetos que
son conocidos para los usuarios de las
aplicaciones, pero que no se han
pensado como como datos o
funciones del negocio
– Ejemplos: Adaptador, generador de
números secuenciales
18/01/199 123

Observaciones sobre los tipos de
objetos
• Cada uno sirve a un propósito
diferente en los negocios y la
tecnología de información (TI)
• Cada uno emerge de un proceso
específico de TI
• Reutilización de cada uno
requiere de planeación y
organización
18/01/199 124

EFECTIVO
18/01/199 125

Pensamiento de objetos efectivo
• El pensamiento de objetos
efectivo
– Inicia en el nivel de la ubicación
espacial del problema (i.e.,
objetos de negocios)
– Se traslada a los servidores de
software compartidos (i.e.,
marcos de objetos de negocios =
business object frameworks =
BOF)
– Se lleva a través del análisis de las
aplicaciones (i.e., análisis OO =
AOO)
– Se refleja en el diseño de la
aplicación (i.e., diseño OO =
DOO)
– Y se ejecuta en software (i.e.,
programación OO = POO)
• Nota: POO no es un requisito
para el pensamiento de
objetos
– Pero la POO hace posible la
realización del pensamiento de
objetos en software
18/01/199 126

El pensamiento de objetos está
relacionado con ... (1)
• Ingeniería de negocios
– Una reingeniería de procesos de negocios (BPR) y una
mejora sustancial de los mismos es posible si se utilizan
objetos de negocios para modelarlos y evaluarlos
• Rediseña la infraestructura para la implementación
– Mensajes a través de middleware que permiten a los
objetos de negocios “simular” las actividades de
negocios, datos almacenados y procedimientos activos
18/01/199 127
Objeto de
negocios

El pensamiento de objetos está
relacionado con ... (2)
• Rediseño de las aplicaciones
– Las aplicaciones se convierten en controladores
útiles para controlar servidores compartidos de
objetos de negocios (todo vía el middleware)
• Aplica el pensamiento de empaquetado en
cada paso
18/01/199 128

Premisas para el pensamiento de
objetos
• Los negocios son más similares que disimilares
– Los negocios son muy parecidos en un 80% en su
estructura, procesos, eventos
– La competitividad es sólo el 5% del modelo de negocios
– Las diferencias tácticas e industriales corresponden al 5%
• Si se capturan las similitudes de conexión y utilización
de los objetos, entonces se puede
– Especializarlos una y otra vez para diferentes usos
– Reutilizarlos de diferentes formas
18/01/199 129

Patrones de negocios
• Una forma de resolver
problemas que utiliza
prototipos
– guías genéricas de diseño,
arquetipos, plantillas
• Colección de objetos y
asociaciones de negocios
que capturan un tema
recurrente
– Las asociaciones pueden ser
interacciones, relaciones o
grupos
• Sub-ensamblaje de
negocios pre-fabricados
– Ensambla un conjunto de
objetos y sus relaciones en
un módulo
• Son una forma poderosa
de iniciar el pensamiento
de objetos en el nivel de
los negocios
18/01/199 130

Utilización de los patrones de negocios
• Se pueden especializar acorde a las necesidades de
los negocios
– Esto implica reutilización en diferentes áreas de los
negocios, siempre y cuando exista una base común
• Eliminan la necesidad de la reinvención
– La arquitectura de “conectar y usar” los requieren para
trabajar con modelos y aplicaciones de negocios
• Los sistemas son más fáciles de desarrollar para un
negocio bien definido
– Los patrones se enfocan al pensamiento de negocios,
haciendo el proceso de definición menos frustrante,
más concreto
18/01/199 131

El inicio del pensamiento de negocios
• El pensamiento de objetos efectivo inicia con los
negocios
– Las empresas enfocadas a los lenguajes de programación
normalmente fallan en la obtención de beneficios
substanciales de la tecnología de objetos
– Aquellas que inician con las aplicaciones normalmente
desean tener modelo de objetos de la empresa para su
segundo proyecto
– Los negocios que inician con objetos de negocios pueden
relacionar la estrategia de negocios y la actividad operacional
con las soluciones de software
• Los negocios dirigen al software
• El software sirve a los negocios
18/01/199 132

EL CASO DE NEGOCIOS
18/01/199 133
OBJETOS DE NEGOCIOS

La información es estratégica
• Los sistemas de información (SI) han
evolucionado de ser simples
herramientas a ser una parte
integral de los procesos de negocios
• Un SI efectivo es un arma estratégica
para las organizaciones
• SI efectivos y flexibles se traducen
en ganancias directas y de
supervivencia corporativa
18/01/199 134
La
información
es
estratégica

Obstáculos para la efectividad (1)
• Aplicaciones heredadas son difíciles de
incorporar a los nuevos esquemas se SI
• SI inflexibles no cambian acorde a las
necesidades de los negocios
• Dificultad para integrar aplicaciones
• Ambientes cerrados y propietarios
18/01/199 135

Obstáculos para la efectividad (2)
• Las aplicaciones no concuerdan con las
necesidades de negocios o con el modelo
de negocios
• Los SI actuales son inaccesibles y poco
comprensibles
• Los SI actuales y tradicionales son caros
en su creación y mantenimiento
• Los SI no son “escalables” conforme al
crecimiento de los negocios
18/01/199 136

OBJETOS DE NEGOCIOS
PROBLEMAS DE LOS SI Y LA
TECNOLOGÍA DE OBJETOS
18/01/199 137

Los objetos y las empresas
18/01/199 138
¿Qué dijo? Encapsulamiento
Polimorfismo
Interfaz
Comportamiento
¡Los objetos no son útiles en las empresas!

Componentes de los negocios
• Personas
• Compañías
• Interacción
• Relaciones
• Dependencias
• Políticas
• Procesos
• Transacciones
Los negocios son
la cooperación e
interacción de
personas y
sistemas a través
de la empresa y
el mundo
18/01/199 139

Componentes de los objetos en los
negocios
• Personas
• Compañías
• Interacción
• Relaciones
• Dependencias
• Políticas
• Procesos
• Transacciones
 Los objetos en los
negocios no se refieren
al aislamiento del
comportamiento o
interfaz de un objeto,
sino a la cooperación e
interacción de objetos a
través de la empresa y
el mundo
18/01/199 140

Objetos y negocios
• Personas
• Compañías
• Interacción
• Relaciones
• Dependencias
• Políticas
• Procesos
• Transacciones
18/01/199 141
Objetos Cooperativos
Marcos de trabajo cooperativos de objetos
resuelven los problemas de negocios

Negocios y objetos
De igual forma que los grupos
cooperativos de personas resuelven
los problemas de negocios
18/01/199 142

Necesidad de un marco de trabajo
para los objetos
• ¿Donde obtener
ayuda?
• ¿Es necesario
conocer esto?
• ¿Puedo hacer esto?
• ¿Quién es el
responsable?
18/01/199 143
Objetos Cooperativos
Los objetos necesitan un marco para interactuar

Necesidad de un marco de trabajo
para las personas
18/01/199 144
• Leyes
• Políticas
• Valores
• Formas de
actuar
De igual forma que las personas lo hacen...

El marco de trabajo de los objetos en
los negocios
• Provee el marco de
trabajo técnico para la
interacción de los objetos
en los negocios
• Es un marco de trabajo
para integrar y construir
objetos en los negocios
• Permite componentes de
objetos en los negocios
con la característica de
“conectar y usar” (plug-
and-play)
18/01/199 145

La clave de los objetos en los negocios
• Los objetos en los negocios se refieren a
marcos de trabajo para componentes de
aplicación plug-and-play, que cooperan
para resolver los problemas de negocios
18/01/199 146

OBJETOS DE NEGOCIOS
DEFINICIÓN DE LOS BO’s
18/01/199 147

Conceptos generales (1)
• Es posible y deseable definir
tanto a los negocios y sus
aplicaciones de software en
términos de objetos de
negocios (BO’s)
• Un BO captura información
acerca de los conceptos del
mundo real (negocios),
operaciones sobre esos
conceptos y otros conceptos
de negocios
• El concepto de negocios
se puede transformar en
diseño e implementación
de software
• Una aplicación se puede
especificar en términos de
interacciones entre una
configuración de BO’s
18/01/199 148

• Un BO es modelo o paquete de
software de procesos de negocios,
políticas y controles relacionado con
un sólo concepto
– Cada BO representa un único concepto
bien definido de negocios: cliente,
orden de pedido, administrador,
automóvil, etc.
• Una forma de organizar los datos
correctos y los procedimientos
correctos en el lugar correcto
18/01/199 149
p

• Independiente de las aplicaciones
• Utilizados en la empresa para
representar conceptos compartidos
de negocios tales como clientes,
ordenes, y productos
18/01/199 150

¿Porqué BO’s? (1)
• Administra las diferencias y cambios en las reglas
de negocios (normalización semántica)
– Colocan las reglas de negocios divisionales/locales en
las especializaciones
– Conservan las definiciones corporativas, reglas de
negocios y datos en la generalización
18/01/199 151

¿Porqué BO’s? (2)
• Ayudan a la reingeniería de procesos de
negocio (Business Process Reengineering:
BPR)y a los aspectos relacionados
– El método estructurado tradicional y orientado
a objetos tienen grandes diferencias
– Las diferencias son caras a menos que
produzcan insumos
18/01/199 152

Definición de los BO’s
• La OMG (Object Mangement Group) define a los BO’s
de acuerdo con sus usos y en dos formas distintas
pero relacionadas:
– En un modelo de negocios:
• un BO describe a un negocio y su contexto
• los BO’s capturan los objetos de negocios y expresan un visión
abstracta de los negocios del “mundo real”
• el término “BO’s de modelado ” se utiliza para designar este uso
– En un diseño de un sistema de software o en la
codificación de un programa:
• los BO’s reflejan cómo los conceptos de negocios se representan
en software
• esta abstracción refleja la transformación de las ideas de
negocios en una realización en software
• el término “BO’s de sistemas” se utiliza para designar este uso
18/01/199 153

BO’s en un modelo de negocios (1)
• Un BO describe una cosa,
concepto, proceso o evento
en operación,
administración, planeación o
contabilidad de un negocio u
otra organización
• Es un objeto conceptual que
se ha especificado con el
propósito de describir o
especificar, y por lo tanto
servir, un propósito o
concepto de negocios
• Un BO es una especificación
de una clase de objeto que
puede existir en uno o mas
dominios del negocio
• Esta especificación puede
incluir atributos, relaciones,
y acciones/eventos que
aplican a estos objetos
• La forma de la especificación
puede ser textual, gráfica
(UML), o en lenguaje natural
18/01/199 154

BO’s en un modelo de negocios (2)
• Estos BO’s de modelado existen sin importar
la existencia de SI, aplicaciones, diseño de
software o codificación de programas
• Son independientes de los SI debido a que
los BO’s de modelado directamente reflejan
y abstraen los conceptos de negocios
• Así, los BO’s de modelado están definidos
independientemente de los sistemas de
aplicación
18/01/199 155

BO’s en un modelo de sistemas (1)
• Un BO, cuando se utiliza para describir un
sistema, representa algo en éste que es
en si mismo una abstracción
representando algo en el mundo real
• Un concepto del mundo real debe
primero representarse en un BO de
modelado, como se describió en el uso
anterior, y entonces este BO de modelado
debe ser la entrada para la especificación
de un BO de sistemas
18/01/199 156

• Así, un BO en este uso tiene una correlación
con los BO’s utilizados para describir los
negocios
• Sin embargo esta correlación puede no ser
uno-a-uno, ya que los conceptos de negocios
encierran restricciones y contexto
• Los BO’s en este uso tienen las propiedades
que un desarrollador esperaría de un objeto de
software o de diseño
18/01/199 157

• Adicionalmente, estos BO’s tienen las
siguientes propiedades:
– comportamiento
– reglas de negocios
• restricciones específicas sobre el comportamiento,
relaciones y/o atributos que reflejan reglas que
gobiernan la conducta del negocio
– identidad de negocios
• uno o mas atributos para cada tipo de BO’s
– por ejemplo, el nombre y su valor en el negocio, los cuales
identifican al negocio y su significado
18/01/199 158

– integridad de las instancias y las relaciones de las
inter-instancias a través de las reglas de negocios
– persistencia
• permanencia durante la aplicación
– seguridad
• protege a las instancias de cualquier uso no autorizado
– interoperabilidad con objetos de negocios definidos
por agentes externos
– transactibilidad
• asegura que los cambios se lleven a cabo y se completen del
todo
18/01/199 159

• Los BO’s comerciales de sistemas deberían
contener tanto software ejecutable como la
especificación del software
• Una biblioteca de clases de BO’s se puede
ver como un marco de trabajo para el
software
• Es razonable esperar que los productos de
BO’s combinen el diseño de software y la
implementación con los BO’s de modelado
18/01/199 160

Relación entre los modelos de
negocios y de sistemas (1)
• Existe una correspondencia entre los BO’s de
sistemas y los BO’s de modelado debido a
que los primeros representan en un sistema
la información y dinámica de los conceptos
de negocios tal como se capturan en el
modelo de negocios
18/01/199 161

• Pueden existir objetos en un modelo de
sistemas que no son BO’s
– un diseño o software que implemente una
aplicación de negocios puede contener contener
objetos que no sean BO’s
• lo anterior se debe a que los objetos pueden representar
conceptos que son específicos de la aplicación o la
tecnología, mas que de los negocios
18/01/199 162
Modelo de sistemas
BO’sBO’s

• La información y dinámica representada por
los BO’s de sistemas está determinada por
el procesamiento que debe efectuar el
sistema con el fin de cumplir su papel en el
modelo de negocios
• Pueden existir BO’s para los cuales no hay
información y dinámica en el modelo de
negocios
18/01/199 163

• Entonces, no todos los BO’s de modelado
en el modelo de negocios tendrá un BO
asociado en el modelo de sistemas
– Esto depende del alcance y de las decisiones
de implementación
18/01/199 164
BO
BO
BO
BO
BO
BO
BO
BO

El enfoque “top half down”
18/01/199 165

Taxonomía para la abstracción
• Abstracciones de negocios
(mitad superior)
– Genérica
– Específica a la compañía
• Abstracciones de software
(mitad inferior)
– Diseño
– Implementación
18/01/199 166
Abstracciones
Abstracciones
Abstracciones
de negocios
Abstracciones
de software

Abstracciones de negocios
• Genéricas
– Horizontal - aplicable en las organizaciones
– Vertical - aplicable a los negocios en una
organización
– Regional - variaciones nacionales dentro de una
organización
• Específica a la compañía
– Empresarial - compartida por muchas/todas las
organizaciones
– Área de negocios - local a la unidad de
negocios, departamental
– Individual - local a un trabajo en grupo
18/01/199 167
Horizontal
Vertical
Regional

Abstracciones de software
• Diseño
– Externa - protocolo para la interfaz
pública, estructura de la clase
– Interna - métodos, atributos,
restricciones, mapeos
• Implementación
– Código fuente - lenguaje objetivo
“humanamente leíble”
– Código ejecutable - formato
determinado por el tiempo de
ejecución
18/01/199 168

Los BO’s no son ...
• Los BO’s no se definen
– Bottom-up
– Por la forma de la infraestructura que los implementa
– En las aplicaciones
• Los BO’s no representan software o conceptos de
aplicación
– Los BO’s sólo representan construcciones de negocios
– Cuando se implementan, los BO’s convierten
componentes de software, pero aún así están
definidos y formados por los conceptos de negocios
que ellos representan
18/01/199 169

OBJETOS DE NEGOCIOS
TAXONOMÍA DE LOS BO’s
18/01/199 170

Taxonomía de los BO’s
18/01/199 171
Objetos de
negocios
Objetos de
eventos de
negocios
Objetos de
entidades de
negocios
Objetos de
procesos de
negocios

Instancias de BO’s
• Un tipo o clase de objetos en particular es
instanciado cuando el representa de forma directa
conceptos concretos en el mundo de los negocios
• Esto es, las instancias se pueden crear para los tipos
18/01/199 172

Objetos de entidades de negocios (1)
• Representan personas, lugares y cosas, de
igual forma las entidades de modelado de
datos
• Empaquetan procedimientos y reglas que son
específicos para el concepto que está siendo
representado, mientras que la entidad de
datos empaqueta sólo datos
18/01/199 173

Objetos de entidades de negocios (2)
• Representan un nombre o sustantivo tangible
de negocios, sin embargo también pueden
representar un concepto intangible
– Empleado
– Empleador
– Empleo
• Sus instancias son paquetes de datos o hechos
referentes a los nombres o sustantivos de los
negocios
18/01/199 174

Objetos de entidades de negocios
comunes
• Clientes
• Requisiciones
• Productos
• Contratos
• Equipos
• Capacidades
• Direcciones
• Vehículos
• Facilidades
• Proveedores
18/01/199 175

Instancias de objetos de entidades
de negocios
• Representan los valores de los datos retenidos
acerca de cosas específicas en el mundo real
• Por ejemplo, un cliente en particular podría
ser representado por una instancia del tipo
cliente de los objetos de entidades de
negocios
18/01/199 176

Objetos de eventos de negocios (1)
• Representan ...
– eventos de negocios
• temporadas de negocios (fin de año fiscal,
temporada otoño-invierno)
– cambios en el ambiente de negocios
– ciclos de vida de productos
– fronteras en el tiempo
• Reconocen que una acción
significante ha sucedido
18/01/199 177

• Son similares a los objetos de
entidades de negocios en el
sentido que son repositorios
para la información y reglas de
negocios relativas a los eventos
• Se utilizan como un actor para
iniciar la actividad de negocios
18/01/199 178

• Poseen ...
– nombre y definición
– hechos acerca de ellos
– procedimientos y restricciones asociados con ellos
• Ocupan un lugar importante en el modelo de
objetos de negocios
– Se encuentran en el inicio y término de interacciones
entre objetos de entidades de negocios
– Pueden resultar de una interacción entre dos objetos
de entidades de negocios
18/01/199 179

Objetos de eventos de negocios
comunes
• Baja de inventarios
• Sobre presión de los tanques
• Ausencia de empleados
• Aprobación de comisiones
• Cambios en las tasas de interés
• Pago de deudas
• Fin de año fiscal
• Vencimiento de prestamos
• Pago de facturas
• Cierre de bodegas
18/01/199 180

Instancias de objetos de eventos de
negocios
• Representan ocurrencias individuales de un
evento en el mundo de los negocios
• Por ejemplo, la contratación de un tipo
particular de ayudante al cierre de un periodo
fiscal
18/01/199 181

Objetos de procesos de negocios (1)
• Representan ...
– verbos relativos a los negocios
– procesos de negocios (en oposición a los
procedimientos), donde un proceso se caracteriza
por la interacción de un conjunto de objetos de
negocios
• Son los actores que llevan a cabo el proceso
de negocios
18/01/199 182

Objetos de procesos de negocios (2)
• Cada interacción entre un par de objetos de
entidades de negocios representa un paso en
el proceso de negocios
• Los objetos de entidades de negocios
empaquetan las políticas y controlan como el
proceso se efectúa
• Así, los objetos de procesos de negocios
empaquetan el “cómo” en un objeto
18/01/199 183

Objetos de procesos de negocios
comunes
• Procesos principales
– Llenado de formatos
– Ejecución de normas y
políticas
– Producción
– Facturación
• Sub-procesos comunes
– Contratación, asignación
de costo, repartición
– Certificación de calidad,
requisiciones, recepción
18/01/199 184

Instancias de objetos de procesos de
negocios
• Representan la iniciación de un proceso
particular de negocios el cual entrega un
resultado de negocios
• Por ejemplo ...
– el proceso que se inicia al llenar la orden de
pedido de un producto
– el proceso de contratación de un nuevo empleado
18/01/199 185

Relaciones entre tipos
• Objetos de entidades de negocios ...
– Son actores que juegan un papel en uno o mas procesos
– Son una fuente de información de negocios además de los
procesos en los cuales participa
• Objetos de procesos de negocios ...
– Controlan los patrones de interacción entre un grupo de
objetos de entidades de negocios para así producir el
resultado deseado
– Puede dividir su trabajo entre objetos de procesos
subordinados
• Objetos de eventos de negocios ...
– Disparan o resultan de la interacción entre dos objetos de
entidades
18/01/199 186

OBJETOS DE NEGOCIOS
APLICACIONES DE LOS BO’s
18/01/199 187

Ejemplo de objetos de entidades de
negocios
18/01/199 188
Vuelo
Código del portador
Número de vuelo
Establecer
itinerario
Cancelar
Portador
Nombre de aerolínea
Certificar
No-certificar
Asiento del segmento
de vuelo
Código del
portador
Número de vuelo
Código IATA del
aeropuerto origen
Código IATA del
aeropuerto destino
Número de fila
Disponer
Asignar
No-asignar
Ocupar
Segmento de vuelo
Código del
portador
Número de vuelo
Código IATA del
aeropuerto origen
Código IATA del
aeropuerto destino
Hora de partida
Hora de llegada
Partir
Llegar
Aeropuerto
Nombre del aeropuerto
Cerrar por clima
Opera
Transporta
Expande
Origina
Termina

Ejemplo de objetos de procesos de
negocios
18/01/199 189
Interacciones entre objetos de
entidades de negocios que incluyen los
pasos efectuados por objetos de
procesos de negocios
Pasajero
Mostrar número de
viajero frecuente
Seleccionar
preferencia de
asiento
Agente de
reservaciones
Asentar reservación
Reservar boleto
Asiento de segmento
de vuelo
Disponer
Asignar
No-asignar
Ocupar
Reservación
Asentar
Etiquetar
Cancelar
Asentar reservación
Reservar boleto
Seleccionar
preferencia
de asiento
Seleccionar preferencia de asiento
Disponer
Asignar
Reservar
Etiquetar

OBJETOS DE NEGOCIÓN
LA ARQUITECTURA DE ZACHMAN Y
LOS BO’s
18/01/199 190

Mapeo de la taxonomía de BO a la
arquitectura de Zachman
18/01/199 191
WHAT
(data)
WHERE
(location)
HOW
(process)
WHO
(organization)
WHEN
(schedule)
WHY
(motive)
SCOPE
(planner)
ENTERPRISE
(owner)
SYSTEM
(designer)
TECHNOLOGY
(builder)
COMPONENTS
(sub-contractor)

Mapeo de los niveles de abstracción a la
arquitectura de Zachman
18/01/199 192
WHAT
(data)
WHERE
(location)
HOW
(process)
WHO
(organization)
WHEN
(schedule)
WHY
(motive)
SCOPE
(planner)
ENTERPRISE
(owner)
SYSTEM
(designer)
TECHNOLOGY
(builder)
COMPONENTS
(sub-contractor)
GENÉRICO
ESP. DE LA
EMPRESA
DISEÑO
EXTERNO
DISEÑO
INTERNO
IMPLEMEN-
TACIÓN

APLICACIONES DE LOS BO’s DE
SISTEMAS
EL MODELO DE NEGOCIOS: DISEÑOS
EJECUTABLES
18/01/199 193

Elementos del modelo de negocios
• Actores
– Personas y procesos automáticos - clientes,
agentes de ventas, autorizador de compras
• Procesos
– hacer pedidos, realizar facturas, reclutar personal,
hacer envíos, manufacturar
• Entidades
– lugares, cosas, partes, órdenes, facturas, compras
18/01/199 194

Ejemplo sencillo de modelo
18/01/199 195
Los actores, procesos y entidades de negocios
definen el modelo de negocios
Llamada de ventaLlamada de venta
OrdenOrdenProductoProducto
Para
Produce

Mapeando el modelo al modelado de
BO’s
18/01/199 196
Llamada de ventaLlamada de venta
AgenteAgente
OrdenOrden
CompradorComprador
Produce
Objeto de proceso de ventaObjeto de proceso de venta
ProductoProducto Para
Tomado por De

Implementando el modelo
• Cada BO señalado abajo se implementa como un
componente independiente conteniendo reglas de
negocio
• Cada uno colabora con el otro BO utilizando marcos de
trabajo estándar
18/01/199 197
AgenteAgente
OrdenOrden
CompradorComprador
Produce
Objeto de proceso de ventaObjeto de proceso de venta
ProductoProducto Para
Tomado por De

Las reglas de negocios aplican a
cualquier BO
18/01/199 198
OrdenOrden
Ninguna orden debe ser
procesada cuando el
comprador esté en espera
CompradorComprador
Los compradores deben
en sus pagos
Los compradores deben
estar en espera cuando
se retrasan 60 días
en sus pagos
Los compradores debenLos compradores deben
estar en espera cuando
excede su límite de
crédito

Estrechando la brecha entre el diseño
y la implantación
18/01/199 199
BO comunes
Marco de trabajo de los BO
DiseñoDiseño
ImplantaciónImplantación

SISTEMAS
CLIENTE/SERVIDOR Y LOS BO’s
18/01/199 200

Problemas en las aplicaciones de dos
niveles (Two tier)
18/01/199 201
Todas las reglas de negocios,
las reglas de datos, las aplicaciones
lógicas y el código de interfaces
de usuario están contenidas aquí
Los datos van aquí
Fuentes de
datos
tradicionales
SQL DBMS
Cliente/Servidor
Fuentes de
datos
tradicionales
SQL DBMS
Cliente/Servidor
Aplicaciones
monolíticas
Aplicaciones
monolíticas
Cosas
malas
Cosas
malas
Aplicaciones
monolíticas
Aplicaciones
monolíticas
Cosas
buenas
Cosas
buenas

Cliente/Servidor de 3 niveles con BO’s
18/01/199 202
SQL DBMS
Aplicaciones
heredadas
Cliente/Servidor
SQL DBMS
Aplicaciones
heredadas
Cliente/Servidor
Objetos de
negocios
Aplicaciones
Cliente
Aplicaciones
Cliente
Las reglas de negocio
y de datos van aquí
La interfaz del usuario
y las aplicaciones
lógicas van aquí
Buenas
cosas
Buenas
cosas
Buenas
cosas
Buenas
cosas Buenas
cosas
Buenas
cosas
Los datos van aquí

SISTEMAS
APLICACIONES HEREDADAS Y LOS
BO’s
18/01/199 203

Los BO’s “incorporan” las aplicaciones
heredadas y datos
• Los objetos de negocio se definen en
términos de su interfaz; su implementación
puede utilizar aplicaciones existentes
– Pueden “llamar” una aplicación existente
– Pueden utilizar un “raspador de pantallas”
• Los nuevos sistemas basados en BO’s se
pueden construir utilizando un DBMS
existente
18/01/199 204

“Incorporación” de sistemas
heredados
18/01/199 205
La incorporación permite que los
programas y datos viejos trabajen
con y como BO’s

SISTEMAS
INTERNET Y LOS BO’s
18/01/199 206

Los BO’s e Internet y/o una intranet
18/01/199 207
La gente puede utilizar los BO´s a través
de los servidores Web en cualquier lugar

BO’s en diferentes empresas interoperan
a través de Internet
18/01/199 208
El Este importaEl Oeste exporta

Internet integra gente, empresas y BO’s en
todo el mundo
18/01/199 209

Internet browsers como clientes de los
BO’s
18/01/199 210
Internet
Browser
Clients
Browser
Clients
Browser
Clients
Web
Servers
Web
Servers
Business
Objects
Business
Objects
Business
Objects

Internet, e-commerce y BO’s
• Los BO’s permiten el e-commerce
– Proporcionan workflow (objetos de procesos de
negocios) y fuentes (objetos de entidades de
negocios) a las aplicaciones equipadas con
browsers
– Traen clientes y proveedores a la empresa
– Integran los negocios con clientes y proveedores
compartiendo BO’s
18/01/199 211

SISTEMAS
RESOLVIENDO LOS PROBLEMAS CON
LOS BO’s
18/01/199 212

Los BO’s y sistemas inflexibles
• Problema
– Sistemas inflexibles no cambian acorde a las
necesidades de negocios
• Respuesta
El modelado de objetos y la implementación
permiten a las componentes de negocios
integrarse y utilizarse de diferentes formas. Los
cambios son sólo sobre un número pequeño de
objetos
Cada BO y cada cliente es un “programa”
separado, el impacto en los cambios se minimiza
18/01/199 213

Los BO’s y aplicaciones heredadas
• Problema
– Las aplicaciones heredadas son difíciles de
evolucionar
• Respuesta
Las aplicaciones heredadas pueden
“incorporarse” en BO’s para una
integración y transición eficiente
18/01/199 214

Los BO’s y unidades de negocio
• Problema
– Dificultad para integrar aplicaciones y
unidades de negocio
• Respuesta
El modelo de BO’s de la OMG opera dentro
de marco estándar que facilita la integración
de la tecnología y las unidades de negocio
Los BO’s se convierten en componentes de
escritorio
18/01/199 215

Los BO’s y ambientes propietarios
• Problema
– Ambientes cerrados y propietarios
• Respuesta
Aplicación de los estándares de BO’s de la OMG
Los BO’s están abiertos para utilizar cualquier
DBMS o las aplicaciones existentes para la
implementación
Los BO’s se pueden utilizar por cualquier
aplicación o programas de escritorio a través de
interfaces estándar
18/01/199 216

Los BO’s y los modelos de negocio
• Problema
– Las aplicaciones no se ajustan a las
necesidades de negocios o al modelo de
negocios
• Respuesta
Los BO’s representan e implementan de
forma directa el modelo de negocios y los
procesos de negocios
18/01/199 217

Los BO’s y su dificultad
• Problema
– Los SI’s son inaccesibles y no entendibles
• Respuesta
Los BO’s utilizan la terminología de negocios
de la forma en que la gente de negocios la
entienden
Los BO’s catalogan al browser como un visor
de alto nivel de los SI’s
18/01/199 218

Los BO’s y su costo de construcción
• Problema
– Los SI’s son caros y difíciles de construir y
mantener
• Respuesta
Los BO’s son componentes reutilizables que
reducen los esfuerzos de desarrollo y
mantenimiento, proporcionando un SI con mas
estructura y menos complejo
El despliegue de los clientes a través de Internet
reduce el mantenimiento
18/01/199 219

Los BO’s y escalabilidad
• Problema
– Los SI’s no son “escalables” cuando los negocios
crecen
• Respuesta
La computación distribuida permite agregar
hardware acorde a los requerimientos de
crecimiento
Sistemas avanzados de replicación y distribución se
pueden emplear “tras bambalinas” para escalar al
sistema
18/01/199 220

Los BO’s y su dificultad
• Problema
– ¡Esto es demasiado difícil!
• Respuesta
Las herramientas y marcos de trabajo basadas
en estándares reducen el 90% el tiempo de
construcción y utilización de BO’s
Los BO’s configurables se pueden “conectar”
por usuarios potenciales y utilizarse en las
aplicaciones de escritorio
18/01/199 221

SISTEMAS
¡LAS BUENAS NOTICIAS!: LOS BO’s
SON REALES
18/01/199 222

Ahora y en el futuro
• Productos y servicios están disponibles hoy en
día para construir y desplegar BO’s
• Estándares y productos basados en estándares
están y estarán disponibles en un futuro
cercano
18/01/199 223
¡Veo BO’s!

Conclusiones
• La tecnología de objetos
distribuidos con BO’s tendrá un
impacto significante en la
efectividad de los SI’s
• Esta es una tecnología
emergente bien fundamentada
• ¡Este es el momento exacto
para iniciar!
18/01/199 224

OBJETOS DE SERVICIOS DE
APLICACIONES
18/01/199 225

Definición
• Objetos de servicios de aplicaciones:
– Un objeto de diseño o de software que proporciona
las funciones necesarias para muchas aplicaciones
– Aquellos conceptos de objetos que son conocidos
para los usuarios de las aplicaciones, pero que no se
han pensado como como datos o funciones del
negocio
– Ejemplos: Adaptador, generador de números
secuenciales
18/01/199 226

Clasificación de los sistemas y
lenguajes de programación (1)
• Los objetos de servicios de aplicaciones pueden
ser sistemas o lenguajes de programación
• Desde el punto de vista de objetos, los sistemas se
pueden clasificar como:
– basados en objetos = encapsulamiento + identidad
de objetos
– basados en clases = basados en objetos + abstracción
de conjunto
– orientados a objetos = basados en clases +
autorreferencia
18/01/199 227

• Los lenguajes orientados a objetos puros son:
– CLOS (Common Lisp Object System)
– Eiffel
– Simula
– Smalltalk
– Prolog++
• Los lenguajes basados en objetos son:
– Ada
– Modula 2
– Ellie
• Los lenguajes basados en clases son
– CLU
18/01/199 228

• Los lenguajes convencionales ampliados son
– C++
– Objective C
– Object Pascal, Turbo Pascal y Delphi
– Modula-3
– Classic Ada
– Object Cobol
18/01/199 229

Otros lenguajes y el diseño de sistemas
• Los diseños orientados a objetos se pueden
construir en lenguajes convencionales, pero
su dificultad y muchos de los beneficios
podrían resultar perdidos
• Se puede utilizar envoltorios de objetos
para migrar a la programación orientada a
objetos, y seguir protegiendo las
inversiones en código convencional
18/01/199 230

¿Orientado a objetos?: aplicación con
GUI (1)
• Si una aplicación tiene una GUI no
necesariamente es orientado a objetos
• Las ventanas, botones y menús son objetos
naturales de la interfaz
– la lógica de la aplicación que reside en las
ventanas puede o no ser orientada a objetos
– depende completamente de la capacidad del
lenguaje de desarrollo y la manera en que se le
diseña
18/01/199 231

¿Orientado a objetos?: aplicación con
GUI (2)
• Muchas herramientas GUI populares primero
fueron escritas para aprovechar los objetos de
la interfaz gráfica del usuario, pero la lógica
del negocio se ejecuta con una mezcla
bastante estándar de guiones SQL y tipo 3GL
– Estas herramientas están adoptando cada vez mas
los principios OO, haciéndolas mas OO en cada
versión subsecuente
18/01/199 232

¿Orientados a objetos?: bases de
datos relacionales (1)
• Si se utiliza un lenguaje OO sobre una base de
datos relacional se está viviendo en ambos
mundos
• Los objetos existen en el ambiente del
momento de ejecución, pero cuando se
guarda información los objetos descargan sus
datos en una BD relacional
• La combinación de ambos modelos es
conocida como discordancia de impedancia
18/01/199 233

¿Orientados a objetos?: bases de
datos relacionales (2)
• El tener una base de datos relacional no hace que un
proyecto sea inferior a otro que utiliza una BD OO
• Las BD relacionales son muy populares en sistemas de
negocios
– esto se debe a que permite que la organización recolecte
un amplio rango de información y ponga muchas
decisiones sobre cómo utilizarla posteriormente
– aunque esto tiene menos sentido para los sistemas de
tiempo real, es una realidad en los sistemas de negocios
debido a la naturaleza competitiva siempre cambiante del
propio negocio
18/01/199 234

Objetos orientados a los negocios curso

Recomendados

Recomendados

Más contenido relacionado

Similar a Objetos orientados a los negocios curso

Similar a Objetos orientados a los negocios curso (20)

Más de Alejandro Domínguez Torres

Más de Alejandro Domínguez Torres (20)

Último

Último (20)

Objetos orientados a los negocios curso