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

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

LA ORIENTACIÓN A OBJETOS

¿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

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

LA ORIENTACIÓN A OBJETOS

¿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

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

LA ORIENTACIÓN A OBJETOS

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: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

LA ORIENTACIÓN A OBJETOS

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

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

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 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

EL PENSAMIENTO DE OBJETOS

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 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

EL PENSAMIENTO DE OBJETOS

ALEJANDRO DOMÍNGUEZ

18/01/199 117

EL PENSAMIENTO DE OBJETOS

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 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

EL PENSAMIENTO DE OBJETOS

EL PENSAMIENTO DE OBJETOS 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

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

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 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

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

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

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

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

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

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

OBJETOS DE NEGOCIOS

APLICACIONES DE LOS BO’s

18/01/199 187

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

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 LAEMPRESA

DISEÑOEXTERNO

DISEÑOINTERNO

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

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

APLICACIONES DE LOS BO’s DE 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í

APLICACIONES DE LOS BO’s DE 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 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

APLICACIONES DE LOS BO’s DE 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

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

APLICACIONES DE LOS BO’s DE 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

• 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

APLICACIONES DE LOS BO’s DE 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

ALEJANDRO DOMÍNGUEZ

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

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