El Diseño de un Sistema Orientado a Objetos

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.

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. 
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.    

...