Brayan Israel Sánchez Ledezma #1676516 grupo: 003 Jueves M4-M6

Actividad: Reporte de investigación sobre las técnicas de diseño de sistemas

orientados a objetos.

El Diseño de un Sistema Orientado a Objetos

En un entorno puramente orientado a objetos, cada pieza de código existe dentro
de una clase de objeto, ya sea toda la interfaz de usuario, toda la lógica del
programa, etcétera. Una aplicación funciona haciendo que las clases envíen y
reciban mensajes de otras clases. Podemos decir que el objetivo del diseño
orientado a objetos (OOD) por sus siglas en inglés, es especificar los objetos y
mensajes del sistema. Un sistema orientado a objetos se estructura en al menos
tres tipos diferentes de clases de objetos.
• Las clases de entidad contienen información conocida como atributos, que
describen las diferentes instancias de la entidad. También encapsulan aquellos
comportamientos (llamados métodos) que mantienen su información o
atributos. Estas clases son el corazón del sistema.
• Las clases de interfaz son las que ayudan al usuario a comunicarse con el
sistema por medio de las interfaces de usuario. Toda la funcionalidad que
tenga que ver con la interacción directa del usuario con el sistema debe
colocarse en las clases de interfaz. La responsabilidad de una clase de interfaz
es doble ya que debe traducir las entradas de datos por parte de los usuarios
en información que el sistema pueda entender para procesarla, y debe también
mostrarle al usuario de una forma correcta el resultado del procesamiento de
los datos que se soliciten.
• Las clases de control implementan toda la lógica de negocios. Las clases de
control procesan mensajes de una clase de interfaz y responden a ellos
enviando y recibiendo mensajes de las clases de entidad.
Un sistema orientado a objetos podría implementarse solo con estos tres tipos de
clases, sin embargo, muchas metodologías incluyen otros dos tipos de clases.
• Las clases de persistencia o de acceso de datos ayudan a las clases de
entidad a que se mantengan neutrales en la implementación, esto puede
permitir que las clases de entidad sean más reutilizables, un objetivo principal
del diseño orientado a objetos.
• Las clases de sistema aíslan a los otros objetos de la funcionalidad específica
del sistema operativo. Si el sistema se traslada a otro sistema operativo, solo
se deben cambiar estas clases y quizás las clases de interfaz.
En el análisis orientado a objetos es importante centrarse en identificar las
relaciones de objetos más comunes, las cuales son asociaciones, relaciones de
agrupación y relaciones de generalización/especialización. Es importante modelar
relaciones para especificar con precisión los componentes de software.
 Brayan Israel Sánchez Ledezma #1676516 grupo: 003 Jueves M4-M6

La forma en que se accede a los atributos y métodos por otras clases está definida
por visibilidad. UML nos provee de tres niveles de visibilidad: publica (denotada
por el símbolo +), protegida (denotada por el símbolo #) y privada (denotada por el
símbolo -). Se puede acceder a los atributos y métodos públicos y pueden ser
invocados por cualquier otro método en cualquier otra clase. Los atributos y
métodos privados pueden ser invocados solo por algún método de la clase en la
que se definen. En la mayoría de los casos, todos los atributos de la clase deben
declarase privados para hacer cumplir la encapsulación.
El Proceso de Diseño Orientado a Objetos
En el análisis orientado a objetos definimos casos de uso y objetos identificados
en función de las condiciones ideales e independientes de la solución de software
y hardware. Durante el diseño orientado a objetos queremos refinar esos casos de
uso y objetos para reflejar el entorno real de nuestra solución propuesta. El diseño
orientado a objetos incluye las siguientes actividades:
1. Refinar el modelo de caso de uso para reflejar el entorno de implementación.
2. Modelar las interacciones de clases, comportamientos y estados que apoyan el
escenario de casos de uso.
3. Actualizar el diagrama de clases para reflejar el entorno de implementación.
Refinando el Modelo de Caso de Uso
En esta iteración del modelado de casos de uso, los casos de uso se refinarán
para incluir detalles de cómo el actor o usuario realmente interactuará con el
sistema y cómo responderá el sistema al estímulo para procesar el evento de
negocios. Es necesario que se detalle y especifique correctamente la manera en
que el usuario accede al sistema, así como el contenido de las ventanas, informes
y consultas. Estos casos de uso servirán para la realización de los manuales de
usuario subsiguientes y los scripts de prueba que se desarrollan durante la
implementación del sistema.
Es importante que cada caso de uso sea altamente detallado al describir la
interacción del usuario con el sistema. El usuario puede utilizar los casos de uso
refinados para validar el sistema.
- Paso 1: Transformación de los casos de uso de análisis a casos de uso de
diseño.
En este paso, refinamos cada uno de esos casos de uso para reflejar los aspectos
físicos del entorno de implementación para nuestro nuevo sistema.
Los elementos del caso de uso son:
1. Tipo de caso de uso: para reflejar los detalles de la implementación, como las
interpretaciones de la interfaz de usuario.
 Brayan Israel Sánchez Ledezma #1676516 grupo: 003 Jueves M4-M6

2. Controles de la ventana: en los casos de uso del diseño del sistema, los
controles de la ventana, como los íconos, las casillas de verificación de los
enlaces y los botones, están explícitamente establecidos.
3. Nombre de ventana: se indica el nombre de cada elemento de la interfaz de
usuario (nombre de ventana).
4. Instrucciones de navegación: se deben especificar instrucciones sobre cómo
el usuario navega por la interfaz de usuario.

- Paso 2: Actualización del diagrama del modelo de caso de uso y otro para
reflejar cualquier nuevo caso de uso.
Después de que todos los casos de uso de análisis de sistemas se hayan
transformado en casos de uso de diseño de sistemas, es muy posible que se
hayan descubierto nuevos casos de uso, dependencias de casos de uso o incluso
actores. Por lo tanto, en este paso, el diagrama del modelo de caso de uso, el
diagrama de dependencia del caso de uso y los glosarios del actor y del caso de
uso deben actualizarse para reflejar cualquier información nueva.
Modelando Interacciones de Clase, Comportamientos y Estados que Apoyan
el Escenario de Caso de Uso
- Paso 1: Identificar y clasificar clases de diseño de casos de uso.
En esta actividad, queremos identificar y categorizar las clases de diseño
requeridas por la funcionalidad que especificamos en cada caso de uso e
identificar las interacciones de clase, sus responsabilidades y sus
comportamientos.
1. Columna de clases de la interfaz: contiene una lista de clases mencionadas
en el caso de uso con el que los usuarios interactúan directamente.
2. Columna de clases de controlador: contiene una lista de clases que
encapsulan la lógica de la aplicación o las reglas de negocios.
3. Columna de clases de entidad: contiene una lista de clases que
corresponden a las clases de dominio de negocios cuyos atributos fueron
referenciados.

- Paso 2: Identificar los atributos de clase.

En este paso, examinamos cada caso de uso en busca de atributos adicionales
que no se hayan identificado previamente, y actualizamos nuestro diagrama de
clase.
- Paso 3: Identificar conductas y responsabilidades de clase.
 Brayan Israel Sánchez Ledezma #1676516 grupo: 003 Jueves M4-M6

Una vez que hemos identificado todos los objetos necesarios cambiamos nuestra
atención a la definición de los comportamientos y responsabilidades específicas.
Este paso involucra las siguientes tareas:
1. Analizar los casos de uso para identificar comportamientos requeridos del
sistema.
2. Asociar conductas y responsabilidades con las clases.
3. Clases modelo que tienen un comportamiento complejo.
4. Examinar el diagrama de clase para comportamientos adicionales.
5. Verificar clasificaciones.
Nuestra primera tarea para identificar los comportamientos y responsabilidades de
la clase se logra al examinar nuevamente nuestro caso de uso. Las frases
verbales se correlacionan con los comportamientos del sistema que se requieren
para completar un escenario de uso. Cada caso de uso debe examinarse por
separado para identificar comportamientos asociados con el caso de uso.
Una vez que se han identificado los comportamientos, nuestra segunda tarea es
determinar si los comportamientos son manuales o si serán automatizados. Si
serán automatizados, deben asignarse al objeto apropiado que tendrá la
responsabilidad de llevar a cabo ese comportamiento.
La siguiente tarea es identificar qué comportamientos deben asociarse con qué
clase para identificar las colaboraciones entre esas clases.
Es necesario identificar la colaboración de los tipos de objetos para garantizar que
todas las clases de casos de uso funcionen en armonía para completar el
procesamiento requerido para el evento de negocios que desencadena el
escenario de casos de uso. Una herramienta para descubrir y/o documentar
comportamientos y responsabilidades de clase es un diagrama de secuencia. Un
diagrama de secuencia representa la interacción entre todas las clases de objetos
involucradas en el escenario; modela la lógica de un caos de uso al representar la
interacción de mensajes entre objetos en una secuencia de tiempo.
Un diagrama de secuencia puede verse como una forma de integrar los pasos de
un caso de uso con los objetos de un diagrama de clase. Se puede utilizar como
una herramienta de comunicación con los programadores para especificar qué
métodos llamar en la implementación de un caso de uso. Las partes de un
diagrama de secuencia son: actor, clase de interfaz, clase de controlador, clase de
entidad, mensajes, barras de activación, mensajes de retorno, mensajes de
retorno, auto llamada y marco.
- Paso 4: Estados del objeto modelo.
El objeto modelo establece que nuestra próxima tarea es identificar y modelar
cualquier objeto que tenga un comportamiento complejo basado en los cambios de
 Brayan Israel Sánchez Ledezma #1676516 grupo: 003 Jueves M4-M6

su estado. Se dice que todos los objetos tienen estado: el valor de los atributos de
los objetos en un punto en el tiempo. Un objeto cambia de estado cuando cambia
el valor de uno de sus atributos, este cambio de estado se desencadena por un
evento de transición de estado.
Un diagrama de esta máquina modela el ciclo de vida de un solo objeto. Describe
los estados diferentes que un objeto puede tener, los eventos que hacen que el
objeto cambie de estado a lo largo del tiempo y las reglas que gobiernan la
transición del objeto entre estados. El diagrama de máquina de estados se
construye solo para aquellos objetos que tienen estados claramente identificables
y comportamientos complejos.
Actualización del Modelo de Objetos Para Reflejar el Entorno de
Implementación
Ahora podemos refinar nuestro diagrama de clase para representar las clases de
software en la aplicación; un diagrama e clase de diseño típicamente incluye lo
siguiente: clases, asociaciones y relaciones gen/spec y agregación, atributos e
información de tipo de atributo, métodos con parámetros, navegabilidad y
dependencias.
Los siguientes pasos se utilizan para transformar el diagrama de clase preparado
en el análisis orientado a objetos a un diagrama de clase de diseño:
1. Añadir objetos de diseño al diagrama. Los objetos de entidad, interfaz y
control que se identificaron previamente deben agregarse al diagrama.
2. Agregar atributos e información de tipo de atributo para diseñar objetos.
Los lenguajes de programación orientados a objetos permiten los tipos de
atributos comunes, como integer, fecha, boolean y cadena, entre otros.
3. Añadir atributo de visibilidad. Los atributos pueden definirse como públicos,
protegidos o privados.
4. Añadir métodos para diseñar objetos. Defina métodos para obtener y
actualizar los valores de todos los atributos de cada objeto.
5. Agregar método de visibilidad. Los métodos pueden ser definidos como
públicos, protegidos o privados.
6. Añadir navegabilidad asociativa entre clases. Agregue flechas de
navegación a las asociaciones unidireccionales para indicar la dirección en la
que se envían los mensajes entre las clases de origen y destino.
7. Añadir relaciones de dependencia. Para cualquier clase de interfaz de
usuario que aparezca en el diagrama, dibuje una línea de dependencia entre
este y el objeto de control.
Los Patrones de Diseño
Los patrones de diseño son unas técnicas para resolver problemas comunes en el
desarrollo de software y otros ámbitos referentes al diseño de interacción o
 Brayan Israel Sánchez Ledezma #1676516 grupo: 003 Jueves M4-M6

interfaces. Es decir, significa que no debes crear un nuevo software para resolver
un problema que alguien más ya ha creado para resolver de manera correcta y
eficiente.
El objetivo de un patrón no es descubrir o inventar una nueva solución a un
problema, sino estructurar formalmente una solución existente para un problema
común, de modo que otros puedan usarlo y tomar una ventaja de ello. Como
ventaja principal esta que nos permite diseñar sistemas de información con las
experiencias de quienes nos precedieron en lugar de comenzar desde cero.
El patrón de estrategia se clasifica como patrón de comportamiento porque
determina cómo se debe realizar el intercambio de mensajes entre diferentes
objetos para resolver una tarea. Permite mantener un conjunto de algoritmos de
entre los cuales el objeto cliente puede elegir aquel que le conviene e
intercambiarlo dinámicamente según sus necesidades.
El patrón adaptador es de categoría estructural y se utiliza para transformar una
interfaz en otra, de tal modo que una clase que no pueda utilizar la primera haga
uso de ella a través de la segunda. Su propósito principal es convertir la interfaz de
una clase en otra interfaz que el cliente espera. El adaptador permite a las clases
trabajar juntas, lo que de otra manera no podría hacerse debido a sus interfaces
incompatibles.
Los desarrolladores utilizan frameworks para aprovechar la reutilización y reducir
el tiempo de desarrollo. Un framework es un subsistema de clases colaborativas
que proporciona un conjunto de servicios relacionados. Mientras que los patrones
son pautas de diseño escritas en papel, los frameworks son clases implementadas
en código de programación y listas para llamar. Al usar frameworks, los
desarrolladores pueden concentrarse en desarrollar la lógica que es nueva o
exclusiva para la aplicación, reduciendo así el tiempo total requerido para construir
todo el sistema.
Un diagrama de comunicación modela la interacción de objetos a través de
mensajes. Es similar a un diagrama de secuencia, pero el diagrama de
comunicación se enfoca en la organización estructural de objetos en formato de
red.
Los diagramas de componentes son diagramas de tipo de implementación que se
utilizan para representar gráficamente la arquitectura física del software del
sistema. Un diagrama de componentes se puede usar para mostrar cómo se
divide el código de programación en componentes y para representar las
dependencias entre esos componentes.
Los diagramas de despliegue son diagramas de tipo implementación que
describen la arquitectura física del hardware y el software en el sistema.
 Brayan Israel Sánchez Ledezma #1676516 grupo: 003 Jueves M4-M6

Representan los componentes de software, los procesadores y los dispositivos

que forman la arquitectura del sistema.

Conclusiones
A lo largo de esta actividad se estuvo presentando información referente al diseño
y un poco del análisis orientado a objetos para realizar sistemas, pude notar que
estos son procesos de mucha importancia para generar una correcta
documentación del software. Aunque ya conocía un poco los sistemas orientados
a objetos y algo de su trasfondo, no sabía con exactitud todo el proceso y los
pasos a seguir que se tienen para una correcta implementación del diseño
orientado a
objetos.
El proceso de diseño orientado a objetos es un proceso exhausto pero necesario y
muy útil ya que su esencia es la reutilización, por el contrario del diseño de
sistemas tradicionales. Esta característica ha logrado que el paradigma orientado
a objetos haya tomado tanta relevancia en los últimos años, pues a día de hoy es
uno de los paradigmas más usados en la industria del software.
Lamentablemente, como se mencionó anteriormente, los sistemas orientados a
objetos demandan mucha precisión en las fases de diseño y análisis, ya que todo
tiene que estar perfectamente detallado y especificado para que la documentación
y la construcción del sistema sea correctamente implementada, sin embargo, los
beneficios son muchos tanto para el equipo de TI, como para los usuarios finales,
entregando sistemas mejor construidos y más funcionales.

Bibliografía
Análisis de Sistemas Diseño y Métodos, B. Whitten, Mc Graw Hill, 2008. ISBN:
97010-4283-2 [Capítulo 18: Object-Oriented Design and Modeling Using the UML).