Metodologias[1]
Upcoming SlideShare
Loading in...5
×
 

Metodologias[1]

on

  • 1,875 views

 

Statistics

Views

Total Views
1,875
Views on SlideShare
1,875
Embed Views
0

Actions

Likes
1
Downloads
104
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Metodologias[1] Metodologias[1] Document Transcript

  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto 3º I. T. INFORMÁTICA DE GESTIÓN PROGRAMACIÓN AVANZADA IGNACIO CRUZADO NUÑO JORGE GARCÍA DEL EGIDO JAVIER PORTUGAL ALONSO Pág. 1.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto RESUMEN ................................................................................................................................................. 4 PALABRAS CLAVE ................................................................................................................................... 4METODOLOGÍAS ORIENTADAS A OBJETOS. ................................................................................ 5 INTRODUCCIÓN ........................................................................................................................................ 5 Concepto de metodología................................................................................................................... 5 Generalidades .................................................................................................................................... 6 Clasificaciones ................................................................................................................................... 6 EL MÉTODO DE BOOCH .......................................................................................................................... 8 Introducción. ...................................................................................................................................... 8 La complejidad................................................................................................................................... 8 El modelo del objeto........................................................................................................................... 9 Elementos del modelo de objetos ...................................................................................................................9 Clases y objetos................................................................................................................................ 11 La naturaleza de un objeto ............................................................................................................................11 Relaciones entre los objetos..........................................................................................................................12 La naturaleza de una clase ............................................................................................................................13 Relaciones entre las clases............................................................................................................................13 La interacción de Clases y objetos................................................................................................................14 Construcción de Clases y Objetos de Calidad...............................................................................................14 Clasificación .................................................................................................................................... 15 Aproximación a las clasificaciones...............................................................................................................15 Procedimientos para encontrar clases y objetos............................................................................................15 El método ......................................................................................................................................... 16 Diagramas de clases......................................................................................................................................17 Diagramas de objetos....................................................................................................................................21 Otros diagramas............................................................................................................................................23 Los procesos del desarrollo orientado al objeto ............................................................................................26 Conclusión........................................................................................................................................ 26 Un ejemplo concreto ........................................................................................................................ 26 OMT (OBJECT MODELING TECNIQUE) JAMES RAMBAUGH ................................................................... 28 Visión general .................................................................................................................................. 28 Fases (4)........................................................................................................................................... 28 Pasos específicos a dar en cada fase ............................................................................................... 29 Fase De Análisis ...........................................................................................................................................29 Fase De Diseño Del Sistema.........................................................................................................................30 Fase de Diseño De Objetos...........................................................................................................................30 Implementación ............................................................................................................................................31 Conclusión........................................................................................................................................ 31 Notación ........................................................................................................................................... 31 MÉTODO DE FUSION. COLEMAN ............................................................................................................ 33 Introducción ..................................................................................................................................... 33 Análisis............................................................................................................................................. 33 Modelo de objetos ........................................................................................................................................34 Modelo de Objetos del sistema .....................................................................................................................36 Modelo de la Interface ..................................................................................................................................36 Modelo del Funcionamiento .........................................................................................................................36 Modelo del Ciclo de Vida.............................................................................................................................37 Proceso de Análisis .......................................................................................................................... 38 Diccionario de datos .....................................................................................................................................38 Desarrollo del Modelo de Objetos ................................................................................................................39 Determinación de la Interface del Sistema....................................................................................................39 Desarrollo del Modelo de la Interface...........................................................................................................41 Verificando los Modelos del Análisis...........................................................................................................41 Diseño .............................................................................................................................................. 42 Gráfico de Interacción de Objetos ................................................................................................................43 Gráficos de visibilidad..................................................................................................................................47 Descripciones de clase..................................................................................................................................50 Gráficos de herencia .....................................................................................................................................52 Implementación ................................................................................................................................ 55 Pág. 2.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Gestión de un Desarrollo Fusion ..................................................................................................... 55 SMM (SHLAER & MELLOR METHOD) ................................................................................................... 56 Características ................................................................................................................................. 56 Proceso............................................................................................................................................. 56 Principales assets generados ........................................................................................................... 57 EROOS: (ESPECIFICACIONES ORIENTADAS A OBJETO E-R) ................................................................. 58 Introducción ..................................................................................................................................... 58 Características ................................................................................................................................. 58 Ciclo de Vida.................................................................................................................................... 58 Filosofía y Conceptos Contemplados............................................................................................... 59 Notación ........................................................................................................................................... 60 METODOLOGÍA MOSES ........................................................................................................................ 64 Introducción ..................................................................................................................................... 64 Modelo Fuente ................................................................................................................................. 64 Ciclo de vida del producto ............................................................................................................... 66 Assets generados .............................................................................................................................. 66 Proceso de Ciclo de Vida (“las 20 actividades”) ............................................................................ 67 BON ...................................................................................................................................................... 71 Principios fundamentales................................................................................................................. 71 Proceso de Análisis .......................................................................................................................... 72 Proceso de diseño............................................................................................................................. 72 LA UNIFICACIÓN DE MÉTODOS .............................................................................................................. 76 UML (Unified Modelating Languaje) .............................................................................................. 76 OPEN. .............................................................................................................................................. 76 CONCLUSIÓN ......................................................................................................................................... 79 BIBLIOGRAFÍA ....................................................................................................................................... 81 Pág. 3.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoResumenEn el mundo de desarrollo de software, se tiende cada vez más hacia la programaciónorientada a objeto, un nuevo paradigma de programación que aporta grandes ventajas alsoftware generado, como son el acercamiento entre el concepto del usuario y elresultado programado o la disponibilidad a la reutilización del código generado.Pero todo ello no es posible sin seguir una metodología que, por medio delestablecimiento de pasos, normas y conceptos a aplicar, lleve el desarrollo a buenpuerto, y con un resultado óptimo.En este documento se pretende acercar al lector a las metodologías orientadas a objetoque existen en la actualidad y dar una visión global de las mismas. Así pues se haceespecial hincapié en OMT (la más difundida actualmente), BOOCH (como punto departida de los conceptos que conlleva la orientación a objeto) y FUSION (como unametodología más desarrollada).No pasa inadvertido que el futuro de las metodologías se basa en su unificación, y porello este documento explica brevemente UML (como notación unificadora) y OPEN(como metodología). En cualquier caso habrá que esperar a la publicación deOBJETORY, que se perfila como la metodología unificadora y de más futuro.Palabras ClaveMetodología, orientación a objeto, ciclo de vida, notación, proceso, Booch, OMT,Fusion, UML, OPEN, MOSES, EROOS, OOSE, BON, unificación, clase, objeto,análisis, diseño. Pág. 4.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Metodologías orientadas a objetos.IntroducciónCon este trabajo se pretende acercar un poco más al lector al mundo de las metodologíasorientadas a objeto. Es un mundo en contínua expansión.Se tratará de ofrecer una idea global de las metodologías orintadas a objeto yprofundizar algo más en las más conocidas:• Booch, como punto de partida de los conceptos de la orientación a objetos.• OMT, como la metodología más difundida en los desarrollos realizados actualmente.• Fusion, como ejemplo de metodología proveniente de otros métodos (2ª generación).Hoy en día se está trabajando en buscar una unificación de métodos. En esta línea se hallegado a una unificación en la notación (UML). No se explicará muy detalladamentepues merecería un artículo aparte.Concepto de metodologíaNo existe un consenso entre los diversos autores sobre el concepto de metodología.Genéricamente se puede decir que una metodología es un conjunto de pasos quedeben seguirse para el desarrollo de software.Conjunto de filosofías, fases, procedimientos, reglas, técnicas, herramientas,documentación y aspectos de formación para los desarrolladores de sistemas deinformación. Según esto, una metodología es un conjunto de componentes queespecifican: Cómo dividir un proyecto en etapas. Qué tareas se llevarán a cabo en cada etapa Qué salidas se producen y cuándo deben producirse. Qué restricciones se aplican. Qué herramientas van a ser utilizadas. Cómo se gestiona y controla el proyecto. R.N. MaddisonDe un modo más general una metodología podría definirse como “un conjunto deconceptos para poder abstraer el dominio del problema, una notación para representaresos conceptos, una serie de pasos y procedimientos a seguir, y un conjunto de assetsgenerados”. Pág. 5.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoGeneralidadesTodas las metodologías distinguen estas tres fases: Análisis Diseño ImplementaciónSegún Piattini [Piattini et al., 1996], se puede observar un cambio “filosófico” entre lasmetodologías clásicas de análisis y diseño estructurado y las de orientación al objeto. Enlas primeras se examinan los sistemas desde el punto de vista de las funciones o tareasque deben realizar, tareas que se van descomponiendo sucesivamente en otras tareasmás pequeñas y que forman los bloques o módulos de las aplicaciones. En laorientación al objeto, por su parte, cobra mucha más importancia el aspecto de“modelado” del sistema, examinando el dominio del problema como un conjunto deobjetos que interactúan entre sí.En las metodologías tradicionales se produce una dicotomía entre los dos elementosconstituyentes de un sistema: funciones que llevan a cabo los programas y datos que sealmacenan en ficheros o bases de datos. Sin embargo, la orientación al objeto propugnaun enfoque unificador de ambos aspectos, que se encapsulan en los objetos.ClasificacionesSe pueden identificar dos enfoques en las metodologías orientadas al objeto, [Fichman yKemerer, 1992]:• “Revolucionarias” o “puras”, que extienden la orientación al objeto como un cambio profundo que convierte a las metodologías estructuradas en obsoletas. En este apartado podrían incluirse metodologías como OOD de [Booch, 1991] o CRC/RDD de [Wirfs-Brock et al., 1990].• “Sintetistas” o “evolutivas”, que piensan que el análisis y diseño estructurados constituyen la base para el desarrollo orientado al objeto, pudiéndose combinar elementos del análisis y diseño estructurados con los de la orientación al objeto. Ejemplos de este tipo podrían ser OMT [Rumbaugh et al., 1991], SYNTHESIS [Bailin, 1989] o [Martin y Odell, 1992].Últimamente están apareciendo nuevas metodologías de desarrollo orientado al objeto,catalogadas como de “segunda generación”, basadas en las citadas anteriormente; de lasque formarían parte [Singer, 1993], FUSION propuesta por [Coleman et al., 1994],OOA/D de [Booch, 1994], MOSES de [Henderson-Sellers y Edwards, 1994],SYNTROPY de [Cook y Daniels, 1994], MÉTODO UNIFICADO [Booch yRumbaugh, 1995] o MEDEA [Piattini, 1994]. En esta segunda generación seaprovechan las técnicas y los procedimientos de las primeras metodologías,especialmente las tarjetas de clase (CRCs), el proceso y notación de diseño de [Booch,1991], el modelo de clases de OMT y los escenarios de Jacobson, con el fin de construirmetodologías más completas y sistemáticas en las que juegan también un papelrelevante las métricas y los lenguajes formales, así como modelos para la mejora delsoftware, como los del SEI (CMM) o ISO (SPICE). Pág. 6.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoOtra posible clasificación, en función de en qué se centran, es: • Metodologías dirigidas por los datos (data-driven) - OMT (Rumbaugh et al. 1991) - FUSION (Coleman et al. 1994) • Metodologías dirigidas por las responsabilidades (responsability-driven) - RDD (Wirfs-Brock et al. 1990) - OBA (Rubin y Goldberg 1992) • Metodologías dirigidas por los casos de uso (use case-driven) - OOSE (Jacobson et al. 1992) • Metodologías dirigidas por estados (state-driven) - Metodología de Shlaer y Mellor 1992) Pág. 7.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoEl método de BOOCHIntroducción.El método de Grady Booch es uno de los más conocidos en la orientación al objeto.En su versión de 1.993 este método cubre las fases de análisis y diseño dentro de undesarrollo orientado al objeto.Se definirán una gran cantidad de símbolos para representar las distintas decisiones dediseño.Este método ofrece una gran libertad en la producción del software, como ya veremosmás adelante.En un primer momento se explicarán una serie de conceptos básicos, los cuales han dequedar claros para poder comprender a fondo la metodología de Booch.Dichos conceptos se pueden estructurar estructurarlos de la siguiente manera: Complejidad. El modelo del objeto. Clases y objetos. Clasificación.La complejidadEl software, por lo general, va a ser un sistema “complejo”, sobre todo cuando se tratede un software “grande”. Esto es debido a 4 elementos: La complejidad del dominio del problema. (Definición de los requisitos, modificaciones que pueden ir sufriendo éstos...) La dificultad de gestionar el proceso de desarrollo. (Sobre todo en proyectos muy grandes.) La flexibilidad que posibilita el software. Los problemas del comportamiento de sistemas discretos.Para tratar un sistema complejo se pueden utilizar las siguientes técnicas:Descomposición: consiste en dividir el sistema en partes más y más pequeñas cada vez,pudiendo ser éstas refinadas independientemente.Abstracción: la abstracción denota las características esenciales de un objeto que lodistinguen de todos los demás tipos de objetos y proporciona así fronteras conceptualesnítidamente definidas respecto a la perspectiva del observador.Jerarquía: para Booch la jerarquía es “una clasificación u ordenación de abstracciones”.Existen dos clases de jerarquía: Pág. 8.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto jerarquía “parte de” (part of) o “tiene un” (has a): corresponde a la estructura del objeto. jerarquía “es un” (is a): corresponde a la estructura de la clase.El modelo del objetoLa programación orientada a objetos es un método en el que los programas se organizancomo una colección de objetos, representando cada uno una instancia de alguna clase,estando relacionadas todas las clases mediante una jerarquía.Un programa que no tenga bien claros estos 3 elementos (que se tengan objetos en lugarde algoritmos, que cada objeto sea instancia de alguna clase, y que entre las clasesexista una relación de herencia que de lugar a una jerarquía) no puede considerarse“orientado a objetos”. Booch lo llama “programación con tipos de datos abstractos”.Se estudiarán las fases de “análisis” y “diseño” en la orientación al objeto. El análisis serealizará a partir del dominio inicial del problema. A continuación vendrá el diseño.Elementos del modelo de objetosHay 4 elementos básicos que constituyen dicho modelo: Abstracción. Encapsulamiento. Modularidad. Jerarquía.Hay otros elementos (no principales) que son los siguientes: Tipos. Concurrencia. Persistencia.La abstracción.“La abstracción denota las características esenciales de un objeto que lo distinguen detodos los demás tipos de objetos y proporciona así fronteras conceptuales nítidamentedefinidas respecto a la perspectiva del observador.”Existen varios tipos de abstracción:Abstracción de entidad: un objeto que representa un modelo útil del problema dedominio de la entidad.Abstracción de acción: un objeto proporciona un conjunto generalizado de operacionespara una determinada función.Abstracción de la máquina virtual: un objeto que agrupa funcionamientos que sonutilizados por niveles superiores de control, y por conjuntos de operaciones de nivelesinferiores.Abstracción coincidental: un objeto que agrupa un conjunto de operaciones que no estánrelacionadas con ninguna otra.El encapsulamiento. Pág. 9.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto“Es el proceso de almacenar en un mismo compartimento los elementos de unaabstracción que constituyen su estructura y su comportamiento; sirve para separar lainterfaz contractual de una abstracción y su implantación”. (El encapsulamiento ocultalos detalles de la implementación de un objeto).La modularidad.Cuando se habla de modularidad hay que imaginarse la fragmentación de un programaen componentes individuales para reducir la complejidad. Booch define modularidadcomo “la propiedad que tiene un sistema que ha sido descompuesto en un conjunto demódulos cohesivos y débilmente acoplados”.Existen varias técnicas para poder obtener una modularidad correcta o inteligente ennuestras clases y objetos: La reducción de los costes del software viene apoyada por la descomposición en módulos, ya que éstos pueden diseñarse y revisarse independientemente. La estructura de cada modulo debe ser lo suficientemente simple como para que pueda entenderse completamente. Debe ser posible modificar la implementación de un módulo sin tener conocimiento de la implementación de otros módulos, y sin que se afecte al comportamiento de otros módulos. La facilidad de realizar un cambio en el diseño debería estar relacionada con la necesidad de ese cambio.La identificación de clases y objetos se corresponde con el diseño lógico del sistema. Laidentificación de módulos es parte del diseño físico del sistema. No se pueden tomartodas las decisiones “físicas” antes que las “lógicas” o viceversa. Más bien, se suelen irtomando a la vez.La jerarquía.Para Booch la jerarquía es “una clasificación u ordenación de abstracciones”. Las 2jerarquías más importantes en un sistema complejo son la estructura de la clase (es un) yla estructura del objeto (parte de) o (tiene un).La herencia es el ejemplo más importante de jerarquía (es un), ya que va a definir lasrelaciones entre clases, tanto en el caso de herencia simple como en el caso de herenciamúltiple.Cuando se habla de jerarquía (es un) normalmente se refiriere a generalización /especialización. Sin embargo (parte de) es más bien un caso de agregación. Lacombinación de la herencia y la agregación puede ser muy potente: la agregaciónpermite el agrupamiento físico de las estructuras lógicas, y la jerarquía permite a estosgrupos su funcionamiento en diferentes niveles de abstracción.Los tipos.Son la puesta en vigor de la clase de los objetos, de modo que los objetos de tiposdistintos no pueden intercambiarse o, como mucho, pueden intercambiarse sólo deformas muy restringidas.Existen varias comprobaciones de tipos: Pág. 10.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoComprobación estricta: un objeto sólo pude realizar aquellas operaciones que seencuentran definidas en la clase o en la superclase del objeto. Se comprueba en tiempode compilación.Comprobación débil: un cliente puede mandar un mensaje a cualquier clase. No sedetectará hasta el momento de la ejecución.La comprobación estricta de tipos toma especial relevancia en las decisiones de diseñocuando la complejidad de nuestro sistema aumenta considerablemente.Estos conceptos se hallan relacionados con los de “ligadura estática” y “ligaduradinámica”; ésta última constituye la base del polimorfismo.La concurrencia.Se produce cuando se tienen varios procesos que se ejecutan a la vez en un sistema. Enla programación orientada a objetos la concurrencia permitirá a diferentes objetos actuarsimultáneamente. Booch define concurrencia como: “la propiedad que distingue unobjeto activo de uno que no está activo”.La persistencia.Es la propiedad de un objeto por la que su existencia transciende el tiempo (es decir, elobjeto continúa existiendo después de que su creador deja de existir) y /o el espacio (esdecir, la posición del objeto varía con respecto al espacio de direcciones en el que fuecreado). Dicho de otra manera, la persistencia conserva el estado de un objeto en eltiempo y en el espacio.El espectro de persistencia abarcará lo siguiente: Resultados transitorios en la evaluación de expresiones. Variables locales en la activación de procedimientos. Variables globales y elementos del heap cuya duración difiere de su ámbito. Datos que existen entre ejecuciones de un programa. Datos que existen entre varias versiones de un programa. Datos que sobrevienen al programa.Clases y objetosLa naturaleza de un objeto“Un objeto tiene estado, comportamiento e identidad; la estructura y el comportamientode objetos similares están definidos en su clase común; los términos instancia y objetoson intercambiables”.Se explican a continuación cada una de las partes de esta definición: Un objeto tiene estado: el estado de un objeto abarca todas las propiedades (normalmente estáticas) del mismo más los valores actuales (normalmente dinámicos) de cada una de esas propiedades. Pág. 11.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Un objeto tiene comportamiento: el comportamiento de un objeto es cómo actúa y se relaciona, en función de sus cambios de estado y paso de mensajes. El estado del objeto representará los resultados acumulados de su comportamiento. Por ejemplo, un cliente puede realizar una serie de operaciones sobre un objeto: modificar (alterar el estado del objeto), seleccionar (acceder al estado de un objeto sin alterarlo), iterar (acceder a todas las partes de un objeto en algún orden establecido), construir (crear un objeto e iniciar su estado) y destruir (liberar el estado del objeto y destruir el objeto). Un objeto tiene identidad: “la identidad será aquella propiedad que lo distingue de todos los demás objetos”. No es conveniente que la identificación la llevan a cabo los nombre de las entidades, ya que: una entidad puede no tener un nombre único y sin embargo ser identificable, puede tener más de un nombre único, puede cambiar de nombre a lo largo del tiempo...Las responsabilidades de un objeto son todos los servicios que proporciona a quien serelacione con él.Pero hay que constatar que un objeto puede tener diferentes roles o papeles, que han dedefinirse en la fase de diseño.Igualdad de objetos: cuando hablamos de igualdad puede significar que dos nombresdesignan el mismo objeto, o que dos nombres designan objetos distintos cuyos estadosson iguales.Se puede considerar que en un “ciclo de vida” habrá un primer momento de“declaración” del objeto y luego vendrá la “asignación” o instanciación del mismo.Relaciones entre los objetosLos objetos se relacionan unos con otros para colaborar entre sí y con el sistema.Existen 2 tipos de relaciones: enlaces y agregaciones.Enlaces.Un enlace es una conexión física o conceptual entre objetos. A través del enlace unobjeto cliente puede solicitar servicios a un objeto proveedor, bien directamente o bien através de enlaces con otros objetos.Un objeto puede desempeñar cualquiera de estos 3 papeles: Actor: cuando puede operar sobre otros objetos pero ningún objeto opera sobre él. Servidor: otros objetos actúan sobre él mientras que él no hace peticiones al resto. Agente: puede operar sobre otros y también otros objetos pueden operar sobre él.Agregaciones.Si los enlaces denotan una relación cliente - servidor, la agregación denotará unajerarquía de partes de un todo. Esas partes pueden ser físicas (Ej. partes de un avión) ono físicas (Ej. acciones de un accionista).La agregación a veces es mejor, porque encapsula partes como secretos de un todo. Losenlaces son óptimos en algunas ocasiones ya que permiten un acoplamiento más débilentre los objetos. Pág. 12.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoLa naturaleza de una claseBooch define clase como “un juego de objetos que comparten una estructura común yun comportamiento común”. La clase es un medio necesario pero no suficiente para ladescomposición.La interfaz de una clase suministra su vista externa y recalca la abstracción, mientrasque oculta su estructura y los secretos de su comportamiento.Dicha interfaz puede estar dividida en 3 partes: Pública: una declaración que es accesible a todos los clientes. Protegida: una declaración que es accesible a la clase, a las subclases y a las clases amigas. Privada: una declaración que a la que sólo acceden la propia clase y las clases amigas.Relaciones entre las clasesHay 3 tipos básicos de relaciones: Generalización / especialización. Todo / partes. Asociación.Dichas relaciones pueden obtenerse como combinación de algunas de estas otras:asociación, herencia, agregación, uso, instanciación, metaclases...La asociación.Una asociación describe un grupo de enlaces con una estructura y una semántica encomún.La herencia.La herencia, para Booch, es una “relación entre clases, en la que una clase comparte laestructura o comportamiento definido en otra (herencia simple) u otras (herenciamúltiple) clases.La herencia define una relación “de tipo” entre clases en la que una subclase hereda deuna o más superclases generalizadas; una subclase suele especializar a sus superclasesaumentando o redefiniendo la estructura y comportamiento existentes”.El polimorfismo.Booch lo define como “concepto de la teoría de tipos, de acuerdo con el cual un nombre(como una declaración de una variable) puede denotar objetos de muchas clasesdiferentes que se relacionan mediante alguna superclase común; así todo objetodenotado por este nombre es capaz de responder a algún conjunto común deoperaciones de diferentes modos”.El polimorfismo es muy útil cuando hay muchas clases con los mismos protocolos.Cada objeto conoce su propio tipo.La agregación. Pág. 13.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoEl concepto de agregación entre clases es equivalente al explicado para la relación entreobjetos.El uso.Una relación de uso es posiblemente una abstracción en la cual aseguramos quién es elcliente y quién es el proveedor de un cierto servicio.La instanciación.La instanciación se refiere al hecho de “ir creando las instancias de las clases”.Aquí hay que destacar también el concepto de clase parametrizada, como plantilla deotras clases.Las metaclases.Una metaclase es una clase cuyas instancias son a su vez clases.La interacción de Clases y objetosDurante la fase de análisis hay dos tareas principales: Identificar las clases y objetos que forman el vocabulario del dominio del problema. (Esas clases y objetos se llaman “key abstractions”). Inventar estructuras en las que los objetos trabajen juntos para proporcionar un modelo de comportamiento que satisfaga los requisitos del problema.Durante estas fases del proceso, no hay que centrarse en esas abstracciones importantesy mecanismos. Esta vista representa el armazón lógico del sistema, y por consiguienteabarca la estructura de la clase y estructura del objeto del sistema.En fases posteriores, y pasando entonces a la implementación, el enfoque está en la vistainterior de estas abstracciones importantes y mecanismos. Estas decisiones de diseño seexplican como parte de la arquitectura del módulo del sistema y arquitectura delproceso.Construcción de Clases y Objetos de CalidadPara medir la calidad de una abstracción se tiene lo siguiente: El acoplamiento: es la medida de la fuerza de una asociación establecida por una conexión entre clases. La cohesión: mide el grado de conectividad entre los elementos de una clase o de un objeto. Suficiencia: significa que la clase capture bastantes características de la abstracción para permitir interacción significante y eficaz. ”Completeness”: una interfaz completa es aquella que cubre todos los aspectos de la abstracción. “Primitiveness”: desde que muchas operaciones de alto nivel están compuestas por operaciones de bajo nivel, se sugiere que esas clases sean primitivas.Es muy frecuente que sobre el primer análisis efectuado sobre las clases se haganecesario modificar y refinar las interfaces, e incluso a veces se llega a la creación de Pág. 14.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objetonuevas clases o a una reorganización de las relaciones existentes entre las que yaexisten.Es importante conocer el concepto de “Visibilidad” ya que la metdología de Fusion seva a apoyar en él. Durante la fase de diseño conviene especificar cómo un objeto esvisible por otro objeto. Hay 4 formas diferentes de que esto se produzca. El objeto servidor es global para el cliente. El objeto servidor es un parámetro de alguna operación del cliente. El objeto servidor es una parte del cliente. El objeto servidor está localmente declarado en el alcance del diagrama de objetos.ClasificaciónLa clasificación va a ser fundamentalmente una cuestión de igualdad que ayudará aidentificar las jerarquías de generalización, especialización y agregación entre clases.También ayuda a la toma de decisiones sobre la “modularización”.Es difícil llevar a cabo una buena clasificación ya que no existe una clasificación“perfecta”. Cualquier clasificación es relativa al punto de vista de su autor. Por otraparte, una buena clasificación requiere una gran creatividad e ingenio.Aproximación a las clasificacionesSe hacen tres divisiones: Categorización clásica: todas las entidades que tienen una propiedad o un conjunto de propiedades en común forman una categoría. Esas propiedades han de ser necesarias y suficientes para constituir dicha categoría. Ej. Una persona está casada o no casada. “Concptual clustering”: las clases se generan a partir de unas descripciones conceptuales previas acerca de las mismas; posteriormente se clasifican las entidades de acuerdo con la descripción. Teoría del prototipo: Una clase de objetos es representada por un objeto prototipo, y un objeto será considerado miembro de la clase si y sólo si se parece al prototipo de manera significativa.En el primer caso hay que centrarse en las estructuras, en el segundo en la colaboraciónde objetos, mientras que en el tercero se considera que el objeto esté definido deacuerdo con una serie de características del objeto prototipo.Procedimientos para encontrar clases y objetosBooch define las fases de análisis y diseño como sigue: Análisis: se va a modelar descubriendo las clases y objetos que forman el vocabulario de dominio del problema. Diseño: se inventarán las abstracciones y los mecanismos necesarios para conseguir el comportamiento que exige el modelo establecido en la fase de análisis. Pág. 15.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoExisten unos cuantos métodos para el análisis de sistemas en orientación al objeto:Acercamientos clásicos: las clases y los objetos se derivan de los requisitos delproblema.Análisis de comportamiento: se basa en el comportamiento dinámico existente entreclases y objetos. Se constituirán clases basadas en grupos de objetos que exhiban uncomportamiento similar. Se formarán jerarquías de clases y subclases de acuerdo conunas responsabilidades que poseen todos los elementos de un mismo grupo.Análisis de dominio: se define como un intento de identificar los objetos, lasoperaciones y las relaciones, que los expertos del dominio consideran importante acercadel dominio.Casos de uso: un caso de uso es una forma o patrón o ejemplo concreto de utilización,un escenario que comienza con algún usuario del sistema que inicia alguna transaccióno secuencia de eventos interrelacionados. Pueden utilizarse en el análisis de requisitosde la siguiente manera: Se enumeran los escenarios principales del sistema. Se realiza un estudio de cada escenario. A medida que se pasa por cada escenario se van identificando los objetos que participan en él, las responsabilidades de cada objeto, y la forma en que los objetos colaboran.Tarjetas de clase: consiste en elaborar por cada clase una tarjeta en la que se anotan: elnombre de la clase, sus superclases y subclases, sus responsabilidades y suscolaboraciones.El métodoEn la metodoogía de Booch se explica qué hay que hacer para definir el sistema, perono se da ninguna prescripción para mejorar las fases de análisis y diseño del sistema.Eso puede ser visto como una ventaja por parte de aquellos que prefieren disponer deuna mayor libertad a la hora de producir software, y como una debilidad para aquellosque no dispongan de mucha experiencia y expertos en la orientación al objeto.Booch propone varias formas de describir un sistema en orientación al objeto. Elmodelo lógico, por ejemplo, se representa bajo la estructura de clases y objetos.Mientras que el diagrama de clases es más bien estático, el diagrama de objetos muestrael comportamiento dinámico del sistema Pág. 16.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Figura 1. Esquema del método de Booch.Diagramas de clasesUn diagrama de clases muestra las relaciones entre las abstracciones de un sistema(vista lógica).En el diagrama se pueden representar todas o parte de las estructuras de clases de unsistema, esto es:Clase: es la unidad modular de la descomposición software orientada al objeto. Unaclase representa un conjunto de elementos u objetos que comparten la misma estructuray un comportamiento común. El comportamiento dinámico de una clase puededescribirse gracias a su diagrama de transición de estados. Pág. 17.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Figura 2. Notación de “clase" en Booch.Clase Utilidad: constituida por una colección de subprogramas libres y declarada comoparte de una clase que no tiene estado. (Aunque se puede decir que todos los métodosson operaciones, no todas las operaciones son métodos). Figura 3. Notación de “clase utilidad” en Booch.Clase Parametrizada: clase que sirve como plantilla para otras clases. Dicha plantillapuede contener parámetros de otras clases, objetos y/o operaciones. Normalmente lasclases parametrizadas se utilizan como clases contenedoras. Los términos clase“genérica” y clase “parametrizada” suelen ser intercambiables. Figura 4. Notación de “clase parametrizada” en Booch. Pág. 18.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoCategorías de clase: colección lógica de clases, algunas de las cuales son visibles a otrascategorías de clase mientras que otras están ocultas. La mayoría de los lenguajes deprogramación en la orientación al objeto no soportan las categorías de clase. Figura 5. Notación de “categorías de clase” en Booch.Atributos: un atributo de la clase describe una información singular guardada en cadacaso. Puede ser muy útil exponer algunos de los atributos relacionados con una clase.Métodos: los métodos especifican que un determinado algoritmo será aplicado a algunainstancia de la clase. Pueden dividirse en funciones y procedimientos, dependiendo de sidevuelven un resultado o no.Adornos y propiedades: son piezas secundarias de información sobre alguna entidad enel modelo del sistema. Se representan mediante una letra dentro de un triángulo. Las“relaciones” también pueden poseerlos; en C++ hay 3 propiedades:1.estática: la designación de un miembro de la clase: objeto o función.2.virtual: la designación de una clase compartida en una estructura de herencia.3.amiga: la designación del acceso concedido a las partes no públicas de una clase. Figura 6. Notación de “adornos y propiedades” en Booch.Control de exportación (para atributos, operaciones y relaciones): los miembros puedenser públicos (accesibles para todos los clientes), protegidos (accesibles sólo a subclases,amigos o a la propia clase), o privado (accesible a él y sus amigos). Pág. 19.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Figura 7. Notación del “control de la exportación” en Booch.Relaciones entre clases.Las clases colaboran entre sí de diversas formas. Las conexiones esenciales entre clasesson:Asociación: que tendrá en cuenta una serie de aspectos: valor clave, restricciones,cardinalidad, papel que desempeña, etiqueta... Figura 8. Notación de “asociación” entre clases en Booch.Herencia: define una relación entre clases donde una clase comparte la estructura o elcomportamiento definido en otra u otras clases. La herencia representa una jerarquía deabstracciones donde una subclase hereda de una o más superclases.La notación consiste en una flecha que apunta de la subclase a la superclase. Figura 9. Notación de “Herencia” en Booch.Agregación: o relación todo/parte; aparece como una asociación con un círculo rellenoque indica la “agregación”.Se puede encontrar agregación por valor: Figura 10. Notación de “Agregación por valor” en Booch. Pág. 20.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoY agregación por referencia: Figura 11. Notación de “Agregación por referencia” en Booch.Uso: el proveedor proporciona ciertos servicios (ver el apartado “diagramas de objetos”para averiguar cómo se ven los objetos entre ellos). Figura 12. Notación de “Uso” en Booch.Instanciaciones: Figura 13. Notación de “instanciaciones” en Booch.Metaclases: Figura 14. Notación de “metaclases” en Booch.Diagramas de objetosLos diagramas de objetos son parte de la notación del diseño orientado a objetos.Muestran todos o algunos objetos junto a sus relaciones en el modelo lógico del sistema.Pueden usarse para ver su ejecución en diferentes escenarios.En un diagrama de objetos se puede tener: Pág. 21.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoObjetos: un objeto es algo que puede hacer cosas; tiene estado, comportamiento eidentidad. La estructura y el comportamiento de los objetos similares se definen en suclase común. Un objeto es una instancia de una clase. Figura 15. Notación de “Objeto” en Booch.Enlace de objetos: este término deriva de Rumbaugh, quien lo define como “conexiónfísica o conceptual entre objetos”. Muestra la asociación entre un objeto Cliente quesolicita una serie de servicios de un objeto Servidor, y la dirección seguida por losmensajes intercambiados entre los objetos.Un objeto que participe de un enlace puede desempeñar uno de estos papeles: Actor: opera en otros objetos, pero nadie opera sobre él. Servidor: no opera en otros objetos, sino que operan otros en él. Agente: opera sobre él mismo, y también otros pueden hacerlo sobre él. Figura 16. Notación de “Enlace de objetos” en Booch.Sincronización de enlaces (para objetos actores): ante múltiples técnicas de control unobjeto requiere más que eso para tratar los problemas de exclusiones mutuas yconflictos que puedan presentarse. Los objetos actores tienen sus propios métodos decontrol, pero con servidores se ha de escoger entre una de las siguientesaproximaciones: Secuencial: un objeto activo en un instante. Guarded: los clientes activos deben colaborar para conseguir la exclusión mutua. Synchronous: el servidor garantiza la exclusión mutua.Los mensajes se adornan utilizando la siguiente notación: Pág. 22.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Figura 17. Notación de “sincronización de enlaces” en Booch.Visibilidad de enlaces: los diagramas de clases muestran las dependencias existentesentre las clases de varios objetos. Pero no dictaminan cómo se ven esas instancias, entreellas. Pro ello es posible adornar enlaces que representen la visibilidad del servidordesde el punto de vista del cliente. Figura 18. Notación de “visibilidad de enlaces” en Booch.Otros diagramasDiagrama de transición de estados:Se utiliza para mostrar el espacio de estados de una determinada clase, los eventos(mensajes) que disparan una transición de un estado a otro y las acciones que resultandel cambio de estado.La notación empleada es la siguiente: un único nombre para cada estado (que puedeincluir acciones asociadas), flechas dirigidas para conectar los diferentes estados... Figura 19. Notación de “estado” en Booch. Pág. 23.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoUna transición conecta dos estados y tiene que haber un estado inicial en el diagrama. Figura 20. Diagrama de transición de estados en Booch.Diagrama de Módulos:Se utiliza para mostrar la colocación de las clases y objetos en los módulos en el diseñofísico de un sistema. Indica la división de la arquitectura del sistema.Los dos elementos esenciales del diagrama son: los módulos y sus dependencias.Un subsistema puede tener dependencias en otros subsistemas o módulos, y un módulopuede tener dependencias en un subsistema. La misma anotación se usa para lasdependencias de los subsistemas. Figura 21. Diagrama de módulos en Booch.Diagrama de procesos:Se usan para mostrar la asignación de procesos a los procesadores en un diseño físicodel sistema. A través de los diagramas se indica la colección de procesadores ydispositivos que sirven como plataforma para ejecutar el sistema. Pág. 24.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoHay 3 elementos esenciales: procesadores, dispositivos y sus conexiones. Figura 22. Diagrama de procesos en Booch.Diagrama de interacción:Traza la ejecución de un escenario en el mismo contexto que un diagrama de objetos.Permite leer el paso de mensajes de unos objetos a otros en perfecto orden.Los objetos se colocan horizontalmente en la parte superior y se trazan unas líneasverticales. Los mensajes se representan horizontalmente con flechas que van desde elcliente al servidor. La “caja” vertical representa el tiempo en el que el control está sobredicho objeto. Figura 23. Diagrama de interacción en Booch. Pág. 25.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoLos procesos del desarrollo orientado al objetoBooch soporta el desarrollo iterativo e incremental.Define dos tipos de procesos para describir los niveles en un desarrollo orientado alobjeto.“Macro procesos”. Establecimiento de los requisitos principales (conceptualización). Desarrollo de un modelo de comportamiento deseado (análisis). Creación de una arquitectura (diseño). Evolución de la implementación (evolución). Mantenimiento.“Micro procesos”. Identificación de las clases y de los objetos en un nivel de abstracción dado. Identificación de la semántica de dichas clases y objetos. Identificación de las relaciones entre estas clases y objetos. Especificar las interfaces y después la implementación de estas clases.ConclusiónLa metodología de Booch es muy poco rígida y ofrece gran libertad al usuario de lamisma, lo cual, como ya se ha dicho, trae consigo una serie de ventajas einconvenientes.A partir de todos los conceptos que conforman el modelo de objetos para Booch y de lanotación que ofrece, el usuario será el único responsable de identificar las fases deanálisis y diseño del sistema. Siempre que se respete esa notación y que los resultadosobtenidos sean coherentes con los conceptos anteriormente explicados podráconsiderarse que el análisis y el diseño se han llevado a cabo correctamente.Un ejemplo concretoSegún Booch, una posible forma (que no tiene por qué ser la mejor) de desarrollar lasfases de análisis y diseño de un sistema informático de “Adquisición de datos: estaciónde monitorizacion del clima”, podría ser:Fase de análisis: Definición de los límites del problema. (Servicios que proporcionará el sistema). Especificación detallada de las necesidades del soporte hardware. Realización del diagrama de procesos del sistema. Ciclo de vida de algún objeto. Pág. 26.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Jerarquía de clases. (Clase sensor). Diagramas de interacción. (Temporizador). Escenarios. Diagrama de transición de estados. (GestorEntrada).Fase de diseño:• Escoger el marco de referencia arquitectónica.• Creación de nuevas clases cuya creación se ha visto necesaria.• Se empiezan a definir internamente las clases. Pág. 27.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoOMT (Object Modeling Tecnique) James RambaughVisión generalEs una metodología orientada a objeto muy difundida, de hecho es la que actualmentemás se está utilizando por encima incluso de la de Booch. Se desarrolló en el ‘Researchand Development Center de General Electric’ a finales de los ’80. Se hace cargo de todoel ciclo de vida del software, y durante ese tiempo mantiene la misma notación. Sedivide en cuatro fases consecutivas. Tiene una parte de diseño no muy compleja. Secentra mucho en un buen análisis. Es de las denominadas “dirigidas por los datos”.Fases (4)1. Análisis de objetos:Se describe el problema: Se obtienen unos requisitos que no den lugar a dudas(rendimiento, funcionalidad, contexto,...). En toda la fase de análisis se describe elcomportamiento del sistema como una “caja negra”.Se hacen los diagramas de objetos con su diccionario de datos. Así obtengo el modelode objetos. En él se define su la estructura de los objetos y clases así como lasrelaciones que les unen. Comprende tanto un Diagrama de Clases como un Diccionariode Datos que las explique. Este modelo debe ser refinado por medio de la iteración.Creación de un modelo dinámico para describir los aspectos de control y evolución delsistema. Incluye un Diagrama de Eventos del sistema y un Diagrama de Estado por cadaclase que tenga un comportamiento dinámico.Creación de un modelo funcional que describa las funciones, los valores de entrada ysalida, e imponga las restricciones pertinentes. Se suelen utilizar Diagramas de Flujo deDatos (DFDs).Se verifican todos los modelos creados.Se itera para conseguir un refinamiento de los 3 modelos.2. Diseño del sistema: Comprende la arquitectura básica. En esta fase se tomarán las decisiones estratégicas (a alto nivel) de diseño (estructura global del sistema).3. Diseño de objetos: Es el último paso antes de implementar, y sirve para definir completamente todas las características de los objetos. Se detallan los 3 modelos ya descritos en el análisis de objetos de cara a poder implementarlo, y optimizar el programa (acceso a datos, iteraciones, control, recursos,...). Todo esto ha de hacerse con independencia del lenguaje o entorno en que finalmente codifiquemos y ejecutemos la aplicación.4. Implementación: Se codifica lo ya diseñado. Pág. 28.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoPasos específicos a dar en cada faseFase De Análisis1.Obtener y escribir una descripción inicial del problema.2.Construir un modelo de objetos: - Identificar las clases (y objetos). - Comenzar a crear un diccionario de datos que contenga descripciones de las clases, sus atributos y sus asociaciones. - Añadir las asociaciones (y agregaciones) entre las clases. - Añadir los atributos de los objetos y sus uniones. - Organizar y simplificar las clases usando herencias. - Probar que los accesos son correctos, usando escenarios e iterando los pasos siguientes como sea necesario. - Agrupar las clases en módulos, basándose en su proximidad y función.3.Construir un modelo dinámico: - Preparar los escenarios para las secuencias de interacción típicas entre los usuarios y el sistema. - Identificar los eventos que se dan entre objetos y preparar una traza de eventos para cada escenario. - Preparar un DTE para el sistema, y una traza de eventos para cada escenario. - Construir un diagrama de estado para cada clase que tenga un marcado comportamiento dinámico. - Chequear la consistencia (y que están todos) de los eventos que aparecen en los diagramas.4.Contruir un modelo funcional: (*) - Identificar los valores de entrada y de salida. - Usar DFDs cuando sea necesario para mostrar las dependencias funcionales. - Describir qué hace cada función. - Identificar las restricciones. - Especificar criterios de optimización. (*) Este modelo ha sido bastante criticado, por no seguir los principios del AOO. Desde 1995 se recomienda que este modelo consista en una descripción detallada de las operaciones del sistema, y solo usa DFDOO cuando estas operaciones impliquen a varios objetos. Conviene, para cada operación especificar las siguientes cosas: Nombre, Responsabilidades, Entradas, Salidas, Objetos modificados, Precondiciones y Postcondiciones.5.Verificar, iterar y refinar los tres modelos: - Añadir las operaciones claves que fueron descubiertas durante la preparación del modelo funcional al modelo de objetos. No mostrar todas las operaciones durante el análisis, sólo mostrar las más importantes. Pág. 29.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto - Verificar que las clases, asociaciones, atributos y operaciones son consistentes y completas al nivel elegido de abstracción. Compara los tres modelos con la definición del problema y probar los modelos mediante el uso de escenarios. - Desarrollar escenarios más detallados (incluyendo condiciones que den errores) como variaciones de los escenarios básicos. Usar estos escenarios “y si...” para verificar en el futuro los tres modelos. - Iterar los pasos anteriores cuanto sea necesario para completar el análisis.Fase De Diseño Del Sistema1. Organizar el sistema en subsistemas (“conjunto de capas horizontales”).2. Identificar la concurrencia inherente al problema.3. Colocar los susbsistemas a sus procesos y tareas. Aquí han de asignarse recursos de lamáquina a los distintos subsitemas (memoria, procesador, ficheros...).4. Elegir la estrategia básica para almacenar los datos; tipos abstractos de datos,estructuras, ficheros y bases de datos.5. Identificar los recursos globales y determinar mecanismos de control de acceso aellos.6. Elegir un método de implementación del control de software. Existen 3 tipos decontrol destacados: Por programa (sistemas dirigidos por procedimientos; C++), Porplanificador del entorno (sistemas dirigidos por eventos; X-Windows) o Concurrente(sistemas concurrentes; Ada). Esto se puede implementar de las siguientes maneras: - Usar el programa como un estado fijo, o - Directamente implementar un autómata de estados, o - Usar tareas de concurrencia.7. Considerar las condiciones límite.8. Establecer las prioridades.Fase de Diseño De Objetos1. Obtener operaciones para el modelo de objetos a partir de los otros modelos: - Encontrar una operación para cada proceso del modelo funcional. - Definir una operación por cada evento del modelo dinámico, dependiendo de la implementación del control.2. Diseñar algoritmos para implementar operaciones: - Elegir algoritmos que minimicen el coste de implementar las operaciones. - Elegir estructuras de datos apropiadas a los algoritmos. - Definir nuevas clases internas y operaciones como sea necesario. - Asignar responsabilidades para operaciones que no han sido claramente asociadas a una sola clase.3. Optimizar los accesos a datos: Pág. 30.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto - Añadir asociaciones redundantes para minimizar el coste de acceso y maximizar la conveniencias. - Reajustar los procesos computacionales para lograr una mayor efectividad. - Almacenar los valores derivados para evitar los cálculos repetidos.4. Implementar el control software mediante el sistema elegido durante el diseño delsistema.5. Ajustar las estructuras de las clases para aumentar la herencia. - Reajuste de clases y sus operaciones para aumentar la herencia. - Extraer el comportamiento abstracto común de grupos de clases. - Delegar para poder compartir comportamientos cuando la herencia sea semánticamente inválida.6. Diseño de la implementación de las asociaciones: - Analizar las asociaciones transversales. - Implementar cada asociación como si fuera un objeto distinto o añadiendo el valor de los objetos como atributos de una o ambas clases de la asociación.7. Determinar la representación exacta de los atributos de los objetos.8. Compactar las clases y asociaciones en módulos, ocultando en la parte privada toda lainformación que deba estar oculta.ImplementaciónNo se detiene en ella (al igual que la fase de pruebas), con lo que se queda a la eleccióndel programador.ConclusiónUna de las grandes virtudes de OMT es su modelo de objetos, que contiene una enormeriqueza semántica, por lo que ha sido adaptado por casi todas las metodologías desegunda generación, y es una de las bases metodológicas de la metodología ‘Objetory’que en breve aparecerá (de la mano de los ‘3 amigos’: Rambaugh, Booch y Jacobson)para completar a UML.OMT es una metodología bastante sólida (si exceptuamos su modelo funcional, bastantecriticado), que completado con otras técnicas de representación (CRCs, Casos de Uso...)la hacen la metodología más difundida (tanto a nivel universitario como empresarial)del momento.NotaciónTodas las relaciones y diagramas han de respetar la siguiente notación: Pág. 31.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Figura 24. Notación de OMT para el Modelo de Objetos Pág. 32.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoMétodo de Fusion. ColemanIntroducciónFusion proporciona un método de desarrollo de software orientado al objeto, que abarcadesde la definición de requisitos a la implementación en un lenguaje de programación.Es considerada como una metodología de segunda generación, porque proviene de: OMT: modelo de objetos, CRC: interacción de objetos, BOOCH: visibilidad, Los métodos Formales: pre- y post- condiciones. • Proporciona un proceso de desarrollo, que se divide en: Análisis, Diseño e Implementación.1 • Ofrece notaciones para los modelos, que describen varios aspectos del software. Actualmente ha abandonado su notación. • Proporciona herramientas de gestión.AnálisisEl análisis se basa más en describir lo que hace un sistema en lugar de cómo lo hace.Para esto, hay que ver el sistema desde la perspectiva del usuario en lugar de desde la dela máquina. El análisis casa con el dominio del problema y se preocupa por elcomportamiento visible externamente.La meta de la fase de análisis es capturar tantos requisitos del sistema como sea posible.Se producen los siguientes modelos del sistema: • Modelo de objetos • Modelo de la interface • Modelo del funcionamiento, • Modelo del ciclo de vida. Estos modelos describen: Clases de objetos que existen en el sistema.2 Relaciones entre esas clases. Operaciones que pueden realizarse en el sistema. Secuencias permitidas de estas operaciones.La entrada para la fase de análisis es un documento de definición de requisitos enlenguaje natural.1 Especifica el orden en el que deben hacerse las cosas dentro de cada fase. También proporcionacriterios de cuándo pasar a la siguiente fase.2 En la fase del análisis de Fusion, sólo los atributos de una clase son considerados. Los métodos sonconsiderados en la fase de diseño. Por consiguiente, en la fase del análisis, los objetos son similares a lasentidades en el tradicional modelo entidad relación. Pág. 33.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoModelo de objetosLa finalidad del modelo de objetos en Fusion es: capturar los conceptos que existen en el dominio del problema y las relaciones entre ellos, mostrar clases y sus relaciones, (no mostrar objetos)El modelo de objetos representa: la estructura estática de la información en el sistema, las clases y relaciones entre ellas, atributos de clases, agregación, especialización/generalización.Definiciones:• Un objeto es cualquier cosa que puede ser identificada. Puede tener una serie de valores nombrados, llamados atributos.• Los objetos se agrupan en conjuntos, llamados clases.• Las relaciones se usan para modelar la idea de asociación o correspondencia entre objetos que pertenecen a clases.Para describir una relación, se consideran los puntos siguientes: Restricciones de Cardinalidad. Cardinalidad es el número de clases que puedenasociarse entre sí en una relación. Invariantes. Restricciones de que alguna propiedad se debe cumplir. Roles. Las clases que participan en una relación tienen roles. Los nombres para losroles o papeles en una relación deben ser únicos. Atributos de la relación. Las relaciones, como los objetos, pueden tener atributos.3 Relaciones ternarias y más altas. Las relaciones ternarias relacionan tres objetosseparados. Las que involucran más de tres objetos se llaman relaciones n-arias.• La agregación es un mecanismo para estructurar el modelo de objetos. Permite la construcción de una clase agregada a partir de las otras clases componentes. La agregación modela las relaciones todo/parte.• La generalización permite a una clase, llamada supertipo, ser formada sacando las propiedades comunes de varias clases, llamadas subtipos. La especialización es el caso inverso en el que un nuevo subtipo se define como una versión más especializada de un supertipo.4• La especialización múltiple permite definir un nuevo subtipo como una especialización de más de un supertipo inmediato. La subclase hereda los atributos y relaciones de todas sus superclases.5Un diagrama de modelado de objetos puede ser dividido en subdiagramas.3 Esto corresponde al Atributo de Unión (Link Attribute) en el la notación de Rumbaugh.4 En el la anotación de Rumbaugh, el supertipo se llama superclase, y el subtipo se llama subclase. Lasnotaciones del triángulo en Fusion son completamente opuestas a las de Rumbaugh.5 En el la notación de Rumbaugh, la especialización múltiple se llama herencia múltiple. La notación esexactamente la misma para los dos métodos. Pág. 34.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Figura 25. Notación del diagrama de objetos de Pág. 35. Fusion.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoModelo de Objetos del sistemaEl modelo de objetos del sistema es un subconjunto del modelo de objetos que describeel sistema a ser construido. Se forma excluyendo todas las clases y relaciones quepertenecen al entorno.Usa la información sobre la interface del sistema para indicar qué clases y quérelaciones pertenecen al estado del sistema, y no a su entorno.Las clases que quedan fuera del modelo de objetos del sistema no participan en lasrelaciones dentro del modelo de objetos del sistema. El modelo de objetos del sistema esla base en la que se hace el resto del desarrollo.Modelo de la InterfaceEl modelo de la interface describe el comportamiento de un sistema, por ejemplo, definela comunicación de entrada y salida del sistema. La descripción está en términos deeventos y el cambio de estado que ellos causan.6Un sistema se modela como una entidad activa que interactúa con otras entidadesactivas llamadas agentes. Los agentes modelan a los usuarios humanos, u otros sistemashardware o software. Las características importantes de un agente son que es activo y seque comunica con el sistema.Un modelo de la interface utiliza dos modelos para diferentes aspectos delcomportamiento: • Modelo del funcionamiento • Modelo de ciclo de vidaModelo del FuncionamientoEl modelo del funcionamiento (modelo funcional) especifica el comportamiento de lasoperaciones del sistema utilizando un Esquema de Modelado de Funcionamiento.Define efectos del funcionamiento en términos de : cambios de estado, eventos que son salidas.Una operación del sistema es un evento de entrada y su efecto en un sistema. Lasoperaciones del sistema son invocadas por agentes en el entorno. Una operación delsistema puede Crear una nueva instancia de una clase. Cambiar el valor de un atributo de un objeto existente. Agregar o anular alguna tupla de objetos de una relación. Enviar un evento a un agente.6 Un evento es una unidad instantánea y atómica de comunicación entre el sistema y su ambiente. Unevento de entrada es enviado por un agente al sistema. Un evento de salida es enviado por el sistema aun agente. Un evento de entrada y el efecto que puede tener se llama una operación del sistema. Pág. 36.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Figura 26. Esquema del modelo de funcionamiento.El modelo del funcionamiento se expresa como una serie de esquemas llamados"Esquemas del Modelo del Funcionamiento." Debe haber un esquema por lo menospara cada operación del sistema.Semántica de cada entrada en la sintaxis del esquema. Operación: Nombre de la operación. Descripción: Descripción concisa de la operación. Lee: Todos los valores a los que la operación puede acceder sin modificación. Cambia: Todos los valores a los que la operación puede acceder y modificar. Envía: Lista de agentes y eventos que la operación puede enviar. Asume: Pre-condición, por ejemplo, lo que debe ser verdad antes de la operación. Resultados: Post-condición, por ejemplo, qué cambios han ocurrido por la operación.Modelo del Ciclo de VidaEl modelo de ciclo de vida describe cómo el sistema se comunica con su entorno desdesu creación hasta su muerte. Consiste en expresiones del ciclo de vida. Una expresióndel ciclo de vida define las secuencias aceptables de interacciones en las que un sistemapuede participar en su tiempo de vida. Es algo parecido al modo en que una gramáticadescribe las secuencias aceptables de símbolos que son aceptadas por un compilador. 77 Este modelo puede ser reemplazado por guiones en la versión ligera de Fusion. Pág. 37.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoProceso de AnálisisEl análisis no es un proceso anárquico: hay una sucesión definida de pasos que puedenaplicarse iterativamente para producir una especificación completa y consistente quecapture los requisitos.El análisis es una actividad incremental e iterativa que formaliza los requisitos. Puedellevarse a cabo de una manera sistemática.En Fusion, el proceso de análisis se define como sigue: 1. Desarrolle un modelo de objetos para el dominio del problema. 2. Determine la interface del sistema. Identifique los agentes, operaciones del sistema, y eventos. Produzca el modelo de objetos del sistema agregando el límite al modelo deobjetos. 3. Desarrolle un modelo de interface. Desarrolle un modelo de ciclo de vida. Desarrolle un modelo de funcionamiento. 4. Verifique el modelo de análisis.Para todos, hasta para el más trivial, de los problemas el proceso debe de ir acompañadopor la construcción y uso de un diccionario del datos.Diccionario de datosEl diccionario de datos sirve para coleccionar información no disponible en losdiagramas de Fusion. El diccionario de los datos es un almacén (repositorio) central dedefiniciones de términos y conceptos.Ejemplo de la estructura del diccionario de datos. Figura 27. Ejemplo de la estructura del diccionario de datos. Pág. 38.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Sin embargo, esto no es obligatorio, y el formato real del diccionario de los datos esinsignificante.Desarrollo del Modelo de Objetos• ¿Cómo empezar a construir el Modelo de Objetos?Empezar el análisis puede ser a menudo la parte más difícil. El análisis debe empezarsecon un alto nivel de abstracción. Es mejor utilizar los requisitos para una tormenta deideas de posibles clases y relaciones. Sólo después de que su estructura global seasatisfactoria deben añadirse los detalles. Hay que recordar que el modelo de objetosutiliza clases, mientras que un documento de requisitos es expresado principalmente entérminos de objetos específicos.• ¿Cómo encontrar clase candidatas?Casi cualquier nombre puede dar lugar a una clase. Sin embargo, para serlo, el nombredebe pertenecer a un concepto que sea importante para la comprensión del dominio.Posibles fuentes de clases candidatas son: Objetos físicos, Personas y organizaciones, Abstracciones.• ¿Cómo encontrar relaciones?Modelan correspondencias entre objetos. Comunicaciones, asociaciones físicas,contenciones, y acciones son todas las posibles fuentes para relaciones candidatas. Unavez que las listas de candidatas se ha hecho, deben racionalizarse. En ese punto, puedenusarse las clases y relaciones para empezar el diccionario de datos.• ¿Qué debe ser considerado en las relaciones? Generalización Agregación Atributos8 Cardinalidades Invariantes• ¿Qué puntos deben remarcarse para construir el modelo de objetos? Modelar objetos no es una ciencia precisa. No hay ninguna respuesta perfecta, asíque el resultado de análisis siempre depende en parte de la experiencia, y incluso de laestética del analista. Es importante recordar que los objetos no tienen que modelar cosas: también puedenmodelar abstracciones. No hay que mal interpretar clases y relaciones como diagramas de flujo de datos.Determinación de la Interface del Sistema• ¿Por qué determinar la interface del sistema?8 Éstos se ignoran durante la fase de la tormenta de ideas inicial. Cualquier clase candidata que no tenganingún atributo y que se relacione con sólo otra clase, puede convertirse en atributos. Pág. 39.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoDurante el análisis, un sistema es modelado como una entidad activa que coopera conotras entidades activas, llamadas agentes. El sistema y los agentes se comunicanenviando y recibiendo eventos. Cuando los eventos son recibidos por el sistema, puedencausar un cambio de estado y eventos de salida. Un evento de la entrada y su efectoasociado son conocidos como una operación del sistema.La interface de un sistema es el conjunto de operaciones del sistema a las que puederesponder y los eventos que puede enviar.Una operación del sistema siempre es invocada por un agente, no por un objeto; la fasedel análisis no se preocupa por mensajes internos entre los objetos.La información obtenida en la determinación de la interface del sistema es el punto departida para desarrollar el modelo de la interface.• ¿Qué es la notación de la interface del sistema?El escenario es una técnica útil para definir la interface del sistema.Un escenario es una sucesión de eventos que fluyen entre agentes y el sistema paraalgún propósito.Un escenario se representa como un diagrama de secuencia, que muestra las órdenestemporales del sistema y los eventos que fluyen a los agentes. Los diagramas desecuencia no pueden mostrar caminos alternativos de comunicación. Por consiguiente,en general pueden necesitarse diagramas múltiples para un sólo escenario.Los diagramas de secuencia de escenario aportan una herramienta para intuir lasconsecuencias del diseño de la interface y visualizar cómo se comporta el sistema. Sonútiles al validar decisiones de la interface con clientes porque son simples e intuitivos deentender. Figura 28. Diagrama de secuencia. Pág. 40.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoDesarrollo del Modelo de la Interface• ¿Cuál es el orden para desarrollar el modelo de la interface?El modelo de la interface comprende un modelo del ciclo de vida y un modelo delfuncionamiento. El orden de desarrollo no es fijo. Sin embargo, es mejor empezar con elmodelo del ciclo de vida porque el ciclo de vida puede ser una ayuda al desarrollo delesquema del modelo de funcionamiento.• ¿Cómo desarrollar el modelo del ciclo de vida?El modelo del ciclo de vida es una expresión generalizada de los escenarios que seexpresan en diagramas de secuencia. Las expresiones del ciclo de vida son másexpresivas que el diagrama de secuencia, porque pueden expresar repetición,alternación, y optionalidad, así como el encadenamiento.Una expresión del ciclo de vida puede definir un conjunto de escenarios, mientras queun diagrama de secuencia puede mostrar sólo un solo escenario.El proceso para formar el modelo del ciclo de vida es: 1. Generalice los escenarios para formar expresiones del ciclo de vida nombradas. 2. Combine las expresiones del ciclo de vida para formar el modelo del ciclo de vida.• ¿Cómo desarrollar el modelo del funcionamiento?El modelo del funcionamiento define la semántica de cada operación del sistema en lainterface del sistema usando un esquema de modelo del funcionamiento.El proceso para desarrollar un esquema puede resumirse como sigue: 1. Desarrolle la cláusulas Asume y Resultados. 2. Extraiga la cláusulas Envía, Lee, y Cambia de Asume y Resultados.Verificando los Modelos del Análisis• ¿Cuándo detener la fase del análisis?El dilema que enfrenta al analista es saber cuándo los modelos del análisis sonsuficientemente buenos para ser usados en el diseño. La perfección es inasequible ynormalmente no se requiere. Sin embargo, una especificación con errores graves nosirve.Verificar los modelos del análisis es una manera de evitar errores graves. Si loschequeos no revelan ningún problema, entonces se puede pensar que la fase del análisisestá completa.• ¿Qué aspectos serán verificados?Hay dos aspectos para ser verificado: completitud (integridad) y consistencia.La integridad puede medirse contra los requisitos. Los modelos del análisis debenprobarse contra los requisitos, y también el conocimiento y expectativas de los clientesy expertos del dominio.1) Chequeo de la Integridad contra los RequisitosHay que verificar que: - Todos los posibles escenarios son cubiertos por el ciclo de vida. - Todos las operaciones del sistema son definidas por un esquema. Pág. 41.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto - Toda la información estática es capturada por el modelo de objetos del sistema. - Cualquier otra información (ej., definiciones técnicas e invariantes), está en eldiccionario de datos.Un conjunto de modelos es consistente cuando los modelos no se contradicen entreellos, explícitamente o implícitamente. En un modelo debe verificarse su consistenciainterna y también para esas áreas donde se solapa con otros modelos.2) Chequeos de la Consistencia SimpleEstos chequeos tratan las áreas de solape entre los modelos del análisis. Verifique que - Todas las clases, relaciones, y atributos mencionados en el modelo delfuncionamiento aparece en el modelo de objetos del sistema. Todos los otros conceptos(ej., predicados), deben aparecer por el modelo del ciclo de vida. - Todos las operaciones del sistema en el modelo del ciclo de vida tienen unesquema. - Todos los identificadores en todos los modelos tienen entradas en el diccionario dedatos.3) Chequeos de la Consistencia SemánticaEstos chequeos intentan asegurar que las implicaciones de los modelos son consistentes.Verifique que - La salida de eventos en el modelo del ciclo de vida y el modelo de funcionamientodeben ser consistentes. El esquema para una operación del sistema debe generar loseventos de salida que lo siguen en los escenarios del modelo de ciclo de vida. - El modelo de funcionamiento debe conservar invariantes del modelo de objetos delsistema. Si hay alguna invariante acerca de una relación o clase, entonces cualquieroperación que puede cambiarlo debe respetar el invariante en su esquema. - Chequear los escenarios usando el esquema. Escoja ejemplos de escenarios , ydefina el cambio de estado que cada uno debe causar. Entonces "ejecute" los escenarios,usando el esquema para definir el comportamiento de cada operación del sistema.Chequee que los resultados son lo que se espera.DiseñoEl diseño consiste en desarrollar un modelo abstracto de cómo un sistema lleva a caboel comportamiento especificado en el análisis.El diseñador escoge cómo se va a construir el sistema. Durante este proceso, losmétodos se unen a las clases. El diseñador también escoge cómo los objetos serelacionan entre ellos y qué relaciones de herencia entre clases son apropiadas.La fase de diseño de Fusion se basa en las CRC y los métodos de Booch.La salida del diseño es una estructura de software orientado a objeto que contiene lamisma información y mantiene las relaciones definidas en el modelo de objetos delsistema.Durante esta fase se desarrollan los cuatro modelos siguientes: • Gráficos de Interacción de Objetos. Describen cómo los objetos interactúan en tiempo de ejecución para conseguir la funcionalidad especificada en el modelo de funcionamiento en la fase del análisis. Pág. 42.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto • Gráficos de visibilidad. Describen las rutas de comunicación entre objetos. • Descripciones de clases. Proporcionan una especificación de la interface de la clase, atributos de datos, atributos de referencia a objetos, y signaturas de los métodos para todas las clases en el sistema. • Gráficos de herencia. Describen las estructuras de herencia clases/subclases.Además, el diccionario de los datos documenta los términos, conceptos, y restriccionesque aparezcan durante esta fase.La entrada de la fase de diseño son los tres modelos desarrollados en la fase delanálisis: Modelo de objetos, modelo de funcionamiento y modelo del ciclo de vida.Gráfico de Interacción de ObjetosLa primera consideración en diseño orientado a objetos es la implementación de cadaoperación del sistema. El modelo de funcionamiento especifica la conducta de estasoperaciones definiendo el efecto de cada operación en términos de cambios de estadodel sistema y de eventos de salida. El propósito de esta fase en diseño es construir lasestructuras de mensajes entre objetos definidas en el modelo de funcionamiento.El gráfico de interacción de objetos se construye para cada operación del sistema.Un gráfico de interacción de objetos es una colección de cajas unidas por flechas. Lascajas representan al objeto, y las flechas representan el paso del mensaje. Hay dos tiposde cajas: Director Le llega una flecha que no viene de ninguna otra caja del gráfico;esta flecha se etiqueta con el nombre de la operación del sistema que implementa esegráfico de iteracción de objetos. Colaboradores El resto de las cajas se llaman colaboradores. El resto de lasflechas, salvo la de la operación del sistema, van de una caja a otra dentro del gráfico.Las sucesiones de mensajes entre los objetos determinan el comportamiento de losobjetos declarado en el gráfico de interacción de objetos. Esto define la implementacióna alto nivel de la funcionalidad a través de los objetos para una operación del sistema.Cada gráfico de interacción de objetos también lleva asociado un texto descriptivo en eldiccionario de los datos, en lenguaje natural, pseudocódigo, o especificación formal,para dar significando a la operación del sistema y los mensajes definidos.Notación del gráfico de interacción de objetos Pág. 43.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Figura 29. Notación del gráfico de iteracción de objetos. Pág. 44.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Objeto del diseño. Tiene atributos y la interface de los métodos. En la fase delanálisis un objeto no tenía ningún atributo ni método. Para distinguirlo de este, se utilizala palabra objeto del diseño. La notación es una caja sólida. Colecciones de Objetos. Colecciones de objetos de la misma clase. Lasimplementaciones típicas de estas colecciones serán listas o arrays. La notación es unacaja con líneas discontinuas. Paso de mensajes. El paso de mensajes es una comunicación punto a punto, y serealiza como una llamada a una función o a un método. La notación es una flechadirecta con etiquetas. La dirección de la flecha es del remitente al receptor. También sellaman cliente y servidor. Paso de mensajes a Colecciones. Un mensaje puede pasarse a colecciones deobjetos. La notación es una flecha directa a una caja con líneas discontinuas. Secuencia de Mensajes . Si una secuencia de pasos de mensajes es importante, sepuede mostrar el orden de la secuencia introduciendo etiquetas de la secuencia entreparéntesis sobre el nombre del mensaje. La notación son etiquetas de la secuencia entreparéntesis. Creación dinámica de Objetos . La palabra clave new indica que un objeto se creacomo parte de la ejecución de un gráfico de interacción de objetos. El mensaje especialcreate también debe ser enviado a cada nuevo objeto, con los parámetros de invocaciónapropiados, para inicializarlo. La notación es una flecha directa con el mensaje create().• ¿Cómo desarrollar un gráfico de interacción de objetos?Para cada operación del sistema se realiza un gráfico de interacción de objetos. Estosignifica que se desarrolla un gráfico de interacción de objetos para cada esquema en elmodelo de funcionamiento.Esto supone los siguientes pasos: 1. Identifique los objetos pertinentes involucrados en la implementación de laoperación del sistema. El esquema del modelo de funcionamiento se usa como el punto de partida paraidentificar los objetos involucrados. La cláusula Lee del esquema proporciona una lista de los objetos a los que laoperación del sistema accede pero no modifica. La cláusula Cambia lista los objetos cambiados por dicha operación. Además de los objetos listados explícitamente en el esquema, puede haber otrosobjetos involucrados. Por ejemplo, pueden introducirse nuevos objetos para representarabstracciones de mecanismos computacionales no identificadas en los modelos delanálisis. La cláusula Envía del esquema, por ejemplo, lista los eventos de salida a agentesdel sistema. 2. Establezca el rol de cada objeto. Identifique al director (es decir, el objeto que recibe la demanda para invocar laoperación del sistema, y es responsable de dicha operación). Identifique a los colaboradores involucrados. 3. Decida los mensajes entre los objetos. Pág. 45.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Cada objeto proporcionará pedazos diferentes de funcionalidad. Estos pedazos defuncionalidad están compuestos por el paso de mensajes entre los objetos. 4. Registre cómo los objetos identificados interactúan en un gráfico de interacción deobjetos. Cada objeto proporciona una parte de la definición funcional de la operación, yesta información puede extraerse para definir la interface del método del objeto. Unadescripción textual de cada método es incluida en el diccionario de los datos. Estoexplica el significado de los métodos.• ¿Cómo refinar un gráfico de interacción de objetos? El proceso de diseño lleva a cabo un desarrollo iterativo y una descomposiciónjerárquica. Los gráficos de Interacción de objetos proporcionan una representaciónvisual de la estructura de los algoritmos. Permiten llevar a cabo experimentos condiseños alternativos y ayudar a la descomposición jerárquica.Diseño alternativo Los diseños alternativos son explorados desarrollando gráficos de interacción deobjetos para el mismo funcionamiento, pero escogiendo diferentes objetos paradirectores y colaboradores, y con mensajes diferentes que pasan entre ellos. Puedendemostrarse las consecuencias de estas alternativas claramente, mostrando los mensajesen “tiempo real” que ocurren para una determinada operación del sistema.Descomposición del método jerárquica Un diseñador puede reducir la complejidad de un gráfico de interacción de objetosposponiendo la descomposición de un método. Esto puede hacerse con el uso de unesquema de modelo de funcionamiento para especificar el método. Después en eldiseño, el esquema del método puede usarse para producir unos gráficos de interacciónde objetos de la manera normal.• ¿Cómo verificar un gráfico de interacción de objetos?Hay dos chequeos básicos que necesitan ser llevados a cabo una vez que el diseñadorestá satisfecho con los diseños iniciales. 1. Consistencia con la especificación del sistema. Verifique que cada una de las clases en el modelo de objetos del sistema serepresenta en por lo menos un gráfico de interacción de objetos. 2. Comprobación de efecto funcional. Chequee que el efecto funcional de cada gráfico de interacción de objetos satisface laespecificación de su operación del sistema dada en el modelo del funcionamiento.Chequee que se satisfacen todas las cláusulas Resultado del esquema.• Principios de buen diseñoHay que tratar de: Minimizar las interacciones entre objetos. Separar ordenadamente la funcionalidad. Desarrollar sistemas modulares. Pág. 46.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoGráficos de visibilidadDurante el desarrollo de los gráficos de interacción de objetos, se suponía que todos losobjetos son visibles entre sí y se pueden enviar mensajes. El propósito del gráfico devisibilidad es definir la estructura de la referencia de clases en el sistema. La tarea esidentificar para cada clase, objetos que las instancias de la clase necesitan referenciar, los tipos apropiados de referencia a esos objetos.• Notación del gráfico de visibilidadHay tres componentes en el gráfico de visibilidad: 1.caja del cliente Esto representa la clase que requiere el acceso. Una caja del cliente es un rectánguloque contiene el nombre de una clase. 2.caja del servidor Esto representa el objeto al que se accede. Una caja del servidor es un rectángulo quecontiene una etiqueta del servidor que nombra la instancia en la caja, la clase de lainstancia, si el servidor es creado por el cliente, y si la referencia al servidor es o noconstante. 3.flecha de visibilidad Esto representa que el cliente tiene acceso a la instancia del servidor vía una ruta deacceso. Pág. 47.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Figura 30. Notación del gráfico de visibilidad. Pág. 48.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto• Semántica del gráfico de visibilidadHay cuatro decisiones de diseño cuando se considera la estructura de la referencia declases. Vida de la referencia Referencia dinámica.- Cuando un cliente sólo necesita mandar un mensaje alservidor en el contexto de una sola invocación del método, puede darse el acceso através de un parámetro o por una variable local del método. En esta situación seespecifica una referencia dinámica. Se denota por una flecha discontinua. Referencia permanente.- Cuando un objeto necesita la misma referencia enmuchos contextos, se usan referencias permanentes. Se denota por una flecha sólida. Visibilidad del servidor Servidor no-compartido.- Un objeto servidor que recibe un mensaje de un clienteexclusivamente. La caja de objeto de servidor tiene un borde doble. Esto garantiza queen el momento de cualquier invocación al método, sólo un cliente tendrá una referenciaal servidor. Sin embargo, puede haber clientes diferentes en momentos diferentes, peroen cualquier invocación hay sólo un cliente. El contorno discontinuo se usa paraservidores que son una colección de objetos servidores. Servidor compartido.- Un objeto servidor que recibe un mensaje de múltiplesclientes. La caja de objeto de servidor tiene un borde simple. Ligadura del servidor Servidor ligado.- Si un objeto servidor debe ser eliminado cuando su cliente seelimina, se dice que el tiempo de vida del servidor es limitado. En este caso, la caja delservidor se pone dentro de la caja del cliente. Servidor no ligado.- Cuando el tiempo de vida de un objeto servidor no se liga alde un cliente, la caja del servidor se muestra fuera de la caja de clase de cliente. Mutabilidad de la referencia Mutabilidad constante.- Si una referencia no es asignable después de inicializarse,se dice que tiene mutabilidad constante. Esto significa que la referencia es fija cuandose inicializa. La palabra clave constante se pone delante del nombre del servidor. Mutabilidad inconstante.- Si una referencia es reasignable, la mutabilidad esinconstante. La palabra clave variable se pone delante del nombre del servidor.• ¿Cómo desarrollar los gráficos de visibilidad?Los gráficos de visibilidad se desarrollan de los gráficos de interacción de objetos de lamanera siguiente: 1. Se inspeccionan todos los gráficos de interacción de objetos. Para cada flecha queva de un objeto a otro, la clase del remitente requiere una referencia de visibilidad alobjeto receptor. 2. Anote la flecha con información de visibilidad detallándolo donde sea apropiado. Vida de la referencia Visibilidad del servidor Ligadura del servidor Mutabilidad de la referencia Pág. 49.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto 3. Para cada clase, considere todas las flechas anotadas de las instancias de la clase.Construya un gráfico de visibilidad con la clase en la caja cliente y con flechas devisibilidad conectadas a las cajas servidor.La etiqueta en las flechas de los gráficos de interacción de objetos puede copiarse através de los gráficos de visibilidad donde sea necesario.• ¿Cómo verificar el gráfico de visibilidad?Hay que hacer tres chequeos importantes: 1.Consistencia con los modelos del análisis. Las relaciones identificadas durante el análisis definen invariantes que debenmantenerse entre las clases. Se debe chequear que las estructuras orientadas a objetodefinidas en los gráficos de visibilidad mantengan las relaciones. Para cada relación enel modelo de objetos de sistema, esperamos que haya un camino de visibilidad entre lasclases correspondientes en el diseño. 2.Consistencia mutua Verifique que los objetos servidor exclusivos no son referenciados por más de uncliente. 3.Integridad Verifique para ver que todos los pasos de mensajes definidos en los gráficos deinteracción de objetos están comprendidos en los gráficos de visibilidad.• Principios de buen diseño Minimizar datos y las dependencias funcionales.Descripciones de claseDespués de desarrollar los gráficos de visibilidad para todas la clases, el siguiente pasoes intercalar información del modelo de objetos del sistema, de los gráficos deinteracción de objetos y de los gráficos de visibilidad en descripciones de clase, unapara cada clase.En esta fase, los métodos, algunos atributos de datos, y los atributos de valor de losobjetos se establecen para cada clase.Cuando estas descripciones iniciales se han producido, se diseñan las estructuras deherencia requeridas en el sistema.• Notación de las descripciones de la claseLa notación es como sigue: clase <Nombre_de_la_Clase> [ isa <Nombre_de_la_SuperClase>] // para cada atributo [attribute][Mutability] <Nombre_del_Atributo>: [Sharing][Binding] <Tipo> : : // para cada método [method] <Nombre_del_método> <Lista_de_argumentos> [: <Tipo>] : : endclass• ¿Cómo desarrollar las descripciones de la clase? Pág. 50.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoEl proceso para construir descripciones de clases es como sigue: Métodos y sus parámetros Se derivan métodos de los gráficos de interacción de objetos. Atributos de datos La fuente para los atributos de datos es el modelo de objetos de sistema y eldiccionario de los datos. Atributos de objeto Se extraen atributos de objetos del gráfico de visibilidad para la clase. Dependencias de herencia Las dependencias de herencia se documentan después de definir los gráficos deherencia.• ¿Cómo verificar las descripciones de la clase?La información en las descripciones de clase se deriva, es decir, no se genera de nuevo.Con tal de que las transcripciones sean exactas, las descripciones serán consistentes conlas descripciones producidas antes en análisis y diseño.Sin embargo, se deben hacer los siguientes chequeos: 1. Atributos de datos. Verifique que se recogen todos los atributos de datos delmodelo de objetos del sistema. 2. Atributos del objeto. Verifique que están todas las referencias de visibilidad. 3.Métodos y parámetros. Verifique que se recogen todos los métodos de los gráficosde interacción de objetos. 4.Herencia. Verifique se recogen que todas las superclases.• Principios de buen diseño Restringir “reusos” basados en herencia. “Reusar” a través de herencia no siempre es la opción mejor. Decidir cuando construir nuevas clases a través de herencia y cuándo construirusando composición es un aspecto del diseño de OO. La herencia debe usarse cuando la interface completa de la clase vieja se aplica ala clase nueva, sin embargo, no debe usarse cuando una alta proporción de códigonecesita volverse a escribir o cuando algunos de los métodos de la clase vieja son nopertinentes. Desarrollar gráficos de herencia poco profundos. Deben organizarse clases en un sistema como un bosque de gráficos de herencia,cada uno cubriendo una categoría particular de clases relacionadas. Deben organizarse clases en jerarquías poco profundas de aproximadamentecuatro a cinco niveles. Hacer una raíz en una clase abstracta. Cada gráfico de herencia debe arraigarse en una clase abstracta que sólo sirve comouna definición de una interface. Debe definir un conjunto de atributos mínimo(preferentemente vacío) para que no se restrinjan subclases potenciales en surepresentación. Pág. 51.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Figura 31. Proceso de construcción de una descripción de clase.Gráficos de herenciaUna consideración importante en diseño orientado a objeto es la herencia, unmecanismo por cuál una clase puede definirse como una especialización de otra. Losgráficos de herencia reflejan las relaciones de herencia entre las clases. Pág. 52.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto • Notación de los gráficos de herencia La notación usada para herencia es igual que la notación del modelo de objetos usada para la generalización y la especialización. Una caja representa una clase, con el nombre de la clase indicado en la sección superior de la caja. Se nombran los atributos en la caja debajo de la línea. Triángulo hueco.- No se hacen ninguna suposición de que las subclases sean disjuntas o que particionen a la superclase. Esto significa eso puede haber otras subclases que hereden de la superclase. Triángulo sólido.- Esto indica que las subclases son disjuntas y que su unión forma la superclase. Esto significa que no hay más subclases que hereden de la superclase.9Figura 32. Notación de los gráficos de herencia. • ¿Cómo desarrollar los gráficos de herencia? Las entradas para desarrollar gráficos de herencia son 1) el modelo de objetos del sistema, 2) los gráficos de interacción de objetos , 3) los gráficos de visibilidad, y 4) las descripciones de clase. Lo siguiente son pasos para desarrollar gráficos de herencia de estos modelos. Modelo de objetos del sistema - generalizaciones Las estructuras de generalización y especialización del modelo de objetos del sistema proporcionan el punto de partida obvio. Una clase del análisis especializada es una subclase, y una clase del análisis generalizada es un superclase. 9 La definición anterior de triángulo del hueco/sólido es completamente opuesta a la de Rumbaugh Pág. 53.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Gráficos de interacción de objetos y descripciones de clase - funcionalidad común Cada descripción de clase es chequeada para descubrir la funcionalidad común.Esta funcionalidad puede extraerse para construir una nueva clase abstracta. Gráficos de visibilidad - estructura común Cada gráfico de visibilidad se verifica contra otros para extraer la estructuracomún. Si dos clases tienen una referencia común en la estructura entonces puede serposible definir una clase abstracta que define las referencias comunes.• ¿Cómo verificar los gráficos de herencia?Los gráficos de herencia tienen que ser verificados con los modelos siguientes: Modelo de objetos del sistema Chequee que las relaciones de subtipos se conservan. Recuerde que el propósitode las relaciones de generalización y especialización en el análisis es declarar lapropiedad de subtipos entre dos clases. Gráficos de interacción de objetos Verifique que todas las clases se representan en un gráfico de herencia. Gráficos de visibilidad Verifique que todas las clases se representan en un gráfico de herencia. Puedendefinirse clases abstractas para la estructura común entre las clases en los gráficos devisibilidad. Descripciones de clase Chequee que las nuevas descripciones de clase capturan todos los métodoscomunes de los anteriores y respetan los gráficos de herencia.• Principios de buen diseño Una Clase; Una Abstracción Una clase debe tener un tipo de funcionalidad. Una manera de medir la cohesión de clases es considerar pares de métodos en lainterface de la clase y los atributos de datos involucrados en su definición. Dos métodos sin atributos de datos comunes sirven funciones separadas y puedeindicar que la clase no es cohesiva. Representación del Encapsulamiento Un buen principio de encapsulación es “esconder” la implementación y reducir ladependencia de la interface en la implementación. Los métodos deben ser ortogonales, es decir, no debe haber ningún solape defuncionalidad entre los métodos. Pág. 54.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoImplementaciónGestión de un Desarrollo Fusion• ¿Cómo introducir Fusion en un proyecto?Se sugiere un acercamiento de tres pasos: 1. Valoración de necesidades Repase el proceso de desarrollo de software del proyecto y sus necesidades denegocio. Chequee si Fusion es apropiada. 2. Entrenando Organice "un curso de entrenamiento" y "un grupo de trabajo" para una nuevatecnología. Después de estos entrenamientos, confirme su decisión de utilizar Fusion. 3. Plan de transición Las pautas para la transición son: Identifique aquellos componentes de software que sean más amenos al uso deFusion. Escoja un o dos componentes de bajo riesgo para aplicar el método. No planee hacer todo el análisis, seguido por todo el diseño, seguido por toda laimplementación. Tome confianza convirtiendo una pequeña parte en código lo antesposible. No es necesario que la totalidad del equipo de proyecto esté involucradadirectamente usando el método. Aquéllos que no estén analizando ni diseñando puedenparticipar revisando. Un experto en el método puede llegar a ser muy eficaz actuando como mentor yconsultor extraoficial del resto del equipo.• Adaptación de Fusion. ¿Qué es la versión ligera de Fusion (Fusion Lightweigt)?Un proyecto no siempre puede poder adoptar la versión de Fusion completa. Entoncesse pueden introducir una versión más ligera.Estas simplificaciones significan que se requiere menos esfuerzo en aprender el método.Ejemplos de estas simplificaciones son: - En el modelo de funcionamiento omitir las cláusulas Asume y Resultados. - Reemplazar el modelo del ciclo de vida por guiones - En las descripciones de clase omitir la información sobre la visibilidad, el tiempo de vida y la mutabilidad de los atributos de los objetos.El costo de utilizar esta versión ligera es que habrá menos documentación para laimplementación y un menor soporte para el mantenimiento. Pág. 55.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoSMM (Shlaer & Mellor Method)CaracterísticasEs una metodología bastante rígida. Sus assets resultan fáciles de verificar. Es válidopara proyectos de muy diversos tamaños. Incluye la planificación dentro de sus fasesmediante el uso de una técnica denominada “matriz de proyecto”.Su forma de trabajar consiste en la separación del problema a solventar en problemasindependientes, denominados “dominios”, y la división de los mismos en subsistemaspara poder analizarlos en profundidad.ProcesoUna vez diferenciados los dominios, se procede al análisis de cada uno de ellosconsiguiendo un modelo de cada dominio:1. División del problema en dominios: Hay 4 tipos de dominios: de Aplicación(usuario), de Servicio (interfaz), de Arquitectura (datos y su control.) y deImplementación (sistema operativo).2. Análisis del Dominio de Aplicación: Se crean varios modelos, para cubrir lasespecificaciones del cliente: • Un Modelo de Información de los objetos en el que se reflejará el análisis conceptual. • Luego un Modelo de Estados que refleje el comportamiento del sistema. • Por último una descripción de acciones específicas, usando A-DFDs.Para toda esta fase se pueden usar herramientas CASE. La metodología también defineuna serie de modelos de subsistemas adicionales.3. Confirmación del análisis: Validar que cumple los requisitos y tiene la formaadecuada. Se hace una simulación mediante secuencias del tipo “Estado_inicial-Comportamiento-Acción” para comprobar si realmente la aplicación va a funcionarcomo deseamos.4. Extracción de requisitos para los Dominios de Servicio. Se representan los dominioscomo elipses. Ahora, a todos los requisitos implícitos no descritos por el cliente(aquellos que tratan sobre la interrelación entre los dominios) se representan por unaflecha entre los dominios afectados, denominada ‘puente’. Deben quedar reflejadosdarse todos estos requisitos, tanto los cualitativos como los cuantitativos.5. Análisis de los Dominios de Servicio: Una vez que ya tenemos los requisitos de losdominios del cliente, pasamos a analizar este segundo tipo de dominios en los quesubdividimos nuestro problema.6. Especificación del Dominio de Arquitectura: En este dominio se especifican facetasde diseño (estructuras de datos a usar, autómatas de control, threads, algoritmos,...). Seusarán los siguientes diagramas: de pertenencia/dependencia -> de clases(estructura Pág. 56.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objetoexterna) -> de estructura de clase(estructura interna). Cada diagrama puede contener o +de los otros tipos, para explicar sus contenidos.7. Construcción del Dominio de Arquitectura: Tiene dos tipos de componentes: • Mecanismos: Procesos que lleva a cabo el sistema. • Estructuras: Colecciones de datos organizadas y arquetipos.8. Codificación de los modelos: Para la codificación nos dan unas pautas generales,aunque ya nos avisa que no tienen por que ser totalmente seguidas debido a la diferenciaexistente entre un LPOO y otro.9. Beneficios: Los desarrollos apoyados en esta metodología son fáciles de verificar.Usa un refinamiento sucesivo, y un acercamiento integral al problema. Los programasson mucho más reutilizables. Existen herramientas CASE que automatizan tosa lametodología.Principales assets generadosFase de análisis Fase de diseñoSystem Level: System Level: Domain Chart Task Communication Diagram Project matrixDomain Level: Task Level: Subsystem Relationship Model Inheritance Diagram Subsystem Communication Model Dependency Diagram Subsystem Access Model Task ArchetypesSubsystem Level: Class Level: Object Information Model Class Diagram Object Communication Model Class Structure Chart Object Access Model Class ArchetypesObject Level: Fase de impementación Object State Model Populated Task Archetypes State Action Specification Populated Module Archetypes Pág. 57.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoEROOS: (Especificaciones Orientadas a Objeto E-R)IntroducciónEs una metodología desarrollada por “Software Development Methodology ResearchGroup”. Tiene tanto una notación como una serie de estrategias para el desarrollo desoftware (desde el análisis hasta la implementación). Todas las especificaciones que sehacen son declarativas, permitiendo posponer así decisiones de diseño eimplementación para justo antes de la codificación, pero habiendo ya realizado un buenanálisis.Intenta acabar con el método de trabajo tradicional al considerarlo ‘informal, ambiguo eincompleto’.CaracterísticasLa potencia de EROOS queda resumida en 3 puntos:1. Combina el modelado del comportamiento con el modelado de las estructuras arepresentar. Una integración total de estos dos modelados proporcionaría al método deespecificación unas propiedades de composición y descomposición mucho máspotentes. Esto llevaría a un software mejor estructurado, mantenible y reutilizable.2. Descripción del software declarativa (no operacional). La primera descripción de ‘loque el sistema ha de hacer’, en lugar de ‘cómo’ le permite ir transformándose sin perderde vista el problema a solventar. Esto da un nivel de abstracción adecuado a cada fasedel desarrollo.3. Separación del dominio del problema de su solución. Esto crea un sistema flexible ycambiable, pero con un núcleo sólido. La funcionalidad del sistema se reflejará en esenúcleo, permitiendo que el sistema se adapte a las peticiones del usuario, en lugar decomenzar desde el principio cada vez que surja una nueva demanda.Una de las virtudes de EROOS es que al dar una notación y reglas a seguir, solo puededarse una solución a un problema (estando en un determinado nivel de abstracción). Asíse minimizan los malentendidos por malas interpretaciones y se facilita el trabajo engrupo.Existen herramientas generadoras de código C++ y herramientas CASE basadas en estametodología que ayudan a llevarla a la práctica.Ciclo de VidaComienza por la solicitud de los requisitos (no después).1. Análisis:• Análisis del contexto del problema: Uso de técnicas de modelado de negocio. Pág. 58.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto• Especificación del problema: Mentalidad de gerente. Especificar los requisitos de la solución.• Especificación de las soluciones: Reingeniería de procesos de negocio e idear nuevas soluciones.2. Diseño: Ha de hacerse antes de dar la solución (información necesaria, decisionespersistentes, interfaces con el mundo real). A partir de ahí análisis y diseño del software(descomposición y restricciones):• Diseño de la solución: Optimización del tamaño, determinación de la información necesaria, toma de decisiones persistentes y definir las interfaces del sistema con el mundo exterior.• Análisis del software: Diseño y descomposición del sistema en subpartes para poder reutilizarlas o compartirlas. Toma de decisiones en cuanto a la distribución de la información y la concurrencia se refieren.• Diseño del software: Conseguir separar el lenguaje de la plataforma en que se ejecutará el programa, realización de las restricciones impuestas al sistema y de nuevo la toma de decisiones en cuanto a la distribución de la información y la concurrencia se refieren.3. Diseño de la solución:• Diseño del código: Selección del lenguaje adecuado para nuestro código y fusión entre el lenguaje y la plataforma. Toma de decisiones en cuanto a la distribución de la información y la concurrencia se refieren.• Codificación: Generación del código.Filosofía y Conceptos ContempladosLos siguientes conceptos son contemplados en la metodología (veáse su representaciónen el apartado “Notaciones”, que viene a continuación):• Objetos y clases: Los objetos son clasificados en clases, distinguiendo entre objetos presentes y pasados. Esto se consigue porque aunque la relación entre el objeto y su clase madre es estática, éste puede mantenerse aún después de la muerte de la clase como ‘archivado’, pudiendo accederse a sus valores, pero nunca más modificarlos. Siempre son creados y destruidos (poseen un ciclo de vida).• Relaciones: Refinan a las clases y especifican las relaciones que las unen. En realidad son objetos, con una existencia dependiente de los objetos implicados en la relación. Solo se permiten relaciones unarias y binarias.• Atributos, Dominios y Valores: Los valores son clasificados en dominios. Esos mismos valores decoran a las clases, y especifican sus propiedades. Una de sus diferencias con los objetos es que ni se crean ni son destruidos. En EROOS solo se puede acceder a los atributos mediante las funciones (servicios) que tiene cada clase, y no de otra forma que violaría el encapsulamiento.• Restricciones: Limitan las posibles relaciones o valores de los atributos. En EROOs las restricciones pueden ser de 3 tipos: Implícitas (Ej un objeto refinado tiene una Pág. 59.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto dependencia existencial de quienes proviene), Integradas (Ej: las de conectividad) y Explícitas (además de los dos tipos anteriores se pueden definir mediante lógica de primer orden). Han de definir las claúsulas que el sistema ha de cumplir en todo momentos, sin importarles cómo son preservadas.Se pueden definir triggers para que reaccionen a posibles violaciones de las restricciones. • Funcionalidades: Divididas en: Consultas dinámicas: Solo acceden a información del sistema y de los objetos, pero no la modifican. Con una flecha hacia arriba devuelve todos los objetos refinados en que una clase participa. Con una flecha hacia abajo devuelve el objeto al que la aplicamos. Con una flecha hacia la derecha devuelve los valores del objeto al que apunta. Eventos: Cambian el estado del sistema. Pueden estar localizados en: - Kernel: Constructores, destructores y mutadores. Los eventos del kernel se especifican mediante post-condiciones con ‘claúsulas de efecto’ que se redactan mediante lógica de primer orden. - Shell: Son más complejos y se especifican mediante combinaciones de funciones del kernel, consultas y otras del shell. • Generalización/especificación: Comprende las relaciones Is-a (“es un”). La herencia es una relación ISA a fin de cuentas. Este tipo de relaciones lo que hacen es ‘fortalecer’ las capacidades de una clase, lugo una clase refinada así debe tener una definición más sólida que su clase preferente. Además se le pueden añadir nuevas funcionalidades. • Herencia: En esta metodología la estructura del sistema se define en forma de herencias. Esto permite tener varios niveles de abstracción incluso dentro de un mismo modelo. Esto a su vez permite extender clases ya definidas, incluso reusarlas. Notación OBJETOS Y CLASES:Figura 33. Notación de objetos y clases en EROOS Pág. 60.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto RELACIONES: Figura 34. Notación para las relaciones entre clases en EROOS (1)Figura 35. Notación para las relaciones entre clasesen EROOS (2) ATRIBUTOS: Figura 36. Notación para los atributos en EROOS Pág. 61.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoRESTRICCIONES: Figura 37. Notación para las restricciones en EROOSCONSULTAS: Figura 38. Notación para las consultas en EROOSKERNEL: Figura 39. Notación para las funcionalidades del Kernel en EROOSSHELL: Figura 40. Notación para las funcionalidades del Shell en EROOS Pág. 62.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoGENERALIZACIÓN/ESPECIALICACIÓN: Figura 41. Notación para las relaciones Is_A en EROOS Pág. 63.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoMetodología MOSESIntroducciónLa metodología MOSES (Methodology for Object-Oriented Software Engineering ofSystems) es una metodología que cubre todo el ciclo de vida del desarrollo de softwareorientado a objeto, no sólo análisis y diseño, sino la gestión de proyectos, planificaciónde negocio, mantenimiento de la aplicación y futuras mejoras. Incluye una notacióncompleta que además es soportada por algunas de las herramientas CASE que existenen el mercado, así como unas técnicas de gestión avanzadas que no están disponibles enninguna otra metodología.Muchas industrias están adoptando MOSES como metodología de desarrollo desoftware de calidad. Uno de los sitios donde se está realizando (buque insignia de estametodología) es en Dow Jones, para su sistema de ‘Telerate’ (Sistema de informaciónque distribuye del valor de las acciones de la bolsa de Dow Jones, Nueva York).MOSES es un compendio de:1. Un ciclo de vida de desarrollo de software basado en el modelo de ciclo de vida ‘fuente’ orientado a objeto.2. Un ciclo de vida del producto con 3 etapas orientadas al negocio.3. Un ciclo de vida de procesos con 5 fases solapadas orientadas a la parte técnica.4. Un conjunto de 20 actividades que componen una detallada guía de pasos a seguir.Ventajas que ofrece MOSES: Incorpora diagramas de modelización de negocio. Consigue unos procesos mejores. Da soporte a la reutilización. Las extensiones y modificaciones son más fáciles de gestionar. Está enfocada a la calidad. Crea una arquitectura flexible. Consigue una gestión adecuada de proyectos complejos. Da soporte a herramientas CASE.Modelo FuenteEl modelo fuente nos da un ciclo de vida de desarrollo software (SDLC) muy iterativo yrecursivo, que es especialmente adecuado para la construcción de software orientado aobjeto. Las ventajas de la reutilización y el análisis y diseño de dominios estánincorporadas, y así se consigue un modelo semánticamente muy rico, aunque flexible.En este modelo (que viene a reemplazar al ‘modelo cascada’ usado en análisisestructurado) aunque las fases son consecutivas, encontramos un considerablesolapamiento. Pág. 64.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoLa creación de sistemas orientados a objeto es más propicia a enfocarla en secciones,denominadas clusters o subsistemas (conjuntos de clases que van a trabajar conjunta yestrechamente). Bien, pues esta metodología da soporte a esta forma de trabajo,proponiendo un nuevo modelo fuente interno para cada uno de estos subsistemas.Como en el desarrollo de aplicaciones orientadas a objeto se busca un alto nivel degranuralidad, el solapamiento entre fases es significativamente menor, aunque laiteración sigue siendo una importante componente del proceso del ciclo de vida. Lageneralización y reutilización son tratadas específicamente. Figura 42. Modelo fuente del ciclo de vida de MOSES Pág. 65.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoCiclo de vida del productoExisten 3 etapas orientadas al negocio que son: Planificación, construcción y entrega(que se repiten recursivamente en cada versión generada del producto software). Tantola primera como la última han de involucrar al usuario, y comprenden las decisionesgenerales, mientras que la parte de construcción sería más técnica.La parte de construcción es en la que se generan más assets, y suele tener las siguientesfases internas: Planificación, investigación (estas 2 comprenden el ‘periodo decrecimiento’), especificación, implementación y revisión.Assets generados1. En la etapa de planificación de negocio:El estudio de planificación de negocio. Es un ‘asset textual’, es decir es una descripciónrealizada en algún procesador de textos en lenguaje natural.2. En la etapa de construcción:- 8 textuales: El plan de iteración, la especificación de requisitos del usuario, el glosariode escenarios y actores, la especificación de clases, la especificación deresponsabilidades de los subsistemas, el código fuente, resultados de las pruebas yresultados de la revisión.De estos 8 destacan 2: *) La especificación de clases (descripción de cada clase que aparecerá en el modelo de objetos y clases) que puede hacerse en una sintaxis formal basada en la usada en Eiffel o usando una sintaxis más informal. *) La especificación de responsabilidades de los subsistemas, que es usada para documentar los nombres de los distintos subsistemas, sus servicios, sus responsabilidades y colaboraciones. También se le conoce como SRS. Se usa un mecanismo similar a las tarjetas de clase (CRC).- 5 gráficos: El modelo de clases y objetos, el modelo de eventos, los diagramas deobjetos, el modelo de herencia y el modelo de estructuras de servicios:1. El modelo de clases y objetos (O/C Model) es el principal asset de MOSES. Representa la estructura estática del sistema (las clases, sus servicios y relaciones con otras clases). (Figura 1: parte superior izquierda).2. El modelo de herencia (inheritance model) se usa para mostrar la herencia que se produzca entre las diferentes clases, y aunque se puede integrar en el modelo anterior, se suele hacer en este otro. (Figura 1: parte superior derecha)3. El diagrama de objetos (objectchart) muestra las clases que presentan comportamiento dinámico. Muestra los diagramas de transición de estados aplicados a clases. (Figura 1: parte inferior izquierda).4. El modelo de eventos (event model) muestra las clases que presentan comportamiento dinámico. Muestra las secuencias de paso de mensajes entre un conjunto de objetos que colaboren. Se suelen usar para formalizar escenarios o casos de uso. (Figura 1: parte inferior derecha) Pág. 66.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto 5. El modelo de estructuras de servicio (SMM model) se suele usar significativamente bastante menos. Se aplica al diseño de la estructura interna de los métodos.Figura 43. Modelos gráficos principales de MOSES En la figura se observan : El modelo de clases y objetos( parte superior izquierda), El modelo de herencia (parte superior derecha), El diagrama de objetos (parte inferior izquierda) y El modelo de eventos (parte inferior derecha). 3. En la etapa de entrega: Estudio de la etapa de entrega (incluye el manual del usuario). Es un asset textual. Además de todas estas técnicas, para poder enfrentarse a proyectos complejos se incluyen cuatro técnicas (hojas, repositorio, visibilidad selectiva y subsistemas). Proceso de Ciclo de Vida (“las 20 actividades”) El proceso de ciclo de vida (process lifecycle) se ocupa de la etapa de construcción ya mencionada. Es dividida en cinco fases (planificación, investigación, especificación, implementación y revisión). Las fases cubren la parte de gestión, diseño y construcción Pág. 67.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objetode los diferentes assets. Es un proceso altamente iterativo, reconstruyendo los assets encada una de las iteraciones.Los assets (de la etapa de construcción) son generados desde cada actividad quecompone el proceso de ciclo de vida. Dependiendo de la profundidad a la que se llegueen una interacción se conseguirá realizar menos iteraciones, pero, por el contrario, conpoca profundidad podría obtenerse rápidamente un prototipo de la aplicación.Se compone de 20 actividades, que se recomienda sean ampliadas (por ejemplo en eldiseño de bases de datos, concurrencia, procesos distribuidos y computación en tiemporeal).Las 20 actividades son las siguientes:1. Contrato de especificación: Es un documento que describe el servicio a prestar,sin entrar en su implementación. MOSES recomienda el uso de afirmaciones (precondiciones, postcondiciones...) para formar un contrato que describirá los servicios que cumplirá. Estos contratos son constantemente refinados y actualizados durante el proceso de desarrollo.2. Revisión de la documentación: Debe ser llevada a cabo a unos intervalos regulares o en unos puntos predeterminados para asegurar la existencia, precisión y consistencia de los assets producidos hasta el momento.3. Construcción del modelo de eventos: Sirve para descubrir la secuencia de mensajes que se pasan entre los objetos como resultado de la solicitud de un servicio. Muestra las colaboraciones de los objetos y clases para llevar a cabo un determinado servicio. Para completar esta actividad debemos identificar las clases, servicios y mensajes que están involucrados en un escenario en particular.4. Generalización para la reutilización: Permite mejorar la calidad de las clases del proyecto, para una futura reutilización fuera del proyecto actual. Hay 3 subactividades para la generalización: ‘Completar la abstracción’, ‘Optimización de algoritmos’ y ‘Refinamiento de las jerarquías de clases’.5. Especificación genérica: Para asegurarse que las clases y objetos genéricos han sido descubiertos y especificados en el sistema. Una vez definidos, estas clases y objetos genéricos pueden formar una librería de clases reutilizables en futuros proyectos.6. Identificación de la herencia: Identifica las jerarquías entre las clases. MOSES refina el concepto de ‘herencia en generalización’ y ‘herencia de implementación’.7. Especificación de la interación: Es usada para identificar y definir relaciones entre clases desde los escenarios y la especificación de requisitos del usuario, o desde el modelo de eventos y diagrama de objetos. Existen subactivides para especificar agregaciones, asociaciones e invariantes.8. Plan de iteración del desarrollo: Es usado primordialmente en la fase de planificación para desarrollar un plan de proyecto que detalle los recursos necesarios, objetivos y plazos de la próxima iteración.9. Incorporación a la librería de clases: Es para la identificación y maximización de la reutilización de las librerías de clase existentes. La librería será investigada para determinar si las clases existentes en librerías son adecuadas para usarlas en este proyecto. Pág. 68.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto10. Construcción del diagrama de objetos: Se usa para construir una herramienta gráfica llamada ‘diagrama de objetos’, que es una extensión de los diagramas de estados y representa los cambios de estados de las clases individuales. Además puede ser usado para especificar completamente el comportamiento de los objetos, de las clases e identificar comportamientos erróneos. Para construir un diagrama de objetos, se debe identificar primero todos los estados aplicables a los objetos y todas las transiciones entre estos estados.11. Identificación de clases y objetos: Es una actividad para modelizar las actividades, identificar y especificar completamente todas las clases y objetos en el dominio del sistema de la aplicación. Esta actividad puede ser dividida en subactividades: refinar la lista de clases iniciales e identificar las clases persistentes.12. Optimización: Vale para optimizar en el diseño, con cambiar la estructura de las clases y sus interfaces. Requiere el conocimiento profundo de los aspectos físicos de la plataforma hardware en que implementaremos el producto.13. Evaluación de la calidad (medidas): Asegura que la clase generalizada para su reutilizabilidad posee la garantía suficiente. Las métricas juegan un rol insignificante.14. Desarrollo de escenarios: Usa el lenguaje natural para implementar la secuencia de interacción (los casos de uso) con un sistema desde el cual las clases, los eventos y las interacciones pueden ser identificados. Las acciones en el sistema son primeramente identificados, y entonces los escenarios pueden ser asociados a cada actor.15. Identificación de los servicios: Ayuda a comprender el comportamiento de los objetos, mediante la especificación de los servicios aplicables a una clase u objeto. Los servicios pueden ser tanto operaciones como propiedades.16. Coordinación de los subsistemas: Es usado en la gestión de tareas de proyectos grandes para descubrir redundancias potenciales y asociar la responsabilidad de una clase a un grupo de trabajo.17. Identificación de subsistemas: Ayuda a manejar sistemas complejos.18. Prueba: Da soporte a la verificación y validación del diseño y el código generado.19. Traducción al Lenguaje de Programación Orientado a Objeto (OOPL): Es básicamente la fase de implementación de un proyecto. Los servicios y estructuras han de codificarse en un determinado lenguajes y plataforma.20. Revisión de los requisitos del usuario: Desarrolla y define una especificación de requisitos formal y estable.Estas veinte actividades están asociadas en la tabla siguiente con las fases (proceso delciclo de vida). Las actividades pueden suceder en más de una fase: Pág. 69.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Figura 44. Relación entre las 20 actividades y las fases en que se realizan en la metodología MOSES Pág. 70.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoBONBON es una metodología de Ingeniería de Software que se inscribe en la categoría demetodologías puramente orientadas al objeto. Tiene su origen en la filosofía de ‘diseñoy programación por contrato’, junto con algunas características del modelo de objetospropuesto por el lenguaje Eiffel y diversas influencias del proyecto europeo ESPRIT II(Research and Development Program).Aunque BON (Business Object Notation) suele aparecer como una metodología ligadaal lenguaje Eiffel, su concepción es independiente de éste. Sin embargo muchas de sustécnicas encuentran un equivalente inmediato en Eiffel en el proceso deimplementación, lo cual facilita la construcción de herramientas CASE que simulen lametodología orientadas a este lenguaje en particular.BON es un método y una notación para un análisis y diseño orientados a objeto desistemas de alto nivel. Algunas de sus características más destacables son: • Hace énfasis en permitir un desarrollo sin transiciones. • Hace posible la reutilización del software a gran escala. • Refleja la confianza necesaria para hacer que los componentes reutilizables se acepten y utilicen por la industria del software.Sus principios fundamentales son: • Desarrollo “sin costuras” (Seamlessness). • Reversibilidad. • Software contractual. • Simplicidad. • Escalabilidad.Principios fundamentalesDesarrollo sin costuras (Seamlessness).El desarrollo sin costuras es el principio de utilizar un conjunto consistente de conceptosy notaciones a través del ciclo de vida del software, evitando lo que su falta genera enlos métodos tradicionales.Una ventaja muy importante del seamlessness es que facilita los procesos de traducciónautomática.Reversibilidad.Este principio complementa el proceso sin costuras, garantizando que los cambiosrealizados en cualquier paso del proceso, incluso en la implementación o elmantenimiento, puedan reflejarse hacia atrás en los primeros pasos, incluyendo elanálisis. Pág. 71.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoSi esto no fuera posible los primeros niveles de modelado pasan a ser obsoletos dejandosolamente el código fuente de la implementación como especificación del sistema, contodos los inconvenientes que esto supone.Software contractual.Con este principio la especificación de un gran sistema está distribuida entre todas suspartes componentes. Las responsabilidades de cada abstracción (clase) estánespecificadas por contratos expresados en función de otras abstracciones.Simplicidad.El principio de simplicidad indica que hay que minimizar el número de conceptosutilizados.Escalabilidad.El principio de escalabilidad se manifiesta en términos de la capacidad de soportar unformalismo para representar grupos de clases progresivos y soportar la división delproblema, basada en capas de abstracción como manejo de la complejidad estructural.Proceso de AnálisisEl objetivo del análisis es poner un cierto orden en nuestra concepción del mundo real.El propósito es simplificar, dominar la complejidad mediante la reformulación delproblema. Hay que eliminar redundancias y ruidos, encontrar inconsistencias, posponerdecisiones de implementación, dividir el espacio del problema...BON considera que el análisis se convierte en diseño cuando se toman decisiones deimplementación, cuando se introducen grados de protección para la información ocuando se introducen clases que no están relacionadas con el espacio de objetos delproblema.Proceso de diseñoEl diseño es un proceso que toma por entrada una representación del problema y latransforma en una representación de la solución, regresando al análisis si es necesario.En el diseño, las clases obtenidas en el análisis se extienden, generalizan y se transformasu representación en un esquema fácilmente traducible a un lenguaje de programaciónorientado al objeto.Se añade la especificación de nuevas clases que aparecen como interfaz con el exteriordel sistema, otras que son de utilidad básica para la construcción del sistema (clasescontenedoras...) y aquellas que son consideradas como clases de aplicación que tratancon información dependiente de la máquina o del sistema, con persistencia de objetos,manejo y recuperación de errores.En BON se modelan tanto el espacio del problema, como el espacio de la solución,como abstracciones de datos que encapsulan servicios. En el modelado, aunque loprimero en que se piense sea en un servicio, debe buscarse la abstracción (clase)subyacente que representa a aquellos individuos que ofrecen tal servicio. Pág. 72.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoEl primer principio es considerar las clases como una representación de tipos de datosabstractos que tienen un estado interno y ofrecen servicios, opuesto al criterio “las cosasque hacen” que está más cerca de las técnicas procedurales.Las clases no se ubican aisladamente sino que se agrupan en clusters. Durante elanálisis, los clusters ayudan ya que agrupan clases de acuerdo con un criterio deproximidad basado en funcionalidad de subsistema, en nivel de abstracción o en elpunto de vista del usuario final. En el diseño, son utilizados frecuentemente como unatécnica estructurada para visualizar selectivamente las conexiones entre las clases. Esmuy común comenzar por un cluster general y luego ir determinando otros después dehaber hecho ciertos agrupamientos de clases.Es importante ubicar el lugar de una clase dentro de la estructura completa. Esto implicaque encontrar clases relacionadas es más significativo que encontrar una clase aislada.Cada etapa en BON (análisis y diseño) refina el modelo general desde dos puntos devista distintos: arquitectura y comportamiento. El resultado es un modelo subdivididoen modelo estático y modelo dinámico. Las actividades globales, que se describen en lametodología para ir creando dichos modelos se describen en la Tabla A mientras que enla Tabla B y en la Figura 46 se describen los elementos gráficos más generales que seutilizan en la descripción del modelo.Es de destacar, que se propone comenzar un proceso de generalización. En este procesodebe analizarse si la arquitectura del sistema es suficientemente general para maximizarfuturas reutilizaciones. De esta manera, del conjunto de clases obtenidas se factorizanrecursos comunes en clases de alto nivel (por herencia o por genericidad) y las clasesexistentes se convierten en versiones especializadas de estas últimas. Pág. 73.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto TAREA DESCRIPCIÓN ESQUEMAEncontrar clases Delinear la frontera del sistema. Encontrar subsistemas, Tabla de Sistema (System Chart), metáforas de los usuarios, casos de uso. Tablas de Escenarios (scenario Charts)Clasificar Listar clases candidatas. Crear un glosario de términos Tabla de Clusters (Clusters Chart) técnicos.Encontrar clusters Tabla de Sistema (System Chart), Seleccionar clases y agruparlas en clusters. Clasificar, Tabla de Clusters (Clusters Chart), esbozar colaboraciones fundamentales entre clases Arquitectura (Static Architecture), Diccionario de clases (Class Dictionary)Definir los recursos de las Definir las clases. Determinar comandos (¿Qué serviciosclases pueden solicitar otras clases a esta?), consultas (¿Qué información pueden preguntar otras clases a esta?) y Tablas de Clases (Class Charts) restricciones (¿Qué conocimiento debe mantener la clase?)Seleccionar y describir Esbozar el comportamiento del sistema. Identificar Tablas de Eventos (Event Charts),escenarios de objetos eventos, creación de objetos y escenarios relevantes Tablas de Escenarios (Scenario Charts), derivados de la utilización del sistema Tablas de Creación (Creatio Charts), Escenarios de Objetos (Object Scenarios)Especificación de las Definir los recursos públicos. Especificar tipos, Interfaz de clases (Class Interfaces),condiciones contractuales. signaturas y contratos formales. Arquitectura (Static Architecture)Refinar el sistema. Interfaz de clases (Class Interfaces), Encontrar nuevas clases de diseño, adicionar nuevos Arquitectura (Static Architecture), recursos. Diccionario de clases (Class Dictionary), Tablas de Eventos (Event Charts), Escenarios de Objetos (Object Scenarios)Incrementar el potencial de Interfaz de clases (Class Interfaces),reusabilidad Generalizar. Factorizar comportamiento común. Arquitectura (Static Architecture), Diccionario de clases (Class Dictionary)Indexar y Documentar Documentar explícitamente la descripción de una clase mediante la cláusula de indexado. Completar la Interfaz de clases (Class Interfaces) información de documentación en el diccionario de Diccionario de clases (Class Dictionary) clases.Evolucionar la arquitectura Completar y revisar el sistema. Producir una arquitectura Modelos estático y dinámico finales dedel sistema final con un comportamiento del sistema. BON. Todos los esquemas completados. Tabla A. Actividades globales de BON.Tabla de Sistema (System Chart): Definición del sistema y lista de los clusters asociados. Solamenteuna Tabla de sistema por proyecto. Los subsistemas se describen mediante su correspondiente Tabla deCluster.Tablas de Clusters (Cluster Charts): Definición de clusters y lista de las clases asociadas y subclusters,si los hay. Un cluster representa un subsistema completo ó sólo un grupo de clases.Tablas de Clases (Class Charts): Definición de las clases de análisis en términos de comandos, consultasy restricciones, de forma que sea entendible para los expertos en el dominio y personal no técnico.Diccionario de Clases (Class Dictionary): Una lista alfabéticamente ordenada de todas las clases delsistema, mostrando el cluster al que pertenece cada clase y una breve descripción. Debe poder sergenerada automáticamente de las Tablas de Clase y de Interfaz.Arquitectura (Static Architecture): Conjunto de diagramas que posiblemente representan clustersanidados, encabezamientos de clases y sus relaciones. Una vista del sistema (con posibilidades de hacerzoom)Interfaz de Clases (Class Interfaces): Definiciones tipadas de las clases con la signatura de los recursosy contratos formales con un lenguaje basado en el cálculo de predicados. Vista detallada del sistemaTablas de Creación (Creation Charts): Lista de las clases que están a cargo de crear instancias de otrasclases. Normalmente se hace una para el sistema pero si se desea se puede incluir una por subsistema.Tablas de Eventos (Event Charts): Conjunto de eventos externos (estímulos) que disparan algúncomportamiento interesante del sistema y el conjunto de respuestas del sistema. Puede ser repetido paracada subsistema.Tablas de Escenarios (Scenario Charts): Lista de los escenarios de objetos utilizados para mostrar algúncomportamiento interesante y representativo del sistema. Los subsistemas pueden contener Tablas deEscenario locales.Escenarios de Objetos (Object Scenarios): Diagramas dinámicos que muestran comunicacionesrelevantes entre objetos para algunos o todos los escenarios que se describen en las Tablas de Escenarios. Tabla B. Elementos más característicos de BON. Pág. 74.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoFigura 45. Elementos gráficos de BON Pág. 75.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoLa Unificación de MétodosDespués de explicar varias metodologías (orientadas a objeto), se puede observar que, apesar de algunas notables diferencias existentes entre unas y otras, todas persiguen unmismo objetivo: la obtención de un software de calidad dentro del paradigma de laorientación al objeto.Por lo tanto se puede llegar fácilmente a la conclusión de que se intentará llegar a unaunificación de los diferentes métodos.He aquí una serie de motivos que también contribuyen a esta tendencia: El esfuerzo por la estandarización y la convergencia en la orientación al objeto. Los avances en herramientas CASE OO. El interés por el modelado de negocios mediante objetos.Comenzarán a surgir: UML, OPEN...UML (Unified Modelating Languaje)Proviene sobre todo de: Booch´93, OMT´93 y OOSE.La idea de unificación pretende en un principio estabilizar el caos existente en lasmetodologías orientadas a objeto, así como la aparición de un modelo más rico,producto del intercambio de experiencias en las tres metodologías génesis de UML.“Es un lenguaje para especificar, construir, visualizar y documentar ingenios software,cuyo alcance pretende cubrir los conceptos de Booch, OMT y OOSE resultando unlenguaje simple, común y ampliamente utilizable por usuarios de otras metodologías”.UML no es una metodología OO, sino una notación universal. El utilizar un lenguaje demodelado estandar le da un valor añadido.Es un lenguaje para representar los modelos que se obtienen a partir de la aplicación decualquier metodología OO.UML no fuerza a utilizar ninguna metodología concreta, porque presupone que distintosdominios de problemas conducen a diferentes métodos de análisis y diseño.En su versión 1.0 los principales elementos son: un metamodelo y una semántica, unanotación gráfica y un conjunto de recomendaciones.OPEN.OPEN fue creada en un principio a partir de una mezcla de algunas metodologías desegunda generación (MOSES, SOMA y “The Firesmith Method”).Es esencialmente un armazón para la tercera generación de métodos de desarrollosoftware en la orientación al objeto, suministrando un gran soporte para el proceso demodelado mediante el uso de modelos de ciclo de vida, mediante una captura derequisitos, y ofreciendo la habilidad de modelar o construir agentes inteligentes. Pág. 76.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoOPEN también toma conceptos de BON, Martin/Odell, OBA, RDD, ROOM, UML yotros.Ofrece un conjunto de principios para el modelado de todos los aspectos del desarrollosoftware: ciclo de vida, tareas, técnicas y modelado del lenguaje.OPEN extiende el concepto de metodología, no sólo incluyendo un modelo de procesos,sino también suministrando líneas para construir versiones del método que se ajusten alas necesidades del dominio industrial, organizaciones individuales...Los elementos principales de esta metodología son: Ciclo de vida o metamodelo. Técnicas. Representación.Se ha conseguido una metodología que comprenda, al menos, un conjunto de técnicas,más un modelo de ciclo de vida y una representación. Figura 46. Elementos principales de OPEN.Las actividades de OPEN tienen tareas que se ejecutan y se completan gracias a lastécnicas. Pág. 77.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto Figura 47. Descomposición de procesos en OPEN.OPEN representa la cúspide de los logros obtenidos en los métodos de orientación alobjeto por decenas de metodologías y un posible camino a seguir en un futuro todavíaincierto. Es de dominio público. Pág. 78.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoConclusiónLos métodos orientados a objeto presentan una visión idealizada del desarrollo desoftware. Describen una manera lógica, racional y sistemática de desarrollar softwareorientado a objeto. En la práctica, el desarrollo no se hace de una manera tan ordenada.Presentar el proceso de desarrollo de una manera racional hace más fácil ilustrar lasdependencias y relaciones entre las diferentes fases del desarrollo. El desarrollo delsoftware real no refleja semejante proceso racional pero la documentación producidarefleja, y en algún sentido "imita", el proceso racional.En el mundo empresarial la reutilización es uno de los valores añadidos que puedepresentar un elemento software, y en este sentido la orientación a objetos presenta unade sus mayores virtudes, pero esta cualidad perderá potencia si no se desarrolla bajo losparámetros que ofrece una metodología.Cualquiera de las metodologías explicadas es válida para trabajar en la orientación alobjeto. Sin embargo hoy en día se tiende a una unificación de los métodos, tal y comose ha visto en el apartado correspondiente. En este sentido cabe destacar la metodologíaObjetory, que en breve será publicada por “Los 3 Amigos” (Booch, Rumbaugh yJacobson), que se perfila como la metodología con más futuro y posiblemente launificadora de todas las publicadas actualmente. Una de las ventajas que ofrece esto esel hecho de utilizar una misma notación que todo el mundo comprenda y que no delugar a ambigüedades.Para poder llegar a esa unificación se ha de estudiar cada una de las metodologíasexistentes para poder tomar lo mejor de cada una de ellas.En este documento se han visto metodologías de todo tipo. Desde la menos rigurosa(que da una libertad de realización mayor al usuario) como puede ser Booch, hasta lamás estricta como es el caso de SMM. En cada caso y circunstancias concretas una uotra metodología será más adecuada, llegando incluso al extremo de combinar varias(Ej: usar el modelo de objetos de Booch y los 3 modelos de OMT).En cada una de las metodologías estudiadas destacan uno o varios aspectos. Así pues,Booch se centra en el diseño, OOSE en los casos de uso, SMM en los dominios, OMTen el análisis...La mayoría de las metodologías son una evolución de otra u otras metodologías. Así porejemplo FUSION es una metodología de segunda generación que ha heredado bastanteselementos de otras metodologías: el modelo de objetos de OMT, la interacción de CRC,la visibilidad de BOOCH, las precondiciones y postcondiciones de los métodosformales, etc.Para esta evolución sea posible tendrá que haber elementos de gran calidad en alguna delas metodologías para que ésta pueda ofrecerlos a otras metodologías. Así por ejemploOMT ofrece un modelo de objetos que contiene una enorme riqueza semántica, por loque ha sido adoptado por casi todas las metodologías de segunda generación. La yamencionada unificación de los métodos tiene un fuerte compromiso en este sentido.El hecho de que una metodologia presente algunas debilidades no quiere decir que nosea válida. Esto es algo que puede apreciarse muy bien en OMT, la cual posee un Pág. 79.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objetomodelo funcional bastante criticado y sin embargo es la más difundida actualmente,dada la solidez del resto de sus elementos.Existen metodologías que cubren las fases típicas de análisis, diseño e imlpementación(aunque algunas se centran sólo en el análisis y el diseño) mientras que también haymetodologías cuyo alcance se extiende a más partes del desarrollo. En concreto MOSESabarca, además de lo anterior, la gestión de proyectos, la planificación del negocio, elmantenimiento de la aplicación. Posee unas técnicas de gestión avanzadas no existentesen ninguna otra de las metodologías. Es por esto que se perfila como una de lasmetodologías de mayor futuro a la hora del desarrollo de un software de calidad.En principio las metodologías son independientes de cualquier lenguaje deprogramación. Sin embargo, en la práctica puede demostrarse que en algunos casos hayuna relación entre lenguajes y metodologías. Por ejemplo la metodología BON está muyligada al lenguaje Eiffel, sobre todo en la fase de implementación.Existen acutalmente en el mercado diversas herramientas CASE que ayudan adesarrollar bajo la filosofía de muchas de las metodologías (especialmente las desegunda generación).Algo común a todas ellas es que tengan unas reglas o pasos marcados a seguir, y unanotación que no de lugar a ambigüedades (al menos entre los usuarios de una mismametodología). Para evitar las ambigüedades entre todas las personas que trabajan en elmundo de la orientación al objeto ya están surgiendo los métodos unificados comoUML, OPEN, etc. )Hoy en día no se puede concebir la orienación al objeto (y el desarrollo de software engeneral) sin que existan por debajo unos métodos de trabajo que marquen unas pautas aseguir. Pág. 80.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a ObjetoBibliografía [Bailin, 1989] Bailin, S.C., “An Object-Oriented Requirements Specification Method”. Communications of the ACM. Vol.32 nº5, Mayo 1989. [Beck, 1989] Beck, K. and Cunningham, W. “A laboratory for teaching object- oriented thinking”. OOPSLA 89, SIGPLAN Notices. 1989. [Booch, 1991] Booch, G., “Object-Oriented Design with Application”. Redwood city, Benajmin/Cummings Publising Company. 1991. [Booch, 1994] Booch, G., “Object-Oriented Design with Application”. Redwood city, Benajmin/Cummings Publising Company. 1994. [BooRubin y Goldberg 1992] Rubin, K. y Goldberg A. “Object Behaviour Analysis”. CACM Vol.25 nº9. 1992. [Carnigie-Mellon U. 1996] Carnegie-Mellon University. "Teaching Model-based Software Engineering". OBJECT MAGAZINE. Enero 1996. [Coleman et al. 1994] Dereck Coleman, Patrick Arnold, Stepahnie Bodoff, Chris Dollin, Helena Gilchrist, Fiona Hayes, Paul Jeremes. “Object-Oriented Development: The Fusion Method”. Prentice Hall 1994, ISBN 0-13-338823-9. Prentice Hall International Edition 1994, ISBN 0-13-101040-9 [Cook y Daniels, 1994] Cook, S. y Daniels, J. “Designing Object Systems: Object-Oriented Modelling with Syntropy”. Prentice Hall. 1994. [Fichman y Kemerer, 1992] Fichman, R..G y Kemerer, C.F., “Object-Oriented and Conventional Analysis and Design Methologies”. IEEE Computer. Octuber 1992. [García, 1997] Francisco José García Peñalvo. “Apuntes de la Asignatura Análisis e Ingeniería del Software”. Universidad de Burgos. 1997. [García, 1998] Francisco José García Peñalvo. “Apuntes de la Asignatura Programación Avanzada”. Universidad de Burgos. 1998. [Graham et al. 1997] The Open Process Specification. Ian Graham, Brian Henderson-Sellers, Houman Younessi. Editorial. Addison-Wesley. 1.997. [Henderson-Sellers y Edwars 1994] Henderson-Sellers, B. y Edwars, J.M. “MOSES: A second generation object-oriented methodology”. Object Magazine. Junio 1994. [Henderson-Sellers, 1992] Henderson-Sellers, B., Edwards, J.M. and Constantine, L.L. “The O-O-O/EUON Handbook”, Centre for InformationTechnology Research Report No. 58, University of New South Wales, Sydney, Australia. 1992. [Jacobson el al. 1992] Jacobson J. et al. “Object-Oriented Software Engineeering. A Use Case Driven Approach”. ACM Press, Addison-Wesley. 1992 Pág. 81.
  • Trabajo Teórico de Programación Avanzada. Metodologías Orientadas a Objeto [Maddison, 1983] Maddison, R.N. “Information System Methodologies”. Wiley Henden 1983. [Martin y Odell, 1992] Martin, J. y Odell J. “Object Oriented Analysis and Design”. Prentice-Hall. 1992. [Martin, 1993] Martin J. “Principles of Object-Oriented Analysis and Design”, Prentice-Hall. ISBN 0-13-720871-5. [Meyer 1992] Meyer, B. “Eiffel: The Language”. Prentice Hall, New York.1992. [Meyer, 1988] Meyer, B. “Object-oriented Software Construction”. Prentice Hall, Hemel Hempstead. 1988. [Meyer, 1989] Meyer, B. “From structured programming to object-oriented design: the road to Eiffel, Structured Programming”, 1989. [Page-Jones et al. 1990] Page-Jones, M. Constantine, L.L., and Weiss, S. “Modeling object-oriented systems: the Uniform Object Notation”. Computer Language. 1990. [Piattini 1994] Piattini, M.G. “Definición de un ametodología para el desarrollo de bases de datos orientadas al objeto fundamentadas en extensiones del modelo relacional”. Tesis doctoral, Facultad de Informática, Universidad Politécnica de Madrid. 1994. [Piattini et al. 1996] Mario G. Piattini Velthuis, José A. Calvo-Manzano, Joaquín Cervera y Luis Fernández. “Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión”. Ra-ma. 1996. [Renouf y Henderson, 1995] Renouf, D.W. y Henderson-Sellers, B. “A Incorporating roles into MOSES”. Prentice Hall. 1995. [Rumbaugh et al. 1991] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lornsen. “Object-Oriented Modeling and Design”. Prentice-Hall International Editions. ISBN 0-13-630054-5 [Shlaer y Mellor, 1988] Sally Shlaer and Stephen J. Mellor. “Object-Oriented Systems Analysis: Modeling the World in Data”. Prentice Hall. 1988. [Shlaer y Mellor, 1990] Sally Shlaer and Stephen J. Mellor. “Recursive Design, in Computer Language”. Miller Freeman, Inc. 1990. [Shlaer y Mellor, 1992] Sally Shlaer and Stephen J. Mellor. “Object Lifecycles: Modeling the World in States“. Prentice Hall. 1992. [Singer, 1993] Singer, G. “An electric approach to developing an Object-Oriented methodology”. Object Magazine. Noviembre/Diciembre 1993. [Steegmans et al, 1995] Steegmans, E., Lewi, J., DHaese, M., Dockx, J., Jehoul, D., Swennen, B., Van Baelen, S., and Van Hirtum, P. “EROOS Reference Manual Version 1.0”. Department of Computer Science, Katholieke Universiteit Leuven. 1995. [Wirfs-Brock et al., 1990] Wirfs-Brock, R.J., Wilkerson, B. and Wiener, L. “Designing Object-Oriented Software”. Prentice Hall. 1990. Pág. 82.