objetos orientados a los negocios curso
TRANSCRIPT
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
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
Aspectos históricos (2)
• 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
Aspectos históricos (3)
• 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
Aspectos históricos (4)
• 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
Aspectos históricos (5)
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
Mediados de los 1990’s (2)
– 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
Mediados de los 1990’s (3)
– 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
Lo que se ha aprendido (2)
• 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
Lo que se ha aprendido (3)
• La tecnología OO es vasta; e.g., mas amplia que lo indicado en los lenguajes de programación OO
18/01/199 24
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
Ventajas tácticas (2)
• 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
Ventajas tácticas (3)
• 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
Ventajas tácticas (4)
• 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
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
Un objeto es ... (2)
• 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
Un objeto es ... (3)
• 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 objeto es ... (4)
• 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:costodimensionespeso
Operaciones:comprarvendermover
¿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:costodimensionespeso
Operaciones:comprarvendermover
¿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:costodimensionespeso
Operaciones:comprarvendermover
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
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:costodimensionespeso
Operaciones:comprarvendermover
El pensamiento de objetos se basa 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:costodimensionespeso
Operaciones:comprarvendermover
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
El pensamiento de objetos se basa 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:costodimensionespeso
Operaciones:comprarvendermover
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:comprarvendermover
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 valorespara 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:352-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:352-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 supertiposen 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 subtiposde 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íao 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
Cuentanombre, 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
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
Proveedoresexternos
Departamentosusuarios
Departamentosde ingeniería
EscrituraGráficos
e impresión
Agenciasexternas
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
Vistas externa e interna (2)
18/01/199 79
DepartamentosDepartamentosusuarios
AgenciasAgenciasexternas
GráficosGráficose impresión
ContabilidadEscritura
Vista externa de gráficos e impresión
Vistas externa e interna (3)
18/01/199 80
Gráficos
FotocomposiciónArtista gráficoCreador de fotolitos...
Hacer diapositivasHacer placasPreparar placasPedir materialesDespachar resultadosHacer informes de costosHacer informes de progreso...
Impresión
AlmacenistaOperadores de máquinaMaquinariaAlmacen de papelTrabajos en curso...
Hacer impresiónHacer reimpresiónHacer informes de progresoEmitir facturasPedir materialesHacer 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 solicitudesAsignar trabajos
Informar progresosFotocompositor
Informar de progresosComponer textos
Hacer cambios
Artista gráfico
Hacer diapositivasHacer placas
Hacer ilustracionesEncargado de pegado
PegarSolicitar cambios
Hacer informe de progresos
Creador de placas
Hacer placasDespachar
Hacer informe de progresos
Vista del objeto “gráficos” después de la tecnología
18/01/199 82
Director
Clasificar solicitudesAsignar trabajos
Informar progresos
Responsable de autoedición
Informar de progresosProducción de documentos
Artista gráfico
Hacer diapositivasHacer placas
Hacer ilustraciones
Creador de placas
Hacer placasDespachar
Hacer informe de progresos
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
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 diferentesniveles 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
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 superclaseslista de subclasesresponsabilidad colaboración
EL PENSAMIENTO DE OBJETOS
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
La gráfica de la arquitectura(2)
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 ProcessI/O = Bus Resources
List of Locations in which
the Business Opeerates
Node = Major Business
Location
e.g. Business Logistics
System
Node = Business LocationLink = Business Linkage
e.g. Distributed System
Node = I/S Function
(Processor, Storage, etc)
Link = Line Characteristics
e.g. System Architecture
Node = Hardware/SystemsSoftware
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)
La gráfica de la arquitectura(3)
• 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
La gráfica de la arquitectura(4)
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-conditionMeans = Step
e.g. STRATEGY
e.g. Rule Design
End = ConditionMeans = Action
e.g. Business Rule Model
End = Structural AssertionMeans = Action Assertion
e.g. Business Plan
End = Business ObjectiveMeans = 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 CycleTime = System Event
e.g. Control Structure
Cycle = Component CycleTime = Execute
e.g. Timing Definition
Cycle = Machine Cycle
Time = Interrupt
e.g. SCHEDULE
e.g. Master Schedule
Time = Business EventCycle = Business Cycle
List of Organizations
People = Major Organizations
People = Organization UnitWork = Work Product
e.g. Human Interface
People = Role
Work = Deliverable
e.g. Presentation Architecture
People = User
Work = Screen Format
e.g. Security Architecture
People = IdentityWork = 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
Características de la arquitectura (2)
• 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
Características de la arquitectura (3)
• 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
Características de la arquitectura (4)
– 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
ENTERPRISE ARCHITECTURE - A FRAMEWORK
Builder
SCOPE(CONTEXTUAL)
MODEL(CONCEPTUAL)
ENTERPRISE
Designer
SYSTEM
MODEL(LOGICAL)
TECHNOLOGY
MODEL(PHYSICAL)
DETAILEDREPRESEN- TATIONS(OUT-OF- CONTEXT)
Sub-Contractor
FUNCTIONINGENTERPRISE
DATA FUNCTION NETWORK
e.g. Data Definition
Ent = FieldReln = Address
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 ofBusiness Thing
List of Processes the
Business Performs
Function = Class of
Business Process
e.g. "Application Architecture"
I/O = User ViewsProc .= Application Function
e.g. "System Design"
I/O = Screen/Device Formats
Proc.= Computer Function
e.g. "Program"
I/O = Control BlockProc.= Language Stmt
e.g. FUNCTION
e.g. Business Process Model
Proc. = Business Process
I/O = Business Resources
List of Locations in which the Business Operates
Node = Major BusinessLocation
e.g. Logistics Network
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/SystemSoftware
Link = Line Specifications
e.g. "Network Architecture"
Node = AddressesLink = Protocols
e.g. NETWORK
Architecture"
Planner
Owner
Builder
ENTERPRISEMODEL
(CONCEPTUAL)
Designer
SYSTEMMODEL
(LOGICAL)
TECHNOLOGYCONSTRAINED
MODEL(PHYSICAL)
DETAILEDREPRESEN- TATIONS (OUT-OF CONTEXT)
Sub-
Contractor
FUNCTIONING
MOTIVATIONTIMEPEOPLE
e.g. Rule Specification
End = Sub-condition
Means = Step
e.g. Rule Design
End = Condition
Means = Action
e.g., Business Rule Model
End = Structural AssertionMeans =Action Assertion
End = Business Objective
Means = Business Strategy
List of Business Goals/Strat
Ends/Means=Major Bus. Goal/Critical Success Factor
List of Events Significant
Time = Major Business Event
e.g. Processing Structure
Cycle = Processing CycleTime = System Event
e.g. Control Structure
Cycle = Component Cycle
Time = Execute
e.g. Timing Definition
Cycle = Machine CycleTime = Interrupt
e.g. SCHEDULE
e.g. Master Schedule
Time = Business Event
Cycle = Business Cycle
List of Organizations
People = Major Organizations
e.g. Work Flow Model
People = Organization Unit
Work = Work Product
e.g. Human Interface
People = RoleWork = Deliverable
e.g. Presentation Architecture
People = User
Work = Screen Format
e.g. Security Architecture
People = IdentityWork = Job
e.g. ORGANIZATION
Planner
Owner
to the BusinessImportant to the Business
What How Where Who When Why
Copyright - John A. Zachman, Zachman International
SCOPE(CONTEXTUAL)
Architecture
e.g. STRATEGYENTERPRISE
e.g. Business Plan
TM
Zachman Institute for Framework Advancement - (810) 231-0531
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 de Objetos de negocios
Objetos de Objetos 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
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
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
Lainformación
esestraté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
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 objetosresuelven 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
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
Conceptos generales (2)
• 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
Conceptos generales (3)
• 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
BO’s en un modelo de sistemas (2)
• 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
BO’s en un modelo de sistemas (3)
• 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
BO’s en un modelo de sistemas (4)
– 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
BO’s en un modelo de sistemas (5)
• 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
Relación entre los modelos de negocios y de sistemas (2)
• 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 sistemasBO’sBO’s
Relación entre los modelos de negocios y de sistemas (3)
• 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
Relación entre los modelos de negocios y de sistemas (4)
• 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
BOBO
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
Abstraccionesde negocios
Abstraccionesde 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
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
Objetos de eventos de negocios (2)
• 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
Objetos de eventos de negocios (3)
• 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
Ejemplo de objetos de entidades de negocios
18/01/199 188
VueloCódigo del portadorNúmero de vuelo
Establecer itinerarioCancelar
PortadorNombre de aerolíneaCódigo del portador
CertificarNo-certificar
Asiento del segmentode vueloCódigo del portadorNúmero de vueloCódigo IATA del aeropuerto origenCódigo IATA del aeropuerto destinoNúmero de fila
DisponerAsignarNo-asignarOcupar
Segmento de vuelo
Código del portadorNúmero de vueloCódigo IATA del aeropuerto origenCódigo IATA del aeropuerto destinoHora de partidaHora de llegada
PartirLlegar
Aeropuerto
Nombre del aeropuertoCódigo del portador
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ónReservar boleto
Asiento de segmentode vuelo
DisponerAsignar
No-asignarOcupar
Reservación
AsentarEtiquetarCancelar
Asentar reservación
Reservar boleto
Seleccionar preferenciade asiento
Seleccionar preferencia de asiento
Disponer
Asignar
Reservar
Etiquetar
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 LAEMPRESA
DISEÑOEXTERNO
DISEÑOINTERNO
IMPLEMEN-TACIÓN
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
OrdenOrdenProductoProductoPara
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
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í
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 DBMSexistente
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
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 browsers como clientes de los BO’s
18/01/199 210
Internet
Browser
Clients
Browser
Clients
Browser
Clients
Web
Servers
Web
Servers
Business
ObjectsBusiness
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
Los BO’s y sistemas inflexibles
• Problema– Sistemas inflexibles no cambian acorde a las
necesidades de negocios
• RespuestaEl 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 objetosCada 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
• RespuestaEl 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
• RespuestaAplicación de los estándares de BO’s de la OMGLos BO’s están abiertos para utilizar cualquier
DBMS o las aplicaciones existentes para la implementaciónLos 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
• RespuestaLos 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
• RespuestaLa 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!
• RespuestaLas 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
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
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
Clasificación de los sistemas y lenguajes de programación (2)
• 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
Clasificación de los sistemas y lenguajes de programación (3)
• 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