diseno orientado a objetos
TRANSCRIPT
Diseño Orientado a Objetos
TEMA
Universidad Agraria del EcuadorEscuela de Computacion e Informatica
GRUPO : 9
CAMPOZANO ALVARADO CARLOS CEPEDA ANDRADE ERICK SANCHEZ ROMERO VICTOR
Diseño Orientado a Objetos
El diseño de software Orientado a objetos requiere la definición de una arquitectura de software multicapa, la especificación de subsistemas que realizan funciones necesarias y proven soporte de infraestructura,
¿Qué es el diseño orientado a objetos?
Un sistema orientado a objetos utiliza las definiciones de las clases derivadas del modelo de análisis.El DO0 permite al ingeniero de software definir la arquitectura OO(orientada a objetos),en forma que maximize la reutilización; de esta manera, semejora la velocidad del desarrollo y lacalidad del producto terminado.
¿Por qué es importante?
¿Cuáles son los pasos?El DOO se divide en dos grandes actividades: diseño de sistema y diseño de objetos. El diseño de sistema crea la arquitectura del producto en una serie de capas, que cumplen funciones específicas del sistema.El diseño de objetos se centra en los detalles internos de cada clase, definición de atributos.
NOTA: conceptos importantes del diseño del software:-Abstracción -Ocultamiento de la información, -independencia -Funcional y modularidad.
Diseño para sistemas orientados a objetos
La capa de mensajes.- Contiene detalles de diseño,que permite a cada objeto comunicarse con sus colaboradores.Esta capa establece interfaces externas e internaspara el sistema.
La capa de responsabilidades. Contiene estructuras de datos y diseños algorítmicos, para todos los atributos y operaciones de cada objeto.
La capa subsistema. Contiene una representaciónde cada uno de los subsistemas, para permitir al software conseguir sus requisitos definidos por el cliente
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.
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).
El enfoque convencional
VS
El enfoque OO
Es importante notar que la arquitectura de un diseño O0 tiene más que vercon la colaboración entre objetos que con el control deflujo entre componentes del sistema.
Enfoque convencional vs Enfoque OO
El modelo de diseño
Transformación de un modelo de
análisis O0 a un modelo de diseño OO.
A
B
c
D
A
CB
D
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:
DescomponibilidadLa facilidad con la cual un método de diseño ayuda al
diseñador para descomponer un gran problema en
subproblemas.
Comprensibilidad: Facilidad de comprensión de un
componenteSin 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
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
Los módulos Se definen como unidades lingüísticas modulares, cuando «corresponden a unidades sintácticas en el lenguaje usado» [MEY90]. Es decir, el lenguaje de programación que se usará debe ser capaz de definir directamente la modularidad.
El Panorama de DO0En el panorama de DOO encontramos una gran variedad, de métodosde análisis y diseño orientados a objetos fue propuesta y utilizada durante los ochenta y los noventa. A continuación, haremos una breve revisión global de los primeros métodos de DOO:
El método de Booch.[B0094]
Abarca un «proceso de micro desarrollo» y un <<proceso de macro desarrollo». En el contexto del diseño, el macro desarrollo engloba una actividad de planificación arquitectónica, que agrupa objetos similares en particiones arquitectónicas separadas.
El método de Rumbaugh.[RUM91]
Engloba una actividad de diseño que alienta al diseño a ser conducido a dos diferentes niveles de abstracción.El modelo de análisis se divide en subsistemas, los cuales se asignan a procesadores y tareas.
El método de Jacobson.[JAC92]
El diseño para ISOO (Ingeniería del software orientada a objetos) [JAC92]es una versión simplificada del método propietario, El modelo de diseño enfatiza la planificación para el modelo de análisis ISOO. En principio, el modelo idealizado de análisis se adapta para acoplarse al ambiente del mundo real.
El método de Coad y Yourdon.
Éste método para DO0 [COA91], se desarrolló estudiando «cómo es que los diseñadores orientados a objetos efectivos» hacen su trabajo.La aproximación de diseño dirige no sólo la aplicación, sino también la infraestructura de la aplicación.
El método de Wirfs-Brock.
Wirfs-Brock, Wilkerson y Weiner [WIR90] definen un conjunto de tareas técnicas, en la cual el análisis conduce sin duda al diseño. Los protocolos para cada clase se construyen refinando contratos entre objetos.
Etapas genéricas del DOO1. Describir cada subsistema y asignar a procesadores y
tareas.2. Elegir una estrategia para implementar la
administración de datos, soporte de interfaz y administración de tareas.
3. Diseñar un mecanismo de control, para el sistema apropiado.
4. Diseñar objetos creando una representación procedural para cada operación, y estructuras de datos para los atributos de clase.
5. Diseñar mensajes, usando la colaboración entre objetos y relaciones.
6. Crear el modelo de mensajería. 7. Revisar el modelo de diseño y renovarlo cada vez que
se requiera.
NOTA : El diseño de sistema se centra en arquitecturade software y definición de subsistemas.
El diseño de objetos describe objetos, hasta un nivel en el cual puedan ser implementados,
en un lenguaje de programación.
Enfoque unificado para el DOODISEÑO DE SISTEMA DISEÑO DE OBJETO
Se centra en la arquitectura del software y definición de subsistemas.
Describe objetos, hasta un nivel en el cual puedan ser implementados en un lenguaje de programación.
1. Se extiende para considerar el diseño de interfaces, administración de datos con el sistema que se va a construir y administración de tareas para los subsistemas que se han especificado.
1. Se centra en la descripción de objetos y sus interacciones con los otros.
2. Una especificación detallada de las estructuras de datos de los atributos y diseño procedural de todas las operaciones, se crea durante el diseño de objetos.
3. La visibilidad para los atributos de la clase se definen, y las interfaces entre objetos se elaboran para definir los detalles de un modelo completo de mensajes
Flujo de proceso para DOO
Diseño del sistema
Diseño de objetos
Diseño de la interfaz humana
Diseño de la gestión de datos
Diseño de la gestión de tareas
Análisis orientado a objetos
Fases del proceso de diseño de sistema
Comunicación entre subsistemas
Componente de gestión de recursos
Componente de administración de datos
Componente de interfaz de usuario
Componente de administración de tareas
Asignación de concurrencia y subsistemas
Particionar el modelo de análisis
Particionar el modelo de análisis
Criterios a tener en cuenta al momento de definir y diseñar los subsistemas
1.El subsistema debe tener una interfaz bien definida, a través de la cual se reduzcan todas las comunicaciones con el resto del sistema.
2.Con la excepción de un numero pequeño de “clases de comunicaciones”, las clases incluidas dentro del subsistema deben colaborar solo con otras áreas dentro del subsistema.
3.El número de subsistemas debe ser bajo
4.Un subsistema puede ser particionado internamente para ayudar a reducir la complejidad.
Enfoque de diseño para estratificación por capas
1.Establecer los criterios de estratificación por capas.
2.Determinar el número de capas.
3.Nombrar las capas y asignar susbsistemas a las capas.
4.Diseñar interfaces para cada capa
5.Refinar los subsistemas, para establecer la estructura de clases de cada capa
6.Definir el modelo de mensajería para la comunicación entre capas.
7.Revisar el diseño de capas, para asegurar que el acoplamiento sea mínimo.
8. Iterar para refinar el diseño de capas.
Asignación de concurrencia y subsistemas
1. El sistema dinámico del modelo objeto-comportamiento provee una indicación de concurrencia entre clases o subsistemas.
2. Si las clases deben actuar en sucesos asincronicamemte y al mismo tiempo, se verán como concurrentes.
3. Cuando los subsistemas son concurrentes, existen dos tipos de alojamiento:
• Alojar cada subsistema en procesadores independientes
• Alojar los subsistemas en el mismo procesador y proporcionar soporte de concurrencia, sobre las características del sistema operativo.
Componente de administración de tareas
Estrategias para el diseño de objetos que manipulan tareas concurrentes.
1.Se determinan las características de la tarea
2.Se define un coordinador de tarea y objetos asociados.
3.Se integra el coordinador y otras tareas
Plantilla básica de una tarea
1. Nombre de la tarea
2. Descripción
3. Prioridad
4. Servicios
5. Coordinado por...
6. Comunicados por ...
Componente de interfaz de usuario
1. Las mayoría de las clases necesarias para crear una interfaz moderada ya existen y están disponibles, para el diseñador.
2. Una vez que el actor y su situación de uso se definen se identifica una jerarquía de comando.
3. La jerarquía de ordenes define la mayoría de las categorías del menú de sistema (barra de menús o la paleta de herramientas), y todas las sub-funciones, que estarán disponibles en el contexto de una categoría importante de menú de sistema (ventanas de menú)
Componente de administración de datos
La administración o gestión de datos engloba dos áreas distintas de interés:
1. La administración de datos críticos para la propia aplicación
2. La creación de infraestructura para el almacenamiento y recuperación de objetos.
En general, la administración de datos se diseña en forma de capas. La idea es aislar los
requisitos de bajo nivel que manipulan las estructuras de datos, de los requisitos de alto nivel para manejar los atributos del sistema.
Componente de gestión de recursos
1. Están disponibles una variedad de recursos diferentes para un sistema o producto OO; y, muchas veces, los subsistemas compiten por estos recursos al mismo tiempo.
2. Los recursos globales del sistema pueden ser entidades externas (unidad de disco, procesador) o abstracciones (base de datos,un objeto).
3. Sin importar la naturaleza del recurso, el ingeniero de software debe diseñar un mecanismo de control para ello.
Rumbaugh sugiere que cada recurso deba ser poseído por un “objeto guardián”, quien controlara el acceso al recurso.
Comunicación entre subsistemas
Una vez que cada subsistema ha sido especificado, es necesario definir las colaboraciones que existen entre subsistemas.
• Listar cada petición que puede ser realizada por los colaboradores del subsistema.
• Para cada contrato, anotar las especificaciones (heredadas y privadas) que se requieren para implementar las responsabilidades que implica el contrato.
• Considerar un contrato a la vez, que incluya: Tipo de contrato (cliente – servidor , Peer to Peer)
Colaboradores (nombres de los subsistemas que son parte del contrato)
Clase (nombres de clases que proporcionan servicios denotados por el contrato)
Operaciones (nombre de operaciones que implementan los servicios)
Formato del mensaje (requerido para implementar la interacción entre colaboradores)
Descripción de objetos
Una descripción del diseño de un objeto (instancia de clase) puede tomar una o dos formas:
1. Una descripción de protocolo que establece a interfaz de un objeto, definiendo cada mensaje que el objeto puede recibir y las operaciones que lleva a cabo cuando recibe un mensaje.
2. Una descripción de implementación que muestra detalles de implementación para cada operación implicada por un mensaje pasado a un objeto.
La descripción del protocolo no es nada mas que un conjunto de mensajes y un comentario correspondiente para cada mensaje.
Diseño de algoritmos y estructura de datos
Una variedad de representaciones contenidas en el modelo de análisis y el diseño del sistema, proveen una especificación para todas las operaciones y atributos.
1. Se crea un algoritmo para implementar la especificación para cada operación. En muchas ocasiones el algoritmo es una simple secuencia computacional o procedural, que puede ser implementada como un modulo de software.
2. Las estructuras de datos se diseñan al mismo tiempo que los algoritmos. Ya que las operaciones manipulan los atributos de una clase, el diseño de estructuras de datos, que reflejan mejor los atributos, tendrán un fuerte sentido en el diseño algorítmico de las operaciones correspondientes.
Modelado de clases
No se muestran todos los atributos y operaciones
No se muestran todos los atributos y operaciones
Nombre
Dirección
Estado
ObtenerCuentas():ConjuntoDeCuentas
EstablecerNombre(cadena Nombre)
ObtenerNombre():Cadena
Cliente
Generalización
No se muestran todos los atributos y operaciones
No se muestran todos los atributos y operaciones
Deposito
Cuenta
CuentaCorriente
Producto ManufacturadoEl diamante vació representa agregación
El diamante vació representa agregación
Componente
Agregación
Producto Manufacturado
Componente
ComponenteB ComponenteCComponenteA
Generalización y Agregación
Cliente
ColecionCuentas
Composición
Universidad
Estudiante
Documentando roles
1
1..*
Hospedar
estudiante miembro
Asociación
Administrador
Iniciar proyecto
Emitir informe de estado
Seleccionar plantilla
Terminar proyecto
Casos de uso
Casos de uso utilizando otro caso de uso
Validar producto
Consultar producto
Consultar nivel de stock
Consultar detalles de orden
“uses”
“uses”
“uses”
Colaboraciones
ViejoCliente:
ClienteBanco
Administrador:Empleado
Administrador:Empleado Informe ventasInforme ventas Transacción ventasTransacción ventas
Actualizar informe
Crear transacción
Cambiar detalles
Un diagrama de secuencias sencillo
Colaboraciones
ViejoCliente:
ClienteBanco
CuentaCuentaInforme balanceInforme balance
GenerarInformeBalance
Otro ejemplo de diagrama de secuencias
Comprobar CuentaValida
Consultar cuenta
Apreciación Global• El DOO se divide en dos grandes actividades:
Diseño del sistema
Diseño de objetos.
• El diseño de sistema crea la arquitectura del producto definiendo una serie de “capas”, que cumplen funciones especificas del sistema e identifica las clases que son encapsuladas por los subsistemas que residen en cada capa. Además incorpora la especificación de tres componentes:
La interfaz de usuario
La gestión de datos
Mecanismos de administración de tareas
• El diseño de objetos se centra en los detalles internos de cada clase, definición de atributos, operaciones y detalles de los mensajes.
GRACIAS POR SU ATENCION