Click here to load reader
Upload
juan-raul-vergara
View
7.206
Download
2
Embed Size (px)
DESCRIPTION
Solo Septimo semestre.
Citation preview
DISEÑO ORIENTADO A OBJETOS
El diseño orientado a objetos (DOO) transforma el modelo el
modelo de análisis creado usando el análisis orientado a
objetos, en un modelo de diseño que sirve como anteproyecto
para la construcción del software.
El DOO constituye un tipo de diseño que logra un cierto
numero de diferentes niveles de modularidad. Los
componentes principales del sistema están organizado en
módulos denominados subsistemas.
La naturaleza única del DOO descansa en su capacidad de
apoyarse en cuatro conceptos importantes del diseño del
software: Abstracción, ocultamiento de la información,
independencia funcional y modularidad.
El diseño orientado a objetos es duro, siendo un poco mas difícil
que los diseños estructurales, a un para aquellas personas que
llevan algo de tiempo aplicando este diseño.
DISEÑO DE SISTEMAS ORIENTADOA OBJETOS.
Se han definido cuatro capas de diseño:Datos,arquitectura, interfaz,
y procedimental, para los sistemas orientados a objetos también
podemos definir un sistema en pirámide, pero las capas son un
poco distintas:
La capa del subsistema: Contiene una representación de cada uno
de los subsistemas que permite al software conseguir que los
requerimientos definidos por el cliente e implementar la
arquitectura técnica que los soporta.
La capa de clases y objetos: Contiene las jerarquía de las clases
que permiten crear el sistema, también contiene representaciones
de cada uno de los objetos.
La capa de mensajes:Contiene los detalles que permiten a cada
objeto comunicarse con sus colaboradores. En esta capa establece
las interfaces internas y externas del sistema.
La capa de responsabilidades:Contiene las estructuras de datos y el
diseño algorítmico para los atributos y operaciones de cada objeto.
Diseño de subsistemas
Diseño de clases y objetos
Diseño de Mensajes
Responsabilidades
del Diseño
El de diseño se centra exclusivamente en el deseño de un producto o
sistema especifico.
El enfoque convencional y el enfoque OO
Los enfoques convencionales para el diseño aplican anotaciones y un
conjunto de normas heurísticas para establecer para establecer
correspondencia entre el modelo de análisis y el diseño.
El DOO aplica el diseño de datos(cuando se representan atributos),
diseño arquitectónico( cuando se desarrolla un modelo de intercambio
de mensajes), y el diseño procedimental(en el diseño de operaciones).
A diferencia de los diseños convencionales el diseño orientado a
objetos no exhibe una estructura de control jerárquica. De hecho la
arquitectura del DOO tiene mas que ver con la colaboraciones entre
objetos que con flujo de control.
Enfoque convencional vs Enfoque OO
Al igual que el diseño de software convencional, el DOO aplica
diseño de datos (cuando se representan atributos), diseño de
interfaces (cuando se presenta el intercambio de mensajes) y
diseño procedimental (en el diseño de operaciones), no obstante
el diseño arquitectónico es diferente.
La arquitectura de diseño OO se centra más en las
colaboraciones entre los objetos que con el flujo de control de
datos. De esta manera las capas de la pirámide se renombran
para reflejar de forma más exacta la naturaleza del DOO. La
siguiente figura muestra ahora la correspondencia entre el AOO
con las correspondientes capas de la
pirámide de diseño OO.
Transformación del modelo de análisis en Método de
diseño OO
El diseño del subsistema se deriva considerando requisitos
generales del cliente (representados en casos de uso).
Componentes que pueden usarse para comparar diversos métodos
de diseño:
1.Representación de jerarquías de modulo.
2.Especificación de definiciones de datos
3. Especificación de la lógica procedimental
4.Indicación de secuencias de proceso
5.Representaciones de estado de objetos y transacciones
6.Definición de clases y jerarquías
7.Asignación de operaciones a clase
8.Definición detallada de la operaciones.
9.especificación de conexiones de mensajes.
10.Identificación de servicios exclusivos.
Como existen muchos enfoques es difícil realizar una
comparación generalizada entre dos métodos.
Asuntos del diseño.
Bertrand Meyer sugiere 5 criterios para juzgar la capacidad que
posee un método de diseño en lograr la modularidad y los
relaciona con el modelo orientado a objeto:
Descomponibilidad: La facilidad con la cual un método de diseño
ayuda al diseñador para descomponer un gran problema en
subproblemas.
Componibilidad: El grado con el cual el método de diseño
asegura que los componentes del programa una vez diseñados y
construidos puedan usarse para crear otro sistema
Comprensibilidad: Facilidad de comprensión de un componente
Sin referencia a otro información o modulo
Continuidad: la facilidad de hacer pequeños cambios en un
programa y hacer que estos se manifiesten por si mismos en
cambios correspondiente en un modulo o en unos pocos.
Protección: Una característica arquitectónica que reducirá la
propagación de efectos colaterales si ocurre un error en un
modulo dado
COMPONENTES GENERICOS DEL MODELO DE DISEÑO OO
A veces resulta difícil hacer una distinción clara entre análisis
OO y diseño OO. En esencia el análisis OO es una actividad
de clasificación, se analiza un problema en un esfuerzo por
determinar las clases de objetos que serán aplicables al
desarrollarse la solución.
El análisis determina también las relaciones y el comportamiento
del objeto.
El diseño OO le posibilita al Ing. De software la posibilidad de
indicar los objetos que se derivan de cada clase y como estos
objetos se relacionan con otros.
Ilustra como se desarrollan las relaciones entre objetos, como se
debe implementar el comportamiento y como implementar la
comunicación entre objetos.
Despues de realizado el proceso de analisis completo el ing. De
software se concentra en el diseño del sistema, esto se realiza a
traves de la descripción de subsistemas necesarios para
implementar los requerimientos del cliente.
Flujo de proceso del DOO
Diseño
De Objetos
Análisis
Diseño del
Sistema
Durante el diseño de subsistemas, es necesario para el ing. De
software definir cuatro componentes de diseño
Dominio del problema:Son los subsistemas responsables de
la implementación de los requisitos del cliente directamente.
Interacción humana: Los subsistema,que implementan la
interfaz de usuario(esto incluye Subsistemas responsables de
interfaz grafica de usuario)
Gestión de tareas: Los subsistemas responsables del control
y coordinación de tareas concurrentes que pueden
empaquetarse dentro de uno o varios subsistemas.
Gestión de datos: El subsistema que es responsable del
almacenamiento y recuperación de objetos.
EL PROCESO DE DISEÑO DEL SISTEMA
Aun que un numero considerables de autores sugieren modelos
de proceso para el diseño de sistemas OO, la secuencia de
actividades propuesta por Rumbaugh y sus colegas es uno de
los temas mas definitivos.
Dividir el modelo de análisis en subsistemas
Identificar la concurrencia dictada por el problema
Asignar subsistemas a procesadores y tareas
Elegir una estrategia básica para la implementación de la
gestión de datos.
Identificar los recursos globales y mecanismos de control
necesarios para acceder a ellos
Diseñar un mecanismo de control apropiado para el sistema
Considerar como manipular las condiciones limites
Revisar y considerar los intercambios.
Clases
Atributos
Métodos
Relaciones
Comportamiento
Objetos
Estructuras de datos
Algoritmos
Mensajes
Control
Conversiones del modelo de análisis en el modelo de diseño
durante el modelo de objetos.
EL PROCESO DE DISEÑO DE OBJETOS
Para seguir con la metáfora el diseño del sistema OO puede verse
como el plano arquitectónico de una casa. Ese plano especifica
los propósitos de cada aplicación y mecanismos que comunican
las habitaciones unas con otras y con el entorno exterior.
El diseño de objetos se centra en las habitaciones, debemos
desarrollar un diseño detallados de atributos y operaciones.
Descripción de objeto
Una descripción del protocolo que establece interfaz de un objeto
definido cada mensaje que el objeto puede recibir y la
correspondiente operación.
Una descripción de la implementación que muestra detalles
de ella para cada operación implicada por un mensaje que se
pasa al objeto.