Christian Alejandro Cordero Cruz
BOOCH La metodología de Booch se enfoca en el análisis y el diseño y no en la implementación o la prueba del resultado de estos. Define seis tipos de diagramas: clase, objeto, estado de transición, interacción, 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 módulos muestra la asignación de clases y objetos o módulos en el diseño físico de un sistema. Un solo diagrama de módulos representa una vista de la estructura de módulos de un sistema. Los dos elementos esenciales de un diagrama de módulos son los módulos y sus dependencias.
Christian Alejandro Cordero Cruz
BOOCH DIAGRAMA DE PROCESO: Es una representación gráfica de los pasos que se siguen en toda una secuencia de actividades, dentro de un proceso o un procedimiento, identificándolos mediante símbolos de acuerdo con su naturaleza; incluye, además, toda la información que se considera necesaria para el análisis, tal como distancias recorridas, cantidad considerada y tiempo requerido.
DIAGRAMA DE TRANSICION DE ESTADO: El Diagrama de Transición de Estado (también conocido como DTE) enfatiza el comportamiento dependiente del tiempo del sistema. Este tipo de modelo sólo importaba para una categoría de sistemas conocido como sistemas de tiempo-real; como ejemplo de estos sistemas se tienen el control de procesos, sistemas de conmutación telefónica, sistemas de captura de datos de alta velocidad y sistemas de control y mando militares.
DIAGRAMAS DE INTERACCION: Una interacción, 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 dinámicos de un sistema y para construir sistemas ejecutables a través de ingeniería hacia adelante e ingeniería inversa.
Christian Alejandro Cordero Cruz
OMT Esta técnica es trilateral, ya que toma en cuenta tres puntos de vista: modelo de objetos, modelo dinámico y modelo funcional. a) El modelo de objetos. El modelo de objetos es el modelo más 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 estática del sistema. El modelo de objetos se representa mediante un diagrama de clases. b) El modelo dinámico. 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 función" del sistema, mediante la transformación 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. Identificación de objetos y/o clases. Diagrama de clases: En el se describen las clases que se descubrieron para el sistema analizado en términos 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. Identificación de las asociaciones y agregaciones entre los objetos. 4. Identificación de atributos y enlaces. 5. Organización y simplificación de las clases empleando herencia. 6. Verificación de las vías 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 módulos. Existe un tipo de clase especial llamada clas e 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 línea que conecta a las instancias junto con el nombre de la asociación que por lo general es un verbo.
MULTIPLICIDAD EN LA ASOCIACIÓN: La multiplicidad especifica cuantas instancias de una clase estarán relacionadas con cada instancia de la otra clase.
GENERALIZACIÓN: Es una relación entre una superclase que hereda sus características (atributos y operaciones) y subclases que harán suyas dichas características. La asociación 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 dinámico son los siguientes: 1. Preparación de escenarios de secuencias típicas de iteración. 2. Identificación de sucesos que actúan entre objetos. 3. Preparar un seguimiento de sucesos para cada escenario. 4. Construcción de un diagrama de estado para cada objeto. 5. Comparación de los sucesos intercambiados entre objetos para v erificar la congruencia. Escenario: Es la representación escrita de los casos de uso y de la interacción de los actores con ellos para especificar el propósito 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 transición, cada transición 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 condición se puede pensar como una protección en las transiciones, debido a que si se cumple dicha condición la transición se dará y podrá pasar el objeto de un estado a otro, si dicha condición no se cumple inclusive podría pasar a otro estado mediante otra transición o quedarse en el estado receptor hasta que la condición se cumpla. Acción: Es una operación que va asociada a un suceso y se representa mediante una barra “/” y el nombre de la
acción, después del nombre de la transición.
Christian Alejandro Cordero Cruz
MODELO FUNCIONAL Los pasos para construir el modelo funcional son los siguientes: a) Identificación de los valores de entrada y de salida. b) Construcción de diagramas de flujo de datos que muestren las dependencias funcionales. c) Descripción de las funciones. d) Identificación de restricciones. e) Especificación de los criterios de optimización. Mediante el modelo funcional se puede observar los resultados que se tienen de un cálculo de valores, especificando solamente entradas y salidas de los valores, mas no como son calculados estos. El modelo funcional consta básicamente de diagramas de flujo de datos. Los diagramas de flujo están compuestos de: a) Procesos: Se representan mediante una elipse, los procesos tienen como entrada datos, los cuales serán transformados, por lo cual un proceso es visto como un método de una operación 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. Además de trasladar los datos a otros procesos, los flujos de datos pueden usarse para copiar un valor, realizar la composición 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 también son llamados terminadores, debido a que su función principal es hacer concluir el flujo de datos. En el diagrama son representados mediante rectángulos.
c) Almacenes de datos:
Son objetos cuya tarea es permitir el almacenamiento y acceso de datos. Se representan en el diagrama mediante unas líneas paralelas que tienen el nombre del almacén.
OOSE
Christian Alejandro Cordero Cruz El método 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, interactúa con él. El modelo de casos de uso de acuerdo con Jacobson, es la base en la etapa de análisis, construcción y prueba. OOSE presenta cinco técnicas 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 análisis. Este modelo delimita el sistema y define su funcionalidad. Consiste en tres partes:
Un modelo de caso de uso Descripción de la interfaces Un modelo en el dominio del problema
MODELO DE CASOS DE USOS: Los actores representan quienes interactúan con el sistema. Representan todas las necesidades de cambio de información con el sistema. Dado que el actor representa la parte exterior del sistema no se describirán 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 estén 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 lógica del usuario del sistema, porque el interés principal es la consistencia de esta vista lógica 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 lógica del sistema que puede usarse para hacer una lista que especifique los casos del uso. El modelo de caso de uso controla la formulación de otros modelos. Esto es desarrollado en cooperación con el modelo de dominio de objeto.
Christian Alejandro Cordero Cruz
OOSE MODELO DE ANALISIS ESTRUCTURA O MODELO IDEAL Aquí se define la estructura lógica del sistema independiente de la aplicación. En este modelo se especifican todos los objetos lógicos que serán incluidos en el sistema y como están relacionados y agrupados. Metas del Modelo Construcción del Sistema propiamente tal Obviar la aplicación 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 más adelante los paquetes)
OBJETOS DEL MODELO IDEAL Objetos de control Controlan la conducta del sistema en la primera aproximación, ellos pueden derivarse de los casos del uso.
Objetos de la identidad Recuerdan el estado del sistema en la primera aproximación, ellos pueden derivarse de los objetos del dominio.
Objetos de la interface Presenta a el sistema a fuera en la primera aproximación, ellos pueden derivarse de las asociaciones de la interacción.
MODELO REAL En este Modelo se definen Interfaces de Objetos y semántica de funcionamientos y pueden tomarse las decisiones sobre los Sistemas de Dirección de Banco de datos y los lenguajes de programación. Se introducen
Christian Alejandro Cordero Cruz
los bloques para los tipos del objeto para esconder la aplicación real. El modelo del plan consiste en diagramas de la interacción y gráficos de transición de estado.
OOSE UN DIAGRAMA DE LA INTERACCIÓN Es llevado para cada caso del uso concreto. Describe lo que el uso incluye por lo que se refiere a comunicar los objetos. Esta comunicación se planea como bloques que envían los estímulos a nosotros. La interacción hace el diagrama de los casos de uso de apoyo con las extensiones. El diagrama de la interacción es una manera apropiada de expresar los guiones conductuales. El diagrama de interacción hace que OOSE pueda involucrar alternativas o iteraciones, ya que ellos son basados en la descripción de un caso del uso en el idioma estructurado. LOS GRÁFICOS DE TRANSICIÓN DE ESTADO Se usan para describir la conducta del objeto por lo que se refiere a que pueden recibirse los estímulos y qué estímulos pueden causar.
IMPLEMENTACIÓN O MODELO DE APLICACIÓN En esta etapa es cuando se procede a la ejecución del código fuente que ha sido seleccionado. Es la codificación 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:
Diseñar clases que sean robustas y favorablemente reusables. Los objetos reales llevando a cabo en un idioma de la programación. La traceabilidad (que es la característica que permite a las clases poder comunicarse y relacionarse con
Christian Alejandro Cordero Cruz
otras clases).
OOSE MODELO DE PRUEBAS O COMPROBACIÓN 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 debería fallar el sistema ente situaciones defectuosas. Se recomienda comenzar por los niveles mas bajos del sistema , es decir:
Módulos de Objetos y Blocks. Casos de Uso. El Desarrollo de la Aplicación
Algunas preguntas que cabrían realizar en esta etapa son: ¿Hay faltas en el Programa? ¿Dónde? La aprobación ¿Ha sido el sistema correcto? La comprobación ¿Ha sido el sistema creado correctamente?
Generalmente hay varias fases de probar:
la comprobación de la unidad la comprobación de la integración la comprobación del sistema
Hay varios acercamientos a probar
la comprobación de la especificación la comprobación estado-basado la comprobación estructural
¿Cómo los casos de uso pueden ayudar en la comprobación? 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 interacción de casos del uso. De esta manera, los casos de uso se aplican en: la comprobación de la integración la comprobación del sistema
La comprobación de esta etapa es el Modelo de Requisitos, ya que si se cumplen todos los requisitos allí especificados, pasa la aprobación. Aquí nuevamente la Robustez del sistema ayuda a la localización 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 método desarrollado por Grady Booch se basa e n el desarrollo iterativo de un sistema e n el cual se ve al producto como una serie de arquitecturas que evolucionan hacia el sistema del desarrollo final. La metodología OMT es base para el desarrollo de software orientado a objetos y se e xtiende del análisis, al diseño y a la implementación
