Repú blica Bolivariana de Venezuela
Ministerio del Poder Popular para la Defensa
Universidad Nacional Experimental Politécnica
De la Fuerza Armada Nacional Bolivariana
Carrera: TSU Aná lisis y Diseñ o de Sistemas
UNIDAD
3:
DISEÑO
ORIENT
ADO A
OBJETOS
Profesor: Bachiller:
Víctor Velá squez Dairelys Martínez C.I:28384910
3.1 Fundamentos del diseño orientado a objetos:
Diseño del componente de dominio problema.
El componente del dominio del problema (PDC) es el conjunto bá sico de objetos funcionales
que llega de la etapa de aná lisis. Tales objetos directamente resuelven el problema que se
pretende ser resuelto por el sistema que se está construyendo, lo que quiere decir que el
diseñ o del PDC se termina en su mayor parte en la etapa de aná lisis, completá ndose ahora
con la ejecució n de tres actividades, las cuales son:
1. Diseño de reúso: Se pueden añ adir en esta etapa nuevas clases para reusar objetos que
será n ú tiles má s adelante. Es el caso de los paquetes comerciales de clase generalizada
como las que contienen las organizaciones de programadores OO con experiencia, ellos
por lo general poseen una biblioteca de clases desarrollada para los objetos. Estas
bibliotecas y paquetes pueden contener clases que tienen atributos y servicios para
objetos similares a los requeridos en el diseñ o del sistema a desarrollarse. Estas clases
reusables pueden ser añ adidas al diseñ o como clases bases en una estructura Gen-Spec.
2. Estructura de Implementación: Debido a la implementació n en un lenguaje de
programació n en particular podría ser necesario que en el diseñ o se agreguen
estructuras que pueden ser de agregació n, o Gen-Spec, este ú ltimo para permitir que
varias clases de objetos compartan un protocolo o estructura de datos. Estas estructuras
usan el concepto de herencia para hacer má s fá cil el enfoque de programació n.
3. Acomodo al lenguaje: En esta secció n podemos corregir (si es necesario) el diseñ o
para que las estructuras puedan ser construidas en el lenguaje de programació n
seleccionado, debido a que estos lenguajes pueden tener diferentes patrones de
herencia. Algunos lenguajes, por ejemplo, incluyen herencia mú ltiple (C++), otros
solamente incluyen herencia simple (Java) y todavía otros que posiblemente no incluyen
herencia. En los casos má s restrictivos, los patrones de herencia del diseñ o deben ser
modificados para permitir las capacidades del lenguaje de programació n.
En la imagen anterior se observa que el objeto Tren hereda de Listas y Celdas (clases
propias de la biblioteca de C++), pero al no tener C++ forma de manejar dos estructuras
Gen-Spec con Listas se tuvo que crear una segundo estructura llamada ListaCarrros y
conectarlos uno a uno con el objeto Tren.
Diseño del componente de interfaz humana.
En esta actividad creamos los menú s, reportes y pantallas interactivas que usará n las
personas para trabajar con el sistema. Por lo general, se puede obtener ayuda en gran forma
en clases de bibliotecas para el diseñ o de clases de Interfaz. Esta es un á rea donde la
reusabilidad de las clases Orientado a Objetos es muy efectiva. Las clases de bibliotecas
generalmente proporcionan generalizaciones de menú s, ventanas, control de tipo de letra, y
utilerías de cortar y pegar.
Los prototipos son muy ú tiles durante el diseñ o de Interfaz para hacer má s fá cil la manera
en que trabajará n las clases de biblioteca con los objetos del dominio.
Por lo general, con la informació n obtenida en las entrevistas y casos de uso podemos
recopilar informació n acerca de los perfiles de usuarios involucrados en el sistema y
diseñ ar una interfaz correspondiente a su perfil. Con base a estos y otros perfiles, podemos
seleccionar una interfaz Diseñ o de componentes de administració n de tarea y datos. Ambos
componentes está n estrechamente relacionados con la tecnología de implementació n. El
manejo de tareas está muy determinado por la configuració n de hardware de computació n,
y el manejo de datos está muy determinado por el software de sistema disponible cuando el
sistema este de hecho en ejecució n.
Diseño de los componentes de administración de tarea y datos.
El componente de manejo de tareas es má s importante cuando el sistema está ejecutá ndose
en varios procesadores o computadoras. Una “tarea” es un conjunto de servicios
relacionados que deben ejecutarse juntos. Las tareas son activadas por el tiempo
transcurrido o por un evento. Los objetos del manejo de tarea obedecen a activadores de
tareas, asignació n de procesadores y prioridades cuando son llamados los servicios.
Un ejemplo de componente de tareas es como se muestra a continuació n, en él, el tema del
componente de manejo de tareas se añ ade al paquete de diagrama de capas existente. Este
componente es implementado luego creando objetos Tarea conforme son necesarios por el
sistema.
El componente de Manejo de Datos comprende, por lo general, clases y objetos necesarios
para almacenar y recuperar a los otros objetos del sistema.
El Componente Manejo de Datos varía considerablemente dependiendo de si la tecnología
de tiempo de ejecució n subyacente es una base de datos orientada a objetos, una base de
datos relacional o un sistema de archivos “plano” ordinario. En un ambiente de Base de
Datos relacional o de archivo plano el componente de manejo de datos debe proporcionar
servicios de almacenamiento al sistema.
Hay tres formas diferentes para diseñ ar el Diagrama de Manejo de Datos:
Construir servicios de almacenamiento en cada Clase y Objetos en el diseño: Esto
involucra, por lo general, una cantidad considerable de programació n de diseñ o
adicional.
Crear una Clase y Objeto, Servidor Objeto, que proporcione todos los servicios de
Base de Datos: Involucra un complejo objeto que sepa có mo guardar o recuperar todos
los objetos del sistema. Cualquier petició n de almacenamiento se hace por medio de
mensajes a este ú nico objeto cuyo diseñ o podría ser como el que se muestra a
continuació n.
Crear una clase Almacenable: Es una combinació n de los dos enfoques anteriores.
Cada objeto del sistema que deba ser guardado o recuperado es conectado luego a una
estructura Gen-Spec con la clase almacenable. La figura a continuació n es un ejemplo de
ésta.
Enfoques alternativos y notación para su implantación.
El diseñ o orientado a los objetos (DOO) permite al ingeniero de software indicar los objetos
que se derivan de cada clase de las interrelaciones entre ellos. Ademá s, el DOO debe
proporcionar una notació n que refleje las relaciones entre los objetos. También se pueden
aplicar de igual forma la terminología, la notació n y el enfoque usados en el AOO.
Los primeros intentos de escribir con método de diseñ o orientado a los objetos no
surgieron hasta principios de la década de los ochenta. Tanto Abbott [ABB83] como Booch
[BOO86A] establecen que el DOO debe comenzar con una descripció n en el lenguaje natural
de la estrategia de solució n mediante una realizació n en software, de un problema del
mundo real. A partir de esa descripció n, el diseñ ador puede identificar los objetos y las
operaciones. Posteriores contribuciones de Schlaer y Mellor [SCL88] y de Coad y Yourdon
[COA90] introdujeron una notació n má s amplia para asistir a esa actividad y argumentaron
que se trataba realmente de una actividad de aná lisis.
Usamos una notació n grá fica para representar los objetos, las operaciones, los mensajes y
otras estructuras propuestas por Coad y Yourdon [COA90]. Esta notació n también para las
primeras etapas del diseñ o. Sin embargo, también se han propuesto otras notaciones que a
menudo se encuentran en el cambio industrial.
A continuació n se explican algunos de estas:
Enfoque Shlaer-Mellor:
Uno de los primeros ejemplos del aná lisis orientado a objetos se debió a Shlaer y Mellor.
Apareció en 1988. El método Shlaer-Mellor está basado en un conjunto integrado de
modelos que pueden ser ejecutados para verificació n, y en un enfoque innovador de diseñ o
que produce un diseñ o de sistema a través de la traducció n delos modelos de aná lisis. El
método está construido sobre un conjunto de reglas bien definidas para la construcció n de
los diagramas y la traducció n de dichos diagramas del aná lisis al diseñ o y finalmente a la
implementació n. La metodología de Shlaer-Mellor inicia con un modelo de informació n que
describen los objetos, los atributos, y las relaciones. (Note que esto es má s bien un modelo
de datos que un modelo de objetos.) Después, un modelo de estados documenta los estados
de los objetos y las transiciones entre ellos. Finalmente, un diagrama de flujo de datos
muestra el modelo de proceso.
La siguiente figura muestra un ejemplo de la notació n de la metodología de Shlaer-Mellor
para representar la herencia.
Enfoque de Embley:
Conjunto de métodos empleados para el desarrollo de sistemas automatizados.
Embley y Kurtz 1990.
Un objeto es una persona, un lugar, o una cosa. Un objeto puede ser físico o conceptual. La
idea es que un objeto es una sola entidad o noció n. Cada objeto es un individuo ú nico. Un
objeto se puede relacionar con o componer de otros objetos, pero cada objeto es ú nico.
Clase (Metodología Embley)
Identificació n de conjunto de objetos que pertenecen juntos por una cierta razó n ló gica
llamada clasificació n. En OSA, un sistema de objetos que pertenecen juntos por una cierta
razó n ló gica se le llama clase del objeto. El modelo de la Objeto-Relació n ínsita a los
analistas a que organicen objetos en clases del objeto. Cada clase del objeto tiene un
nombre genérico y denota a cualquier miembro de la clase del objeto. Así, en un ORM, una
clase del objeto con nombre X señ ala una clasificació n de los objetos cada uno de los cuales
se considera ser un X. Como cada objeto en clase del objeto X es un X, los objetos en la clase
son semejantes, por lo menos en un cierto sentido.
Enfoque de Rumbaugh.
La técnica de modelado de objetos (TMO) [RUM91] engloba una actividad de diseñ o que
alienta al diseñ o a ser conducido a dos diferentes niveles de abstracció n. El diseñ o de
sistema se centra en el esquema de los componentes que se necesitan para construir un
sistema o producto completo. El modelo de aná lisis se divide en subsistemas, los cuales se
asignan a procesadores y tareas. Se define una estrategia para implementar la
administració n de datos, y se identifican los recursos y mecanismos de control requeridos
para accesarlos. El diseñ o de objetos enfatiza el esquema detallado de un objeto individual.
Se seleccionan las operaciones del modelo de aná lisis, y los algoritmos se definen para cada
operació n. Se representan las estructuras de datos apropiadas para atributos y algoritmos.
Las clases y atributos de clase son diseñ ados de manera que se optimice el acceso a los
datos, y se mejore la eficiencia computacional. Se crea un modelo de mensajería, para
implementar relaciones de objetos (asociaciones).
3.2. Pruebas Orientadas a Objetos:
Modelos de pruebas en Orientación a Objetos.
El objetivo general de las pruebas orientadas a objetos es encontrar el nú mero de errores
má ximo con el mínimo de esfuerzo; es el mismo objetivo de las pruebas del software
convencional. Pero las estrategias y tá ctica para la pruebas OO difieren significativamente.
La visió n de la prueba se amplía hasta incluir los modelos de aná lisis y diseñ o
Como dichos modelos está n semá nticamente enlazados las pruebas comienzan durante
estas actividades de ingeniería (aná lisis- diseñ o).
Una vez realizada la programació n Orientada a objeto, la prueba de la unidad se aplica a
cada clase. Estas pruebas de clases usan una variedad de métodos: pruebas basadas en
errores, pruebas aleatorias y de partició n. Cada uno de estos métodos ejercita las
operaciones encapsuladas por la clase. Se diseñ an secuencias de pruebas para asegurar que
se ejerciten operaciones relevantes. El estado de una clase, representado por valores de sus
atributos, se examina para determinar si existen errores.
Las pruebas de integració n pueden realizarse usando estrategias basadas en hilos o basadas
en el uso. Las pruebas basadas en hilos integran el conjunto de clases que colaboran para
dar respuesta a una entrada o evento. Las pruebas basadas en uso construye el sistema por
capas, comenzando con aquellas que no hacen uso de las clases servidores.
Los métodos de diseñ o de pruebas de integració n pueden también hacer uso de pruebas
aleatorias y de partició n.
La validació n de los sistemas OO posee una orientació n de caja negra y pueden realizarse a
través de la aplicació n de los mismos métodos de caja negra para el software convencional.
Sin embargo, la prueba de basada en escenarios domina la validació n de sistemas OO,
haciendo de los casos de uso del principal controlador para las pruebas de validació n.
