Modelamiento Orientado a Objetos

La distancia entre el espacio del problema (Universo de Discurso) y el espacio de la solucin (producto software) hace necesario que la especificacin de requisitos del sistema, resultante del proceso de modelado conceptual, tenga dos importantes propiedades: debe ser abstracta y declarativa. A que nos referimos con modelo: Modelo: abstraccin de algo, con el comprenderlo antes de construirlo. Modelos y abstraccin. propsito de

Un modelo sirve para: Verificar una entidad fsica antes de su construccin. Comunicarnos con otros usuarios. Visualizar. Disminuir la complejidad. Abstraccin: examen selectivo de ciertos aspectos del problema, eliminando los aspectos que no son importantes. La abstraccin debe servir para un propsito que nos determina lo que no es importante, delimitando nuestro universo. Es posible obtener mltiples abstracciones de la misma cosa.

Todas las abstracciones son incompletas e inadecuadas.

Un buen modelo captura los aspectos cruciales del problema y omite el resto.

Entre las ventajas ms destacables cabe sealar las siguientes:

La encapsulacin bajo el concepto de objeto incluyendo las perspectivas esttica y dinmica del sistema estudiado.
La desaparicin de barreras estrictas entre las distintas fases del ciclo de vida o proceso de produccin de software. La proximidad de sus nociones a los mecanismos cognitivos humanos reduciendo as la distancia entre el problema y su solucin. La orientacin a objetos es un enfoque apropiado para el modelado de requisitos de sistemas de informacin.

Modelo Conceptual

En la fase de Modelizacin Conceptual se construyen tres modelos del sistema: Modelo de Objetos. Modelo Dinmico. Modelo Funcional.

Modelo de Objetos
Una clase se representa grficamente como una caja dividida en tres reas:

Cabecera: contiene la declaracin del nombre de la clase.

Parte Esttica: contiene la definicin de los atributos que representan el estado de los objetos de la clase. Los atributos podrn ser constantes, variables y derivados. Aquellos atributos utilizados para identificar objetos se subrayan. Parte Dinmica: contiene la declaracin de los servicios de la clase. Cada servicio se declara especificando su nombre y argumentos (con sus tipos respectivos). Se distinguir (grficamente) entre los eventos de creacin, borrado y los eventos compartidos con otras clases.

Ejemplo de clase

La Herencia
Se define grficamente trazando una flecha desde la subclase hacia la superclase correspondiente. Esta flecha de especializacin puede etiquetarse con una condicin de especializacin o con los eventos correspondientes de activacin/cancelacin de la especializacin temporal (rol).

 Restricciones de Integridad:
Establecen condiciones que el estado de los objetos debe satisfacer siempre (estticas) o durante un determinado perodo de su existencia (dinmicas).

Derivaciones: Sirven para calcular el valor de los atributos derivados. Dicho valor se determinar en funcin de otros que ya fueron definidos.

Caractersticas
Describe la estructura ele los objetos en un sistema (identidad, relaciones con otros objetos, atributos y operaciones). Marco en el que podemos ubicar los Modelos Dinmico y Funcional. Los objetos son las unidades en las que dividiremos el mundo y que sern las molculas de los distintos modelos. Se representa de forma grfica mediante diagramas de objetos que contendrn clases de objetos. Las clases se disponen en jerarquas que comparten estructura y comportamientos comunes, y que estn asociadas con otras clases.

Ejemplo de Modelo de Objetos

Modelo Dinmico
En el Modelo Dinmico se representan aspectos relacionados con las secuencias posibles de eventos (vidas posibles) y la interaccin entre objetos. Para representar estos aspectos, tenemos dos tipos de diagramas: Diagrama de Transicin de Estados (DTE)

Diagrama de Interaccin de Objetos (DIO)

Caractersticas
El Describe los aspectos del sistema que tienen que ver con el tiempo y la secuencia de las operaciones: Sucesos (eventos). Estados. Acciones. Captura el control del sistema. Se representa grficamente mediante diagrama de estados.

Diagramas de Transicin de Estados

Se utilizan para describir el comportamiento de los objetos estableciendo las vidas posibles. Una vida vlida de un objeto, es una secuencia de eventos que caracteriza un comportamiento correcto para todos los objetos de la clase. Las transiciones representan cambios de estado permitidos que pueden restringirse introduciendo condiciones. La especificacin de una transicin posee la sintaxis siguiente:

evento | accin | transaccin [if precondicin] [when condicin-de-control ]

Notacin de Elementos

Diagrama de Interaccin de Objetos

La interaccin entre objetos se modela grficamente mediante un Diagrama de Interaccin entre Objetos (DIO). En el DIO podemos especificar dos interacciones bsicas: Disparos: son servicios de una clase que se activan de forma automtica cuando se satisface una condicin en un objeto dicha clase.

Interacciones Globales: Son transacciones compuestas por servicios de clases diferentes.

Los disparos se definirn dibujando una flecha que vaya de la cabecera de una clase a la accin disparada y etiquetada con la condicin de disparo.
Las interacciones globales se introducen conectando los servicios que componen la interaccin y nominndola mediante un identificador de interaccin global comn (idIG). Ejemplo de DIO.

Modelo Funcional
El propsito del Modelo Funcional es capturar la semntica asociada a los cambios de estado de forma fcil e intuitiva. En este modelo especificaremos mediante un dilogo interactivo el efecto de un evento sobre los atributos. El valor de cada atributo se modificar dependiendo de la accin ocurrida, de los argumentos del evento y del estado actual del objeto.

Caractersticas
Describe los aspectos que tienen que ver con la transformacin de los valores:

Funciones.
Correspondencias. Restricciones. Dependencias funcionales. Captura lo que hace el sistema, sin preocuparse del como ni del cuando. Se representa mediante diagramas de flujo de datos.

El Mtodo Orientado a Objetos

Proporciona un modelo mediante el cual el analista slo tiene que categorizar cada atributo de entre un conjunto predefinido de tres categoras no disjuntas. Estas categoras determinan qu informacin se necesita para determinar cmo cambia el valor del atributo ante la ocurrencia de determinados eventos.
Las tres categoras de atributos son: Cardinales.

Independientes del estado.

De situacin.

Cardinales:
Sus eventos relevantes incrementan o decrementan su valor en una determinada cantidad.

Categora: cardinal Tipo Accin Incremento Decremento

Clase: coche Accin USR: alquilar(...) US R: devolver (...)

Atributo: cant-alquileres Efecto +1 pi Cond. Evaluacin

Independientes de estado:
tienen un valor que slo depende de la ltima accin ocurrida. Una vez ha ocurrido una accin relevante el nuevo valor del atributo es independiente del valor que tena antes.
Categora: estado Accin USR: devolver(..., lugar, ...) USR: cambiar_de_base(lugar) USR: reparar(...) Clase: coche Efecto = lugar = lugar = "taller:" taller" + "nombreAtributo: ubicacin Cond. Evaluacin

De situacin:
Mediante la activacin de una accin portadora se le asigna al atributo un valor de un dominio discreto.

Categora: situacin Accin USR: alquilar(...) USR: devolver(...)

Clase: cliente Efecto = "con-coche" = "sin-coche"

Atributo: status Cond. Evaluacin Status <> "con-coche" nro-coches >= 2

Relacin entre Modelos

Cada modelo describe un aspecto del sistema manteniendo referencias al resto de los modelos.

El Modelo de Objetos define las estructuras de datos sobre las que actuarn el Modelo Dinmico y el Modelo Funcional.
Los sucesos sern las operaciones de los objetos definidas en el Modelo de Objetos. Puede existir una eventual ambigedad acerca de qu modelo debe contener ciertos elementos de informacin. Puede ocurrir que ciertas propiedades del sistema no queden bien expresadas por ningn modelo, en cuyo caso el lenguaje natural ser la mejor alternativa.

Modelo de Ejecucin
Una vez especificado el sistema, un Modelo de Ejecucin establece: 1. Una representacin del modelo conceptual en un entorno de desarrollo, atendiendo aspectos estticos y dinmicos (estrategia de generacin de cdigo). 2. Una estrategia de ejecucin.

Estrategia de generacin de cdigo

Basado en tres niveles 1 Nivel de interfaz: En este nivel se sitan los componentes que implementan la interaccin con los usuarios finales, mostrando una representacin visual de los datos y los servicios que ofrecen los objetos del sistema. 2 Nivel de aplicacin: En este nivel se sitan los componentes que implementan de forma completa el comportamiento de las clases especificadas en la fase de modelado conceptual.

3 Nivel de persistencia: En este nivel se sitan los componentes que proporcionan los servicios necesarios para dar persistencia a los objetos del nivel de aplicacin. La persistencia de los objetos actualmente se realiza recurriendo a un sistema gestor de bases de datos relacional (SGBDR).

Estrategia de ejecucin
Para animar el sistema especificado, se define una estrategia de ejecucin e interaccin. Esta estrategia es cercana a las tcnicas de realidad virtual, en el sentido de que un objeto activo se introduce en la sociedad de objetos como miembro de ella e interacta con los dems enviando y recibiendo mensajes. Para iniciar una sesin de ejecucin, los pasos a seguir son:

1.Identificacin del usuario (control de acceso):

Consiste en la conexin del usuario al sistema. Una vez conectado se le proporciona una visin clara de la sociedad de objetos (ofrecindole qu clases de objetos puede ver, los servicios que puede activar y los atributos que puede consultar).

2.Activacin de servicios:
El usuario podr activar cualquier servicio (evento o transaccin) disponible en su visin de la sociedad. Adems, podr realizar observaciones del sistema (object queries).

Las clases que implementan las tareas de control de acceso y construccin de la vista del sistema (clases y servicios visibles) se implementarn en el nivel de interfaz. La informacin necesaria para configurar la vista del sistema est incluida en la especificacin del sistema (relaciones de agente) obtenida en la fase de modelado conceptual.

 Cualquier activacin de un servicio tiene dos partes: la construccin del mensaje y la ejecucin (s es posible).

1. Identificacin del objeto servidor:

Si el objeto existe el nivel de persistencia se encargar de recuperar el objeto senador de la base de datos y si es un evento de creacin reservar espacio para su almacenamiento.

2. Introducir los argumentos necesarios para la ejecucin del evento:

El nivel de interfaz preguntar por los argumentos del evento que va a activarse (s es necesario).

 Una vez el mensaje se ha enviado, se identifica el objeto servidor (la existencia del objeto servidor es una condicin implcita para ejecutar cualquier evento, excepto si se trata del evento creacin) y se procede a seguir una secuencia de acciones sobre dicho objeto:

1. Transicin vlida de estado:

Se verifica en el diagrama de transicin de estados que exista una transicin vlida (desde el estado actual a un nuevo estado) para el servicio seleccionado.

2. Satisfaccin de precondicin:
Se comprueba que se cumpla la precondicin asociada al servicio en ejecucin (s existe).

 Si no se cumplen 1 y 2 se elevar una excepcin informando que el servicio no puede ejecutarse.

3. Evaluaciones:
Se modifican los valores de los atributos afectados por la ocurrencia del servicio (como fuera especificado en el modelo funcional).

4. Comprobacin de las restricciones de integridad:

Las evaluaciones del servicio deben dejar al objeto en un estado vlido. Se comprueba que no se violan las restricciones de integridad (estticas y dinmicas). Si alguna de ellas se viola, se generar una excepcin y el cambio de estado producido se ignorar.

5. Comprobacin de las relaciones de disparo:

Despus de un cambio de estado vlido, y como accin final, se debe verificar el conjunto de reglas condicinaccin que representa la actividad interna del sistema. Si alguna de ellas se cumple, se activar el servicio correspondiente. Una vez finalizadas con xito las acciones precedentes, los componentes de la capa de persistencia se encargan de actualizar (UPDATE) la BDR correspondiente.

Lo Que Puede Llamarse Ciclo De Vida

Una metodologa de Ingeniera de Software es un proceso de produccin organizada de software, utilizando una coleccin predefinida de tcnicas y notaciones. Normalmente se presenta como una serie de fases o pasos: 1) Formulacin inicial del problema 2) Anlisis

3) Diseo
4) Implementacin 5) Pruebas 6) Mantenimiento

Anlisis
Escribir y obtener una descripcin inicial del problema (Definicin del Problema). Construir un Modelo de Objetos: Identificar las clases. Comenzar el diccionario de datos con la descripcin de las clases, sus atributos y operaciones. Aadir las asociaciones entre las clases. Aadir los atributos a las clases y a las asociaciones. Organizar y simplificar las clases utilizando la herencia. Verificar los caminos de acceso utilizando guiones e iterando los pasos anteriores. Agrupar las clases en mdulos, basados en el acoplamiento y funciones relacionadas.

 Modelo de Objetos = diagrama del Modelo de Objetos + Diccionario de Datos

Desarrollar un Modelo Dinmico:

Preparar guiones de las secuencias de interaccin ms frecuentes.

Identificar sucesos entre objetos y preparar una traza de sucesos por cada guion. Preparar un Diagrama de Flujo de Sucesos para el sistema completo. Desarrollar un Diagrama de Estados por cada clase que tenga un comportamiento dinmico significativo. Comprobar la consistencia y complexin de los sucesos compartidos entre los diagramas de estado.

 Modelo Dinmico = Diagramas de Estado + Diagrama de Flujo de Sucesos Global Construir un Modelo Funcional: Identificar valores de entrada y salida. Utilizar diagramas de Flujo de Datos para mostrar las dependencias funcionales. Describir lo que hace cada funcin. Identificar las restricciones. Especificar los criterios de optimizacin.

 Modelo Funcional = diagramas de Flujo de Datos + Restricciones.

Verificar, iterar y refinar los tres modelos:

Aadir operaciones clave descubiertas en la preparacin del Modelo Funcional. Verificar las clases, atributos, operaciones y asociaciones son consistentes y completas al nivel de abstraccin elegido. Desarrollar guiones ms detallados (Qu pasara- s). Iterar los pasos anteriores, segn sea, necesario para completar el anlisis. Documento del Anlisis = Definicin del Problema + Modelo de Objetos + Modelo Dinmico + Modelo Funcional.