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.











Christian Alejandro Cordero Cruz



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.
Christian Alejandro Cordero Cruz






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.
Operaciones
Las 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.
Christian Alejandro Cordero Cruz

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.
Christian Alejandro Cordero Cruz













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.
Christian Alejandro Cordero Cruz


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.
Christian Alejandro Cordero Cruz


MODELO FUNCIONAL
Los 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.
Christian Alejandro Cordero Cruz


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
Christian Alejandro Cordero Cruz

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 la interfaces
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.






Christian Alejandro Cordero Cruz


OOSE
MODELO DE ANALISIS ESTRUCTURA O MODELO IDEAL
Aqu 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 IDEAL
Objetos de control
Controlan la conducta del sistema en la primera aproximacin, ellos pueden derivarse de los casos del
uso.

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


Objetos de la interface
Presenta 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
Christian Alejandro Cordero Cruz

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 INTERACCIN
Es 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 ESTADO
Se 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
Christian Alejandro Cordero Cruz

otras clases).


OOSE
MODELO DE PRUEBAS O COMPROBACIN

En esta etapa se procede a 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 Aplicacin
Algunas 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).




Christian Alejandro Cordero Cruz


CONCLUSIONES
El 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