Embed Size (px)
Citation preview
Ingeniería de software
Unidad II
Ingeniería de Software Orientado a Objetos
Diseño Orientado a Objetos
Tema
Semana 8
Objetivos Generales:
Comprender correcta y eficientemente los conceptos y principios del espectro de técnicas de Ingeniería de Software que puedan ser aplicadas en proyectos de software.
Desarrollar una cultura de ingeniería de software.
Objetivos Específicos:
Aplicar correctamente los conceptos y principios relacionados a la Ingeniería de Software en la resolución de casos prácticos para la gestión de proyectos de software de calidad.
Utilizar herramientas para el modelado y gestión de proyectos de software.
Utilizar metodologías agiles en el desarrollo de software.
Objetivos Instruccionales:
Comprender los conceptos relacionados al diseño orientado a objetos
Establecer la interrelación entre los objetos en el proceso orientado a objetos
Capas de la pirámide del diseño OO
Diseño de subsistemas
Diseño de clases y objetos
Diseño de mensajes
Diseño de responsabilidades
contiene las representaciones de cada uno de los subsistemas y la infraestructura necesaria que permiten al software lograr los requisitos del cliente
contiene la jerarquía de la clase incluso las representaciones de
cada objeto
establece las interfaces internas y externas para el sistema, incluso los detalles de comunicación entre los colaboradores del objeto
contiene los datos estructurados en detalle y el detalle algorítmico para
los atributos de cada objeto y funcionamientos
Dis
eño
para
Sis
tem
as O
O
Relación entre el análisis y diseño OO
Transformación de un modelo de análisis OO a un modelo de diseño OO
Diseño de subsistemas
Diseño de clases y objetos
Diseño de mensajes
Diseño de responsabilidad
es
Modelo de diseño
Casos deusoM
odel
o de
tarje
tas
CR
CModelo de
objeto-relaciones
Modelo deComportamiento de
objetos
Modelo de análisis
Atr
ibut
os,
operaciones Colaboraciones
Dis
eño
para
Sis
tem
as O
O
Enfoque Convencional vs. OO
Fichman y Kemerev sugieren diez componentes de diseño modelado para comparar métodos convencionales y orientados a objetos.
1. Representación de la jerarquía de módulos
2. Especificación de las definiciones de datos
3. Especificación de la lógica procedimental
4. Indicación de secuencias de proceso final-a-final (end-to-end)
5. Representación de estados y transición de los objetos
6. Definición de clases y jerarquías
7. Asignación de operaciones a las clases
8. Definición detallada de operaciones
9. Especificación de conexiones de mensajes
10. Identificación de servicios exclusivos
Dis
eño
para
Sis
tem
as O
O
Aspectos del diseñoCriterios para juzgar la
capacidad de métodos de diseño para conseguir
modularidad.
DESCOMPONIBILIDAD
COMPONIBILIDAD
COMPRENSIBILIDAD
CONTINUIDAD
PROTECCCION
UNIDADES LINGUISTICASMODULARES
POCAS INTERFACES
PEQUEÑAS INTERFACES
INTERFACES EXPLICITAS
OCULTAMIENTO DE LAINFORMACION
Principios básicos de diseño, que pueden ser
deducidos para arquitecturas modulares
Descomposición de un problema grande en problemas pequeños
Un método de diseño facilita...
Los componentes del programa una vez diseñados
y construidos, pueden ser reutilizados
Los componentes de un programa puedan ser entendidos, sin hacer
referencia a otro modulo
Pequeños cambios en un programa se revelen haciendo los cambios pertinentes en uno
o muy pocos módulos
Reduce la propagación de efectos colaterales, si ocurre un error en un modulo dado.
Dis
eño
para
Sis
tem
as O
O
Panorama del DOO
El método de Booch
Abarca un “microproceso de desarrollo” y un “macroproceso de desarrollo”.
Microproceso1.Define un conjunto de reglas que
regulan el uso de operaciones y atributos y las políticas del dominio especifico para la administración de la memoria, manejo de errores,etc.
2.Desarrolla situaciones que describen la semántica de las reglas y políticas
3.Crea un prototipo para cada política
4. Instrumenta y refina el prototipo
5.Revisa cada política para así transmitir su visión arquitectónica
Macroproceso1.Engloba una actividad de
planificación arquitectónica, que:
• Agrupa objetos similares en particiones arquitectónicas separadas,
• Agrupa capas de objetos por nivel de abstracción,
• Identifica situaciones relevantes,
• Crea un prototipo de diseño,
• Valida el prototipo
Dis
eño
para
Sis
tem
as O
O
El método de Rumbaugh
Engloba una actividad de diseño que alienta al diseño a ser conducido a dos diferentes niveles de abstracción.
Diseño de sistema1.Se centra en el esquema de los
componentes que se necesitan para construir un sistema o producto completo.
2.El modelo de análisis se divide en subsistemas
3.Se define una estrategia para implementar la administración de datos
4.Se identifican los recursos y mecanismos de control para accesarlos
Diseño de objeto1.Enfatiza el esquema detallado de
un objeto individual.
2.Se seleccionan las operaciones del modelo de análisis y los algoritmos se definen para cada operación.
3.Se representan las estructuras de datos apropiadas para atributos y algoritmos.
4.Las clases y atributos de clase son diseñados de manera que optimicen el acceso a los datos.
5.Se crea un modelo de mensajería.
Panorama del DOOD
iseñ
o pa
ra S
iste
mas
OO
El método de Jacobson
1. El modelo idealizado de análisis se adapta para acoplarse al ambiente del mundo real.
2. Después los objetos de diseño primarios, llamados “bloques”, son creados y catalogados como bloques de interfaz, bloque de entidades y bloques de control.
3. La comunicación entre bloques durante la ejecución se define y los bloques se organizan en subsistemas.
Panorama del DOOD
iseñ
o pa
ra S
iste
mas
OO
Etapas genéricas del DOO
1. 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.
Dis
eño
para
Sis
tem
as O
O
Enfoque unificado para el DOO
DISEÑ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
Dis
eño
para
Sis
tem
as O
O
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
Dis
eño
para
Sis
tem
as O
O
Pro
ceso
de
dise
ño d
el s
iste
ma
Fases del proceso de diseño de sistema
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.
Fases del proceso de diseño de sistemaP
roce
so d
e di
seño
del
sis
tem
a
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.
Proceso de diseño de sistemaP
roce
so d
e di
seño
del
sis
tem
a
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
Proceso de diseño de sistema
Plantilla básica de una tarea
1. Nombre de la tarea
2. Descripción
3. Prioridad
4. Servicios
5. Coordinado por...
6. Comunicados por ...
Pro
ceso
de
dise
ño d
el s
iste
ma
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 subfunciones, que estarán disponibles en el contexto de una categoría importante de menú de sistema (ventanas de menú)
Proceso de diseño de sistemaP
roce
so d
e di
seño
del
sis
tem
a
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.
Proceso de diseño de sistemaP
roce
so d
e di
seño
del
sis
tem
a
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.
Proceso de diseño de sistemaP
roce
so d
e di
seño
del
sis
tem
a
Comunicación entre subsistemas
Una vez que cada subsistema ha sido especificado, es necesario definir las colaboraciones que existen entre subsistemas.
Proceso de diseño de sistema
• 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)
Pro
ceso
de
dise
ño d
el s
iste
ma
Descripción de objetos
Diseño de algoritmos y estructura de datos
Pro
ceso
de
dise
ño d
e ob
jeto
s
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.P
roce
so d
e di
seño
de
obje
tos
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.
Pro
ceso
de
dise
ño d
e ob
jeto
s
Pat
rone
s de
dis
eño
Modelado de clases
Cliente
Nombre
Dirección
Estado
ObtenerCuentas():ConjuntoDeCuentas
EstablecerNombre(cadena Nombre)
ObtenerNombre():Cadena
No se muestran todos los atributos y operaciones
No se muestran todos los atributos y operacionesP
rogr
amac
ión
orie
ntad
o a
obje
tos
Generalización
Cuenta No se muestran todos los atributos y operaciones
No se muestran todos los atributos y operaciones
CuentaCorriente Deposito
Pro
gram
ació
n or
ient
ado
a ob
jeto
s
Producto ManufacturadoEl diamante vació
representa agregación
El diamante vació representa agregación
Componente
Pro
gram
ació
n or
ient
ado
a ob
jeto
s Agregación
Producto Manufacturado
Componente
ComponenteA ComponenteB ComponenteC
Pro
gram
ació
n or
ient
ado
a ob
jeto
s Generalización y Agregación
Cliente
ColecionCuentas
Pro
gram
ació
n or
ient
ado
a ob
jeto
s Composición
Administrador
Empleado
Administrador
Empleado
Administrador
Empleado
Relación simple Multiplicidad Documentada
1
1..*
1
1..*
Administra
Pro
gram
ació
n or
ient
ado
a ob
jeto
s Asociación
Asociación
Universidad
Estudiante
Documentando roles
1
1..*
Hospedar
estudiante miembro
Pro
gram
ació
n or
ient
ado
a ob
jeto
s
Administrador
Iniciar proyecto
Emitir informe de estado
Seleccionar plantilla
Terminar proyecto
Pro
gram
ació
n or
ient
ado
a ob
jeto
s Casos de uso
Casos de uso utilizando otro caso de uso
Administrador
del almacén
Validar producto
Consultar producto
Consultar nivel de stock
Consultar detalles de orden
“uses”
“uses”
“uses”
Pro
gram
ació
n or
ient
ado
a ob
jeto
s
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
Pro
gram
ació
n or
ient
ado
a ob
jeto
s
Colaboraciones
ViejoCliente:
ClienteBanco
CuentaCuentaInforme balanceInforme balance
GenerarInformeBalance
Otro ejemplo de diagrama de secuencias
Comprobar CuentaValida
Consultar cuenta
Pro
gram
ació
n or
ient
ado
a ob
jeto
s
Diagrama de estados
Cuenta activaCuenta activa
Cuenta vacíaCuenta vacía
Transacción
Crear cuentaTransacción
Cerrar cuenta
Pro
gram
ació
n or
ient
ado
a ob
jeto
s
•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.
Apreciación Global
Ingeniería de software
Unidad II
Ingeniería de Software Orientado a Objetos
Diseño Orientado a Objetos
Tema
Semana 8
