1.

Fusin Coleman GANOZA El Mtodo fusin (Coleman y Hayes, 1991) es un mtodo hbrido desarrollado por un equipo liderado por Derek Coleman en los laboratorios Hewlett Packard del Reino Unido. HP realiz una investigacin de los mtodos que se estaban empleando dentro de HP, y que existan, en general, en 1990; esto dio lugar a un conjunto de requisitos para un mtodo. El principal requisito identificado era el de un modelo de utilizacin que poseyera una notacin sencilla. Ningn mtodo satisfaca los requisitos de HP.OMT que proporciona un proceso para el anlisis, pero tan solo ofrece reglas prcticas para el diseo. Por tanto se construy fusin tomando ideas prestadas de otros mtodos. Sigue siendo desarrollado de esta forma. Las influencias principales han sido la notacin de OMT y el modelado de interaccin CRC, ideas de Booch 1991 acerca de la visibilidad y de algunas ideas de las escuelas formales Z y VDM. La idea de casos de utilizacin procedente de Objectory se est incorporando en estos momentos. El modelo de procesos de Fusin se ilustra en la figura N1. El modelo dinmico de OMT (y el de otros mtodos, como Shaler/ Mellor) result no ser til en la prctica, y no se utiliza. Este hecho nos sirve como estmulo, aun cuando resulte notable cuando se comparan con las ideas convencionales, lo cual me hace sospechar que un nfasis excesivo en los modelos de estado es el resultado de las telecomunicaciones, y de una procedencia de aplicaciones de tiempo real. Los diagramas de flujo de datos se utilizan para el modelo funcional, porque resultan demasiado operacionales. En su lugar, se utilizan las condiciones previas y posteriores, aun cuando siempre he encontrado que a los usuarios les resulta muy difcil entenderlas, No se presentan los mtodos mientras no se alcanza la fase de diseo. No hay apoyo para la concurrencia, as que todava no existe la invariancia de condiciones en el mtodo. Dado que estas afirmaciones no se asocian a clases, no es posible heredarlas. Un problema difcil para algunas de las personas que emplean el anlisis orientado a objetos es saber cundo debe uno dejar de hacer anlisis. Se dice que Fusin sirve de ayuda para este problema. La visibilidad que presenta en el momento decisivo. Las interacciones definen que objetos necesitan que mtodos: una vez ms, esto se hace en el momento de diseo. Se utiliza CRC para el mtodo de interaccin, aunque no se utilicen contratos. Esto se puede hacer en sesiones de representacin de papeles.

2. Antecedentes

PP

El mtodo de Fusin se considera el mtodo de desarrollo de "la segunda generacin" Ha integrado y ha extendido los acercamientos existentes para proporcionar una ruta directa de una definicin de los requisitos a travs de una aplicacin del lenguaje de programacin. Da requisitos de desarrollo para volver a usar con el uso de la ingeniera. Los siguientes mtodos o tcnicas han influido en la Fusin: *OMT (Rumbaugh., 1991): El modelo del Objeto es casi similar a OMT. El modelo del Funcionamiento es anlogo al modelo funcional en OMT; la circulacin de datos hace el diagrama de OMT son no destinar segn Coleman y se ha formalizado por las condiciones de los antecedentes.

Los mtodos *Formal: se adoptan por las condiciones de los antecedentes para describir lo que un sistema hace formalmente. *Clase Responsabilidad Colaborador (CRC): CRC se extendi con la informacin y comunicacin que ha influido en los grficos de interaccin de Objeto. *Orientado Objeto Designa con las Aplicaciones (Booch, 1991): los grficos de Visibilidad son influenciados por la informacin de visibilidad sobre los diagramas del Objeto de Booch. La fusin es basada en un juego pequeo pero comprensivo de tcnicas de diagramas bien definidas para describir el anlisis y pasos del proyecto. La fusin consiste en tres fases: el anlisis, plan y aplicacin. Los pasos en cada orden de la fase las decisiones importantes y las consultas de cada paso son las entradas para un paso siguiente. Asociado con cada paso, la Fusin tambin mantiene las reglas verificando la consistencia e integridad de los modelos en vas de desarrollo. En la suma, puede adaptarse la Fusin. Algunas pautas se dan para obtener una versin simplificada de Fusin en caso de que no todas las tcnicas se requieren totalmente y se describe cmo puede combinarse la Fusin con otros mtodos.

3. Acercamiento General La fusin divide el proceso de desarrollo en el anlisis de las fases, plan y aplicacin Fusin no tiene ninguna fase de requisitos.

Los Modelos en esta fase describen las clases de objetos, las relaciones entre las clases, funcionamientos que pueden realizarse en los sistemas y las sucesiones aceptables de esos funcionamientos. En los modelos de fase de plan se produce que muestra cmo los funcionamientos del sistema son llevados a cabo actuando recprocamente los objetos, las referencias entre las clases, las relaciones de herencia, los atributos de clases y funcionamientos en las clases. Durante la herencia de aplicacin, se llevan a cabo referencia y atributos de la clase en las clases del lenguaje de programacin. Se programan interacciones entre los objetos como mtodos que pertenecen a una clase. Se llevan a cabo las mquinas del Estado para reconocer sucesiones permitidas de funcionamientos. La fusin mantiene un diccionario de datos, un almacn dnde pueden nombrarse las entidades diferentes del sistema y pueden describirse. 4. Conceptos y estructuras de Fusin Coleman . Los conceptos JUAN

*El objeto: Modela una parte de la realidad y es por tanto algo que existe en el tiempo y en el espacio, representa un elemento, unidad o entidad individual e identificable ya sea real o exacta *El atributo: Son los nombres que describen sobre todo objetos individuales tambin un juego de valores nombrados asociados con un objeto o relacin *La clase: Una abstraccin que representa la idea o la nocin general de un juego de objetos similares *La clase abstracta: Una clase sin cualquier caso directo *La relacin: Un tuple de objetos, por ejemplo <John Smith, Dept_1> *En las variantes: Una asercin que alguna propiedad siempre debe sostener *El papel: Nombre que califica la clase que participa en una relacin *Agente: La entidad en el ambiente del sistema que invoca los funcionamientos del sistema (enviando los eventos) y recibe los resultados (llev por los eventos) *El evento: Una unidad instantnea y atmica de comunicacin entre el sistema y el ambiente *El evento de la entrada: Comunicacin de la entrada con que el ambiente pide el sistema

*El evento del rendimiento: La comunicacin del rendimiento asncrona envi a agente de un sistema *El funcionamiento de Sistemas: Un evento de la entrada y su efecto en un sistema. Un funcionamiento del sistema se invoca por un agente en el ambiente *La interfaz: El juego de funcionamientos del sistema que puede recibir y el juego de eventos que enlata el rendimiento *El Estado (de un sistema): abarca todas las propiedades del mismo ms los valores actuales de todas las propiedades. Un juego de objetos que participan en las relaciones *La condicin previa: Un predicado que caracteriza las condiciones bajo que un funcionamiento del sistema puede invocarse *Las condiciones de anunciar: Un predicado que describe cmo el estado del sistema se cambia por un funcionamiento del sistema y qu eventos se envan a agentes *Director: El objeto (o un grfico de interaccin de objeto) el respondiendo responsable de a una demanda de funcionamiento de sistema *El colaborador: El objeto (o un grfico de interaccin de objeto) eso proporciona alguna funcionalidad como un servidor llevar a cabo un funcionamiento del sistema *El mensaje: La cosa que se enva a un objeto para pedirle que realizar un funcionamiento *El mtodo: Son los que especifican la forma en que se controlan los datos de un objeto La aplicacin de un funcionamiento (en una clase).

Las relaciones entre las Clases YESENIA 1.-Binario, ternario hasta n-ario son las relaciones (tambin el sostenimiento entre los Objetos): Una relacin se ve como objetos dobles que pueden etiquetarse con una cantidad de atributos. El nmero de objetos separados son los que participan en la relacin. Una obligacin del cardinalidad que restringe el nmero de objetos que pueden asociarse entre s, en una relacin.

2.- La agregacin: La agregacin es un mecanismo para estructurar al modelo del objeto. Es un tipo de la relacin que muestra cmo una clase contiene otras clases.

3.- La generalizacin y especializacin: 3.1 La generalizacin.- se define cuando una clase, llamada de tipo excelente, se forma tomando propiedades comunes de varias clases, llamados los subtipos. Los atributos y las relaciones del excelente tipo son heredados por todos los subtipos. Cada subtipo se permite tener los atributos adicionales y participar en las relaciones adicionales. Una propiedad importante de generalizacin es que todos los objetos de un subtipo tambin pertenecen al tipo excelente. La generalizacin Mltiple ocurre cuando una clase puede ser dividida en dos o ms excelentes clases. 3.2 La especializacin.- ocurre cuando un nuevo tipo del subalterno se define como una versin ms especializada de un tipo excelente. La especializacin Mltiple permite definir un nuevo subtipo como una especializacin de ms de un tipo excelente inmediato. Como arriba expresado, todos los atributos y relaciones de las excelentes clases son heredados por la clase del subalterno.

Los Funcionamientos y comunicacin Un funcionamiento del sistema es un evento de la entrada (envi por un agente al sistema) y el efecto que puede tener. Cuando un sistema recibe tal un evento que puede causar un cambio del estado y el rendimiento de eventos. En cualquier punto de tiempo slo un funcionamiento del sistema puede estar activo. Un funcionamiento del sistema puede: & cree un nuevo caso de una clase & cambie el valor de un atributo de un objeto & agregue o anule algunos objetos dobles de una relacin & enve un evento a un agente

La Comunicacin entre los objetos: Los caminos de la Comunicacin son las relaciones de visibilidad en el mtodo de Fusin. stos son organizados en cuatro categoras:

1.-La vida de la referencia, tambin llamada la referencia dinmica, ocurre cuando un cliente slo necesita al mensaje un servidor en el contexto de una sola

invocacin del mtodo. Puede darse el acceso a travs de un parmetro o por una variable local del mtodo. 2.-La visibilidad del servidor. Un objeto del servidor puede usarse exclusivamente por un cliente que enva un mensaje al servidor o en caso de que el servidor puede compartirse por varios clientes. 3.-El servidor ligado, si anulando un objeto implica anular todos los objetos relacionados, nosotros decimos las vidas de objetos relacionados estn limitadas. Servidor que liga los medios as que si un cliente sostiene una nica referencia al servidor, entonces el objeto del servidor debe anularse cuando la vida del cliente se acaba. 4.-La mutabilidad de la referencia. La mutabilidad de una referencia indica si puede ser reasignado despus de la inicializacin. La mutabilidad constante significa que una referencia no es asignable despus de la inicializacin. Si la mutabilidad es inconstante, entonces puede ser reasignado. 5 Tcnicas El mtodo de Fusin usa varias tcnicas. Los extremos de fase de anlisis con modelos del funcionamiento y el proyecto empiezan con hacer los grficos de interaccin de objeto y termina haciendo los grficos de herencia. Una descripcin de las tcnicas se resume debajo: Modelos del objeto que definen la estructura esttica de la informacin en el sistema. Se describen ambos los conceptos en el dominio del problema y relaciones entre ellos. El objeto la anotacin ejemplar est basada en la anotacin de relacin de entidad extendida. Los sistemas objetan a modelos. Un modelo de objeto de sistema es un subconjunto de un modelo del objeto que relaciona al sistema a ser construido. Se forma excluyendo todas las clases y relaciones que pertenecen al ambiente. Modelos de la interfaz definen la comunicacin de la entrada y salida del sistema. La descripcin est por lo que se refiere a los eventos y el cambio del estado que ellos causan. MALENA La interfaz de un sistema es el juego de funcionamientos del sistema que puede recibir y el juego de eventos que enlazar el rendimiento. Se describen aspectos diferentes de conducta en dos modelos:

3 a. Ciclo - Vida planea que caracteriza la secuencia aceptable de funcionamientos del sistema y eventos. Una expresin del ciclo - vida define un modelo de comunicacin mostrando las sucesiones aceptables de interacciones que un sistema puede participar en encima de su vida. 3 b. El Funcionamiento planea que describe el efecto de cada funcionamiento del sistema por lo que se refiere al cambio estatal causa y los eventos del rendimiento el funcionamiento de enviar. EL ejemplar usa condiciones previas y anuncia Objetos con los grficos de la interaccin. Estos grficos se construyen para cada funcionamiento del sistema. Define las sucesiones de mensajes que ocurren entre los objetos para comprender un funcionamiento particular. Los grficos de visibilidad muestran la estructura de la referencia de clases en el sistema. Lo siguiente se identifica para cada clase: Objetos que clasifican los casos necesitan a la referencia Los tipos apropiados de referencia a esos objetos Clasifique las descripciones. Una descripcin de la clase es hecha para cada clase. Describe los mtodos, algunos datos atribuye y los atributos objeto-estimados. Una clase es un juego de objetos que tienen los mismos atributos y mtodos algunos de los cuales pueden heredarse de las clases excelentes. Las descripciones sirven como las fundaciones para la aplicacin. Los grficos de herencia muestran las relaciones de la generalizacin-especializacin entre las clases. Hay una diferencia entre la generalizacin y especializacin en la fase del anlisis y la herencia estructura de plan. En la fase del anlisis, se identifican relaciones del subtipo abstracto entre las clases que existe en el dominio del sistema y no del diseo de sistema o aplicacin. Al plan, la relacin de herencia se lleva a cabo en el sistema y necesariamente no se identifica en el dominio. Las relaciones de herencia aqu son pre descriptivas, mientras en la fase del anlisis ellos son descriptivos.

VENTAJAS Y DESVENTAJAS Ha integrado y ha extendido los acercamientos existentes para proporcionar una ruta directa de una definicin de requisitos a travs de una aplicacin del lenguaje de programacin

La fusin est basada en tcnicas comprensivas de los diagramas bien definidas para describir anlisis y pasos del plan. La Fusin mantiene las reglas verificando la consistencia e integridad de los modelos en vas de desarrollo. La fusin mantiene un diccionario de datos, un almacn dnde pueden nombrarse las entidades diferentes del sistema y pueden describirse.