Un sistema orientado a objetos está arreglado de objetos interactuando que mantienen su propio estado local y proveen operaciones en ese estado. La representación del estado es privada y no puede ser accedida directamente desde afuera del objeto. Los procesos del diseño orientado a objetos provee diseñar objetos y su interacción.
Los objetos incluyen tanto datos como operaciones para manipular esos datos. Ellos quizás estén definidos como entidades independientes. Cambiar la implementación de un objeto o agregar servicios no debería afectar otros objetos del sistema. Porque los objetos están asociados con cosas, hay un mapeo entre el mundo real y las entidades; y sus objetos de control en el sistema. Esto mejora el entendimiento y por lo tanto la mantenibilidad del diseño.
Para desarrollar un diseño de sistema se recomiendan los siguientes puntos:
- Entender y definir el contexto y las interacciones del sistema.
- Diseñar la arquitectura del sistema.
- Identificar los principales objetos en el sistema.
- Desarrollar los modelos del diseño.
- Especificar interfaces.
1. Contexto e interacciones del sistema
Se debe desarrollar un entendimiento de las relaciones entre el software que está siendo diseñado y su ambiente externo. Esto es esencial para decidir cómo proveer la funcionalidad del sistema requerido y cómo estructurar el sistema para comunicar con su ambiente.
Configurar los límites del sistema ayuda a decidir qué características son implementadas en el sistema siendo diseñadas y que características están en otros sistemas asociados.
Los modelos de contexto del sistema y los modelos de interacción presentan vistas complementarias de las relaciones entre un sistema y su ambiente:
- Un modelo de contexto del sistema es un modelo estructural que demuestra los otros sistemas en el ambiente del sistema siendo desarrollado.
- Un modelo de interacción es un modelo dinámico que muestra cómo el sistema interactúa con su ambiente como es usado.
El modelo de contexto de un sistema quizá sea representado usando asociaciones. Las asociaciones simplemente muestran que hay algunas relaciones entre las entidades envueltas en la asociación. Se puede documentar el ambiente del sistema usando un simple bloque de diagrama, mostrando las entidades en el sistema y sus asociaciones.
El modelo de las interacciones de un sistema con su ambiente, debería usar un acercamiento abstracto que no incluye demasiado detalle. Una manera para hacer esto es usando el modelo de casos de uso. Cada caso de uso representa una interacción con el sistema. Cada posible interacción es nombrada en una elipse, y la entidad externa está involucrada en la interacción que es representada por una figura. Cada uno de estos casos de uso debería ser escrito en lenguaje natural estructurado. Esto ayuda a los diseñadores identificar objetos en el sistema y darles un entendimiento de lo que el sistema está intentado a hacer.
2. Diseñar la arquitectura del sistema.
El diseño de la arquitectura del sistema se ve en en otra publicación.
3. Modelos del diseño
Los modelos del sistema muestran los objetos o clases de objetos en un sistema. Ellos también muestran las asociaciones y relaciones entre estas entidades. Estos modelos son el puente entre los requerimientos del sistema y la implementación de un sistema. Ellos tiene que ser abstractos para que los detalles innecesarios no oculten las relaciones entre ellos y los requerimientos del sistema. Sin embargo, ellos también tienen que incluir suficientes detalles para que los programadores puedan tomar las decisiones de implementación.
El nivel de detalle que se necesita en el modelo de diseño depende en los procesos de diseño usados. Donde hay estrecha relación estrecha entre los ingenieros de requerimientos, diseñadores y programadores, entonces los modelos abstractos quizá sean todo lo que es requerido. La especificación de las decisiones del diseño quizá sea hecho como el sistema es implementado, con problemas resueltos a través de discusiones informales. Similarmente, si el desarrollo ágil es usado, los modelos de diseño de esquema en una pizarra pueden ser todo lo que se requiere.
Modelado dirigido por eventos.
El modelado dirigido por eventos muestra como un sistema responde a eventos externos e internos. Es basado en la suposición que un sistema tiene un número finito de estados y que los eventos (estímulos) pueden causar una transición desde un estado a otro. Por ejemplo, un sistema controla una válvula que puede mover desde un estado “válvula abierta” a un estado “válvula cerrada” cuando un comando de operado (el estímulo) es recibido. Esta vista de un sistema es particularmente apropiada para sistemas de tiempo-real. El modelado dirigido-por eventos es usado extensivamente en el diseño y documentación de sistemas de tiempo real.
UML soporta el modelado basado en eventos usando diagramas de estado, los cuales son basados en gráficos de estados (Harel, 1987). Los diagramas de estado muestran los estados del sistema y eventos que causan las transiciones de un estado a otro. Ellos no muestran el flujo de información dentro del sistema pero puede incluir información adicional sobre los cálculos realizados en cada Estado.
En los diagramas de estado de UML, rectángulos redondeados representan los estados del sistema. Ellos quizá incluya una descripción amigable de las acciones tomadas en ese estado. Las marcas de las flechas representan el estímulo que fuera una transición de un estado a otro. Se puede indicar el comienzo y final de cada estado usando círculos llenos, como en diagramas de actividad.
El problema con modelado basado en estados es que el número de posibles estados incrementa rápidamente. Para modelos de sistemas grandes, por lo tanto, se necesita ocultar detalle en los modelos. Una manera para hacer esto es usando la notación de un “super estado”. que encapsula un número de estados separados. Este super estado parece un estado único en un modelo de alto nivel pero es entonces expandido para mostrar más detalles en un diagrama separado.
El modelo de navegación define el orden y las relaciones entre las funcionalidades (casos de uso), se documenta usado diagramas de estado UML. Las pantallas del sistema se definen como estados, se identifica el evento que causa el cambio de pantalla (estado).
Para construir el diagrama de estados, que modela la navegación, se parte del prototipo de interfaz de usuario construido para los casos de uso. Las pantallas se representan por estados y los eventos, que ocasionan el cambio de una pantalla a otra, por las transiciones entre estados. El estado inicial del diagrama, apunta al estado que representa a la pantalla principal del sistema. En esta pantalla, por lo general, se tienen varias opciones para navegar. Cada opción representa un evento que puede llevar a otra pantalla.
4. Especificación de interfaz
Una parte importante de algunos procesos de diseño es la especificación de las interfaces entre los componentes del diseño. Se necesita especificar interfaces para que los objetos y subsistemas puedan ser diseñados en paralelo. Una vez que una interfaz ha sido especificada, los desarrolladores de otros objetos quizá asuman esa interfaz que será implementada.
El diseño de la interfaz se preocupa con especificar los detalles de la interfaz a un objeto o un grupo de objetos. Esto significa definir las firmas y semánticas de los servicios que son proveídos por el objetos o por un grupo de objetos. Las interfaces pueden ser especificadas usando la misma notación de UML como una clase de diagrama.
No se debe incluir detalles de la representación en un diseño de interfaz, los atributos no son definidos en una especificación de interfaz. Sin Embargo, se debe incluir operación para acceder y actualizar los datos. Como la representación de los datos está oculta, esto puede ser fácilmente cambiando sin afectar los objetos que usan esos datos. Esto conlleva a un diseño que inherentemente es más mantenible.
Referencias
Sommerville, Ian, Software Engineering, (10th edition). Addison Wesley, 2016.
Comentarios
Publicar un comentario