Metodologias1 121105164855 Phpapp01.Desbloqueado

Trabajo Terico de Programacin Avanzada. Metodologas Orientadas a Objeto

Pg. 1.

3 I. T. INFORMTICA DE GESTIN PROGRAMACIN AVANZADA

IGNACIO CRUZADO NUO JORGE GARCA DEL EGIDO JAVIER PORTUGAL ALONSO


Pg. 2.

RESUMEN................................................................................................................................................. 4 PALABRAS CLAVE ................................................................................................................................... 4

METODOLOGAS ORIENTADAS A OBJETOS. ................................................................................ 5

INTRODUCCIN ........................................................................................................................................ 5 Concepto de metodologa................................................................................................................... 5 Generalidades .................................................................................................................................... 6 Clasificaciones ................................................................................................................................... 6

EL MTODO DE BOOCH.......................................................................................................................... 8 Introduccin. ...................................................................................................................................... 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 interaccin de Clases y objetos................................................................................................................14 Construccin de Clases y Objetos de Calidad...............................................................................................14

Clasificacin .................................................................................................................................... 15 Aproximacin a las clasificaciones...............................................................................................................15 Procedimientos para encontrar clases y objetos............................................................................................15

El mtodo ......................................................................................................................................... 16 Diagramas de clases......................................................................................................................................17 Diagramas de objetos....................................................................................................................................21 Otros diagramas............................................................................................................................................23 Los procesos del desarrollo orientado al objeto ............................................................................................26

Conclusin........................................................................................................................................ 26 Un ejemplo concreto ........................................................................................................................ 26

OMT (OBJECT MODELING TECNIQUE) JAMES RAMBAUGH................................................................... 28 Visin general .................................................................................................................................. 28 Fases (4)........................................................................................................................................... 28 Pasos especficos a dar en cada fase ............................................................................................... 29

Fase De Anlisis ...........................................................................................................................................29 Fase De Diseo Del Sistema.........................................................................................................................30 Fase de Diseo De Objetos...........................................................................................................................30 Implementacin ............................................................................................................................................31

Conclusin........................................................................................................................................ 31 Notacin ........................................................................................................................................... 31

MTODO DE FUSION. COLEMAN ............................................................................................................ 33 Introduccin ..................................................................................................................................... 33 Anlisis............................................................................................................................................. 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 Anlisis .......................................................................................................................... 38 Diccionario de datos .....................................................................................................................................38 Desarrollo del Modelo de Objetos ................................................................................................................39 Determinacin de la Interface del Sistema....................................................................................................39 Desarrollo del Modelo de la Interface...........................................................................................................41 Verificando los Modelos del Anlisis...........................................................................................................41

Diseo .............................................................................................................................................. 42 Grfico de Interaccin de Objetos ................................................................................................................43 Grficos de visibilidad..................................................................................................................................47 Descripciones de clase..................................................................................................................................50 Grficos de herencia .....................................................................................................................................52

Implementacin ................................................................................................................................ 55


Pg. 3.

Gestin de un Desarrollo Fusion ..................................................................................................... 55 SMM (SHLAER & MELLOR METHOD) ................................................................................................... 56

Caractersticas ................................................................................................................................. 56 Proceso............................................................................................................................................. 56 Principales assets generados ........................................................................................................... 57

EROOS: (ESPECIFICACIONES ORIENTADAS A OBJETO E-R) ................................................................. 58 Introduccin ..................................................................................................................................... 58 Caractersticas ................................................................................................................................. 58 Ciclo de Vida.................................................................................................................................... 58 Filosofa y Conceptos Contemplados............................................................................................... 59 Notacin ........................................................................................................................................... 60

METODOLOGA MOSES ........................................................................................................................ 64 Introduccin ..................................................................................................................................... 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 Anlisis .......................................................................................................................... 72 Proceso de diseo............................................................................................................................. 72

LA UNIFICACIN DE MTODOS.............................................................................................................. 76 UML (Unified Modelating Languaje) .............................................................................................. 76 OPEN. .............................................................................................................................................. 76

CONCLUSIN ......................................................................................................................................... 79 BIBLIOGRAFA ....................................................................................................................................... 81


Pg. 4.

Resumen En el mundo de desarrollo de software, se tiende cada vez ms hacia la programacin orientada a objeto, un nuevo paradigma de programacin que aporta grandes ventajas al software generado, como son el acercamiento entre el concepto del usuario y el resultado programado o la disponibilidad a la reutilizacin del cdigo generado.

Pero todo ello no es posible sin seguir una metodologa que, por medio del establecimiento de pasos, normas y conceptos a aplicar, lleve el desarrollo a buen puerto, y con un resultado ptimo.

En este documento se pretende acercar al lector a las metodologas orientadas a objeto que existen en la actualidad y dar una visin global de las mismas. As pues se hace especial hincapi en OMT (la ms difundida actualmente), BOOCH (como punto de partida de los conceptos que conlleva la orientacin a objeto) y FUSION (como una metodologa ms desarrollada).

No pasa inadvertido que el futuro de las metodologas se basa en su unificacin, y por ello este documento explica brevemente UML (como notacin unificadora) y OPEN (como metodologa). En cualquier caso habr que esperar a la publicacin de OBJETORY, que se perfila como la metodologa unificadora y de ms futuro.

Palabras Clave Metodologa, orientacin a objeto, ciclo de vida, notacin, proceso, Booch, OMT, Fusion, UML, OPEN, MOSES, EROOS, OOSE, BON, unificacin, clase, objeto, anlisis, diseo.


Pg. 5.

Metodologas orientadas a objetos.

Introduccin Con este trabajo se pretende acercar un poco ms al lector al mundo de las metodologas orientadas a objeto. Es un mundo en contnua expansin.

Se tratar de ofrecer una idea global de las metodologas orintadas a objeto y profundizar algo ms en las ms conocidas: Booch, como punto de partida de los conceptos de la orientacin a objetos. OMT, como la metodologa ms difundida en los desarrollos realizados

actualmente. Fusion, como ejemplo de metodologa proveniente de otros mtodos (2

generacin).

Hoy en da se est trabajando en buscar una unificacin de mtodos. En esta lnea se ha llegado a una unificacin en la notacin (UML). No se explicar muy detalladamente pues merecera un artculo aparte.

Concepto de metodologa No existe un consenso entre los diversos autores sobre el concepto de metodologa.

Genricamente se puede decir que una metodologa es un conjunto de pasos que deben seguirse para el desarrollo de software. Conjunto de filosofas, fases, procedimientos, reglas, tcnicas, herramientas, documentacin y aspectos de formacin para los desarrolladores de sistemas de informacin. Segn esto, una metodologa es un conjunto de componentes que especifican:

Cmo dividir un proyecto en etapas. Qu tareas se llevarn a cabo en cada etapa Qu salidas se producen y cundo deben producirse. Qu restricciones se aplican. Qu herramientas van a ser utilizadas. Cmo se gestiona y controla el proyecto.

R.N. Maddison

De un modo ms general una metodologa podra definirse como un conjunto de conceptos para poder abstraer el dominio del problema, una notacin para representar esos conceptos, una serie de pasos y procedimientos a seguir, y un conjunto de assets generados.


Pg. 6.

Generalidades Todas las metodologas distinguen estas tres fases:

Anlisis Diseo Implementacin

Segn Piattini [Piattini et al., 1996], se puede observar un cambio filosfico entre las metodologas clsicas de anlisis y diseo estructurado y las de orientacin al objeto. En las primeras se examinan los sistemas desde el punto de vista de las funciones o tareas que deben realizar, tareas que se van descomponiendo sucesivamente en otras tareas ms pequeas y que forman los bloques o mdulos de las aplicaciones. En la orientacin al objeto, por su parte, cobra mucha ms importancia el aspecto de modelado del sistema, examinando el dominio del problema como un conjunto de objetos que interactan entre s.

En las metodologas tradicionales se produce una dicotoma entre los dos elementos constituyentes de un sistema: funciones que llevan a cabo los programas y datos que se almacenan en ficheros o bases de datos. Sin embargo, la orientacin al objeto propugna un enfoque unificador de ambos aspectos, que se encapsulan en los objetos.

Clasificaciones Se pueden identificar dos enfoques en las metodologas orientadas al objeto, [Fichman y Kemerer, 1992]:

Revolucionarias o puras, que extienden la orientacin al objeto como un cambio profundo que convierte a las metodologas estructuradas en obsoletas. En este apartado podran incluirse metodologas como OOD de [Booch, 1991] o CRC/RDD de [Wirfs-Brock et al., 1990].

Sintetistas o evolutivas, que piensan que el anlisis y diseo estructurados constituyen la base para el desarrollo orientado al objeto, pudindose combinar elementos del anlisis y diseo estructurados con los de la orientacin al objeto. Ejemplos de este tipo podran ser OMT [Rumbaugh et al., 1991], SYNTHESIS [Bailin, 1989] o [Martin y Odell, 1992].

ltimamente estn apareciendo nuevas metodologas de desarrollo orientado al objeto, catalogadas como de segunda generacin, basadas en las citadas anteriormente; de las que formaran 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], MTODO UNIFICADO [Booch y Rumbaugh, 1995] o MEDEA [Piattini, 1994]. En esta segunda generacin se aprovechan las tcnicas y los procedimientos de las primeras metodologas, especialmente las tarjetas de clase (CRCs), el proceso y notacin de diseo de [Booch, 1991], el modelo de clases de OMT y los escenarios de Jacobson, con el fin de construir metodologas ms completas y sistemticas en las que juegan tambin un papel relevante las mtricas y los lenguajes formales, as como modelos para la mejora del software, como los del SEI (CMM) o ISO (SPICE).


Pg. 7.

Otra posible clasificacin, en funcin de en qu se centran, es:

Metodologas dirigidas por los datos (data-driven) - OMT (Rumbaugh et al. 1991)

- FUSION (Coleman et al. 1994)

Metodologas dirigidas por las responsabilidades (responsability-driven) - RDD (Wirfs-Brock et al. 1990)

- OBA (Rubin y Goldberg 1992)

Metodologas dirigidas por los casos de uso (use case-driven) - OOSE (Jacobson et al. 1992)

Metodologas dirigidas por estados (state-driven) - Metodologa de Shlaer y Mellor 1992)


Pg. 8.

El mtodo de BOOCH

Introduccin. El mtodo de Grady Booch es uno de los ms conocidos en la orientacin al objeto.

En su versin de 1.993 este mtodo cubre las fases de anlisis y diseo dentro de un desarrollo orientado al objeto.

Se definirn una gran cantidad de smbolos para representar las distintas decisiones de diseo.

Este mtodo ofrece una gran libertad en la produccin del software, como ya veremos ms adelante.

En un primer momento se explicarn una serie de conceptos bsicos, los cuales han de quedar claros para poder comprender a fondo la metodologa de Booch.

Dichos conceptos se pueden estructurar estructurarlos de la siguiente manera: Complejidad. El modelo del objeto. Clases y objetos. Clasificacin.

La complejidad El software, por lo general, va a ser un sistema complejo, sobre todo cuando se trate de un software grande. Esto es debido a 4 elementos:

La complejidad del dominio del problema. (Definicin 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 tcnicas:

Descomposicin: consiste en dividir el sistema en partes ms y ms pequeas cada vez, pudiendo ser stas refinadas independientemente.

Abstraccin: la abstraccin denota las caractersticas esenciales de un objeto que lo distinguen de todos los dems tipos de objetos y proporciona as fronteras conceptuales ntidamente definidas respecto a la perspectiva del observador.

Jerarqua: para Booch la jerarqua es una clasificacin u ordenacin de abstracciones. Existen dos clases de jerarqua:


Pg. 9.

jerarqua parte de (part of) o tiene un (has a): corresponde a la estructura del objeto.

jerarqua es un (is a): corresponde a la estructura de la clase.

El modelo del objeto La programacin orientada a objetos es un mtodo en el que los programas se organizan como una coleccin de objetos, representando cada uno una instancia de alguna clase, estando relacionadas todas las clases mediante una jerarqua.

Un programa que no tenga bien claros estos 3 elementos (que se tengan objetos en lugar de algoritmos, que cada objeto sea instancia de alguna clase, y que entre las clases exista una relacin de herencia que de lugar a una jerarqua) no puede considerarse orientado a objetos. Booch lo llama programacin con tipos de datos abstractos.

Se estudiarn las fases de anlisis y diseo en la orientacin al objeto. El anlisis se realizar a partir del dominio inicial del problema. A continuacin vendr el diseo.

Elementos del modelo de objetos Hay 4 elementos bsicos que constituyen dicho modelo:

Abstraccin. Encapsulamiento. Modularidad. Jerarqua.

Hay otros elementos (no principales) que son los siguientes: Tipos. Concurrencia. Persistencia.

La abstraccin. La abstraccin denota las caractersticas esenciales de un objeto que lo distinguen de todos los dems tipos de objetos y proporciona as fronteras conceptuales ntidamente definidas respecto a la perspectiva del observador.

Existen varios tipos de abstraccin:

Abstraccin de entidad: un objeto que representa un modelo til del problema de dominio de la entidad.

Abstraccin de accin: un objeto proporciona un conjunto generalizado de operaciones para una determinada funcin.

Abstraccin de la mquina virtual: un objeto que agrupa funcionamientos que son utilizados por niveles superiores de control, y por conjuntos de operaciones de niveles inferiores.

Abstraccin coincidental: un objeto que agrupa un conjunto de operaciones que no estn relacionadas con ninguna otra.

El encapsulamiento.


Pg. 10.

Es el proceso de almacenar en un mismo compartimento los elementos de una abstraccin que constituyen su estructura y su comportamiento; sirve para separar la interfaz contractual de una abstraccin y su implantacin. (El encapsulamiento oculta los detalles de la implementacin de un objeto).

La modularidad. Cuando se habla de modularidad hay que imaginarse la fragmentacin de un programa en componentes individuales para reducir la complejidad. Booch define modularidad como la propiedad que tiene un sistema que ha sido descompuesto en un conjunto de mdulos cohesivos y dbilmente acoplados.

Existen varias tcnicas para poder obtener una modularidad correcta o inteligente en nuestras clases y objetos: La reduccin de los costes del software viene apoyada por la descomposicin en

mdulos, ya que stos pueden disearse y revisarse independientemente. La estructura de cada modulo debe ser lo suficientemente simple como para que

pueda entenderse completamente. Debe ser posible modificar la implementacin de un mdulo sin tener conocimiento

de la implementacin de otros mdulos, y sin que se afecte al comportamiento de otros mdulos.

La facilidad de realizar un cambio en el diseo debera estar relacionada con la necesidad de ese cambio.

La identificacin de clases y objetos se corresponde con el diseo lgico del sistema. La identificacin de mdulos es parte del diseo fsico del sistema. No se pueden tomar todas las decisiones fsicas antes que las lgicas o viceversa. Ms bien, se suelen ir tomando a la vez.

La jerarqua. Para Booch la jerarqua es una clasificacin u ordenacin de abstracciones. Las 2 jerarquas ms importantes en un sistema complejo son la estructura de la clase (es un) y la estructura del objeto (parte de) o (tiene un).

La herencia es el ejemplo ms importante de jerarqua (es un), ya que va a definir las relaciones entre clases, tanto en el caso de herencia simple como en el caso de herencia mltiple.

Cuando se habla de jerarqua (es un) normalmente se refiriere a generalizacin / especializacin. Sin embargo (parte de) es ms bien un caso de agregacin. La combinacin de la herencia y la agregacin puede ser muy potente: la agregacin permite el agrupamiento fsico de las estructuras lgicas, y la jerarqua permite a estos grupos su funcionamiento en diferentes niveles de abstraccin.

Los tipos. Son la puesta en vigor de la clase de los objetos, de modo que los objetos de tipos distintos no pueden intercambiarse o, como mucho, pueden intercambiarse slo de formas muy restringidas.

Existen varias comprobaciones de tipos:


Pg. 11.

Comprobacin estricta: un objeto slo pude realizar aquellas operaciones que se encuentran definidas en la clase o en la superclase del objeto. Se comprueba en tiempo de compilacin.

Comprobacin dbil: un cliente puede mandar un mensaje a cualquier clase. No se detectar hasta el momento de la ejecucin.

La comprobacin estricta de tipos toma especial relevancia en las decisiones de diseo cuando la complejidad de nuestro sistema aumenta considerablemente.

Estos conceptos se hallan relacionados con los de ligadura esttica y ligadura dinmica; 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. En la programacin orientada a objetos la concurrencia permitir a diferentes objetos actuar simultneamente. Booch define concurrencia como: la propiedad que distingue un objeto 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, el objeto contina existiendo despus de que su creador deja de existir) y /o el espacio (es decir, la posicin del objeto vara con respecto al espacio de direcciones en el que fue creado). Dicho de otra manera, la persistencia conserva el estado de un objeto en el tiempo y en el espacio.

El espectro de persistencia abarcar lo siguiente: Resultados transitorios en la evaluacin de expresiones. Variables locales en la activacin de procedimientos. Variables globales y elementos del heap cuya duracin 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 objetos

La naturaleza de un objeto Un objeto tiene estado, comportamiento e identidad; la estructura y el comportamiento de objetos similares estn definidos en su clase comn; los trminos instancia y objeto son intercambiables.

Se explican a continuacin cada una de las partes de esta definicin:

Un objeto tiene estado: el estado de un objeto abarca todas las propiedades (normalmente estticas) del mismo ms los valores actuales (normalmente dinmicos) de cada una de esas propiedades.


Pg. 12.

Un objeto tiene comportamiento: el comportamiento de un objeto es cmo acta y se relaciona, en funcin 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 algn 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 dems objetos. No es conveniente que la identificacin 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 ms 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 se relacione con l.

Pero hay que constatar que un objeto puede tener diferentes roles o papeles, que han de definirse en la fase de diseo.

Igualdad de objetos: cuando hablamos de igualdad puede significar que dos nombres designan el mismo objeto, o que dos nombres designan objetos distintos cuyos estados son iguales.

Se puede considerar que en un ciclo de vida habr un primer momento de declaracin del objeto y luego vendr la asignacin o instanciacin del mismo.

Relaciones entre los objetos Los 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 conexin fsica o conceptual entre objetos. A travs del enlace un objeto cliente puede solicitar servicios a un objeto proveedor, bien directamente o bien a travs de enlaces con otros objetos.

Un objeto puede desempear cualquiera de estos 3 papeles:

Actor: cuando puede operar sobre otros objetos pero ningn objeto opera sobre l.

Servidor: otros objetos actan sobre l mientras que l no hace peticiones al resto.

Agente: puede operar sobre otros y tambin otros objetos pueden operar sobre l.

Agregaciones. Si los enlaces denotan una relacin cliente - servidor, la agregacin denotar una jerarqua de partes de un todo. Esas partes pueden ser fsicas (Ej. partes de un avin) o no fsicas (Ej. acciones de un accionista).

La agregacin a veces es mejor, porque encapsula partes como secretos de un todo. Los enlaces son ptimos en algunas ocasiones ya que permiten un acoplamiento ms dbil entre los objetos.


Pg. 13.

La naturaleza de una clase Booch define clase como un juego de objetos que comparten una estructura comn y un comportamiento comn. La clase es un medio necesario pero no suficiente para la descomposicin.

La interfaz de una clase suministra su vista externa y recalca la abstraccin, mientras que oculta su estructura y los secretos de su comportamiento.

Dicha interfaz puede estar dividida en 3 partes: Pblica: una declaracin que es accesible a todos los clientes. Protegida: una declaracin que es accesible a la clase, a las subclases y a las clases

amigas. Privada: una declaracin que a la que slo acceden la propia clase y las clases

amigas.

Relaciones entre las clases Hay 3 tipos bsicos de relaciones: Generalizacin / especializacin. Todo / partes. Asociacin.

Dichas relaciones pueden obtenerse como combinacin de algunas de estas otras: asociacin, herencia, agregacin, uso, instanciacin, metaclases...

La asociacin. Una asociacin describe un grupo de enlaces con una estructura y una semntica en comn.

La herencia. La herencia, para Booch, es una relacin entre clases, en la que una clase comparte la estructura o comportamiento definido en otra (herencia simple) u otras (herencia mltiple) clases.

La herencia define una relacin de tipo entre clases en la que una subclase hereda de una o ms superclases generalizadas; una subclase suele especializar a sus superclases aumentando o redefiniendo la estructura y comportamiento existentes.

El polimorfismo. Booch lo define como concepto de la teora de tipos, de acuerdo con el cual un nombre (como una declaracin de una variable) puede denotar objetos de muchas clases diferentes que se relacionan mediante alguna superclase comn; as todo objeto denotado por este nombre es capaz de responder a algn conjunto comn de operaciones de diferentes modos.

El polimorfismo es muy til cuando hay muchas clases con los mismos protocolos. Cada objeto conoce su propio tipo.

La agregacin.


Pg. 14.

El concepto de agregacin entre clases es equivalente al explicado para la relacin entre objetos.

El uso. Una relacin de uso es posiblemente una abstraccin en la cual aseguramos quin es el cliente y quin es el proveedor de un cierto servicio.

La instanciacin. La instanciacin se refiere al hecho de ir creando las instancias de las clases.

Aqu hay que destacar tambin el concepto de clase parametrizada, como plantilla de otras clases.

Las metaclases. Una metaclase es una clase cuyas instancias son a su vez clases.

La interaccin de Clases y objetos Durante la fase de anlisis 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 importantes y mecanismos. Esta vista representa el armazn lgico del sistema, y por consiguiente abarca la estructura de la clase y estructura del objeto del sistema.

En fases posteriores, y pasando entonces a la implementacin, el enfoque est en la vista interior de estas abstracciones importantes y mecanismos. Estas decisiones de diseo se explican como parte de la arquitectura del mdulo del sistema y arquitectura del proceso.

Construccin de Clases y Objetos de Calidad Para medir la calidad de una abstraccin se tiene lo siguiente: El acoplamiento: es la medida de la fuerza de una asociacin establecida por una

conexin entre clases. La cohesin: mide el grado de conectividad entre los elementos de una clase o

de un objeto. Suficiencia: significa que la clase capture bastantes caractersticas de la

abstraccin para permitir interaccin significante y eficaz. Completeness: una interfaz completa es aquella que cubre todos los aspectos

de la abstraccin. Primitiveness: desde que muchas operaciones de alto nivel estn compuestas

por operaciones de bajo nivel, se sugiere que esas clases sean primitivas.

Es muy frecuente que sobre el primer anlisis efectuado sobre las clases se haga necesario modificar y refinar las interfaces, e incluso a veces se llega a la creacin de


Pg. 15.

nuevas clases o a una reorganizacin de las relaciones existentes entre las que ya existen.

Es importante conocer el concepto de Visibilidad ya que la metdologa de Fusion se va a apoyar en l. Durante la fase de diseo conviene especificar cmo un objeto es visible 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 parmetro de alguna operacin del cliente. El objeto servidor es una parte del cliente. El objeto servidor est localmente declarado en el alcance del diagrama de

objetos.

Clasificacin La clasificacin va a ser fundamentalmente una cuestin de igualdad que ayudar a identificar las jerarquas de generalizacin, especializacin y agregacin entre clases. Tambin ayuda a la toma de decisiones sobre la modularizacin.

Es difcil llevar a cabo una buena clasificacin ya que no existe una clasificacin perfecta. Cualquier clasificacin es relativa al punto de vista de su autor. Por otra parte, una buena clasificacin requiere una gran creatividad e ingenio.

Aproximacin a las clasificaciones Se hacen tres divisiones: Categorizacin clsica: todas las entidades que tienen una propiedad o un conjunto

de propiedades en comn forman una categora. Esas propiedades han de ser necesarias y suficientes para constituir dicha categora. 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 descripcin.

Teora del prototipo: Una clase de objetos es representada por un objeto prototipo, y un objeto ser considerado miembro de la clase si y slo si se parece al prototipo de manera significativa.

En el primer caso hay que centrarse en las estructuras, en el segundo en la colaboracin de objetos, mientras que en el tercero se considera que el objeto est definido de acuerdo con una serie de caractersticas del objeto prototipo.

Procedimientos para encontrar clases y objetos Booch define las fases de anlisis y diseo como sigue: Anlisis: se va a modelar descubriendo las clases y objetos que forman el

vocabulario de dominio del problema. Diseo: se inventarn las abstracciones y los mecanismos necesarios para conseguir

el comportamiento que exige el modelo establecido en la fase de anlisis.


Pg. 16.

Existen unos cuantos mtodos para el anlisis de sistemas en orientacin al objeto:

Acercamientos clsicos: las clases y los objetos se derivan de los requisitos del problema.

Anlisis de comportamiento: se basa en el comportamiento dinmico existente entre clases y objetos. Se constituirn clases basadas en grupos de objetos que exhiban un comportamiento similar. Se formarn jerarquas de clases y subclases de acuerdo con unas responsabilidades que poseen todos los elementos de un mismo grupo.

Anlisis de dominio: se define como un intento de identificar los objetos, las operaciones y las relaciones, que los expertos del dominio consideran importante acerca del dominio.

Casos de uso: un caso de uso es una forma o patrn o ejemplo concreto de utilizacin, un escenario que comienza con algn usuario del sistema que inicia alguna transaccin o secuencia de eventos interrelacionados. Pueden utilizarse en el anlisis de requisitos de 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: el nombre de la clase, sus superclases y subclases, sus responsabilidades y sus colaboraciones.

El mtodo En la metodooga de Booch se explica qu hay que hacer para definir el sistema, pero no se da ninguna prescripcin para mejorar las fases de anlisis y diseo del sistema. Eso puede ser visto como una ventaja por parte de aquellos que prefieren disponer de una mayor libertad a la hora de producir software, y como una debilidad para aquellos que no dispongan de mucha experiencia y expertos en la orientacin al objeto.

Booch propone varias formas de describir un sistema en orientacin al objeto. El modelo lgico, por ejemplo, se representa bajo la estructura de clases y objetos. Mientras que el diagrama de clases es ms bien esttico, el diagrama de objetos muestra el comportamiento dinmico del sistema


Pg. 17.

Diagramas de clases Un diagrama de clases muestra las relaciones entre las abstracciones de un sistema (vista lgica).

En el diagrama se pueden representar todas o parte de las estructuras de clases de un sistema, esto es:

Clase: es la unidad modular de la descomposicin software orientada al objeto. Una clase representa un conjunto de elementos u objetos que comparten la misma estructura y un comportamiento comn. El comportamiento dinmico de una clase puede describirse gracias a su diagrama de transicin de estados.

Figura 1. Esquema del mtodo de Booch.


Pg. 18.

Clase Utilidad: constituida por una coleccin de subprogramas libres y declarada como parte de una clase que no tiene estado. (Aunque se puede decir que todos los mtodos son operaciones, no todas las operaciones son mtodos).

Clase Parametrizada: clase que sirve como plantilla para otras clases. Dicha plantilla puede contener parmetros de otras clases, objetos y/o operaciones. Normalmente las clases parametrizadas se utilizan como clases contenedoras. Los trminos clase genrica y clase parametrizada suelen ser intercambiables.

Figura 2. Notacin de clase" en Booch.

Figura 3. Notacin de clase utilidad en Booch.

Figura 4. Notacin de clase parametrizada en Booch.


Pg. 19.

Categoras de clase: coleccin lgica de clases, algunas de las cuales son visibles a otras categoras de clase mientras que otras estn ocultas. La mayora de los lenguajes de programacin en la orientacin al objeto no soportan las categoras de clase.

Atributos: un atributo de la clase describe una informacin singular guardada en cada caso. Puede ser muy til exponer algunos de los atributos relacionados con una clase.

Mtodos: los mtodos especifican que un determinado algoritmo ser aplicado a alguna instancia de la clase. Pueden dividirse en funciones y procedimientos, dependiendo de si devuelven un resultado o no.

Adornos y propiedades: son piezas secundarias de informacin sobre alguna entidad en el modelo del sistema. Se representan mediante una letra dentro de un tringulo. Las relaciones tambin pueden poseerlos; en C++ hay 3 propiedades:

1.esttica: la designacin de un miembro de la clase: objeto o funcin.

2.virtual: la designacin de una clase compartida en una estructura de herencia.

3.amiga: la designacin del acceso concedido a las partes no pblicas de una clase.

Control de exportacin (para atributos, operaciones y relaciones): los miembros pueden ser pblicos (accesibles para todos los clientes), protegidos (accesibles slo a subclases, amigos o a la propia clase), o privado (accesible a l y sus amigos).

Figura 5. Notacin de categoras de clase en Booch.

Figura 6. Notacin de adornos y propiedades en Booch.


Pg. 20.

Relaciones entre clases. Las clases colaboran entre s de diversas formas. Las conexiones esenciales entre clases son:

Asociacin: que tendr en cuenta una serie de aspectos: valor clave, restricciones, cardinalidad, papel que desempea, etiqueta...

Herencia: define una relacin entre clases donde una clase comparte la estructura o el comportamiento definido en otra u otras clases. La herencia representa una jerarqua de abstracciones donde una subclase hereda de una o ms superclases.

La notacin consiste en una flecha que apunta de la subclase a la superclase.

Agregacin: o relacin todo/parte; aparece como una asociacin con un crculo relleno que indica la agregacin.

Se puede encontrar agregacin por valor:

Figura 7. Notacin del control de la exportacin en Booch.

Figura 8. Notacin de asociacin entre clases en Booch.

Figura 9. Notacin de Herencia en Booch.

Figura 10. Notacin de Agregacin por valor en Booch.


Pg. 21.

Y agregacin por referencia:

Uso: el proveedor proporciona ciertos servicios (ver el apartado diagramas de objetos para averiguar cmo se ven los objetos entre ellos).

Instanciaciones:

Metaclases:

Diagramas de objetos Los diagramas de objetos son parte de la notacin del diseo orientado a objetos. Muestran todos o algunos objetos junto a sus relaciones en el modelo lgico del sistema. Pueden usarse para ver su ejecucin en diferentes escenarios.

En un diagrama de objetos se puede tener:

Figura 11. Notacin de Agregacin por referencia en Booch.

Figura 12. Notacin de Uso en Booch.

Figura 13. Notacin de instanciaciones en Booch.

Figura 14. Notacin de metaclases en Booch.


Pg. 22.

Objetos: un objeto es algo que puede hacer cosas; tiene estado, comportamiento e identidad. La estructura y el comportamiento de los objetos similares se definen en su clase comn. Un objeto es una instancia de una clase.

Enlace de objetos: este trmino deriva de Rumbaugh, quien lo define como conexin fsica o conceptual entre objetos. Muestra la asociacin entre un objeto Cliente que solicita una serie de servicios de un objeto Servidor, y la direccin seguida por los mensajes intercambiados entre los objetos.

Un objeto que participe de un enlace puede desempear 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 tambin otros pueden hacerlo sobre l.

Sincronizacin de enlaces (para objetos actores): ante mltiples tcnicas de control un objeto requiere ms que eso para tratar los problemas de exclusiones mutuas y conflictos que puedan presentarse. Los objetos actores tienen sus propios mtodos de control, pero con servidores se ha de escoger entre una de las siguientes aproximaciones:

Secuencial: un objeto activo en un instante.

Guarded: los clientes activos deben colaborar para conseguir la exclusin mutua.

Synchronous: el servidor garantiza la exclusin mutua.

Los mensajes se adornan utilizando la siguiente notacin:

Figura 15. Notacin de Objeto en Booch.

Figura 16. Notacin de Enlace de objetos en Booch.


Pg. 23.

Visibilidad de enlaces: los diagramas de clases muestran las dependencias existentes entre las clases de varios objetos. Pero no dictaminan cmo se ven esas instancias, entre ellas. Pro ello es posible adornar enlaces que representen la visibilidad del servidor desde el punto de vista del cliente.

Otros diagramas Diagrama de transicin de estados:

Se utiliza para mostrar el espacio de estados de una determinada clase, los eventos (mensajes) que disparan una transicin de un estado a otro y las acciones que resultan del cambio de estado.

La notacin empleada es la siguiente: un nico nombre para cada estado (que puede incluir acciones asociadas), flechas dirigidas para conectar los diferentes estados...

Figura 17. Notacin de sincronizacin de enlaces en Booch.

Figura 18. Notacin de visibilidad de enlaces en Booch.

Figura 19. Notacin de estado en Booch.


Pg. 24.

Una transicin conecta dos estados y tiene que haber un estado inicial en el diagrama.

Diagrama de Mdulos:

Se utiliza para mostrar la colocacin de las clases y objetos en los mdulos en el diseo fsico de un sistema. Indica la divisin de la arquitectura del sistema.

Los dos elementos esenciales del diagrama son: los mdulos y sus dependencias.

Un subsistema puede tener dependencias en otros subsistemas o mdulos, y un mdulo puede tener dependencias en un subsistema. La misma anotacin se usa para las dependencias de los subsistemas.

Diagrama de procesos:

Se usan para mostrar la asignacin de procesos a los procesadores en un diseo fsico del sistema. A travs de los diagramas se indica la coleccin de procesadores y dispositivos que sirven como plataforma para ejecutar el sistema.

Figura 20. Diagrama de transicin de estados en Booch.

Figura 21. Diagrama de mdulos en Booch.


Pg. 25.

Hay 3 elementos esenciales: procesadores, dispositivos y sus conexiones.

Diagrama de interaccin:

Traza la ejecucin 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 lneas verticales. Los mensajes se representan horizontalmente con flechas que van desde el cliente al servidor. La caja vertical representa el tiempo en el que el control est sobre dicho objeto.

Figura 22. Diagrama de procesos en Booch.

Figura 23. Diagrama de interaccin en Booch.


Pg. 26.

Los procesos del desarrollo orientado al objeto Booch soporta el desarrollo iterativo e incremental.

Define dos tipos de procesos para describir los niveles en un desarrollo orientado al objeto.

Macro procesos. Establecimiento de los requisitos principales (conceptualizacin).

Desarrollo de un modelo de comportamiento deseado (anlisis).

Creacin de una arquitectura (diseo).

Evolucin de la implementacin (evolucin).

Mantenimiento.

Micro procesos. Identificacin de las clases y de los objetos en un nivel de abstraccin dado.

Identificacin de la semntica de dichas clases y objetos.

Identificacin de las relaciones entre estas clases y objetos.

Especificar las interfaces y despus la implementacin de estas clases.

Conclusin La metodologa de Booch es muy poco rgida y ofrece gran libertad al usuario de la misma, lo cual, como ya se ha dicho, trae consigo una serie de ventajas e inconvenientes.

A partir de todos los conceptos que conforman el modelo de objetos para Booch y de la notacin que ofrece, el usuario ser el nico responsable de identificar las fases de anlisis y diseo del sistema. Siempre que se respete esa notacin y que los resultados obtenidos sean coherentes con los conceptos anteriormente explicados podr considerarse que el anlisis y el diseo se han llevado a cabo correctamente.

Un ejemplo concreto Segn Booch, una posible forma (que no tiene por qu ser la mejor) de desarrollar las fases de anlisis y diseo de un sistema informtico de Adquisicin de datos: estacin de monitorizacion del clima, podra ser:

Fase de anlisis: Definicin de los lmites del problema. (Servicios que proporcionar el sistema). Especificacin detallada de las necesidades del soporte hardware. Realizacin del diagrama de procesos del sistema. Ciclo de vida de algn objeto.


Pg. 27.

Jerarqua de clases. (Clase sensor). Diagramas de interaccin. (Temporizador). Escenarios. Diagrama de transicin de estados. (GestorEntrada).

Fase de diseo: Escoger el marco de referencia arquitectnica. Creacin de nuevas clases cuya creacin se ha visto necesaria. Se empiezan a definir internamente las clases.


Pg. 28.

OMT (Object Modeling Tecnique) James Rambaugh

Visin general Es una metodologa orientada a objeto muy difundida, de hecho es la que actualmente ms se est utilizando por encima incluso de la de Booch. Se desarroll en el Research and Development Center de General Electric a finales de los 80. Se hace cargo de todo el ciclo de vida del software, y durante ese tiempo mantiene la misma notacin. Se divide en cuatro fases consecutivas. Tiene una parte de diseo no muy compleja. Se centra mucho en un buen anlisis. Es de las denominadas dirigidas por los datos.

Fases (4) 1. Anlisis de objetos:

Se describe el problema: Se obtienen unos requisitos que no den lugar a dudas (rendimiento, funcionalidad, contexto,...). En toda la fase de anlisis se describe el comportamiento del sistema como una caja negra.

Se hacen los diagramas de objetos con su diccionario de datos. As obtengo el modelo de objetos. En l se define su la estructura de los objetos y clases as como las relaciones que les unen. Comprende tanto un Diagrama de Clases como un Diccionario de Datos que las explique. Este modelo debe ser refinado por medio de la iteracin.

Creacin de un modelo dinmico para describir los aspectos de control y evolucin del sistema. Incluye un Diagrama de Eventos del sistema y un Diagrama de Estado por cada clase que tenga un comportamiento dinmico.

Creacin de un modelo funcional que describa las funciones, los valores de entrada y salida, e imponga las restricciones pertinentes. Se suelen utilizar Diagramas de Flujo de Datos (DFDs).

Se verifican todos los modelos creados.

Se itera para conseguir un refinamiento de los 3 modelos.

2. Diseo del sistema: Comprende la arquitectura bsica. En esta fase se tomarn las decisiones estratgicas (a alto nivel) de diseo (estructura global del sistema).

3. Diseo de objetos: Es el ltimo paso antes de implementar, y sirve para definir completamente todas las caractersticas de los objetos. Se detallan los 3 modelos ya descritos en el anlisis 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 aplicacin.

4. Implementacin: Se codifica lo ya diseado.


Pg. 29.

Pasos especficos a dar en cada fase

Fase De Anlisis 1.Obtener y escribir una descripcin 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. - Aadir las asociaciones (y agregaciones) entre las clases. - Aadir 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 mdulos, basndose en su proximidad y funcin.

3.Construir un modelo dinmico: - Preparar los escenarios para las secuencias de interaccin tpicas 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 dinmico. - Chequear la consistencia (y que estn 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 funcin. - Identificar las restricciones. - Especificar criterios de optimizacin. (*) Este modelo ha sido bastante criticado, por no seguir los principios del AOO. Desde 1995 se recomienda que este modelo consista en una descripcin detallada de las operaciones del sistema, y solo usa DFDOO cuando estas operaciones impliquen a varios objetos. Conviene, para cada operacin especificar las siguientes cosas: Nombre, Responsabilidades, Entradas, Salidas, Objetos modificados, Precondiciones y Postcondiciones.

5.Verificar, iterar y refinar los tres modelos: - Aadir las operaciones claves que fueron descubiertas durante la preparacin

del modelo funcional al modelo de objetos. No mostrar todas las operaciones durante el anlisis, slo mostrar las ms importantes.


Pg. 30.

- Verificar que las clases, asociaciones, atributos y operaciones son consistentes y completas al nivel elegido de abstraccin. Compara los tres modelos con la definicin del problema y probar los modelos mediante el uso de escenarios.

- Desarrollar escenarios ms detallados (incluyendo condiciones que den errores) como variaciones de los escenarios bsicos. Usar estos escenarios y si... para verificar en el futuro los tres modelos.

- Iterar los pasos anteriores cuanto sea necesario para completar el anlisis.

Fase De Diseo Del Sistema 1. 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 la mquina a los distintos subsitemas (memoria, procesador, ficheros...).

4. Elegir la estrategia bsica 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 a ellos.

6. Elegir un mtodo de implementacin del control de software. Existen 3 tipos de control destacados: Por programa (sistemas dirigidos por procedimientos; C++), Por planificador 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 autmata de estados, o - Usar tareas de concurrencia.

7. Considerar las condiciones lmite.

8. Establecer las prioridades.

Fase de Diseo De Objetos 1. Obtener operaciones para el modelo de objetos a partir de los otros modelos:

- Encontrar una operacin para cada proceso del modelo funcional. - Definir una operacin por cada evento del modelo dinmico, dependiendo de

la implementacin del control.

2. Disear 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:


Pg. 31.

- Aadir 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 clculos repetidos.

4. Implementar el control software mediante el sistema elegido durante el diseo del sistema.

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 comn de grupos de clases. - Delegar para poder compartir comportamientos cuando la herencia sea

semnticamente invlida.

6. Diseo de la implementacin de las asociaciones: - Analizar las asociaciones transversales. - Implementar cada asociacin como si fuera un objeto distinto o aadiendo el

valor de los objetos como atributos de una o ambas clases de la asociacin.

7. Determinar la representacin exacta de los atributos de los objetos.

8. Compactar las clases y asociaciones en mdulos, ocultando en la parte privada toda la informacin que deba estar oculta.

Implementacin No se detiene en ella (al igual que la fase de pruebas), con lo que se queda a la eleccin del programador.

Conclusin Una de las grandes virtudes de OMT es su modelo de objetos, que contiene una enorme riqueza semntica, por lo que ha sido adaptado por casi todas las metodologas de segunda generacin, y es una de las bases metodolgicas de la metodologa Objetory que en breve aparecer (de la mano de los 3 amigos: Rambaugh, Booch y Jacobson) para completar a UML.

OMT es una metodologa bastante slida (si exceptuamos su modelo funcional, bastante criticado), que completado con otras tcnicas de representacin (CRCs, Casos de Uso...) la hacen la metodologa ms difundida (tanto a nivel universitario como empresarial) del momento.

Notacin Todas las relaciones y diagramas han de respetar la siguiente notacin:


Pg. 32.

Figura 24. Notacin de OMT para el Modelo de Objetos


Pg. 33.

Mtodo de Fusion. Coleman

Introduccin Fusion proporciona un mtodo de desarrollo de software orientado al objeto, que abarca desde la definicin de requisitos a la implementacin en un lenguaje de programacin.

Es considerada como una metodologa de segunda generacin, porque proviene de: OMT: modelo de objetos, CRC: interaccin de objetos, BOOCH: visibilidad, Los mtodos Formales: pre- y postcondiciones.

Proporciona un proceso de desarrollo, que se divide en: Anlisis, Diseo e Implementacin.1

Ofrece notaciones para los modelos, que describen varios aspectos del software. Actualmente ha abandonado su notacin.

Proporciona herramientas de gestin.

Anlisis El anlisis se basa ms en describir lo que hace un sistema en lugar de cmo lo hace. Para esto, hay que ver el sistema desde la perspectiva del usuario en lugar de desde la de la mquina. El anlisis casa con el dominio del problema y se preocupa por el comportamiento visible externamente.

La meta de la fase de anlisis 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 anlisis es un documento de definicin de requisitos en lenguaje natural.

1 Especifica el orden en el que deben hacerse las cosas dentro de cada fase. Tambin proporciona criterios de cundo pasar a la siguiente fase. 2 En la fase del anlisis de Fusion, slo los atributos de una clase son considerados. Los mtodos son considerados en la fase de diseo. Por consiguiente, en la fase del anlisis, los objetos son similares a las entidades en el tradicional modelo entidad relacin.


Pg. 34.

Modelo de objetos La 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 esttica de la informacin en el sistema, las clases y relaciones entre ellas, atributos de clases, agregacin, especializacin/generalizacin.

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 asociacin o correspondencia entre objetos que pertenecen a clases.

Para describir una relacin, se consideran los puntos siguientes:

Restricciones de Cardinalidad. Cardinalidad es el nmero de clases que pueden asociarse entre s en una relacin. Invariantes. Restricciones de que alguna propiedad se debe cumplir. Roles. Las clases que participan en una relacin tienen roles. Los nombres para los roles o papeles en una relacin deben ser nicos. Atributos de la relacin. Las relaciones, como los objetos, pueden tener atributos.3 Relaciones ternarias y ms altas. Las relaciones ternarias relacionan tres objetos separados. Las que involucran ms de tres objetos se llaman relaciones n-arias.

La agregacin es un mecanismo para estructurar el modelo de objetos. Permite la construccin de una clase agregada a partir de las otras clases componentes. La agregacin modela las relaciones todo/parte.

La generalizacin permite a una clase, llamada supertipo, ser formada sacando las propiedades comunes de varias clases, llamadas subtipos. La especializacin es el caso inverso en el que un nuevo subtipo se define como una versin ms especializada de un supertipo.4

La especializacin mltiple permite definir un nuevo subtipo como una especializacin de ms de un supertipo inmediato. La subclase hereda los atributos y relaciones de todas sus superclases.5

Un diagrama de modelado de objetos puede ser dividido en subdiagramas.

3 Esto corresponde al Atributo de Unin (Link Attribute) en el la notacin de Rumbaugh. 4 En el la anotacin de Rumbaugh, el supertipo se llama superclase, y el subtipo se llama subclase. Las notaciones del tringulo en Fusion son completamente opuestas a las de Rumbaugh. 5 En el la notacin de Rumbaugh, la especializacin mltiple se llama herencia mltiple. La notacin es exactamente la misma para los dos mtodos.


Pg. 35. Figura 25. Notacin del diagrama de objetos deFusion.


Pg. 36.

Modelo de Objetos del sistema El modelo de objetos del sistema es un subconjunto del modelo de objetos que describe el sistema a ser construido. Se forma excluyendo todas las clases y relaciones que pertenecen al entorno.

Usa la informacin 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 las relaciones dentro del modelo de objetos del sistema. El modelo de objetos del sistema es la base en la que se hace el resto del desarrollo.

Modelo de la Interface El modelo de la interface describe el comportamiento de un sistema, por ejemplo, define la comunicacin de entrada y salida del sistema. La descripcin est en trminos de eventos y el cambio de estado que ellos causan.6

Un sistema se modela como una entidad activa que interacta con otras entidades activas llamadas agentes. Los agentes modelan a los usuarios humanos, u otros sistemas hardware o software. Las caractersticas importantes de un agente son que es activo y se que comunica con el sistema.

Un modelo de la interface utiliza dos modelos para diferentes aspectos del comportamiento:

Modelo del funcionamiento Modelo de ciclo de vida

Modelo del Funcionamiento El modelo del funcionamiento (modelo funcional) especifica el comportamiento de las operaciones del sistema utilizando un Esquema de Modelado de Funcionamiento. Define efectos del funcionamiento en trminos de : cambios de estado, eventos que son salidas.

Una operacin del sistema es un evento de entrada y su efecto en un sistema. Las operaciones del sistema son invocadas por agentes en el entorno. Una operacin del sistema 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 relacin. Enviar un evento a un agente.

6 Un evento es una unidad instantnea y atmica de comunicacin entre el sistema y su ambiente. Un evento de entrada es enviado por un agente al sistema. Un evento de salida es enviado por el sistema a un agente. Un evento de entrada y el efecto que puede tener se llama una operacin del sistema.


Pg. 37.

El modelo del funcionamiento se expresa como una serie de esquemas llamados "Esquemas del Modelo del Funcionamiento." Debe haber un esquema por lo menos para cada operacin del sistema.

Semntica de cada entrada en la sintaxis del esquema. Operacin: Nombre de la operacin. Descripcin: Descripcin concisa de la operacin. Lee: Todos los valores a los que la operacin puede acceder sin modificacin. Cambia: Todos los valores a los que la operacin puede acceder y modificar. Enva: Lista de agentes y eventos que la operacin puede enviar. Asume: Pre-condicin, por ejemplo, lo que debe ser verdad antes de la operacin. Resultados: Post-condicin, por ejemplo, qu cambios han ocurrido por la operacin.

Modelo del Ciclo de Vida El modelo de ciclo de vida describe cmo el sistema se comunica con su entorno desde su creacin hasta su muerte. Consiste en expresiones del ciclo de vida. Una expresin del ciclo de vida define las secuencias aceptables de interacciones en las que un sistema puede participar en su tiempo de vida. Es algo parecido al modo en que una gramtica describe las secuencias aceptables de smbolos que son aceptadas por un compilador. 7

7 Este modelo puede ser reemplazado por guiones en la versin ligera de Fusion.

Figura 26. Esquema del modelo de funcionamiento.


Pg. 38.

Proceso de Anlisis El anlisis no es un proceso anrquico: hay una sucesin definida de pasos que pueden aplicarse iterativamente para producir una especificacin completa y consistente que capture los requisitos.

El anlisis es una actividad incremental e iterativa que formaliza los requisitos. Puede llevarse a cabo de una manera sistemtica.

En Fusion, el proceso de anlisis 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 lmite al modelo de objetos.

3. Desarrolle un modelo de interface. Desarrolle un modelo de ciclo de vida. Desarrolle un modelo de funcionamiento.

4. Verifique el modelo de anlisis.

Para todos, hasta para el ms trivial, de los problemas el proceso debe de ir acompaado por la construccin y uso de un diccionario del datos.

Diccionario de datos El diccionario de datos sirve para coleccionar informacin no disponible en los diagramas de Fusion. El diccionario de los datos es un almacn (repositorio) central de definiciones de trminos y conceptos.

Ejemplo de la estructura del diccionario de datos.

Figura 27. Ejemplo de la estructura del diccionario de datos.


Pg. 39.

Sin embargo, esto no es obligatorio, y el formato real del diccionario de los datos es insignificante.

Desarrollo del Modelo de Objetos Cmo empezar a construir el Modelo de Objetos? Empezar el anlisis puede ser a menudo la parte ms difcil. El anlisis debe empezarse con un alto nivel de abstraccin. Es mejor utilizar los requisitos para una tormenta de ideas de posibles clases y relaciones. Slo despus de que su estructura global sea satisfactoria deben aadirse los detalles. Hay que recordar que el modelo de objetos utiliza clases, mientras que un documento de requisitos es expresado principalmente en trminos de objetos especficos.

Cmo encontrar clase candidatas? Casi cualquier nombre puede dar lugar a una clase. Sin embargo, para serlo, el nombre debe pertenecer a un concepto que sea importante para la comprensin del dominio. Posibles fuentes de clases candidatas son: Objetos fsicos, Personas y organizaciones, Abstracciones.

Cmo encontrar relaciones? Modelan correspondencias entre objetos. Comunicaciones, asociaciones fsicas, contenciones, y acciones son todas las posibles fuentes para relaciones candidatas. Una vez que las listas de candidatas se ha hecho, deben racionalizarse. En ese punto, pueden usarse las clases y relaciones para empezar el diccionario de datos.

Qu debe ser considerado en las relaciones? Generalizacin Agregacin 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 anlisis siempre depende en parte de la experiencia, y incluso de la esttica del analista.

Es importante recordar que los objetos no tienen que modelar cosas: tambin pueden modelar abstracciones.

No hay que mal interpretar clases y relaciones como diagramas de flujo de datos.

Determinacin 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 tenga ningn atributo y que se relacione con slo otra clase, puede convertirse en atributos.


Pg. 40.

Durante el anlisis, un sistema es modelado como una entidad activa que coopera con otras entidades activas, llamadas agentes. El sistema y los agentes se comunican enviando y recibiendo eventos. Cuando los eventos son recibidos por el sistema, pueden causar un cambio de estado y eventos de salida. Un evento de la entrada y su efecto asociado son conocidos como una operacin del sistema.

La interface de un sistema es el conjunto de operaciones del sistema a las que puede responder y los eventos que puede enviar.

Una operacin del sistema siempre es invocada por un agente, no por un objeto; la fase del anlisis no se preocupa por mensajes internos entre los objetos.

La informacin obtenida en la determinacin de la interface del sistema es el punto de partida para desarrollar el modelo de la interface.

Qu es la notacin de la interface del sistema? El escenario es una tcnica til para definir la interface del sistema. Un escenario es una sucesin de eventos que fluyen entre agentes y el sistema para algn propsito.

Un escenario se representa como un diagrama de secuencia, que muestra las rdenes temporales del sistema y los eventos que fluyen a los agentes. Los diagramas de secuencia no pueden mostrar caminos alternativos de comunicacin. Por consiguiente, en general pueden necesitarse diagramas mltiples para un slo escenario.

Los diagramas de secuencia de escenario aportan una herramienta para intuir las consecuencias del diseo de la interface y visualizar cmo se comporta el sistema. Son tiles al validar decisiones de la interface con clientes porque son simples e intuitivos de entender.

Figura 28. Diagrama de secuencia.


Pg. 41.

Desarrollo del Modelo de la Interface Cul 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 del funcionamiento. El orden de desarrollo no es fijo. Sin embargo, es mejor empezar con el modelo del ciclo de vida porque el ciclo de vida puede ser una ayuda al desarrollo del esquema del modelo de funcionamiento.

Cmo desarrollar el modelo del ciclo de vida? El modelo del ciclo de vida es una expresin generalizada de los escenarios que se expresan en diagramas de secuencia. Las expresiones del ciclo de vida son ms expresivas que el diagrama de secuencia, porque pueden expresar repeticin, alternacin, y optionalidad, as como el encadenamiento.

Una expresin del ciclo de vida puede definir un conjunto de escenarios, mientras que un diagrama de secuencia puede mostrar slo 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.

Cmo desarrollar el modelo del funcionamiento? El modelo del funcionamiento define la semntica de cada operacin del sistema en la interface del sistema usando un esquema de modelo del funcionamiento.

El proceso para desarrollar un esquema puede resumirse como sigue:

1. Desarrolle la clusulas Asume y Resultados. 2. Extraiga la clusulas Enva, Lee, y Cambia de Asume y Resultados.

Verificando los Modelos del Anlisis Cundo detener la fase del anlisis? El dilema que enfrenta al analista es saber cundo los modelos del anlisis son suficientemente buenos para ser usados en el diseo. La perfeccin es inasequible y normalmente no se requiere. Sin embargo, una especificacin con errores graves no sirve.

Verificar los modelos del anlisis es una manera de evitar errores graves. Si los chequeos no revelan ningn problema, entonces se puede pensar que la fase del anlisis est completa.

Qu aspectos sern verificados? Hay dos aspectos para ser verificado: completitud (integridad) y consistencia.

La integridad puede medirse contra los requisitos. Los modelos del anlisis deben probarse contra los requisitos, y tambin el conocimiento y expectativas de los clientes y expertos del dominio.

1) Chequeo de la Integridad contra los Requisitos

Hay que verificar que: - Todos los posibles escenarios son cubiertos por el ciclo de vida. - Todos las operaciones del sistema son definidas por un esquema.


Pg. 42.

- Toda la informacin esttica es capturada por el modelo de objetos del sistema. - Cualquier otra informacin (ej., definiciones tcnicas e invariantes), est en el diccionario de datos.

Un conjunto de modelos es consistente cuando los modelos no se contradicen entre ellos, explcitamente o implcitamente. En un modelo debe verificarse su consistencia interna y tambin para esas reas donde se solapa con otros modelos.

2) Chequeos de la Consistencia Simple

Estos chequeos tratan las reas de solape entre los modelos del anlisis. Verifique que - Todas las clases, relaciones, y atributos mencionados en el modelo del funcionamiento 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 un esquema. - Todos los identificadores en todos los modelos tienen entradas en el diccionario de datos.

3) Chequeos de la Consistencia Semntica Estos 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 funcionamiento deben ser consistentes. El esquema para una operacin del sistema debe generar los eventos 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 del sistema. Si hay alguna invariante acerca de una relacin o clase, entonces cualquier operacin que puede cambiarlo debe respetar el invariante en su esquema. - Chequear los escenarios usando el esquema. Escoja ejemplos de escenarios , y defina el cambio de estado que cada uno debe causar. Entonces "ejecute" los escenarios, usando el esquema para definir el comportamiento de cada operacin del sistema. Chequee que los resultados son lo que se espera.

Diseo El diseo consiste en desarrollar un modelo abstracto de cmo un sistema lleva a cabo el comportamiento especificado en el anlisis.

El diseador escoge cmo se va a construir el sistema. Durante este proceso, los mtodos se unen a las clases. El diseador tambin escoge cmo los objetos se relacionan entre ellos y qu relaciones de herencia entre clases son apropiadas.

La fase de diseo de Fusion se basa en las CRC y los mtodos de Booch.

La salida del diseo es una estructura de software orientado a objeto que contiene la misma informacin y mantiene las relaciones definidas en el modelo de objetos del sistema.

Durante esta fase se desarrollan los cuatro modelos siguientes:

Grficos de Interaccin de Objetos. Describen cmo los objetos interactan en tiempo de ejecucin para conseguir la funcionalidad especificada en el modelo de funcionamiento en la fase del anlisis.


Pg. 43.

Grficos de visibilidad. Describen las rutas de comunicacin entre objetos. Descripciones de clases. Proporcionan una especificacin de la interface de la

clase, atributos de datos, atributos de referencia a objetos, y signaturas de los mtodos para todas las clases en el sistema.

Grficos de herencia. Describen las estructuras de herencia clases/subclases. Adems, el diccionario de los datos documenta los trminos, conceptos, y restricciones que aparezcan durante esta fase.

La entrada de la fase de diseo son los tres modelos desarrollados en la fase del anlisis: Modelo de objetos, modelo de funcionamiento y modelo del ciclo de vida.

Grfico de Interaccin de Objetos La primera consideracin en diseo orientado a objetos es la implementacin de cada operacin del sistema. El modelo de funcionamiento especifica la conducta de estas operaciones definiendo el efecto de cada operacin en trminos de cambios de estado del sistema y de eventos de salida. El propsito de esta fase en diseo es construir las estructuras de mensajes entre objetos definidas en el modelo de funcionamiento.

El grfico de interaccin de objetos se construye para cada operacin del sistema.

Un grfico de interaccin de objetos es una coleccin de cajas unidas por flechas. Las cajas representan al objeto, y las flechas representan el paso del mensaje. Hay dos tipos de cajas:

Director Le llega una flecha que no viene de ninguna otra caja del grfico; esta flecha se etiqueta con el nombre de la operacin del sistema que implementa ese grfico de iteraccin de objetos.

Colaboradores El resto de las cajas se llaman colaboradores. El resto de las flechas, salvo la de la operacin del sistema, van de una caja a otra dentro del grfico.

Las sucesiones de mensajes entre los objetos determinan el comportamiento de los objetos declarado en el grfico de interaccin de objetos. Esto define la implementacin a alto nivel de la funcionalidad a travs de los objetos para una operacin del sistema. Cada grfico de interaccin de objetos tambin lleva asociado un texto descriptivo en el diccionario de los datos, en lenguaje natural, pseudocdigo, o especificacin formal, para dar significando a la operacin del sistema y los mensajes definidos.

Notacin del grfico de interaccin de objetos


Pg. 44.

Figura 29. Notacin del grfico de iteraccin de objetos.


Pg. 45.

Objeto del diseo. Tiene atributos y la interface de los mtodos. En la fase del anlisis un objeto no tena ningn atributo ni mtodo. Para distinguirlo de este, se utiliza la palabra objeto del diseo. La notacin es una caja slida.

Colecciones de Objetos. Colecciones de objetos de la misma clase. Las implementaciones tpicas de estas colecciones sern listas o arrays. La notacin es una caja con lneas discontinuas.

Paso de mensajes. El paso de mensajes es una comunicacin punto a punto, y se realiza como una llamada a una funcin o a un mtodo. La notacin es una flecha directa con etiquetas. La direccin de la flecha es del remitente al receptor. Tambin se llaman cliente y servidor.

Paso de mensajes a Colecciones. Un mensaje puede pasarse a colecciones de objetos. La notacin es una flecha directa a una caja con lneas discontinuas.

Secuencia de Mensajes . Si una secuencia de pasos de mensajes es importante, se puede mostrar el orden de la secuencia introduciendo etiquetas de la secuencia entre parntesis sobre el nombre del mensaje. La notacin son etiquetas de la secuencia entre parntesis.

Creacin dinmica de Objetos . La palabra clave new indica que un objeto se crea como parte de la ejecucin de un grfico de interaccin de objetos. El mensaje especial create tambin debe ser enviado a cada nuevo objeto, con los parmetros de invocacin apropiados, para inicializarlo. La notacin es una flecha directa con el mensaje create().

Cmo desarrollar un grfico de interaccin de objetos? Para cada operacin del sistema se realiza un grfico de interaccin de objetos. Esto significa que se desarrolla un grfico de interaccin de objetos para cada esquema en el modelo de funcionamiento.

Esto supone los siguientes pasos: 1. Identifique los objetos pertinentes involucrados en la implementacin de la operacin del sistema. El esquema del modelo de funcionamiento se usa como el punto de partida para identificar los objetos involucrados. La clusula Lee del esquema proporciona una lista de los objetos a los que la operacin del sistema accede pero no modifica. La clusula Cambia lista los objetos cambiados por dicha operacin. Adems de los objetos listados explcitamente en el esquema, puede haber otros objetos involucrados. Por ejemplo, pueden introducirse nuevos objetos para representar abstracciones de mecanismos computacionales no identificadas en los modelos del anlisis. La clusula Enva del esquema, por ejemplo, lista los eventos de salida a agentes del sistema.

2. Establezca el rol de cada objeto. Identifique al director (es decir, el objeto que recibe la demanda para invocar la operacin del sistema, y es responsable de dicha operacin). Identifique a los colaboradores involucrados.

3. Decida los mensajes entre los objetos.


Pg. 46.

Cada objeto proporcionar pedazos diferentes de funcionalidad. Estos pedazos de funcionalidad estn compuestos por el paso de mensajes entre los objetos.

4. Registre cmo los objetos identificados interactan en un grfico de interaccin de objetos. Cada objeto proporciona una parte de la definicin funcional de la operacin, y esta informacin puede extraerse para definir la interface del mtodo del objeto. Una descripcin textual de cada mtodo es incluida en el diccionario de los datos. Esto explica el significado de los mtodos.

Cmo refinar un grfico de inte

Metodologias1 121105164855 Phpapp01.Desbloqueado

Documents

Transcript of Metodologias1 121105164855 Phpapp01.Desbloqueado