El documento presenta una introducción al diseño de objetos realizado por un grupo de estudiantes. Explica la diferencia entre objetos de aplicación y objetos de solución, y las actividades clave del diseño de objetos como la identificación de atributos, operaciones, tipos, visibilidad, restricciones y excepciones. También menciona temas como bibliotecas de clases, marcos de aplicación, asociaciones, reutilización, administración del diseño y asignación de responsabilidades.

1. INTRODUCCION DISEÑO DE OBJETOS
Integrantes:
Diego Alirio Carrascal Cód.. 1151340
Deiby Camilo Galvis Cód.. 1151381
Aarón Soto Cód.. 1151452
Martha Alejandra Chacín Cód.. 1151401
José Camilo Boada Cód.. 1151362
Samir Parada Cód.. 1150364
Alejandra Barragán Cód.. 1150792
Javier Calderón Cód.. 1151229
Jhorman Botello Cód.. 1151454

2. OBJETOS DE APLICACIÓN FRENTE A OBJETOS DE SOLUCIÓN
• Los objetos de aplicación representan conceptos del dominio que manipula el
sistema
• Los objetos de solución representan componentes de apoyo que no tienen una
contraparte en el dominio de la aplicación.
• Durante el análisis identificamos los objetos de aplicación
• Durante el diseño identificamos subsistemas y los objetos de solución mas
importantes
• Durante el diseño de objetos refinamos y detallamos ambos conjuntos de
objetos
9 de junio de 2018 2

3. REVISIÓN DE TIPOS, FORMAS Y VISIBILIDAD
• El tipo de un atributo especifica el rango de valores que puede tomar el atributo
y las operaciones de este.
• Para oda operación, al tuplo compuesto por los tipos de sus parámetros y el tipo
de valor de retorno se le llama firma de la operación.
• La visibilidad de un atributo o una operación especifica si puede ser usada por
otras clases o no.
– Privado
– Protegido
– Publico
9 de junio de 2018 3

4. CONTRATOS
• Son restricciones sobre una clase que permiten que el llamador y el llamado
compartan las mismas suposiciones acerca de la clase.
– Invariante: se usan para especificar restricciones de consistencia entre
atributos de clase.
– Precondición: se usan para especificar restricciones que debe satisfacer el
llamador antes de llamar a una operación
– Poscondición: se usan para especificar restricciones que el objeto debe
asegurar después de la invocación de la operación.
9 de junio de 2018 4

5. 9 de junio de 2018 5

6. LENGUAJE DE RESTRICCIÓN DE OBJETOS
• Las restricciones se expresan usando OCL.
• OCL es un lenguaje que permite que se especifiquen de manera formal las
restricciones en elementos únicos del modelo o en grupos de elementos del
modelo.
9 de junio de 2018 6

7. ACTIVIDADES DEL DISEÑO DE OBJETOS
9 de junio de 2018 7
Identificación de atributos y operaciones faltantes: durante este paso examinamos la
descripción de servicios del subsistema e identificamos atributos y operaciones faltantes de
la etapa de análisis. Una herramienta muy útil para realizar esta actividad es el diagrama de
secuencia.

8. ACTIVIDADES DEL DISEÑO DE OBJETOS
Especificación de tipo de firmas y visibilidad: durante esta actividad especificamos los tipos
de atributos, las firmas de las operaciones y la visibilidad de los mismos. Esto refina el modelo
del diseño de objetos especificando primero rangos para los atributos, y segundo,
estableciendo correspondencia entre clases y atributos del modelo de objetos.
Especificación de restricciones: durante este proceso añadimos las restricciones a las clases y
operaciones para especificar con mayor precisión su comportamiento y casos de frontera,
buscando eliminar la ambigüedad mediante 3 tipos de restricciones:
•Invariantes: condiciones de los atributos que siempre son ciertas.
•Precondiciones: condiciones que deben ser satisfechas (por quien llama) antes de una
operación dada.
•Poscondiciones: representan condiciones que están garantizadas por quien fue llamado
cuando termina la operación.
Especificación de excepciones: durante este paso especificamos condiciones que las
operaciones detectan y tratan como errores elevando una excepción. Para esto se deben
establecer convenciones y mecanismos para su manejo. Usualmente se asocian con la
violación de precondiciones.
9 de junio de 2018 8

9. 7.4.5 IDENTIFICACIÓN Y AJUSTES DE BIBLIOTECAS DE CLASE
9 de junio de 2018 9

10. 7.4.6 IDENTIFICACIÓN Y AJUSTE DE MARCOS DE
APLICACIÓN
7.4.7 EJEMPLO DE MARCO: WEBOBJECTS
• Marcos de infraestructura
• Marcos middleware
• Marcos de aplicación empresariales
• Marcos de Caja Blanca
• Marcos de Caja negra
9 de junio de 2018 10

11. 7.4.8 REALIZACIÓN DE ASOCIACIONES
• 1 a 1 Unidireccionales
• 1 a 1 Bidireccionales
• 1 a *
• * a *
• 1 a * con clase intermedia
• 1 a * calificado (existe un hash table en el *)
9 de junio de 2018 11

12. INCREMENTO DE LA REUTILIZACIÓN
• La herencia permite que los desarrolladores reutilicen el código a través de
varias clases similares.
• JFC: Java Foundation Classes
9 de junio de 2018 12
AbstractButton
JButton JMenuItem JToggleButton
JRadioButton JCheckBox

13. VENTAJAS PRINCIPALES EN LA UTILIZACIÓN DE UNA JERARQUÍA DE
HERENCIA BIEN DISEÑADA
• Se reutiliza más código, y esto conduce a menos redundancias y, por tanto,
menos oportunidades para que haya defectos.
• El código es extensible, incluyendo una interfaz bien documentada para la
creación de especializaciones futuras.
9 de junio de 2018 13

14. ENFOQUES PRINCIPALES PARA EL DISEÑO DE UNA JERARQUÍA DE
HERENCIA A FIN DE REUTILIZARLA
• Se examinan varias clases similares y abstraer su comportamiento en común.
• Desacoplar una clase cliente de un cambio anticipado introduciendo un nivel de
abstracción. Los patrones de diseño usan herencia para protegerse contra un
cambio anticipado.
ELIMINACIÓN DE LAS DEPENDENCIAS DE IMPLEMENTACIÓN
• Se usa generalización para clasificar a los objetos en jerarquías de
generalización/especificación.
• Esto permite diferenciar el comportamiento común del caso general con
respecto al comportamiento específico de los objetos especializados.
9 de junio de 2018 14

15. • Al uso de la herencia con el único propósito de la reutilización se llama Herencia
de Implementación.
• A la clasificación de conceptos en jerarquías de especialización-generalización se
le llama Herencia de Interfaz. También conocida como subtipeado.
REVISIÓN DE LA RUTA DE ACCESO
El recorrido repetido de asociaciones múltiples cuando se tiene acceso a la
información que se necesita, ocasiona un desempeño ineficiente. Otra causa es
el modelado excesivo
Para cada operación:
¿Con cuánta frecuencia se llama a la operación?
¿Cuáles asociaciones tiene que recorrer la operación para obtener la información
que necesita?
9 de junio de 2018 15

16. DESCOMPOSICIÓN DE OBJETOS: CONVERSIÓN DE OBJETOS EN
ATRIBUTOS
9 de junio de 2018 16
Al realizar el análisis los desarrolladores identifican clases que están asociadas con
conceptos de dominio. Durante el diseño del sistema y el diseño de objetos se
reestructura y optimiza el modelo de objetos, en ciertas ocasiones quedan clases con sólo
unos cuantos atributos y poco comportamiento, para lo cual se hace necesario que dichas
clases se asocien con otras, así puedan descomponerse hacia un atributo, reduciendo por
tanto la complejidad general del modelo.

17. CACHEO DE RESULTADOS DE CÁLCULOS COSTOSOS
Con frecuencia los cálculos costosos solo necesitan realizarse una vez, debido a que
los valores con los que se realiza el calculo no cambian o lo hacen despacio. En tales
casos se habla de cachear el resultado como un atributo privado.
La operación Capa obtenerContorno() se supone que ElementoCapa se define una
sola vez como parte de la configuración del sistema y no cambian durante la
ejecución. El vector de punto regresado por la operación capa.obtenerContorno ()
siempre es el mismo para un cuadroLim y detalle, tomando en cuentas esto, una
optimización simple es añadir un atributo privado puntos Cacheados a la clase capa,
el cual recuerda el resultado de la operación obtenerContorno ()
Este enfoque incluye un intercambio por un lado mejoramiento del tiempo de
respuesta para la operación solicitada obtenerContorno(), pero por el otro se
consume espacio de memoria guardando información redundante
9 de junio de 2018 17

18. RETRASO DE CÁLCULOS COSTOSOS
Un enfoque alterno para los cálculos costosos es retrasarlos lo mas posible. En el
ejemplo la carga desde el archivo de todos los pixeles es costosa, sin embargo los
datos no necesitan cargarse sino hasta que se vaya a desplegar, para esto se usa un
patrón apoderado que toma el lugar de Imagen y proporciona la misma interfaz que
el objeto, las operaciones simples son manejadas por este, de ser necesario trazar ()
la Imagen este patrón carga los datos desde el disco y crea un objeto ImagenReal,
de lo contrario no se crea ningún objeto ahorrando tiempo de cálculos.
Las clases llamadoras solo acceden
al ApoderadoImagen e ImagenReal
mediante la interfaz de Imagen.
9 de junio de 2018 18

19. 9 de junio de 2018 19
ADMINISTRACIÓN DEL DISEÑO DE OBJETOS
Incremento en la complejidad de la
comunicación
Cantidad de participantes
involucrados durante la fase de
desarrollo
Consistencia en decisiones y
documentos anteriores
Detallar y refinar el respectivo
modelo de diseño para mantener
registros del estado actual del
desarrollo.
• Documentación del diseño de objetos: El diseño de objetos se documenta en
el documento de diseños de objetos (ODD) y este describe Compromisos del
diseño de objetos tomado por los desarrolladores. Intercambio de información
de interfaz entre equipos y referencias en una prueba.

20. Existen tres enfoques principales para documentar el diseño de objetos
1. ODD auto contenido generado a partir del modelo : Documentar los
modelos de análisis, diseño del sistema para mantener un modelo de
UML
2.ODD como extensión del RAD: En este enfoque se trata al modelo de
diseño como una extensión del modelo del análisis es decir se considera
al diseño de objetos como el conjunto de objetos de aplicación
aumentado con los objetos de solución.
3.ODD incrustado en el código fuente: En este enfoque se incrusta el
ODD(Documento de diseño de objetos) en el código fuente
La unión de estos enfoques busca la descripción de los objetos una sola vez y sus
consecuencias entre documentación, los stubs y el código se mantenga de forma
automática.
9 de junio de 2018 20

21. ASIGNACIÓN DE RESPONSABILIDADES
Para asegurar que los cambios a las interfaces se documenten y comuniquen en
forma ordenada varios roles colaboran para controlar, comunicar e implementar
los cambios.
A continuación se presentan los papeles principales del diseño de objetos:
• Arquitecto principal: desarrolla los lineamientos y convenciones de
codificación antes que comience el diseño de objetos.
• Los coordinadores de arquitectura: Documentan las interfaces de los
sistemas públicos de los que son responsables. Esto conduce a un primer
borrador del ODD que utilizan los desarrolladores.
9 de junio de 2018 21

22. • Diseñadores de objetos: Refinan y detallan la especificación de la interfaz
de la clase o subsistema que implementan.
• El gerente de configuración: lidera los cambios de las interfaces y al ODD
una vez que se encuentran disponibles.
• Los escritores técnicos del equipo de documentación pulen la versión final
del ODD.
Al igual que en diseño del sistema, el equipo de arquitectura es la fuerza
integradora del diseño de objetos. El equipo de arquitectura aseguran que los
cambios sean consistentes en los objetivos del proyecto. El equipo de
documentación, incluyendo a los escritores técnicos, aseguran que los
cambios sean consistentes en los lineamientos y convenciones.
9 de junio de 2018 22

23. 9 de junio de 2018 23

24. GRACIAS
9 de junio de 2018 24