Objetivo Particular:
Utilizar la tecnica UML en el analisis de sistemas OO.
DESCRIPCIÓN DEL CICLO DE VIDA ORIENTADO A OBJETOS SEGÚN GRADY BOOCH
Características del proceso de producción de software orientado a objetos
Según la experiencia de Booch, todos los sistemas orientados a objeto que analizó y
que terminaron con éxito tienen dos características en común:
1.- La existencia de una fuerte visión estructural con buena integridad
conceptual
2.- La aplicación de un ciclo de vida del desarrollo bien dirigido, iterativo e
incremental
Cuando dice bien dirigido lo dice en el sentido de que el proceso pueda controlarse y medirse,
aunque no debe ser tan rígido como para que limite la creatividad.
Según sus observaciones, cualquier actividad humana que requiera creatividad e
innovación demanda un proceso incremental e iterativo, que se apoya en la
experiencia, inteligencia y talento de todos los miembros del equipo.
El primer problema del análisis orientado a objetos es un problema de clasificación (creación
de clases), y esa clasificación inteligente es un trabajo intelectualmente difícil de por
sí y la parte más difícil de un diseño orientado a objetos. La mejor forma de
abordarlo es por un proceso iterativo e incremental.
De esta forma la descomposición orientada a objetos reduce en gran medida el
riesgo que representa construir sistemas de software complejos, porque están
diseñados para evolucionar de forma incremental partiendo de sistemas más
pequeños en los que ya se tiene confianza.
Booch desaconseja, a título personal, el uso del análisis estructurado como punto de
partida para el diseño orientado a objetos.
En el proceso orientado a objetos, las fronteras entre el análisis y diseño son difusas
aunque el objetivo principal de ambos es bastante diferente. En el análisis se
descubren las clases y objetos, y en el diseño se plantean las abstracciones y
mecanismos que proporcionan el comportamiento.
Para el análisis, Booch recomienda fuertemente el análisis de casos de uso y la
técnica de escenarios para guiar el proceso de identificación de clases y objetos. El análisis se
desarrolla entonces como un estudio de cada escenario fundamental,
usando técnicas de presentación.
En cuanto al diseño, los mecanismos son el alma del mismo. Durante el proceso de
diseño el desarrollador debe considerar no sólo el diseño de clases individuales, sino
también cómo trabajan juntas las instancias de esas clases . Nuevamente el uso de
escenarios dirige este proceso.
El ciclo de vida incremental e iterativo
Como dijimos anteriormente, los proyectos con éxito orientados a objeto que Booch
ha analizado, no siguen ni los ciclos de desarrollo anárquicos ni los draconianos
(estrictos). Se encuentra que el proceso tiende a ser iterativo e incremental.
Proceso Iterativo en el sentido de que conlleva el refinamiento sucesivo de una
arquitectura orientada a objetos, por el cual se aplica la experiencia y resultados de
cada versión a la siguiente iteración del análisis y el diseño.
Proceso incremental en el sentido de que cada pasada por un ciclo
análisis/diseño/evolución lleva a refinar gradualmente las decisiones estratégicas y
tácticas.
Un ciclo de vida iterativo e incremental es la antítesis del ciclo de vida tradicional en
cascada y por lo tanto no representa ni un proceso descendente ni ascendente en
sentido estricto. Booch considera que es más bien un proceso global circular.
Ahora bien, ¿cómo se reconcilia la necesidad de creatividad e innovación con el
requerimiento de prácticas de gestión más controladas?. La respuesta propuesta por
Booch reside en la distinción de los micro y macroelementos del proceso de
desarrollo. En consonancia con ellos idea un microproceso y un macroproceso.
El microproceso está más estrechamente relacionado con el modelo espiral de
desarrollo de Boehm, y sirve como marco de referencia para un enfoque iterativo e
incremental de desarrollo. El macroproceso tiene más que ver con el ciclo de vida
tradicional en cascada, y sirve como el marco de referencia controlador para el
microproceso. Reconciliando estos dos procesos dispares, se acaba por emular un
proceso de desarrollo plenamente racional. Cada proyecto es único, y los
desarrolladores deben hacer un balance entre la informalidad del microproceso y la
formalidad del macroproceso.
Los párrafos reseñados anteriormente conforman un resumen de la presentación y
fundamentación de Booch al ciclo de vida iterativo e incremental, prácticamente con
sus mismas palabras. Considero necesario en este punto hacer una aclaración que
permita ubicarnos mejor en su esquema.
Booch habla de un macroproceso que da orden al desarrollo de software y dentro
del cual existe un microproceso.
El esquema de Booch entonces se centra en la iteración de este ciclo que el llama el
macroproceso. Esta iteración se centra principalmente en las etapas de análisis,
diseño y evolución.
A su vez el ciclo que llama el microproceso, consta también de cuatro etapas.
La idea de Booch es que ese microproceso con sus cuatro etapas se itera dentro de
fases del macroproceso. Tendríamos entonces una iteración dentro de otra iteración.
Es por eso que en la explicación del microproceso se tiende a separar el significado
de cada etapa del mismo, según sea la etapa del macroproceso en que se
encuentre.
Si bien no es objetivo de este informe presentar el método de Booch en forma
completa, se comentará cada fase lo suficiente como para que el lector pueda tener
una idea acabada de sus características generales.
Sigamos entonces con la descripción de los dos procesos.
BOOCH
El método de Booch considera que las etapas del proceso en un desarrollo orientado a objetos son:
1. Identificar las clases y objetos en un nivel dado de abstracción
2. Identificar la semántica de estas clases y objetos
3. Identificar las relaciones entre clases y objetos
4. Especificar la interfaz y la implementación de estas clases y objetos
Estas etapas suelen seguirse por la mayoría de los métodos de diseño OO existentes.
Object Modeling Technique
Técnica de modelado de objetos
OMT es una de las metodologías de análisis y diseño orientadas a objetos, más maduras y eficientes que existen en la actualidad. La gran virtud que aporta esta metodología es su carácter de abierta (no propietaria), que le permite ser de dominio público y , en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolución para acoplarse a todas las necesidades actuales y futuras de la ingeniería de software.
Las fases que conforman a la metodología OMT son:
• Análisis. El analista construye un modelo del dominio del problema, mostrando sus propiedades más importantes. El modelo de análisis es una abstracción resumida y precisa de lo que debe de hacer el sistema deseado y no de la forma en que se hará. Los elementos del modelo deben ser conceptos del dominio de aplicación y no conceptos informáticos tales como estructuras de datos. Un buen modelo debe poder ser entendido y criticado por expertos en el dominio del problema que no tengan conocimientos informáticos.
"El resultado del análisis debería ser la compresión del problema como
preparación para el diseño".
• Diseño del sistema. El diseñador del sistema toma decisiones de alto nivel sobre la arquitectura del mismo. Durante esta fase el sistema se organiza en subsistemas basándose tanto en la estructura del análisis como en la arquitectura propuesta. Se selecciona una estrategia para afrontar el problema.
• Diseño de objetos. El diseñador de objetos construye un modelo de diseño basándose en el modelo de análisis, pero incorporando detalles de implementación. El diseño de objetos se centra en las estructuras de datos y algoritmos que son necesarios para implementar cada clase. OMT describe la forma en que el diseño puede ser implementado en distintos lenguajes (orientados y no orientados a objetos, bases de datos, etc.).
• Implementación. Las clases de objetos y relaciones desarrolladas durante el análisis de objetos se traducen finalmente a una implementación concreta. Durante la fase de implementación es importante tener en cuenta los principios de la ingeniería del software de forma que la correspondencia con el diseño sea directa y el sistema implementado sea flexible y extensible. No tiene sentido que utilicemos AOO y DOO de forma que potenciemos la reutilización de código y la correspondencia entre el dominio del problema y el sistema informático, si luego perdemos todas estas ventajas con una implementación de mala calidad.
Pruebas y Mtto.
El propósito del Análisis orientado a objetos es definir todo aquello que resulte
relevante al problema que se va resolver para lo cual se deben ejecutar
los siguientes pasos:
• Definición del problema
• Construcción del modelo de objetos
• Construcción del modelo dinámico
• Construcción del modelo funcional
La metodología OMT emplea tres clases de modelos para describir el sistema:
• Modelo de objetos. Describe la estructura estática de los objetos del sistema (identidad, relaciones con otros objetos, atributos y operaciones). El modelo de objetos proporciona el entorno esencial en el cual se pueden situar el modelo dinámico y el modelo funcional. El objetivo es capturar aquellos conceptos del mundo real que sean importantes para la aplicación. Se representa mediante diagramas de onjetos.
• Modelo dinámico. Describe los aspectos de un sistema que tratan de la temporización y secuencia de operaciones (sucesos que marcan los cambios, secuencias de sucesos, estados que definen el contexto para los sucesos) y la organización de sucesos y estados. Captura el control, aquel aspecto de un sistema que describe las secuencias de operaciones que se producen sin tener en cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en que están implementadas. Se representa gráficamente mediante diagramas de estado.
• Modelo funcional. Describe las transformaciones de valores de datos (funciones, correspondencias, restricciones y dependencias funcionales) que ocurren dentro del sistema. Captura lo que hace el sistema, independientemente de cuando se haga o de la forma en que se haga. Se representa mediante diagramas de flujo de datos
RELACION EXISTENTE ENTRE LOS 3 MODELOS
Modelo Funcional: El modelo de objetos muestra la estructura de los actores,
almacenes de datos y flujos del modelo funcional. El modelo dinámico
muestra la secuencia en que se llevan a cabo los procesos. dfd
Modelo de Objetos: El modelo funcional muestra las operaciones aplicadas
a clases y los argumentos de cada operación. El modelo dinámico muestra
los estados de cada objeto y las operaciones que se efectúan a medida que
recibe sucesos y cambia su estado.
Modelo dinámico: El modelo funcional muestra las definiciones de las acciones
primitivas y las actividades que no están definidas por el modelo dinámico.
El modelo de objetos muestra lo que cambia de estado y lo que sufre
operaciones. destado
OMT pone énfasis en la importancia del modelo y uso del modelo para lograr una abstracción, en el cual el análisis esta enfocado en el mundo real para un nivel de diseño, también pone detalles particulares para modelado de recursos de la computadora. Esta Tecnología puede ser aplicada en varios aspectos de implementación incluyendo archivos, base de datos relacionales, base de datos orientados a objetos. OMT esta construido alrededor de descripciones de estructura de datos, constantes, sistemas para procesos de transacciones.
Es muy fácil de aprender ya que para el 90% de casi todos los proyectos se ocupan casi todo el mismo subconjunto de notaciones, además debido a su sencillez se ha extendido a casi todo los niveles de ingeniería de software, pero esta simplicidad del método hace posible que en algunos casos (sobre todo complejos) no se puedan modelar con este sistema.
TRABAJO FINAL
El trabajo es entregado a titulo personal o por equipos de 2 integrantes, siempre y cuando no hayan reprobado ambos el parcial numero 2.
El trabajo consiste en una serie de estudios que deberan cubrir EL ANALISIS Y DISEÑO de un problema de desarrollo de las materias que cubren lenguaje C o MICROSOFT ACCESS, no es obligatorio generar el problema, sino que puede ser alguno que exista previamente o se encuentre en desarrollo para alguna otra materia de la especialidad.
El analisis y diseño estara basado en un esquema ESTRUCTURADO o CLASICO, pero agregaremos algunas caracteristicas de la unidad III para Orientarla a Objetos.
Las etapas que se deben incluir son:
--Gestion de proyectos. Descripcion breve y completa acerca de las 3 P's de Pressman para la Gestion de proyectos.
--SRS. Listado de los requerimientos y caracteristicas que el cliente afirma que quiere para terminar su proyecto. Deben cumplir con las caracteristicas del buen SRS.
--Elaborar un prototipo que ilustre de forma visual como quedara la respuesta al problema basandonos en el paso anterior.
--Propuesta de Desarrollo. Se debe ilustrar la propuesta, y mostrar alguno de los modelos existentes para indicar que se realizara en cada una de las etapas, similar a la exposicion que se hizo para aplicar algunos de los modelos de desarrollo mas famosos.
--Realizar un diagrama de Flujo de Datos.
--Realizar un diagrama de Entidad Relacion.
--Realizar un diagrama de Flujo Transicion de estados.
--Acceso directo al proyecto terminado o incluir el proyecto terminado.(opcional)
--Analisis y diseño ORIENTADO A OBJETOS, es decir incluir algunos diagramas que ilustren el MODELO ESTATICO, FUNCIONAL y DINAMICO, del problema de lenguaje C o Access, similar al ultimo trabajo que se entrego por equipos.(bonus)
El limite de tiempo para hacer entrega de este trabajo sera el proximo jueves 23 de noviembre del 2006.