miércoles, 10 de junio de 2009

Microproceso

Booch en esencia plantea que para trabajar con su método es conveniente trabajar en dos partes fundamentales: un microproceso y un macroproceso. Ambas partes incluyen varios pasos como son la identificación de clases y objetos a un nivel de abstracción dado, la identificación de la semántica de esas clases y objetos, la identificación de las relaciones entre esas clases y objetos, la selección de la estructura de datos y algoritmos para la implantación de estas clases y objetos, la conceptualización del sistema, etc. El microproceso de desarrollo del AOO de Booch incluye:

  • Identificación de clases y objetos.
  • Proposición de objetos candidatos.
  • Conducción del análisis de comportamiento.
  • Identificación de escenarios relevantes.
  • Definición de atributos y operaciones para cada clase.
  • Identificación de la semántica de clases y objetos.
  • Selección y análisis de escenarios.
  • Asignación de responsabilidades para alcanzar el comportamiento deseado.
  • División de las responsabilidades para equilibrar el comportamiento.
  • Selección de un objeto y enumerar sus papeles y responsabilidades.
  • Definición de operaciones para satisfacer las responsabilidades.
  • Búsqueda de colaboraciones entre objetos.
  • Identificación de interrelaciones entre clases y objetos.
  • Definición de las dependencias que existen entre objetos.
  • Descripción del papel de cada objeto participante.


  • Validación de escenarios por revisión completa.
  • Realización de una serie de refinamientos.
  • Producción de los diagramas apropiados para el trabajo realizado en las partes anteriores.
  • Definición de jerarquías de clases apropiadas.
  • Creación de agrupamientos basados en clases comunes.
  • Implementación de clases y objetos.

martes, 9 de junio de 2009

Diseño orientado a objetos

La metodología de Booch o también llamado “diseño orientado a objetos de Grady Booch (OOD)”. Provee una forma de desarrollar análisis y diseño de un sistema orientado a objetos.
La metodología de Booch es secuencial en el sentido que la fase de análisis es completada y posteriormente la fase de diseño también. Es cíclica en el sentido que cada fase está compuesta de pasos cíclicos más pequeños.

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.


Para Booch el Diseño Orientado a Objetos (DOO) "es el método que lleva a una descomposición Orientado a Objetos. Aplicando DOO, se crea software resistente al cambio y escrito con economía de expresión. Se logra un mayor nivel de confianza en la corrección del software a través de la división inteligente de su espacio de estados. En última instancia, se reducen los riesgos inherentes al desarrollo de sistemas".
En su libro Análisis y Diseño Orientado a Objetos con Aplicaciones, Grady Booch señala que: "Los métodos son importantes por varias razones. En primer lugar, inculcan una disciplina en el desarrollo de sistemas de software complejos. Definen los productos que sirven como vehículo común para la comunicación entre los miembros de un equipo de desarrollo. Además, los métodos definen los hitos que necesita la dirección para medir el progreso y gestionar el riesgo".

El papel del ingeniero como artista es particularmente dificultoso cuando la tarea es diseñar un sistema completamente nuevo. Francamente, es la circunstancia más habitual en la ingeniería del software.

"Es imposible capturar todos los detalles sutiles de un sistema de software complejo en una sola vista. ... Uno debe comprender la estructura taxonómica de las clases, los mecanismos de herencia utilizados, los comportamientos individuales de los objetos y el comportamiento dinámico del sistema en su conjunto".

Diagramas de clases

En este tipo de diagramas se muestran las clases con sus relaciones, o lo que es lo mismo, la estructura de clases.

El gráfico correspondiente a una clase en la notación de Booch es una especie de nube a trazos en cuyo interior se escribe el nombre de la misma, separado por una linea de sus atributos (estado) y métodos (comportamiento). Cada clase lleva asociado un nombre que en general debe ser único. No se especifican todos los métodos y atributos siempre, sino solamente aquellos que son relevantes para la parte del diseño que tratamos de describir.


http://www.ifca.unican.es/~matorras/programacion/Diagramas_clase.html

Diagramas de módulos


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.

Programa principal: Identifica al archivo que contiene la raíz del programa.
Especificación y cuerpo: Identifican los archivos que contienen la declaración y la definición de los objetos o bien procedimientos o funciones necesarias para el correcto funcionamiento de la aplicación.
http://www2.uah.es/jcaceres/uploaded/capsulas/DiagramaModulos.pdf

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. Con fines analíticos y como ayuda para descubrir y eliminar ineficiencias, es conveniente clasificar las acciones que tienen lugar durante un proceso dado en cinco clasificaciones. Estas se conocen bajo los términos de operaciones, transportes, inspecciones, retrasos o demoras y almacenajes. Las siguientes definiciones en la tabla 5.1, cubren el significado de estas clasificaciones en la mayoría de las condiciones encontradas en los trabajos de diagramado de procesos.


Este diagrama muestra la secuencia cronológica de todas las operaciones de taller o en máquinas, inspecciones, márgenes de tiempo y materiales a utilizar en un proceso de fabricación o administrativo, desde la llegada de la materia prima hasta el empaque o arreglo final del producto terminado. Señala la entrada de todos los componentes y subconjuntos al ensamble con el conjunto principal. De igual manera que un plano o dibujo de taller presenta en conjunto detalles de diseño como ajustes tolerancia y especificaciones, todos los detalles de fabricación o administración se aprecian globalmente en un diagrama de operaciones de proceso.




El Diagrama de Transición 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.
Elementos
Entidades: Las entidades pasan por varios estados. En cada uno de ellos pueden suceder determinados eventos que provoquen efectos o acciones sobre la entidad.

Eventos: Algo que sucede en el mundo real y como consecuencia se ejecuta un proceso.
Acciones: Descripción del estado de un evento sobre una entidad

Definición de DTE.

Un diagrama de transición de estados describe un conjunto de transiciones que pueden suceder sobre una entidad. El estado en que se encuentra una entidad es el resultado de todas las transiciones sucedidas durante su vida.

referencias electrónicas:
http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060030/lecciones/Capitulo%204/estado.htm

http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060030/lecciones/Capitulo%204/estado.htm

Diagramas de interacción




Diagramas de interacción Muestran 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.



Comúnmente contienen:




Objetos
Enlaces





Mensajes Pueden servir para visualizar, especificar, construir y documentar los aspectos dinámicos de una sociedad particular de objetos, o pueden ser usados para modelar un flujo particular de control de un caso de uso.
Los diagramas de interacción están conformados por los diagramas de secuencia y los diagramas de colaboración.

Método Booch



Esta metodología fue desarrollada por Grady Booch en el año de 1991 mientras trabajaba en Rational Software, que es parte de IBM desde el 2003.

Define seis tipos de diagramas:


•Diagrama de clase:

para mostrar la existencia de clases y sus relaciones en la visión lógica de un sistema.



•Diagrama de objetos:



para mostrar la existencia de objetos y sus relaciones en el diseño lógico de un sistema.



Diagramas de Módulos:


para mostrar la asignación de clases y objetos a módulos en el diseño físico de un sistema



Diagramas de Transición de Estados:

para mostrar el espacio de estados de una clase determinada, los eventos que provocan una transición de un estado a otro, y las acciones que resultan de ese cambio de estado.


•Diagramas de Interacción:

para realizar una traza de la ejecución de un escenario en el mismo contexto que un diagrama de objetos.


¿Cómo funciona el método?


La fase de análisis se divide en pasos:


Análisis de requerimientos


se establecen los requerimientos desde una perspectiva del consumidor o usuario, éste paso genera una descripción de alto nivel del funcionamiento y de la estructura del sistema.




Análisis de Dominio



se definen las clases, sus atributos, la herencia de clases y métodos de éstas. Los diagramas de los objetos son realizados posteriormente.



Diseño


Un diseño lógico es mapeado físicamente en donde los detalles de la ejecución, procesos, rendimiento, tipo de datos, estructura de datos, visibilidad y distribución son establecidos.

referencia electrónica:
http://www.scribd.com/doc/12849637/MDA-MDA-en-Java-Metodologias-de-Booch-y-de-Rumbaugh-OMT

La complejidad de los sistemas de software

Según Grady Booch, la complejidad de los sistemas de software se deriva de cuatro elementos:

1.- La complejidad del dominio del problema.
Los problemas que se intentan resolver son inherentemente complejos, con una gran cantidad de requisitos que compiten entre sí.

2.- La dificultad de gestionar el proceso de desarrollo.
Los desarrolladores de software enfrentan el reto de dar a los usuarios la impresión de simplicidad, esto es reducir al mínimo la complejidad externa. Este reto les obliga a incrementar el tamaño de los sistemas, a inventar mecanismos ingeniosos, o a reutilizar diseños y código ya existentes.

3.- La flexibilidad que se puede alcanzar a través del software.
La elaboración de software es una actividad muy laboriosa porque empuja al desarrollador a construir por sí mismo prácticamente todos los bloques fundamentales sobre los que se apoyan las abstraccicones de más alto nivel. Esto es propiciado, en gran medida, por la existencia de pocos estándares para el control de calidad.

4.- Los problemas de caracterizar el comportamiento de sistemas discretos.
Los comportamientos de la mayoría de los objetos se representan por sistemas analógicos en los que, a través de funciones contínuas, pequeños cambios en las entradas siempre producen pequeños cambios en las salidas.
Por el contrario, puesto que el software se ejecuta en computadoras digitales, se tienen sistemas con un número finito de estados discretos. En sistemas grandes, este número puede crecer a cantidades enormes. Como no existen herramientas matemáticas para modelar el comportamiento completo de los grandes sistemas discretos, se debe aceptar la pérdida de cierto grado de confianza en cuanto a que las salidas sean correctas.
si quieres saber más,aquí te dejo la dirección de la página de donde lo investigue:
Aquí les dejo estas direcciones en donde pueden investigar

http://www.scribd.com/doc/12849637/MDA-MDA-en-Java-Metodologias-de-Booch-y-de-Rumbaugh-OMT


http://www.scribd.com/doc/12849637/MDA-MDA-en-Java-Metodologias-de-Booch-y-de-Rumbaugh-OMT

http://www.scribd.com/doc/12839949/Metodologias-para-Analisis-y-Diseno-Orientado-a-Objetos-y-MDA-Model-Driven-Architecture-

http://148.202.148.5/cursos/id209/mzaragoza/unidad2/unidad2dos.htm

http://148.202.148.5/cursos/cc321/fundamentos/unidad3/tema3_4_2.html

http://www.mcc.unam.mx/~cursos/Objetos/Cap18/cap18.html

http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060030/lecciones/Capitulo%204/estado.htm

http://catarina.udlap.mx/u_dl_a/tales/documentos/macm/macias_l_c/capitulo4.pdf