Your SlideShare is downloading. ×
Objetos orientados a los negocios   curso
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Objetos orientados a los negocios curso

1,462

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,462
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
38
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. LA METODOLOGÍA DE OBJETOS ORIENTADA A LOS NEGOCIOS ALEJANDRO DOMÍNGUEZ 18/01/199 1
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. LA ORIENTACIÓN A OBJETOS HISTORIA DE LA ORIENTACIÓN A OBJETOS 18/01/199 10
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. LA ORIENTACIÓN A OBJETOS ¿PORQUÉ OBJETOS? 18/01/199 25
  • 26. 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
  • 27. 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
  • 28. 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
  • 29. 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
  • 30. 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
  • 31. 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
  • 32. 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
  • 33. 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
  • 34. LA ORIENTACIÓN A OBJETOS ¿QUÉ ES UN OBJETO? 18/01/199 34
  • 35. 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
  • 36. 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
  • 37. 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:
  • 38. 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:
  • 39. ¿Dónde existen los objetos? (1) • Los objetos son una representación en ... – el mundo real (i.e., negocios) – computadoras (i.e., tecnología) • Entonces los objetos existen en ... – el modelado , análisis, y reingeniería de negocios – Análisis y diseño de sistemas – Software 18/01/199 39 Procedimientos Restricciones Datos Nombre: silla Atributos: costo dimensiones peso Operaciones: comprar vender mover
  • 40. ¿Dónde existen los objetos? (2) • Los objetos son construcciones tanto para el modelado de negocios como para el modelado de software – Los objetos no son sólo una forma de programar 18/01/199 40 Procedimientos Restricciones Datos Nombre: silla Atributos: costo dimensiones peso Operaciones: comprar vender mover
  • 41. ¿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
  • 42. ¿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
  • 43. Los objetos redefinen la modularidad • La frontera del objeto determina su dominio – Separa el interior (el cómo) del exterior (el qué) creando modularidad – Proporciona una interfaz bien definida para otros objetos – Oculta la complejidad de la implementación – Previene los conflictos en la manipulación de atributos causados por procedimientos y reglas redundantes 18/01/199 43 Procedimientos Restricciones Datos Nombre: silla Atributos: costo dimensiones peso Operaciones: comprar vender mover
  • 44. 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
  • 45. 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
  • 46. LA ORIENTACIÓN A OBJETOS CONCEPTOS CLAVE Y TERMINOLOGÍA 18/01/199 46
  • 47. El pensamiento de objetos se basa en tipos (1) • Un tipo o clase describe un conjunto de objetos con las mismas propiedades – El término “tipo” se utiliza en el modelado de negocios – El término “clase” se utiliza en el diseño/programación de software 18/01/199 47 Procedimientos Restricciones Datos Nombre: silla Atributos: costo dimensiones peso Operaciones: comprar vender mover
  • 48. 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: costo dimensiones peso Operaciones: comprar vender mover
  • 49. 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
  • 50. 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: costo dimensiones peso Operaciones: comprar vender mover
  • 51. Los atributos de los tipos • Un atributo representa un responsabilidad para conocer algo • Los atributos pueden ser – Públicos: Se pueden utilizar y visualizar desde fuera de la clase (“+” delante del nombre) – Privados: no se puede acceder al mismo desde otras clases (“-” delante del nombre) – Indefinidos 18/01/199 51 Procedimientos Restricciones Datos Nombre: silla Atributos: +costo +dimensiones -núm. de serie Operaciones: comprar vender mover
  • 52. 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
  • 53. Las instancias almacenan datos (1) • Instancia = un miembro del tipo o clase • Una clase puede tener varias instancias – Las instancias tienen diferentes valores para sus atributos – Los datos se almacenan en las instancias 18/01/199 53 Silla Atributos: +costo +dimensiones -num. de serie Operaciones: +comprar +medir -marcar serie Mi silla: Silla Atributos: +costo: 50.00 +dim:352 -num. serie:12 Operaciones: +comprar +medir -marcar serie Clase Instancia
  • 54. Las instancias almacenan datos (2) • Todas las instancias de una clase – son del mismo tipo – tienen el mismo comportamiento – tienen los mismos atributos 18/01/199 54 Silla Atributos: +costo +dimensiones -num. de serie Operaciones: +comprar +medir -marcar serie Mi silla: Silla Atributos: +costo: 50.00 +dim:352 -num. serie:12 Operaciones: +comprar +medir -marcar serie Clase Instancia
  • 55. 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
  • 56. 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
  • 57. Tipos abstractos (2) • Las tipos abstractos no tienen instancias – Por ejemplo: integer, float, string – Los tipos abstractos se crean para ... • Generalizar características • Facilitar cambios • Crear oportunidades de re-utilización • Eliminar redundancia – Comúnmente los tipos abstractos son supertipos en la jerarquía • Definen propiedades en común para todas las subclases 18/01/199 57
  • 58. Tipos concretos • Tipos concretos pueden tener instancias – Por ejemplo: mobiliario • Los tipos concretos se crean para ... – implementar un tipo de objetos – reflejar diferencias – crear instancias • Comúnmente los tipos concretos son subtipos de uno o mas tipos abstractos. Así – cumplen con las propiedades del supertipo – agregar sus propias propiedades – crear instancias de su tipo 18/01/199 58
  • 59. 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
  • 60. 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
  • 61. 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
  • 62. 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
  • 63. Especialización y generalización (2) • La especialización contiene la diferencia en las propiedades – Hijo es más concreto • Cada especialización sirve para un propósito específico • Se pueden organizar en una jerarquía o superjerarquía 18/01/199 63
  • 64. ¿Qué es jerarquía? (1) • Una estructura de especialización donde el hijo puede tener al menos uno y sólo un padre – La estructura resultante es un árbol • La jerarquía facilita la separación de lo general de lo específico – Las hojas del árbol representan conceptos más especializados que los nodos superiores 18/01/199 64 Cuenta nombre, dirección, estado, balance, fecha de apertura, fecha de cierre ... sacar balance, depositar, pedir préstamo Cuenta de cheques balance, balance mínimo, etc. sacar balance, depositar, pedir préstamo Cuenta de ahorros balance, balance mínimo, tasa de interés, etc. sacar balance, depositar, pedir préstamo
  • 65. ¿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
  • 66. 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
  • 67. 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
  • 68. 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
  • 69. 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
  • 70. 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
  • 71. 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
  • 72. 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
  • 73. 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
  • 74. ¿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
  • 75. LA ORIENTACIÓN A OBJETOS EJEMPLO PRÁCTICO: MODELADO DE UNA EMPRESA 18/01/199 75
  • 76. 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
  • 77. La estructura del departamento • La siguiente figura muestra la estructura de alto nivel del departamento, así como sus interacciones con otros departamentos, en forma de 7 capas • Se muestra cada capa como un objeto, y los enlaces representan el posible paso de mensajes 18/01/199 77 Proveedores externos Departamentos usuarios Departamentos de ingeniería Escritura Gráficos e impresión Agencias externas Contabilidad
  • 78. 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
  • 79. Vistas externa e interna (2) 18/01/199 79 DepartamentosDepartamentos usuarios AgenciasAgencias externas GráficosGráficos e impresión ContabilidadEscritura Vista externa de gráficos e impresión
  • 80. Vistas externa e interna (3) 18/01/199 80 Gráficos Fotocomposición Artista gráfico Creador de fotolitos ... Hacer diapositivas Hacer placas Preparar placas Pedir materiales Despachar resultados Hacer informes de costos Hacer informes de progreso ... Impresión Almacenista Operadores de máquina Maquinaria Almacen de papel Trabajos en curso ... Hacer impresión Hacer reimpresión Hacer informes de progreso Emitir facturas Pedir materiales Hacer informes de costos ... Vista interna de gráficos e impresión
  • 81. Vista del objeto “gráficos” antes de la tecnología 18/01/199 81 Director Clasificar solicitudes Asignar trabajos Informar progresos Fotocompositor Informar de progresos Componer textos Hacer cambios Artista gráfico Hacer diapositivas Hacer placas Hacer ilustracionesEncargado de pegado Pegar Solicitar cambios Hacer informe de progresos Creador de placas Hacer placas Despachar Hacer informe de progresos
  • 82. Vista del objeto “gráficos” después de la tecnología 18/01/199 82 Director Clasificar solicitudes Asignar trabajos Informar progresos Responsable de autoedición Informar de progresos Producción de documentos Artista gráfico Hacer diapositivas Hacer placas Hacer ilustraciones Creador de placas Hacer placas Despachar Hacer informe de progresos
  • 83. 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
  • 84. EL PENSAMIENTO DE OBJETOS MODELOS 18/01/199 84
  • 85. 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
  • 86. 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
  • 87. 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
  • 88. 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
  • 89. 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
  • 90. Modelos múltiples • A menudo es útil construir modelos múltiples para una misma cosa o situación – Estos modelos para una cosa o situación en el mismo nivel de abstracción (nivel de detalle) permite un mejor entendimiento • Específicamente, un modelo puede mostrar algún detalle que otro modelo no muestra o que es incapaz de mostrar – Estos modelos para una cosa o situación en diferentes niveles de abstracción (diferentes niveles de detalle) permiten controlar cuánta información se desea mostrar • Tales modelos permiten revelar progresivamente mas detalle acerca de una cosa o situación como el entendimiento de ellos se incrementa 18/01/199 90
  • 91. 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
  • 92. EL PENSAMIENTO DE OBJETOS MODELOS OO 18/01/199 92
  • 93. 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
  • 94. 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
  • 95. 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
  • 96. 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
  • 97. 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
  • 98. 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
  • 99. 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
  • 100. 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
  • 101. 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
  • 102. Otros modelos OO • Class-Responsability-Collaboration Cards (CRC Cards) es un modelo que no se ajusta a ninguna de las categorías de modelado antes mencionadas • CRC Cards utiliza fichas de cartón como herramienta CASE para documentar diseños OO y también para la enseñanza de los conceptos básicos 18/01/199 102 Clase: nombre de la clase (abstracta o concreta) lista de superclases lista de subclases responsabilidad colaboración
  • 103. EL PENSAMIENTO DE OBJETOS EL MODELADO DE LAS EMPRESAS: LA ARQUITECTURA DE LAS EMPRESAS DE ZACHMAN 18/01/199 103
  • 104. 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
  • 105. 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
  • 106. 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
  • 107. 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
  • 108. 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 Process I/O = Bus Resources List of Locations in which the Business Opeerates Node = Major Business Location e.g. Business Logistics System Node = Business Location Link = Business Linkage e.g. Distributed System Node = I/S Function (Processor, Storage, etc) Link = Line Characteristics e.g. System Architecture Node = Hardware/Systems Software Link = Line Specifications e.g. Network Architecture Node = Address Link = Protocol e.g. NETWORK Architecture Planner Builder Designer Sub- Contractor Owner What How Where MODEL (PHYSICAL) (OUT-OF- CONTEXT) (CONTEXTUAL) (CONCEPTUAL)
  • 109. 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
  • 110. 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-condition Means = Step e.g. STRATEGY e.g. Rule Design End = Condition Means = Action e.g. Business Rule Model End = Structural Assertion Means = Action Assertion e.g. Business Plan End = Business Objective Means = Business Strategy List of Business Goals/ Strategies Ends/Means = Major Business Goals/Critical Success Factors List of Events Significant Time = Major Business Event e.g. Processing Structure Cycle = Processing Cycle Time = System Event e.g. Control Structure Cycle = Component Cycle Time = Execute e.g. Timing Definition Cycle = Machine Cycle Time = Interrupt e.g. SCHEDULE e.g. Master Schedule Time = Business Event Cycle = Business Cycle List of Organizations People = Major Organizations People = Organization Unit Work = Work Product e.g. Human Interface People = Role Work = Deliverable e.g. Presentation Architecture People = User Work = Screen Format e.g. Security Architecture People = Identity Work = Job e.g. ORGANIZATION Architecture Planner Owner to the BusinessImportant to the Business E1 E1.1 E2 A1 E1.2 E1.3 E1 E1.1 E2 A1 E1.2 E1.3 E1 E1.1 E2 A1 E1.2 E1.3 e.g. Work Flow Model (LOGICAL) (CONCEPTUAL) (PHYSICAL) TECHNOLOGY MODEL
  • 111. 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
  • 112. 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
  • 113. 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
  • 114. 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
  • 115. 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
  • 116. The Zachman framework 18/01/199 116 e.g.DATA ENTERPRISEARCHITECTURE-AFRAMEWORK Builder SCOPE (CONTEXTUAL) MODEL (CONCEPTUAL) ENTERPRISE Designer SYSTEM MODEL (LOGICAL) TECHNOLOGY MODEL (PHYSICAL) DETAILED REPRESEN- TATIONS (OUT-OF- CONTEXT) Sub- Contractor FUNCTIONING ENTERPRISE DATA FUNCTION NETWORK e.g.DataDefinition Ent=Field Reln=Address e.g.PhysicalDataModel Ent=Segment/Table/etc. Reln=Pointer/Key/etc. e.g.LogicalDataModel Ent=DataEntity Reln=DataRelationship e.g.SemanticModel Ent=BusinessEntity Reln=BusinessRelationship ListofThingsImportant totheBusiness ENTITY=Classof BusinessThing ListofProcessesthe BusinessPerforms Function=Classof BusinessProcess e.g."ApplicationArchitecture" I/O=UserViews Proc.=ApplicationFunction e.g."SystemDesign" I/O=Screen/DeviceFormats Proc.=ComputerFunction e.g."Program" I/O=ControlBlock Proc.=LanguageStmt e.g.FUNCTION e.g.BusinessProcessModel Proc.=BusinessProcess I/O=BusinessResources ListofLocationsinwhich theBusinessOperates Node=MajorBusiness Location e.g.LogisticsNetwork Node=BusinessLocation Link=BusinessLinkage e.g."DistributedSystem Node=I/SFunction (Processor,Storage,etc) Link=LineCharacteristics e.g."SystemArchitecture" Node=Hardware/System Software Link=LineSpecifications e.g."NetworkArchitecture" Node=Addresses Link=Protocols e.g.NETWORK Architecture" Planner Owner Builder ENTERPRISE MODEL (CONCEPTUAL) Designer SYSTEM MODEL (LOGICAL) TECHNOLOGY CONSTRAINED MODEL (PHYSICAL) DETAILED REPRESEN- TATIONS (OUT-OF CONTEXT) Sub- Contractor FUNCTIONING MOTIVATIONTIMEPEOPLE e.g.RuleSpecification End=Sub-condition Means=Step e.g.RuleDesign End=Condition Means=Action e.g.,BusinessRuleModel End=StructuralAssertion Means=ActionAssertion End=BusinessObjective Means=BusinessStrategy ListofBusinessGoals/Strat Ends/Means=MajorBus.Goal/ CriticalSuccessFactor ListofEventsSignificant Time=MajorBusinessEvent e.g.ProcessingStructure Cycle=ProcessingCycle Time=SystemEvent e.g.ControlStructure Cycle=ComponentCycle Time=Execute e.g.TimingDefinition Cycle=MachineCycle Time=Interrupt e.g.SCHEDULE e.g.MasterSchedule Time=BusinessEvent Cycle=BusinessCycle ListofOrganizations People=MajorOrganizations e.g.WorkFlowModel People=OrganizationUnit Work=WorkProduct e.g.HumanInterface People=Role Work=Deliverable e.g.PresentationArchitecture People=User Work=ScreenFormat e.g.SecurityArchitecture People=Identity Work=Job e.g.ORGANIZATION Planner Owner totheBusinessImportanttotheBusiness What How Where Who When Why Copyright-JohnA.Zachman,ZachmanInternational SCOPE (CONTEXTUAL) Architecture e.g.STRATEGY ENTERPRISE e.g.BusinessPlan TM ZachmanInstituteforFrameworkAdvancement-(810)231-0531
  • 117. EL PENSAMIENTO DE OBJETOS ALEJANDRO DOMÍNGUEZ 18/01/199 117
  • 118. EL PENSAMIENTO DE OBJETOS CATEGORIZANDO A LOS OBJETOS 18/01/199 118
  • 119. 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
  • 120. Taxonomía de los objetos (2) 18/01/199 120 ObjetosObjetos Objetos baseObjetos baseObjetos deObjetos de negocios Objetos deObjetos de servicios de aplicación
  • 121. 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
  • 122. 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
  • 123. 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
  • 124. 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
  • 125. EL PENSAMIENTO DE OBJETOS EL PENSAMIENTO DE OBJETOS EFECTIVO 18/01/199 125
  • 126. 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
  • 127. 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
  • 128. 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
  • 129. 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
  • 130. 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
  • 131. 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
  • 132. 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
  • 133. EL CASO DE NEGOCIOS 18/01/199 133 OBJETOS DE NEGOCIOS
  • 134. La información es estratégica • Los sistemas de información (SI) han evolucionado de ser simples herramientas a ser una parte integral de los procesos de negocios • Un SI efectivo es un arma estratégica para las organizaciones • SI efectivos y flexibles se traducen en ganancias directas y de supervivencia corporativa 18/01/199 134 La información es estratégica
  • 135. 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
  • 136. 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
  • 137. OBJETOS DE NEGOCIOS PROBLEMAS DE LOS SI Y LA TECNOLOGÍA DE OBJETOS 18/01/199 137
  • 138. Los objetos y las empresas 18/01/199 138 ¿Qué dijo? Encapsulamiento Polimorfismo Interfaz Comportamiento ¡Los objetos no son útiles en las empresas!
  • 139. 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
  • 140. 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
  • 141. Objetos y negocios • Personas • Compañías • Interacción • Relaciones • Dependencias • Políticas • Procesos • Transacciones 18/01/199 141 Objetos Cooperativos Marcos de trabajo cooperativos de objetos resuelven los problemas de negocios
  • 142. Negocios y objetos De igual forma que los grupos cooperativos de personas resuelven los problemas de negocios 18/01/199 142
  • 143. 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
  • 144. 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...
  • 145. 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
  • 146. 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
  • 147. OBJETOS DE NEGOCIOS DEFINICIÓN DE LOS BO’s 18/01/199 147
  • 148. 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
  • 149. 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
  • 150. 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
  • 151. ¿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
  • 152. ¿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
  • 153. 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
  • 154. 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
  • 155. 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
  • 156. 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
  • 157. 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
  • 158. 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
  • 159. 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
  • 160. 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
  • 161. 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
  • 162. 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 sistemas BO’sBO’s
  • 163. 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
  • 164. 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 BO BO
  • 165. El enfoque “top half down” 18/01/199 165
  • 166. Taxonomía para la abstracción • Abstracciones de negocios (mitad superior) – Genérica – Específica a la compañía • Abstracciones de software (mitad inferior) – Diseño – Implementación 18/01/199 166 Abstracciones Abstracciones Abstracciones de negocios Abstracciones de software
  • 167. 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
  • 168. 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
  • 169. 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
  • 170. OBJETOS DE NEGOCIOS TAXONOMÍA DE LOS BO’s 18/01/199 170
  • 171. 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
  • 172. 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
  • 173. 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
  • 174. 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
  • 175. Objetos de entidades de negocios comunes • Clientes • Requisiciones • Productos • Contratos • Equipos • Capacidades • Direcciones • Vehículos • Facilidades • Proveedores 18/01/199 175
  • 176. 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
  • 177. 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
  • 178. 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
  • 179. 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
  • 180. 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
  • 181. 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
  • 182. 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
  • 183. 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
  • 184. 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
  • 185. 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
  • 186. 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
  • 187. OBJETOS DE NEGOCIOS APLICACIONES DE LOS BO’s 18/01/199 187
  • 188. Ejemplo de objetos de entidades de negocios 18/01/199 188 Vuelo Código del portador Número de vuelo Establecer itinerario Cancelar Portador Nombre de aerolínea Código del portador Certificar No-certificar Asiento del segmento de vuelo Código del portador Número de vuelo Código IATA del aeropuerto origen Código IATA del aeropuerto destino Número de fila Disponer Asignar No-asignar Ocupar Segmento de vuelo Código del portador Número de vuelo Código IATA del aeropuerto origen Código IATA del aeropuerto destino Hora de partida Hora de llegada Partir Llegar Aeropuerto Nombre del aeropuerto Código del portador Cerrar por clima Opera Transporta Expande Origina Termina
  • 189. Ejemplo de objetos de procesos de negocios 18/01/199 189 Interacciones entre objetos de entidades de negocios que incluyen los pasos efectuados por objetos de procesos de negocios Pasajero Mostrar número de viajero frecuente Seleccionar preferencia de asiento Agente de reservaciones Asentar reservación Reservar boleto Asiento de segmento de vuelo Disponer Asignar No-asignar Ocupar Reservación Asentar Etiquetar Cancelar Asentar reservación Reservar boleto Seleccionar preferencia de asiento Seleccionar preferencia de asiento Disponer Asignar Reservar Etiquetar
  • 190. OBJETOS DE NEGOCIÓN LA ARQUITECTURA DE ZACHMAN Y LOS BO’s 18/01/199 190
  • 191. 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)
  • 192. Mapeo de los niveles de abstracción a la arquitectura de Zachman 18/01/199 192 WHAT (data) WHERE (location) HOW (process) WHO (organization) WHEN (schedule) WHY (motive) SCOPE (planner) ENTERPRISE (owner) SYSTEM (designer) TECHNOLOGY (builder) COMPONENTS (sub-contractor) GENÉRICO ESP. DE LA EMPRESA DISEÑO EXTERNO DISEÑO INTERNO IMPLEMEN- TACIÓN
  • 193. APLICACIONES DE LOS BO’s DE SISTEMAS EL MODELO DE NEGOCIOS: DISEÑOS EJECUTABLES 18/01/199 193
  • 194. 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
  • 195. Ejemplo sencillo de modelo 18/01/199 195 Los actores, procesos y entidades de negocios definen el modelo de negocios Llamada de ventaLlamada de venta OrdenOrdenProductoProducto Para Produce
  • 196. 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
  • 197. 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
  • 198. 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
  • 199. 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
  • 200. APLICACIONES DE LOS BO’s DE SISTEMAS CLIENTE/SERVIDOR Y LOS BO’s 18/01/199 200
  • 201. 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
  • 202. 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í
  • 203. APLICACIONES DE LOS BO’s DE SISTEMAS APLICACIONES HEREDADAS Y LOS BO’s 18/01/199 203
  • 204. Los BO’s “incorporan” las aplicaciones heredadas y datos • Los objetos de negocio se definen en términos de su interfaz; su implementación puede utilizar aplicaciones existentes – Pueden “llamar” una aplicación existente – Pueden utilizar un “raspador de pantallas” • Los nuevos sistemas basados en BO’s se pueden construir utilizando un DBMS existente 18/01/199 204
  • 205. “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
  • 206. APLICACIONES DE LOS BO’s DE SISTEMAS INTERNET Y LOS BO’s 18/01/199 206
  • 207. 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
  • 208. BO’s en diferentes empresas interoperan a través de Internet 18/01/199 208 El Este importaEl Oeste exporta
  • 209. Internet integra gente, empresas y BO’s en todo el mundo 18/01/199 209
  • 210. Internet browsers como clientes de los BO’s 18/01/199 210 Internet Browser Clients Browser Clients Browser Clients Web Servers Web Servers Business Objects Business Objects Business Objects
  • 211. 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
  • 212. APLICACIONES DE LOS BO’s DE SISTEMAS RESOLVIENDO LOS PROBLEMAS CON LOS BO’s 18/01/199 212
  • 213. Los BO’s y sistemas inflexibles • Problema – Sistemas inflexibles no cambian acorde a las necesidades de negocios • Respuesta El modelado de objetos y la implementación permiten a las componentes de negocios integrarse y utilizarse de diferentes formas. Los cambios son sólo sobre un número pequeño de objetos Cada BO y cada cliente es un “programa” separado, el impacto en los cambios se minimiza 18/01/199 213
  • 214. 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
  • 215. Los BO’s y unidades de negocio • Problema – Dificultad para integrar aplicaciones y unidades de negocio • Respuesta El modelo de BO’s de la OMG opera dentro de marco estándar que facilita la integración de la tecnología y las unidades de negocio Los BO’s se convierten en componentes de escritorio 18/01/199 215
  • 216. Los BO’s y ambientes propietarios • Problema – Ambientes cerrados y propietarios • Respuesta Aplicación de los estándares de BO’s de la OMG Los BO’s están abiertos para utilizar cualquier DBMS o las aplicaciones existentes para la implementación Los BO’s se pueden utilizar por cualquier aplicación o programas de escritorio a través de interfaces estándar 18/01/199 216
  • 217. 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
  • 218. 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
  • 219. Los BO’s y su costo de construcción • Problema – Los SI’s son caros y difíciles de construir y mantener • Respuesta Los BO’s son componentes reutilizables que reducen los esfuerzos de desarrollo y mantenimiento, proporcionando un SI con mas estructura y menos complejo El despliegue de los clientes a través de Internet reduce el mantenimiento 18/01/199 219
  • 220. Los BO’s y escalabilidad • Problema – Los SI’s no son “escalables” cuando los negocios crecen • Respuesta La computación distribuida permite agregar hardware acorde a los requerimientos de crecimiento Sistemas avanzados de replicación y distribución se pueden emplear “tras bambalinas” para escalar al sistema 18/01/199 220
  • 221. Los BO’s y su dificultad • Problema – ¡Esto es demasiado difícil! • Respuesta Las herramientas y marcos de trabajo basadas en estándares reducen el 90% el tiempo de construcción y utilización de BO’s Los BO’s configurables se pueden “conectar” por usuarios potenciales y utilizarse en las aplicaciones de escritorio 18/01/199 221
  • 222. APLICACIONES DE LOS BO’s DE SISTEMAS ¡LAS BUENAS NOTICIAS!: LOS BO’s SON REALES 18/01/199 222
  • 223. 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!
  • 224. 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
  • 225. OBJETOS DE SERVICIOS DE APLICACIONES ALEJANDRO DOMÍNGUEZ 18/01/199 225
  • 226. 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
  • 227. 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
  • 228. 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
  • 229. 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
  • 230. 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
  • 231. ¿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
  • 232. ¿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
  • 233. ¿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
  • 234. ¿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

×