DDOO_U3_A2_ANDB

UnADM

Unidad 3. Metodologías de diseño para la generación de sistemas orientados a objetos. Actividad 2. Importancia de las metodologías OMT y OOSE en el diseño de sistemas orientados a objetos. El propósito de esta actividad es que identifiques la metodología de diseño orientado a objetos OMT y OOSE.

Grupo: DS-DDOO-1502S-B1-006|Andrea Paola De León Blanco

Ingeniería en Desarrollo de Software Análisis y diseño orientado a objetos | Docente: Dorian Ruiz Alonso

Aplicación de la Metodología OMT

Proceso de desarrollo Las páginas 2- 24 de este documento pertenecen a los autores citados a continuación: Víctor Manuel Chávez Gaona #Control: 99120839 Víctor Manuel Chávez Gaona #Control: 99120839 ez Gaona #Control: 99120839 Juan Carlos Olivares Rojas #Control: 99120871. (2002). Metodología OMT. 25 de Agosto de 2015, de INSTITUTO TECNOLOGICO DE MORELIA, DEPARTAMENTO DE SISTEMAS Y COMPUTACION, INGENIERÍA EN SISTEMAS COMPUTACIONALES Sitio web: http://dsc.itmorelia.edu.mx/~jcolivares/documents/omt

EJEMPLO Sistema de cajero automático: ATM (Automated Teller Machine) Diseñar el software para dar soporte a una red bancaria automatizada, que incluya tanto cajeros humanos como cajeros automáticos (CA), y que deberán ser compartidos por un consorcio de bancos. Cada banco proporciona sus propias computadoras para mantener sus cuentas y procesar transacciones relativas a

OMT

Instituto Tecnológico de Morelia

ellas. Las terminales de cajero son propiedades de cada banco, y se comunican directamente con las computadoras del banco. Los cajeros humanos insertan los datos de la cuenta y de la transacción. Los cajeros automáticos se comunican con una computadora central que aprueba las transacciones con los bancos adecuados. Los cajeros automáticos admiten tarjetas, interaccionan con el usuario, se comunican con el sistema central para llevar a cabo la transacción, entregan dinero e imprimen recibos. El sistema necesita mantener unos registros adecuados y también las oportunas medidas de seguridad y debe admitir accesos concurrentes a una misma cuenta de forma correcta. Los bancos proporcionarán su propio software para sus computadoras; el analista debe diseñar el software para los CA y para la red. El coste del sistema compartido será prorrateado entre los bancos de acuerdo con el número de clientes que tengan sus tarjetas de crédito.

Terminal de cajero Computadora del banco

CA CA

Cuenta

Computadora central

Cuenta Computadora del banco

CA

Cuenta

Cuenta

Una red de CA ANÁLISIS MODELO DE OBJETOS:

Identificar los objetos y la clase.

26

OMT

Instituto Tecnológico de Morelia Software

Red Bancaria

Computador a de Banco Computadora central Mantenimiento de contabilidad

Cuent a

Cajero

CA

Terminal de cajero

Transacción

Tarjeta de crédito

Consorcio

Usuario

Mantenimiento de seguridad

Banco

Datos de Cuenta

Dinero

Datos de transacció n

Recibo

Acceso

Sistema

Coste

Cliente

Clases extraídas de los nombres de definición del problema Líneas de Registro de comunicacione transacciones s Clases de CA identificadas a partir del conocimiento del dominio del problema Vaga Red Bancaria Sistema Mantenimiento de contabilidad

Datos de Cuenta Dinero

Recibo

Atributo

Datos de transacción

Coste Irrelevante

Software Acceso

Usuario Implementación

Mantenimiento de seguridad

Redundante

Clases Incorrectas

27

OMT

Instituto Tecnológico de Morelia Computador a de Banco Computadora central

Cuent a

Cajero

Transacción

CA

Terminal de cajero

Consorcio

Tarjeta de crédito

Banco

Cliente

Clases Correctas

Preparar un diccionario de datos

Cuenta Cuenta individual de un banco a la cual se le pueden aplicar transacciones. Las cuentas pueden ser de varios tipos; como mínimo serán de ahorro o a la vista. Un cliente puede tener más de una CA Punto que permite a los clientes introducir sus propias transacciones empleando una tarjeta de crédito como identificación. El CA interacciona con el cliente para obtener información de la transacción, la envía a la computadora central para su verificación y procesamiento, y suministra dinero al usuario. Suponemos que el CA no necesita funcionar independientemente de la red. Banco Una institución financiera que tiene cuentas para clientes y que proporciona tarjeta de crédito que autorizan para acceder a dichas cuentas a través de la red de CA. Computadora de banco Computadora de un banco, que tiene una interfaz con la red de CA, y con los puestos de cajeros del propio blanco. Éste puede tener su propia red interna de computadoras para procesar las cuentas, aunque sólo nos concierne la que se comunica con la red. Tarjeta de Crédito Tarjeta que le ha sido asignada a un cliente del banco, y que le autoriza para acceder a cuentas empleando un CA. Cada tarjeta contiene un número y código de banco, que estarán codificados, con toda probabilidad, de acuerdo con los estándares nacionales para tarjetas de crédito y de débito (bancarias). El código del banco le identifica de forma única dentro del consorcio. El número de la tarjeta determina las cuentas a las cuales puede acceder. Una tarjeta no accede necesariamente a todas las cuentas del cliente. Toda tarjeta bancaria es poseída por un único cliente, pero pueden existir múltiples copias de ella de modo que es preciso considerar la posibilidad de su uso simultáneo en varias máquinas distintas. Cajero Empelado de un banco que está autorizado para efectuar transacciones en los terminales de cajero y para admitir y proporcionar dinero y cheques a los clientes. Las transacciones, el dinero y los cheques gestionados

28

OMT


por cada cajero deben ser insertados en las computadoras y controlados debidamente. Terminal de cajero Puesto en el cual los cajeros introducen transacciones de sus clientes. Los cajeros proporcionan dinero y cheques; el terminal imprime recibos. El terminal de cajero se comunica con la computadora del banco para verificar y procesar las transacciones. Computadora central Computadora explotada por el consorcio y encargada de despachar las transacciones entre los CA y las computadoras de los bancos. Verifica los códigos de los bancos, pero no procesa directamente las transacciones. Consorcio Organización de los bancos que contrata y explota la red de CA. La red sólo admite transacciones para los bancos del consorcio. Cliente Poseedor de una o más cuentas de un banco. Un cliente puede ser una o más personas o compañías; la correspondencia no es relevante para este problema. Una misma persona que tenga una cuenta en distintos bancos será considerada como varios clientes distintos. Transacción Única solicitud completa de operaciones que afecta a cuentas de un solo cliente. Hemos especificado que los CA deben de proporcionar dinero, aunque no debería excluirse la posibilidad de imprimir cheques o de admitir dinero o cheques. Quizá sea necesario también ofrecer la flexibilidad para operar sobre cuentas de distintos clientes, aunque esto no se necesita todavía. Las distintas operaciones deben cuadrar correctamente. Diccionario de datos para las clases de CA.

Identificar asociaciones entre objetos

Locuciones Verbales La red bancaria incluye cajeros y CA El consorcio comparte los CA. El banco proporciona la computadora del banco. La computadora del banco proporciona las cuentas. La computadora del banco procesa las transacciones de cada cuenta. El banco posee el punto de caja. El punto de caja se comunica con la computadora del banco. El cajero introduce las transacciones para la cuenta. Los CA se comunican con la computadora central para la transacción. La computadora central verifica la transacción con el banco. El CA admite tarjetas bancarias. El CA interacciona con el usuario. El CA proporciona dinero. 29

OMT

Instituto Tecnológico de Morelia El CA imprime recibos. El sistema gestiona accesos concurrentes. Los bancos aportan su software. Los costes se prorratean entre los bancos.

Locuciones verbales implícitas El consorcio está formado por bancos. Los bancos tienen cuentas. El consorcio posee la computadora central. El sistema se encarga del registro. El sistema se encarga de la seguridad. Los clientes tienen tarjeta de crédito. Conocimiento del dominio del problema Las tarjetas de crédito acceden a cuentas. Los bancos emplean cajeros. Asociaciones para la definición del problema de un CA. Consta de Consorcio

Código de banco

Banco

Posee Posee

Computadora central

Se comunica con

Introducida en CA

Contiene

Se comunica con

P o s e e

Cuenta

Concierne a Se comunica con

Computadora de banco

Se comunica con Terminal cajero

Tiene

Cliente

Accede a

Concierne a

T i e n e

Cajero Introducido por

Introducida en

Transacción remota

Transacción de cajero

Tarjeta de crédito Autorizada por 30

OMT

Instituto Tecnológico de Morelia Diagrama inicial para un sistema ATM.

Nombre Emite Código de tarjeta Consorcio Código de banco

Consta de

Banco Nombre Código terminal

Posee

Contiene Código de cuenta Código de empleado

Tiene

Cuenta

Cliente

Saldo Límite de crédito Tipo

Nombre Dirección

Emplea a Tiene

Concierne a

Posee Posee



Código de banco

Cajero Accede a Nombre

Se comunica con Código terminal

Código terminal

Concierne a Introducido por

Se comunica con

Transacción de cajero Terminal de cajero

Introducido en Clase Fecha-hora Cantidad

Se comunica con

CA Introducida en Dinero en efectivo Dispensado

Transacción remota Clase Fecha-hora Cantidad

Tarjeta de crédito Autorizado por

Modelo de objetos de un CA con sus atributos

Organizar y simplificar la clase de objetos usando herencia.

31

OMT

Instituto Tecnológico de Morelia Terminal de entrada

Transacción Introducida en

Clase Fecha-hora Cantidad Concierne a

CA

Terminal cajero Transacción de cajero

Dinero en efectivo dispensado

Transacción remota

Se comunica con Introducido por

Se comunica con Código de terminal

Código de terminal

Computadora central


Cajero Nombre

Código de banco

Emplea a

Autorizado por Emite

Se comunica con

Posee Tiene

Tarjeta de crédito

Posee Código de puesto

Posee

Banco

Cliente Código de empleado

Nombre dirección Tiene

Consta de

Código de banco

Accede a

Nombre Código de tarjeta

Consorcio

Contraseña

Código de cuenta Contiene

Cuenta Saldo Límite de crédito Tipo

Modelo de objetos de un CA con atributos y herencia Verificar que existen las vías de acceso adecuadas para las probables consultas. Iterar y refinar el modelo.

32

OMT

Instituto Tecnológico de Morelia Transacción Introducida en Fecha-hora

Consta de Actualización

Terminal de entrada Cantidad Clase Transacción de cajero

Transacción remota

Introducida por CA

Terminal de caja

Concierne a

Cajero Iniciada por

Efectivo Dispensado Nombre Posee Posee Emplea a

Banco

Cliente Código de empleado

Consorcio Código de banco Consta de

Contraseña Límite

Nombre Dirección

Identifica a

Nombre Código de cuenta

Aurotización de tarjeta

Tiene

Código de terminal

Código de terminal

Emite

Código de tarjeta

Tiene Cuenta

Contiene

Saldo Límite de crédito Tipo

Cuenta Saldo Límite de crédito Tipo Accede a

Modelo de objetos del CA después de otra revisión

Agregar las clases en módulos

MODELADO DINÁMICO:

Se preparan escenarios de secuencias típicas de interacción.

El CA pide al usuario que inserte una tarjeta; el usuario inserta una tarjeta de crédito. El CA admite la tarjeta y lee su número de serie. El CA solicita la contraseña; el usuario escribe “1234”. El CA verifica el número de serie y la contraseña con el consorcio; esta la comprueba con el banco “39” y notifica la aceptación al CA. El CA pide al usuario que seleccione la clase de transacción que desea (retirar fondos, hacer un ingreso o una transferencia); el usuario selecciona retirar fondos. El CA verifica que la cantidad se encuentre dentro de los límites de crédito predefinidos, y pide al consorcio que procese la transacción; éste pasa la 33

OMT


solicitud al banco, que eventualmente confirma el éxito de la misma y proporciona el nuevo saldo disponible en cuenta. El CA proporciona el dinero y pide al usuario que lo recoja; éste toma el dinero. El CA pregunta si el usuario desea continuar; éste dice que no. El CA imprime un recibo, expulsa la tarjeta y pide al usuario que la recoja; el usuario toma el recibo y la tarjeta. El CA pide a un usuario que inserte una tarjeta. Escenario normal de un CA. El CA pide al usuario que inserte una tarjeta; inserta una tarjeta de crédito. El CA admite la tarjeta y se lee un número de serie. El CA solicita la contraseña; el usuario escribe “9999”. El CA verifica el número de serie y la contraseña con el consorcio, que los rechaza después de consultar con el banco adecuado. El CA indica que la contraseña es incorrecta, y pide al usuario que vuelva a escribirla; éste usuario escribe “1234”, y la tarjeta es admitida por el consorcio tras verificar el CA. El CA pide al usuario que seleccione la clase de transacción que desea; el usuario selecciona una retirada de fondos. El CA pregunta la cantidad de dinero; el usuario cambia de opinión y pulsa “cancelar”. El CA expulsa la tarjeta y pide al usuario la recoja, el usuario la recoge. El CA pide a un usuario que inserte una tarjeta. Un escenario de CA con excepciones.

Se identificar sucesos que actúen entre objetos.

Mensajes al usuario 0

1

2

3

4

5

6

7

8

9

Introducir

Recibos

Borrar

Cancelar

Ranura de

Formato de la interfaz ATM

34

OMT


Se prepara un seguimiento de sucesos para cada escenario. Usuario

CA

Consorcio

Banco

Insertar tarjeta Solicitar contraseña Introducir contraseña

Solicitar tipo de operación

Verificar cuenta

Cuenta correcta

Verificar tarjeta con banco Cuenta de banco correcta

Introducir tipo Solicitar cantidad Introducir cantidad

Procesar transacción

Transacción con éxito

Procesar transacción de banco Transacción de banco con éxito

Dispensar dinero Solicitar retirar dinero Retirar dinero Solicitar continuación Terminar Imprimir recibo Expulsar tarjeta Solicitar retirar tarjeta Retirar tarjeta Visualizar pantalla principal

Seguimiento de sucesos para un escenario de CA.

35

OMT

Instituto Tecnológico de Morelia Insertar tarjeta, introducir contraseña, tipo, y cantidad, tomar efectivo y tarjeta, cancelar, terminar, continuar Usuario

CA Visualizar pantalla principal, Mensaje tarjeta ilegible, Solicitar Contraseña, tipo y cantidad Mensaje cancelado Expulsar tarjeta, mensaje de error Dispensar dinero, Solicitar retirar dinero Solicitar continuación Imprimir recibo, Solicitar retirar tarjeta. Mensaje cuenta incorrecta Mensaje código banco incorrecto

-Transacción con éxito. -Transacción fallida. -Cuenta correcta. -Cuenta incorrecta. -Código de banco incorrecto.

Verificar cuenta Procesar transacción Verificar tarjeta con banco, Procesar transacción con banco Banco

Consorcio Transacción de banco con éxito Transacción de banco fallida. Cuenta de banco correcta. Cuenta de banco incorrecta Contraseña de banco incorrecta

Diagrama de flujo de sucesos para el ejemplo de CA.

Se construye un diagrama de estados.

36

OMT


Esperar respuesta red

Respuesta de red

Insertar tarjeta [legible] Pantalla principal hacer: visualizar pantalla principal Insertar tarjeta [ilegible] Retirar tarjeta

Interrupción hacer: mensaje cancelado

Insertar contraseña

Cancelar Hacer: verificar cuenta

Hacer: solicitar contraseña Contraseña incorrecta

Cuenta correcta Cuenta incorrecta

Ilegible hacer: mensaje tarjeta ilegible

Hacer: solicitar tipo

Cancelar

Tarjeta expulsada hacer: expulsar tarjeta; Solicitar retirar tarjeta

Cancelar hacer: mensaje cancelado

Introducir tipo

Cancelar Cancelar

Hacer: solicitar tipo FIN hacer: imprimir recibo

Hacer: mensaje cuenta incorrecta

Introducir cantidad Terminar Transacción con éxito

Cancelar Continuar Retirar dinero Hacer: solicitar continuación

Hacer: dispensar dinero; Solicitar retirar dinero

Hacer: procesar transacción

Transacción con éxito Red responde = Cuenta correcta, cuenta incorrecta Código banco incorrecto, Contraseña incorrecta, Transacción con éxito, transacción fallida

Esperar 5 segundos

Hacer: mensaje error Cancelar

Diagrama de estados para la clase CA

37

OMT

Instituto Tecnológico de Morelia Procesar transacción

Verificar cuenta

Hacer: procesar transacción de banco

Hacer: verificar código de banco

[Código incorrecto] /código de banco incorrecto

[Código bueno] Transacción de banco fallida /transacción fallida

Cuenta de banco incorrecta /cuenta incorrecta

Transacción de banco con éxito /transacción con éxito

Hacer: verificar tarjeta con banco Contraseña de banco incorrecta /contraseña incorrecta Cuenta de banco incorrecta /cuenta incorrecta

Diagrama de estados para la clase Consorcio.

Procesar transacción de banco

Hacer: actualizar cuenta

Verificar tarjeta con banco

Hacer: verificar número de tarjeta

[No es válida] /cuenta de banco incorrecto

[Válida] [Fallo] / Transacción de banco fallida [Éxito] / Transacción de banco con éxito

Hacer: verificar contraseña

[No válida] /Contraseña de banco incorrecta

[Válida] /Cuenta de banco correcta

Diagrama de estados para la clase Banco. Se comparan los sucesos intercambiados entre objetos para verificar la congruencia. MODELO FUNCIONAL:

Identificar los valores de entrada y salida.

38

OMT

Instituto Tecnológico de Morelia Código de banco, código de tarjeta Tarjeta de crédito Contraseña, Tipo de transacción, Tipo de cuenta, Cantidad

CA Límites del sistema

Dinero, recibo, Mensajes

Usuario

Valores de entrada y salida para el sistema CA. Construir diagramas dependencias funcionales.

de

flujo

de

datos

que

muestren

Tarjeta de crédito

Tarjeta de crédito Código de banco, Código de tarjeta Leer entradas Contraseña, Tipo de transacción, Cantidad, Tipo de cuenta

Saldo Efectuar transacción

Usuario

Generar salidas

Mensajes, Dinero, Recibo

Diagrama de flujo de datos del más alto nivel para el CA

39

las

OMT

Instituto Tecnológico de Morelia Consorcio Código de banco

Seleccionar banco

Código de tarjeta

Código de banco incorrecto Banco

Seleccionar tarjeta Cuentas

Contraseña

Código de tarjeta incorrecto Autorización de tarjeta Contraseña Verificar contraseña

Tipo de cuenta

Contraseña incorrecta

Cuenta Incorrecta

Seleccionar tarjeta Cuenta

Saldo Cantidad y tipo de transacción

Actualizar Cuenta

Transacción fallida Dinero, recibo

Diagrama de flujo de datos para el proceso efectuar transacción en un CA.

Describir funciones.

Actualizar cuenta (cuenta, cantidad, tipo-de-transacción) -> dinero, recibo, mensaje Si la cantidad que se intenta retirar supera el saldo disponible, Rechazar la transacción y no entregar ningún dinero. Si la cantidad que se intenta retirar no supera el saldo disponible, Cargar el importe y dispensar el efectivo solicitado Si la transacción es un ingreso, Abandonar el importe y no dispensar efectivo. Si la transacción es una petición de saldo No dispensar efectivo. En todo caso, El recibo muestra el número del CA, fecha, hora, número de cuenta, tipo-detransacción, importe (si lo hubiere) y nuevo saldo. Descripción de la función actualizar cuenta.

Identificar las restricciones. 40

OMT


Especificar los criterios de optimización

DISEÑO

CA

Cajero

Tarjeta de crédito

Terminal de cajero

Consorcio

Base de datos Cuenta

Líneas Telefónicas

Usuario

Cliente

Interfaz de usuario

Líneas Telefónicas

Transacción

Transacción

Autorización de tarjeta

Transacción

Arquitectura del Sistema CA

41

OMT


Pantalla principal Insertar tarjeta Solicitar Contraseña Introducir Contraseña Verificar cuenta Cuenta incorrecta

Cuenta OK Solicitar Clase Introducir clase Solicitar cantidad Introducir cantidad

Transacción fallida

Procesar transacción Transacción correcta Dispensar efectivo Retirar efectivo

Continuar

Solicitar continuación Concluir Fin Concluir

Tomar tarjeta

Tarjeta expulsada

Control de un CA Pseudocódigo Hacer para siempre Mostrar pantalla principal Leer tarjeta

42

OMT

Instituto Tecnológico de Morelia Repetir Pedir contraseña Leer contraseña Verificar cuenta Hasta que la verificación de cuenta sea correcta Repetir Repetir Preguntar clase de transacción Leer clase Leer cantidad Comenzar transacción Esperar que acabe Hasta que la transacción sea correcta Dispensar efectivo Esperar a que lo tome el cliente Preguntar si continúa Hasta que el usuario quiera terminar Expulsar tarjeta Esperar hasta que el cliente tome la tarjeta

43

Actividad 2. Importancia de las

[UNIDAD 3. METODOLOGÍAS DE DISEÑO PARA LA GENERACIÓN DE SISTEMAS metodologías OMT y OOSE en el diseño ORIENTADOS A OBJETOS.] de sistemas orientados a objetos.

OOSE Correspondencia de los modelos y sus fases

Proceso de análisis:

Proceso de construcción:

Proceso de prueba:

• Modelo de requerimientos. • Modelo de análisis.

• Modelo de diseño. • Modelo de implementación.

• Modelo de pruebas.

Establece los límites del sistema, y se destacan por ser funcionales y útiles. Desarrolla la estructura del sistema, donde existen tres tipos de objetos: de interface, de entidad y de control.

Subsecuente del modelo de análisis para el diseño y se adapta para establecerlo dentro de un ambiente de implementación.

Se realiza para establecer las pruebas al modelo de implementación.

Se basa en el código fuente de los objetos especificados en el modelo de diseño.

Ingeniería en Desarrollo de Software | Análisis y diseño orientado a objetos

1


[UNIDAD 3. METODOLOGÍAS DE DISEÑO PARA LA GENERACIÓN DE SISTEMAS metodologías OMT y OOSE en el diseño ORIENTADOS A OBJETOS.] de sistemas orientados a objetos. OMT Proceso de aplicación de las fases y modelos del OMT

1

Determinar el modelo para comprender el problema en el dominio de la aplicación.

2

Determinar la estructura del sistema en términos de subsistemas.

3

Dimensionar, afinar y optimizar el modelo de análisis, agregando conceptos de programación.

4

5

Implementar las clases de objetos representadas en un lenguaje de programación.

Validar el comportamiento de las clases y objetos que se encuentran descritos en los escenarios.

Modelo objeto: Modelo funcional: Especifican las clases que se descubrieron para el sistema analizado en términos del dominio del problema. Además se especifican los atributos y operaciones que distinguen a cada una de las clases y las relaciones con las que podemos conocer su responsabilidad en el sistema.

Aspectos que se transforman de acuerdo a la función del sistema; este modelo comúnmente es representado mediante un diagrama de flujo.

Modelo dinámico:

Aspectos temporales de comportamiento del sistema, mediante la secuencia de operaciones en el tiempo.


2


[UNIDAD 3. METODOLOGÍAS DE DISEÑO PARA LA GENERACIÓN DE SISTEMAS metodologías OMT y OOSE en el diseño ORIENTADOS A OBJETOS.] de sistemas orientados a objetos. 

Conclusiones:

La metodología OMT es una técnica de modelado de objetos, desarrollada por James Rumbaugh, que es uno de los precursores del Lenguaje Unificado de Modelado (UML). El significado de las siglas de esta metodología es Técnica de Modelado en Objetos (Object Modeling Technique), la definen como una de las metodologías de la Ingeniería de Software aplicable al desarrollo orientado a objetos en las fases de análisis y diseño. La fase de análisis comienza con la declaración del problema que incluye, una lista de objetivos (metas) y conceptos claves definitivos definidos para el dominio del problema a resolver. La declaración del problema se “expande“ después en tres modelos: • Modelo de objetos • Modelo dinámico • Modelo funcional El modelo de objetos representa los objetos del sistema. El modelo dinámico representa la interacción entre esos objetos representados como eventos, estados y transiciones. El modelo funcional representa los métodos del sistema desde la perspectiva de flujo de datos. La fase de análisis genera diagramas del modelo de objetos, diagramas de estado, diagramas de eventos de flujo y diagramas de flujos de datos. Es entonces cuando se tiene completa la fase de análisis. Después de la fase de análisis, se sigue con la fase de diseño de sistema. Aquí se define la arquitectura completa del sistema. Primero el sistema se organiza en subsistemas que están asignando a ciertos procesos y tareas, tomando en cuenta la colaboración y concurrencia entre ellos. Luego, el almacenamiento persistente de datos se establece por medio de una estrategia de manejo de información global compartida. Después, se examinan las situaciones límite para ayudar a establecer las prioridades de negociación. La fase de diseño de objetos viene después de la fase de diseño del sistema. Aquí se establece el plan de implementación. Se definen las clases de objetos, así como sus algoritmos, poniendo especial atención con la optimización y persistencia de datos. Se definen cuestiones de herencia, asociaciones, agregaciones y valores por omisión. La metodología OMT es secuencial en el sentido de que la primera fase es la de análisis, seguida por el diseño. En cada fase, se hacen aproximaciones iterativas entre los pequeños pasos a seguir. La metodología OMT es muy similar a la metodología Booch, cuyo principal criterio es hacer énfasis en las fases de diseño y análisis para una primera entrega del producto. Ambas OMT y Booch no hacen prioritarias las fases de implementación, evaluación u otras del ciclo de vida. OMT pone especial atención en el modelo y uso de modelos para lograr una abstracción, en el cual el análisis está enfocado en el mundo real a nivel de diseño, también pone detalles particulares para modelado de recursos físicos. Esta tecnología es aplicable en varios aspectos de implementación incluyendo archivos, bases de datos relacionales y orientados a objetos. OMT se construye alrededor de descripciones de estructuras de datos, constantes, sistemas de


3


[UNIDAD 3. METODOLOGÍAS DE DISEÑO PARA LA GENERACIÓN DE SISTEMAS metodologías OMT y OOSE en el diseño ORIENTADOS A OBJETOS.] de sistemas orientados a objetos. procesos de transacciones. OMT hace énfasis en especificaciones declarativas de la información, captura de manera transparente los requerimientos, especificaciones imperativas para poder descender prematuramente en el diseño y declaraciones que permiten optimizar los estados. Ivar Jacobson (OOSE) es el autor de los casos de uso y afirma que su metodología soporta el ciclo total de vida del software orientado-a-objetos. OMT se combina con OOSE en los casos de uso. La técnica de modelado de objetos (OMT) es considerado ampliamente como uno de los sistemas de análisis orientados a objetos más completos que se han publicado hasta el momento. El OMT tiene la intención de ser un método tanto para el análisis como para el diseño, pero aun cuando contiene un método bastante completo para el análisis, solamente tiende a dar indicaciones prácticas para el diseño. El OMT abarca más temas que la mayoría de los demás métodos, pero sigue siendo incompleto en algunos aspectos y resulta muy complejo aprender y utilizar sus notaciones. OMT está dividida en tres etapas: análisis, sistema de diseño, y diseño de objetos, además provee técnicas para describir el dominio del problema en tres perspectivas diferentes; la estructura estática de objetos y clases y el comportamiento dinámico de objetos, y la estructura funcional. Booch describe un número de propiedades generales para una buena estructura de un sistema complejo. El problema es modelado en dos perspectivas diferentes, una estructura lógica del sistema y una estructura física del sistema. La metodología de diseño propuesta por Booch es una de las mejor desarrolladas y contiene una noción de estructura mucho más general. El método original de Booch comienza por un análisis de flujo de datos, que se utiliza entonces como ayuda para identificar objetos, buscando tanto objetos concretos como objetos abstractos en el espacio del problema, que se encontraran a partir de las burbujas y almacenes de datos en el diagrama de flujo de datos (DFD). Booch utiliza una noción de estructura mucho más general. Existe otra metodología propuesta por Yourdon que presenta una notación menos torpe que la propuesta por Booch o algunas otras (Mellor) de las aproximaciones de diseño orientado a objetos. BIBLIOGRAFÍA: Riel J. Arthur, Object-Oriented Design Heuristics. Addison-Wesley Publishing Company, Inc. 1996. Shuguang Hong, Geert Van Den Goor, Sjaak Brinkkemper. A Formal Approach to the Comparison of Object-Oriented Analysis and Design Methodologies. Georgia State University, University of Nijmegen, University of Twente. (1997) Coldbert Edward. Choosing the Right Object-Oriented Method. Absolute Software Co. Inc. (1992). James Martin, James J.Odell. Médotods Orientados a Objetos. Prentice Hall. 1997. Guillén Romero Paola, Análisis y Diseño Orientado a Objetos, III Metodologías, Instituto Tecnológico de la Laguna. Víctor Manuel Chávez Gaona #Control: 99120839 Víctor Manuel Chávez Gaona #Control: 99120839 ez Gaona #Control: 99120839 Juan Carlos Olivares Rojas #Control: 99120871. (2002). Metodología OMT. 25 de Agosto de 2015, de INSTITUTO TECNOLOGICO DE MORELIA, DEPARTAMENTO DE SISTEMAS Y COMPUTACION, INGENIERÍA EN SISTEMAS COMPUTACIONALES Sitio web: http://dsc.itmorelia.edu.mx/~jcolivares/documents/omt


4

DDOO_U3_A2_ANDB

Recommend Documents