Professional Documents
Culture Documents
Escribir un reporte comentando las respuestas a las preguntas sugeridas. Incluir lista de
diagramas UML que son necesarios para cada metodologa si es aplicable.
INTRODUCCIN
Las metodologas de desarrollo de sistemas tratan las siguientes fases del ciclo de vida
del desarrollo de sistemas: planeacin, anlisis, diseo, proteccin y transicin.
Al anlisis del sistema modela un rea de sistemas basados en ideas y conceptos de los
expertos de dominio proponiendo cualquier decisin relacionada con la
instrumentacin.
Cuando analizamos sistemas, creamos modelos del rea de aplicacin que nos interesa.
Un modelo puede incorporar un sistema, centrarse en el rea de la empresa o abarcar
toda la empresa.
Con el anlisis orientado a objetos, la forma de modelar la realidad difiere del anlisis
convencional. Modelamos el mundo en trminos de tipos de objetos y lo que le ocurre a
stos. Los modelos que construimos en el anlisis OO reflejan la realidad de modo ms
natural que los del anlisis tradicional de sistemas. Mediante las tcnicas OO,
construimos software que modela mas fielmente el mundo real. Cuando el mundo real
cambia, nuestro software es ms fcil de cambiar, lo que es una ventaja real.
La fase de anlisis comienza con la declaracin del problema que incluye, una lista de
de objetivos (metas) y conceptos claves definitivos definidos para el dominio del
problema a resolver. La declaracin del problema se expande despus en tres
modelos:
Modelo de objetos
Modelo dinmico
Modelo funcional
El modelo de objetos representa los objetos del sistema. El modelo dinmico representa
la interaccin entre esos objetos representados como eventos, estados y transiciones. El
modelo funcional representa los mtodos del sistema desde la perspectiva de flujo de
datos. La fase de anlisis 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 anlisis.
Despus de la fase de anlisis, se sigue con la fase de diseo de sistema. Aqui se define
la arquitectura completa del sistema. Primero el sistema se organiza en subsistemas que
estn asigando a ciertos procesos y tareas, tomando en cuenta la colaboracin y
concurrencia entre ellos. Luego, el almacenamiento persistente de datos se establece por
medio de una estrategia de manejo de informacin global compartida. Despus, se
examinan las situaciones limite para ayudar a establecer las prioridades de negociacin.
La fase de diseo de objetos viene despus de la fase de diseo del sistema. Aqui se
establece el plan de implementacin. Se definen las clases de objetos, as como sus
algoritmos, poniendo especial atencin con la optimizacin y persistencia de datos. Se
definen cuestiones de herencia, asociaciones, agregaciones y valores por omisin.
OMT pone especial atencin en el modelo y uso de modelos para lograr una
abstraccin, en el cual el anlisis est enfocado en el mundo real a nivel de diseo,
tambin pone detalles particulares para modelado de recursos fsicos. Esta tecnologa es
aplicable en varios aspectos de implementacin incluyendo archivos, bases de datos
relacionales y orientadas a objetos. OMT se construye alrededor de descripciones de
estructuras de datos, constantes, sistemas de procesos de transacciones.
Conceptualizacin El desarrollo comienza con el anlisis de la empresa o negocio, la visin que tienen los
usuarios del sistema y la formulacin de requerimientos.
Pueden existir diversas fuentes de informacin que pueden ser tiles en esta etapa.
Puede existir algun lenguaje formal para describir el problema. Algunas veces los
expertos del dominio pueden proveer escenarios, storyboards y casos de uso para un
nuevo sistema.
Aqui es donde se determina el modelo del objeto, se hace una tentativa de clases, se
eliminan las clases irrelevantes, se definen las posibles asociaciones entre las clases y se
hace la refinacin de ellas eliminando las redundantes o las que no tienen relevancia,
posteriormente se hace una tentativa de atributos de objetos y enlaces.
Una vez determinados los objetos del sistema, se hace la depuracin del modelo,
posteriormente se busca un nivel de abstraccin para modelar subsistemas, para buscar
un sistema tngible y slido.
Diseo del sistema El diseo tiene un alto nivel estratgico y decisivo para la resolucin de problemas. Los
problemas grandes se deben ver desde el punto de vista de anlisis y diseo, subdividir
el sistema en subsistemas, poder modular los subsistemas de tal manera que cada
modulo sea manejable y comprensible.
En esta etapa se deben crear estrategias, formular una arquitectura para el sistema y las
polticas que deben guiarla , adems del detalle de diseo. Se deben considerar los
siguientes aspectos:
Visualizacin de la arquitectura
Elegir un tipo de implementacin para control extremo
Si se usa una base de datos, definir el paradigma a utilizar
Determinar oportunidades para el re-uso
Elegir estrategia para interaccin de datos
La metodologa OMT soporta mltiples estilos de desarrollo. Se puede usar OMT para
conseguir un alto desempeo en las fases de anlisis, diseo e implementacin.
UML Como se coment anteriormente, la metodologa OMT se define como una metodologa
predecesora del UML, por lo que se pueden definir tres tipos de diagramas en OMT que
hoy da son parte de UML: diagramas de objetos, dinmicos y funcionales.
Diagramas de vista de objetos:
El modelo de objeto de OMT ilustra las relaciones estticas entre clases y objetos del
sistema. Estos diagramas son muy similares a los objetos de clases y objetos de UML.
Clases, el tipo grfico para representar una clase siguiendo una metodologa OMT es el
mismo que se utiliza en UML, donde se divide un rectangulo en tres partes, cada una
corresponde al nombre de la clase, los atributos y las operaciones.
Atributos ligados, para describir las propiedades de una relacin o asociacin, se puede
utilizar un arco para adjuntar un atributo a la relacin.
La notacin OMT para diagramas dinmicos son como los diagramas de secuencia y
estados de UML
Herramientas para Una de las herramientas que permite el uso de la metodologa OMT es el SmartDraw,
que como se ha visto en clase, nicamente permite el dibujo de los diagramas definidos
metodologa OMT por esta metodologa. Otras herramientas que soportan metodologa OMT son: Rational
Rose, System Architect 4.0, Poseidon, Power Builder, entre otras.
METODOLOGA BOOCH
La metodologa Booch se enfoca principalmente al diseo de estado de un proyecto.
Boch describe una serie de propiedades generales de los sistemas complejos bien
estructurados. Los sistemas construidos con una metodologa de anlisis y diseo
orientado a objetos deben satisfacer estas propiedades.
La arquitectura del modelo y del proceso describe la ubicacin fsica de las clases en
mdulos y procesos.
Procesos micro:
Identificar las clases y objetos a cierto nivel de abstraccin,
Identificar la semntica de estas clases y objetos,
Identificar las relaciones entre las clases y objetos,
Especificar la interfaz y despus la implementacin de las clases y objetos.
La metodologa Booch cubre las fases de anlisis y diseo de un sistema O.O. Esta
metodologa en ocasiones es criticada por el uso de muchos simbolos diferentes. Es
cierto que Booch define muchos simbolos que documentar casi para cada decisin de
diseo. Si se trabaja con esta metodologa, uno se percata de que nunca se utilizan todos
estos simbolos y diagramas. Se comienza con diagramas clase-objeto en la fase de
anlisis y se depuran en varios pasos. Unicamente cuando se est listo para generar
cdigo, se agregan algunos simbolos de diseo. Y est es la parte en que la metodologa
Booch es fuerte, realmente es posible documentar el cdigo orientado a objetos.
Categoria de clase
Sintxis para
atributos y operaciones
Clase parametrizada
Objeto
Sincronizacin (para objetos activos)
Visibilidad
Relacin objeto
cono de historial
de estado
cono de estado
Subsistema
El diseo creativo tomando como referencia una base arquitectnica es seguir paso a
paso los mtodos y procesos con la asistencia de herramientas, para convertir los
requerimientos dentro de una arquitectura viable para la construccin de un proyecto
incluyendo la creacin de prototipos.
Modelo de anlisis Especifica el comportamiento funcional del sistema bajo prcticamente circunstancias
ideales y sin hacer alusin a un ambiente particular de implementacin.
Construccin
Consiste en la verificacin del trabajo de cada uno de los paquetes de servicio definidos
en el modelo de anlisis Esta fase tiene lugar en varios niveles, desde funciones
especficas, hasta el sistema completo.
FIGURA 18.
Modelo de anlisis Se ha visto que el modelo de requerimientos tiene como objetivo definir las limitaciones
del sistema y especificar su comportamiento. Cuando el modelo de requerimientos ha
sido desarrollado y aprobado por los usuarios se puede iniciar el desarrollo del sistema.
Existen varios tipos de objetos usados para la estructura del sistema en el modelo de
anlisis. Cada objeto al menos captura dos de las tres dimensiones del modelo de
anlisis, sin embargo cada uno de ellos tiene cierta inclinacin hacia una de las
dimensiones.
Modelo de anlisis
Modelo de diseo de El proceso de construccin edifica el sistema usando tanto el modelo de anlisis como el
modelo de requerimientos. Primero se crea el modelo de diseo que es un refinamiento
objetos y formalizacin del modelo de anlisis. Al inicio del trabajo cuando se desarrolla el
modelo de diseo es para adaptarlo a la implementacin del ambiente actual.
Cuando se tiene que crear la estructura del bloque, se dibuja un diagrama de interaccin
para mostrar como los bloques se comunican. Normalmente se dibuja un diagrama de
interaccin para cada caso de uso.
Diagrama de interaccin
Modelo de prueba El modelo de prueba es el ultimo modelo a construir. Describe simplemente el estado de
resultados de la prueba. El modelo de requerimientos de nuevo representa una
herramienta potente de prueba, al probar cada caso de uso, se verifica que los objetos se
comuniquen correctamente en dicho caso de uso. De manera simular se verifica la
interfase de usuario, descrita en el modelo de requerimientos, con todo lo anterior, el
modelo de requerimientos es la base de verificado para el modelo de prueba.
Conclusiones Ivar Jacobson (OOSE) es el autor de los casos de uso y afirma que su metodologa
soporta el ciclo total de vida del software orientado-a-objetos. OMT se combina con
OOSE en los casos de uso.
OMT est dividida en tres etapas: anlisis, sistema de diseo, y diseo de objetos,
adems provee tcnicas para describir el dominio del problema en tres perspectivas
diferentes; la estructura esttica de objetos y clases y el comportamiento dinmico de
objetos, y la estructura funcional.
El mtodo original de Booch comienza por un anlisis 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 nocin
de estructura mucho mas general.
Existe otra metodologa propuesta por Yourdon que presenta una notacin menos torpe
que la propuesta por Booch o algunas otras (Mellor) de las aproximaciones de diseo
orientado a objetos.
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. Mdotods Orientados a Objetos. Prentice Hall. 1997.
http://www.cis.gsu.edu/~shong/
http://www.dte.us.es/personal/pruiz/investigacion/trabajo_investigacion/html/
http://www.db.stanford.edu/~burback/watersluice/
http://www.ifra.ing.tu-bs.de/docs/BoochReferenz/