Christian Alejandro Cordero Cruz

BOOCH

La metodologa de Booch se enfoca en el anlisis y el diseo y no en la implementacin o la prueba del resultado de estos.Define seis tipos de diagramas: clase, objeto, estado de transicin, interaccin, modulo y proceso.

DIAGRAMA DE CLASE:En este tipo de diagramas se muestran las clases con sus relaciones, o lo que es lo mismo, la estructura de clases.

DIAGRAMA DE MODULO: El diagrama de mdulos muestra la asignacin de clases y objetos o mdulos en el diseo fsico de un sistema. Un solo diagrama de mdulos representa una vista de la estructura de mdulos de un sistema. Los dos elementos esenciales de un diagrama de mdulos son los mdulos y sus dependencias.

BOOCH

DIAGRAMA DE PROCESO: Es una representacin grfica de los pasos que se siguen en toda una secuencia de actividades, dentro de un proceso o un procedimiento, identificndolos mediante smbolos de acuerdo con su naturaleza; incluye, adems, toda la informacin que se considera necesaria para el anlisis, tal como distancias recorridas, cantidad considerada y tiempo requerido.

DIAGRAMA DE TRANSICION DE ESTADO:El Diagrama de Transicin de Estado (tambin conocido como DTE) enfatiza el comportamiento dependiente del tiempo del sistema. Este tipo de modelo slo importaba para una categora de sistemas conocido como sistemas de tiempo-real; como ejemplo de estos sistemas se tienen el control de procesos, sistemas de conmutacin telefnica, sistemas de captura de datos de alta velocidad y sistemas de control y mando militares.

DIAGRAMAS DE INTERACCION:Una interaccin, que consiste de un conjunto de objetos y sus relaciones, incluyendo los mensajes que puedan ser realizados entre ellos. Son importantes para modelar los aspectos dinmicos de un sistema y para construir sistemas ejecutables a travs de ingeniera hacia adelante e ingeniera inversa.

OMT

Esta tcnica es trilateral, ya que toma en cuenta tres puntos de vista: modelo de objetos, modelo dinmico y modelo funcional.a) El modelo de objetos. El modelo de objetos es el modelo ms importante, ya que en l se identifican las clases dentro del sistema junto con sus relaciones, as como sus atributos y operaciones, lo que representa la estructura esttica del sistema. El modelo de objetos se representa mediante un diagrama de clases.b) El modelo dinmico. Representa los aspectos temporales de comportamiento "de control" del sistema, mediante la secuencia de operaciones en el tiempo.c) El modelo funcional. Representa los aspectos transformacionales "de funcin" del sistema, mediante la transformacin de valores de los datos. Se representa mediante un diagrama de flujo.

MODELO DE OBJETOS:Los pasos para construir el modelo de objetos son los siguientes:1. Identificacin de objetos y/o clases.Diagrama de clases:En el se describen las clases que se descubrieron para el sistema analizado en trminos del dominio del problema.Atributos:Es un dato que distingue a una clase y que puede almacenar valores para el mismo en cada instancia que genere la clase. Debe tener un nombre y el tipo de dato que va a recibir.OperacionesLas operaciones son funciones que pueden realizar las instancias de una clase.Mediante ellas se pueden visualizar cuales son las responsabilidades de cada clase dentro del sistema.

2. Crear un diccionario de datos.3. Identificacin de las asociaciones y agregaciones entre los objetos.4. Identificacin de atributos y enlaces.5. Organizacin y simplificacin de las clases empleando herencia.6. Verificacin de las vas de acceso necesarias para llevar a cabo las probables consultas.7. Realizar las iteraciones necesarias para el refinamiento del modelo.8. Agrupar las clases en mdulos.

Existe un tipo de clase especial llamada clase abstracta. Este tipo de clase no genera instancias directas, lo nico que hace es heredar a otras clases que pueden generar instancias directas.

OMT

DIAGRAMA DE OBJETOS:En este diagrama se representan las instancias de las clases relacionadas entre s.

RELACIONES (ASOCIACIONES):Representan los enlaces entre las instancias dentro del diagrama. Se representan mediante una lnea que conecta a las instancias junto con el nombre de la asociacin que por lo general es un verbo.

MULTIPLICIDAD EN LA ASOCIACIN:La multiplicidad especifica cuantas instancias de una clase estarn relacionadas con cada instancia de la otra clase.

GENERALIZACIN:Es una relacin entre una superclase que hereda sus caractersticas (atributos y operaciones) y subclases que harn suyas dichas caractersticas. La asociacin se representa mediante un triangulo que conecta a la superclase con sus subclases.

OMT

MODELO DINAMICO:Los pasos para construir el modelo dinmico son los siguientes:1. Preparacin de escenarios de secuencias tpicas de iteracin.2. Identificacin de sucesos que actan entre objetos.3. Preparar un seguimiento de sucesos para cada escenario.4. Construccin de un diagrama de estado para cada objeto.5. Comparacin de los sucesos intercambiados entre objetos para verificar la congruencia.

Escenario: Es la representacin escrita de los casos de uso y de la interaccin de los actores con ellos para especificar el propsito del sistema.

Suceso:Es un evento que ocurre en un determinado momento del sistema y por medio del cual se pueden transmitir valores entre los objetos.

Diagramas de estados:Relaciona sucesos y estados. Un diagrama de estados se representa mediante estados, transiciones, condiciones y acciones.Estados:Los estados representan las respuestas de los objetos a varios sucesos en determinado tiempo dentro del sistema. Dicha respuesta puede cambiar el estado del objeto. Se representan mediante cuadros redondeados que contienen un nombre.

OMT

Transiciones:Se representan mediante flechas que salen del estado receptor hasta el estado destino y el nombre que se coloca en la flecha es el nombre del suceso que dio lugar a dicha transicin, cada transicin que sale de un estado corresponde a un suceso distinto, lo cual indica que no deben de existir sucesos duplicados dentro de un estado.

Condiciones:Una condicin se puede pensar como una proteccin en las transiciones, debido a que si se cumple dicha condicin la transicin se dar y podr pasar el objeto de un estado a otro, si dicha condicin no se cumple inclusive podra pasar a otro estado mediante otra transicin o quedarse en el estado receptor hasta que la condicin se cumpla.Accin:Es una operacin que va asociada a un suceso y se representa mediante una barra / y el nombre de la accin, despus del nombre de la transicin.

MODELO FUNCIONALLos pasos para construir el modelo funcional son los siguientes:a) Identificacin de los valores de entrada y de salida.b) Construccin de diagramas de flujo de datos que muestren las dependencias funcionales.c) Descripcin de las funciones.d) Identificacin de restricciones.e) Especificacin de los criterios de optimizacin.

Mediante el modelo funcional se puede observar los resultados que se tienen de un clculo de valores, especificando solamente entradas y salidas de los valores, mas no como son calculados estos. El modelo funcional consta bsicamente de diagramas de flujo de datos.

Los diagramas de flujo estn compuestos de:a) Procesos:Se representan mediante una elipse, los procesos tienen como entrada datos, los cuales sern transformados, por lo cual un proceso es visto como un mtodo de una operacin aplicada a una clase de objetos.

OMT

a) Flujos de datos:Un flujo de datos conecta la salida de un proceso a la entrada de otro.Se representa en el diagrama por medio de una flecha, la cual puede llevar el nombre o el tipo de dato. Adems de trasladar los datos a otros procesos, los flujos de datos pueden usarse para copiar un valor, realizar la composicin de un agregado y viceversa.

b) Actores:Los actores son objetos que consumen y producen datos generando operaciones por si mismos, estos se encuentran siempre en las fronteras del diagrama indicando entradas y salidas de datos. Los actores tambin son llamados terminadores, debido a que su funcin principal es hacer concluir el flujo de datos. En el diagrama son representados mediante rectngulos.

c) Almacenes de datos:Son objetos cuya tarea es permitir el almacenamiento y acceso de datos. Se representan en el diagrama mediante unas lneas paralelas que tienen el nombre del almacn.

OOSE

El mtodo desarrollado por Ivar Jacobson OOSE ha sido llamado un enfoque para el manejo de casos de uso, en este enfoque el modelo de casos de uso sirve como un modelo central del cual todos los otros modelos son derivados. Un modelo de casos de uso describe la funcionalidad completa del sistema, identificando como, todo lo que esta fuera del sistema, interacta con l.El modelo de casos de uso de acuerdo con Jacobson, es la base en la etapa de anlisis, construccin y prueba. OOSE presenta cinco tcnicas para modelar un sistema:

MODELO DE REQUISITOS

Un modelo de requerimientos es creado para especificar toda la funcionalidad del sistema. Esto es principalmente hecho por casos de uso. Este modelo es la base del modelo de anlisis.Este modelo delimita el sistema y define su funcionalidad. Consiste en tres partes:

Un modelo de caso de uso Descripcin de lainterfaces Un modelo en el dominio del problema

MODELO DE CASOS DE USOS:Los actores representan quienes interactan con el sistema. Representan todas las necesidades de cambio de informacin con el sistema. Dado que el actor representa la parte exterior del sistema no se describirn detalles de ellos. La diferencia entre un actor y un usuario radica en que el usuario es la persona que usa el sistema, mientras que el actor es un rol que el usuario puede jugar.DESCRIPCION DE LAS INTERFACES:Es importante que los usuarios estn envueltos en las descripciones de las interfaces detalladas. Por consiguiente estas descripciones deben hacerse en una fase temprana. La interface tiene que capturar la vista lgica del usuario del sistema, porque el inters principal es la consistencia de esta vista lgica y la conducta real del sistema. Puede tratarse que ambos usuario sean unidos con otros sistemas por la interface.MODELO DE OBJETO DE DOMINIO:Para desarrollar una vista lgica del sistema que puede usarse para hacer una lista que especifique los casos del uso. El modelo de caso de uso controla la formulacin de otros modelos. Esto es desarrollado en cooperacin con el modelo de dominio de objeto.

OOSE

MODELO DE ANALISIS ESTRUCTURA O MODELO IDEALAqu se define la estructura lgica del sistema independiente de la aplicacin. En este modelo se especifican todos los objetos lgicos que sern incluidos en el sistema y como estn relacionados y agrupados.

Metas del Modelo Construccin del Sistema propiamente tal Obviar la aplicacin y todo lo que conlleva esta Establecer la robustez del Sistema

Objetivos Reconocer los objetos que forman parte del Sistema Reconocer asociaciones y estructuras de objetos Asignar atributos a los objetos Asociar un objeto a sus atributos Dividir el sistema en subsistemas (para preparar ms adelante los paquetes)

OBJETOS DEL MODELO IDEALObjetos de controlControlan la conducta del sistema en la primera aproximacin, ellos pueden derivarse de los casos del uso.

Objetos de la identidadRecuerdan el estado del sistema en la primera aproximacin, ellos pueden derivarse de los objetos del dominio.

Objetos de la interfacePresenta a el sistema a fuera en la primera aproximacin, ellos pueden derivarse de las asociaciones de la interaccin.

MODELO REAL

En este Modelo se definen Interfaces de Objetos y semntica de funcionamientos y pueden tomarse las decisiones sobre los Sistemas de Direccin de Banco de datos y los lenguajes de programacin. Se introducen los bloques para los tipos del objeto para esconder la aplicacin real. El modelo del plan consiste en diagramas de la interaccin y grficos de transicin de estado.

OOSE

UN DIAGRAMA DE LA INTERACCINEs llevado para cada caso del uso concreto. Describe lo que el uso incluye por lo que se refiere a comunicar los objetos. Esta comunicacin se planea como bloques que envan los estmulos a nosotros. La interaccin hace el diagrama de los casos de uso de apoyo con las extensiones.El diagrama de la interaccin es una manera apropiada de expresar los guiones conductuales. El diagrama de interaccin hace que OOSE pueda involucrar alternativas o iteraciones, ya que ellos son basados en la descripcin de un caso del uso en el idioma estructurado.

LOS GRFICOS DE TRANSICIN DE ESTADOSe usan para describir la conducta del objeto por lo que se refiere a que pueden recibirse los estmulos y qu estmulos pueden causar.

IMPLEMENTACIN O MODELO DE APLICACIN

En esta etapa es cuando se procede a la ejecucin del cdigo fuente que ha sido seleccionado. Es la codificacin del sistema tanto el desarrollo de las Bases de Datos como de los distintas aplicaciones con las que contar.Aqu los paquetes, antes mencionados, pasan a ser clases.

Metas del Modelo:

Disear clases que sean robustas y favorablemente reusables. Los objetos reales llevando a cabo en un idioma de la programacin. La traceabilidad (que es la caracterstica que permite a las clases poder comunicarse y relacionarse con otras clases).

OOSE

MODELO DE PRUEBAS O COMPROBACIN

En esta etapa se procedea probar tanto las aplicaciones como el funcionamiento de las clases y la robustez del sistema, si esta ltima es buena no debera fallar el sistema ente situaciones defectuosas.

Se recomienda comenzar por los niveles mas bajos del sistema , es decir:

Mdulos de Objetos y Blocks. Casos de Uso. El Desarrollo de la AplicacinAlgunas preguntas que cabran realizar en esta etapa son:Hay faltas en el Programa? Dnde?La aprobacin Ha sido el sistema correcto?La comprobacin Ha sido el sistema creado correctamente?

Generalmente hay varias fases de probar: la comprobacin de la unidad la comprobacin de la integracin la comprobacin del sistema

Hay varios acercamientos a probar la comprobacin de la especificacin la comprobacin estado-basado la comprobacin estructural Cmo los casos de uso pueden ayudar en la comprobacin?Probando los guiones pueden derivarse de los guiones de casos del uso.Pueden elaborarse los talones de la prueba probablemente basado en los diagramas de la interaccin de casos del uso.De esta manera, los casos de uso se aplican en: la comprobacin de la integracin la comprobacin del sistema

La comprobacin de esta etapa es el Modelo de Requisitos, ya que si se cumplen todos los requisitos all especificados, pasa la aprobacin. Aqu nuevamente la Robustez del sistema ayuda a la localizacin de faltas y la traceabilidad ayuda al movimiento dentro del Modelo del Plan (a donde la falta ser corregida).

CONCLUSIONESEl mtodo desarrollado por Grady Booch se basa en el desarrollo iterativo de un sistema en el cual se ve al producto como una serie de arquitecturas que evolucionan hacia el sistema del desarrollo final.La metodologa OMT es base para el desarrollo de software orientado a objetos y se extiende del anlisis, al diseo y a la implementacin