ESTRATEGIAS DE DISEÑO
El diseño se define como la búsqueda de una solución en cualquier campo, sin embargo las soluciones no llegan de una manera simple, muchas veces realizamos soluciones complejas a problemas sencillos o en otras ocasiones una gran solución conlleva a otro problema.
La cuestión está en cómo abordamos esos retos de diseño. Estudios demuestran que nos enfocamos en resolver los problemas de manera individual alejándonos cada vez más del sistema completo en el que estamos trabajando, “es como diseñar una ventana sin el edificio”, recuerden todo tiene un impacto y en un sistema todo está relacionado.
Así que por otro lado que tal si vemos todo el sistema y así planeamos mejor nuestro diseño, haciendo que las soluciones de una parte no perjudiquen a la otra, o mejor que se complementen entre si. Esto nos ayudara a ver qué lugar social, ambiental y técnico nuestro producto hace parte. Se recomienda que tengamos en cuenta: Metas ambiciosas que resuelvan varios problemas, colaboración a través de diferentes disciplinas, establecer parámetros base, definir la vida útil, iniciar desde cero los diseños, usar datos medibles y no asumir reglas entre otros.
En las siguientes imágenes podemos ver un sencillo pero útil flujo de trabajo para iniciar nuestros diseños o la mejora de ellos.
Diseñar es una tarea que involucra muchos aspectos, diseñar es divertido así que si utilizamos las herramientas adecuadas podremos crear productos de una mejor calidad!
Antes de poder resolver el diseño es necesario tomar decisiones generales sobre las estrategias de diseño a seguir. Algunas de las decisiones a tomar se presentan a continuación y se relacionan con aspectos que incluyen la arquitectura, robustez, reúso y extensibilidad del sistema.
ARQUITECTURA
El término arquitectura se refiere, en nuestro caso, a la organización de las clases dentro del sistema. Durante el modelo de análisis se generó una arquitectura de clases para el sistema y se definió la funcionalidad “conceptual” ofrecida por las distintas clases dentro de la arquitectura. Durante el diseño esta arquitectura debe detallarse, pudiéndose cambiar los aspectos considerados inicialmente, como fue la funcionalidad inicialmente asignada a cada clase, e incluso las propias clases, como hemos mencionado al inicio del capítulo.El conocimiento y funcionalidad asignada a cada clase puede ser vista como la “inteligencia” de cada clase dentro del sistema. En otras palabras, algunas clases pueden ser vistas como más inteligentes que otras según el conocimiento y control que tengan sobre las demás clases.
ROBUSTEZ
La robustez de un sistema debe ser uno de los objetivos principales del diseño. Jamás debe agregarse funcionalidad o simplificar código a expensas de la robustez. El sistema debe estar protegido contra errores y debe al menos ofrecer diagnósticos para las fallas que aún pudiesen ocurrir, en particular aquellas que son fatales. Durante el desarrollo es a veces bueno insertar instrucciones internas en el código para descubrir fallas, aunque luego sean removidas durante la producción. En general se debe escoger lenguajes de programación que apoyen estos aspectos, como son el manejo de excepcionesREÚSO
El reúso es un aspecto fundamental del diseño. Cuanto más se pueda reutilizar el código mejor será la robustez del sistema. Las siguientes son algunas estrategias para mejorar las posibilidades de reúso del diseño:A través de la herencia se puede incrementar el reúso de código. Se toman los aspectos comunes a clases similares utilizando.
DISEÑO DE OBJETOS
¿Qué es el diseño? Es el proceso previo de configuración mental en la búsqueda de una solución en cualquier área.Durante el diseño de objetos, se ejecuta la estrategia seleccionada durante el diseño del sistema y se rellenan los detalles. Se produce un desplazamiento del énfasis pasando de los conceptos del dominio de la aplicación a los propios de las computadoras. Los objetos descubiertos durante el análisis sirven como esqueleto del diseño, pero el diseñador debe escoger distintas formas de implementarlos con el objetivo de minimizar el tiempo de ejecución, la memoria y el costo.
En particular, las operaciones identificadas durante el análisis deben expresarse en forma de algoritmos, descomponiendo las operaciones complejas en operaciones internas más sencillas.
Las clases, atributos y asociaciones del análisis deben de implementarse en forma de estructuras de datos específicas. Es necesario introducir nuevas clases de objetos para almacenar resultados intermedios durante la ejecución del programa y para evitar la necesidad de recalcularlos.
La optimización del diseño no debería llevarse a extremos exagerados porque la facilidad de implementación y mantenimiento y la extensibilidad son también objetivo importantes. La fase de análisis determina lo que debe hacer la implementación y la fase de diseño del sistema determina el plan de ataque.
La fase de diseño de objetos determina las definiciones completas de las clases y asociaciones que se utilizarán en la implementación, así como las interfaces y algoritmos de los métodos utilizados para implementar las operaciones. La fase de diseño de objetos añadirá objetos internos para la implementación y optimizará las estructuras de datos y los algoritmos. El diseño de objetos es análogo a la fase preliminar de diseño del ciclo de vida de desarrollo de software tradicional.
DISEÑO DE SISTEMAS
Se adapta el modelo al ambiente de implementación. Este paso incluye identificar e investigar las consecuencias del ambiente de implementación sobre el diseño. Aquí deben ser tomadas las decisiones de implementación estratégicas:· cómo se incorporará una base de datos en el sistema,
· qué bibliotecas de componentes se usarán y cómo,
· qué lenguajes de programación se utilizarán,
· cómo se manejarán los procesos, incluyendo comunicación y requisitos de rendimiento,
Durante el diseño se debe decidir cómo mecanismos abstractos como la asociación, serán implementados. Similarmente, si el lenguaje de programación no ofrece ninguna técnica para apoyar herencia, se debe especificar cómo ésta será implementada.
Durante el diseño de sistema se toman consideraciones en base al ambiente de implementación teniendo como objetivo lograr una buena rastreabilidad de la arquitectura de objetos al código final. Estos objetos deben ser vistos como abstracciones del código a ser escrito donde, por ejemplo, un típico objeto sería representado por un archivo en el sistema, como es el caso de Java. En otros lenguajes, como C++, en lugar de un archivo se escriben dos, uno correspondiente a la interface del objeto y el otro a su implementación. En general, el diseño de sistema incluye diversos aspectos como:
· Selección del lenguajes de programación a utilizarse, típicamente estructurados u orientados a objetos;
· Incorporación de una base de datos, típicamente relacionales, relacionales extendidos u orientados a objetos;
· Acceso a archivos, en sus diferentes formatos;
Estos aspectos pueden variar radicalmente entre uno y otro sistema y también pueden afectar de gran manera la arquitectura resultante del sistema. En general existen diversos enfoques para la incorporación del ambiente de implementación a la arquitectura del sistema:
Agregando clases abstractas o interfaces que luego serán especializadas según el ambiente de implementación particular. Esto es posible hacer, por ejemplo, cuando el lenguaje de programación, como en el caso de Java, es común a los diversos ambientes.
Instanciando objetos especializados que administren los aspectos particulares del ambiente de implementación particular. Esto puede significar una integración parcial o completa de componentes adicionales a la arquitectura del sistema. Por ejemplo, una integración con las interfaces nativas de Java (JNI) para manejo de aspectos de bajo nivel del ambiente.
Configurando múltiples versiones del sistema correspondientes a diferentes plataformas. Este es el enfoque más flexible, aunque por lo general el de mayor costo de desarrollo. Por ejemplo, cambios radicales en los lenguajes de programación incluyendo diseños para lenguajes estructurados.
INTERFACES GRÁFICAS
Las interfaces gráficas tienen como aspecto esencial que toda interacción con el usuario es a través de elementos gráficos, como lo son los botones, menús y textos. En lo que se refiere a la aplicación, todo sistema que interactúe mediante interfaces gráficas está dirigido por eventos. Estos eventos corresponden al movimiento del ratón, el oprimir o soltar uno de sus botones, el oprimir una tecla, junto con los que no son directamente iniciados por el usuario, como los eventos de desplegar una pantalla o interrumpir un programa.El desarrollar un sistema dirigido por eventos significa que la aplicación debe desde un inicio considerar un diseño adecuado.
BASES DE DATOS
El aspecto de bases de datos siempre juega un papel fundamental en los sistemas de información. La decisión estratégica más importante en nuestro contexto es si utilizar bases de datos relacionales o las orientadas a objetos. Dado su amplia utilización y la situación actual en el mercado, escogeremos para nuestro desarrollo una base de datos relacional utilizando el lenguaje SQL estándar. Simplificaremos al máximo el diseño de la base de datos para minimizar su efecto sobre el sistema completo. Más bien, demostraremos cómo es posible diseñar buenas clases que permitan en un futuro cambiar de manejadores de bases de datos.REVISIÓN DE DISEÑO
La revisión se desarrolla según la planificación para determinar si el diseño satisface los requisitos, identificar cualquier problema percibido y proponer acciones de rectificación.También es una actividad emprendida para asegurar la convivencia, adecuada y eficiencia.
El propósito de la revisión es entender y analizar con atención el diseño, es porque se debe dedicar a la revisión la mitad del tiempo en planear el diseño.
Verificación del diseño.- El auditor deberá comprobar que:
Se realiza la verificación del diseño de acuerdo con la planificación para asegurarse de los resultados del diseño cumplan con dichos requisitos de los elementos de entrada del diseño.
Validación del diseño.- El auditor deberá comprobar que:
Se realiza la validación del diseño de acuerdo con planificación para asegurarse del producto.
Control de los cambios.- Los cambios el diseño y desarrollo:
se identifican antes en su implementación del diseño, los cambios se revisan y validan del mismo.
DIAGRAMA DE SECUENCIAS DE DISEÑO
En un diagrama de secuencia ponemos varios de los objetos o clases que forman parte de nuestro programa y ponemos qué llamadas van haciendo unos a otros para realizar una tarea determinada.Hacemos un diagrama de secuencia por cada caso de uso o para una parte de un caso de uso (lo que llamo subcaso de uso). En nuestro ejemplo de ajedrez, podemos hacer diagramas de secuencia para "jugar partida" o bien para partes de "jugar partida", como puede ser "mover pieza".
El detalle del diagrama depende de la fase en la que estemos, lo que pretendamos contar con el diagrama y a quién. En una primera fase de diseño podemos poner clases grandes y ficticias, que representen un paquete/librería o, si nuestro programa está compuesto por varios ejecutables corriendo a la vez, incluso clases que representen un ejecutable.
Si estamos en una fase avanzada, estamos diseñando el programa y queremos dejar bien atados los detalles entre dos programadores, que cada uno va a programar una de las clases que participan, entonces debemos posiblemente ir al nivel de clase real de codificación y método, con parámetros y todo, de forma que los programadores tengan claro que métdos van a implementar, que deben llamar de la clase del otro, etc. Incluso si es un diagrama para presentar al cliente, podemos hacer un diagrama de secuencia en el que sólo salga el actor "jugador" y una única clase "juego ajedrez" que representa nuestro programa completo, de forma que el cliente vea qué datos y en qué orden los tiene que meter en el programa y vea qué salidas y resultados le va a dar el programa.
El siguiente puede ser un diagrama de secuencia de nuestro ejemplo del ajedrez a un nivel de diseño muy preliminar
Aquí ya hemos decidido que vamos a hacer tres librerías/paquetes, una para la interface de usuario, otra para contener el tablero y reglas del ajedrez (movimiientos válidos y demás) y otra para el algoritmo de juego del ordenador. Hemos puesto una clase representando cada uno de los paquetes y hemos representado el caso de usa "mover pieza".
En el diagrama de secuencia no se ponen situaciones erróneas (movimientos inválidos, jaques, etc) puesto que poner todos los detalles puede dar lugar a un diagrama que no se entiende o difícil de leer. El diagrama puede acompañarse con un texto en el que se detallen todas estas situaciones erróneas y particularidades. Si se quiere dejar muy claro que un determinado error se contempla, por ejemplo, un movimiento no válido por el usuario, entonces sí se puede poner en el diagrama de secuencia, siempre que no "embarulle" demasiado.
En este diagrama sencillo ya vamos dejando algunas cosas claras, como por ejemplo, que la interface de usuario hace llamadas y, por tanto, ve a los otros dos, mientras que algoritmo sólo ve al tablero/reglas. El tablero/reglas aparentemente ve a la interface de usuario, pero no nos interesa si seguimos un patrón modelo-vista-controlador, así que ese "Refresca pantalla" lo implementaremos con un patrón observador, pero eso son detalles que quizás no vienen al caso ahora.
Herramienta
CASE
(Easycase)
Es una herramienta que automatiza las fases de análisis y diseño del desarrollo de un proyecto, eliminando algunas de las tareas mas repetitivas y mecánicas. Puede usarse para formar estructuras de análisis, diseño de estructuras y modelar información y datos.
Soporta los siguientes diagramas:
• Diagrama de flujo de datos
• Diagrama de flujo de datos en tiempo real.
• Diagrama de transición de estados.
• Diagramas de estructuras.
• Diagramas de entidad relación.
• Diagramas de estructuras de datos.
• Diagramas de modelos de datos.
• Diagramas históricos de vida de entidades.
• Diagrama de estructura de datos lógicos.
EasyCase almacena todos los diagramas, registros, elementos, ficheros de texto asociados a un determinado sistema (proyecto), en un directorio propio de ese proyecto. Así se:
• Simplifica el acceso a todos los datos relativos al proyecto.
• Simplifica las uniones entre diagramas y ficheros de texto.
• Asegura la integridad de los datos.
• ((cada proyecto tiene su propio directorio de proyecto))
Forma de Trabajar:
Un proyecto consta de varios diagramas y a su vez, un diagrama esta formado por varios tipos de objetos como son:
• Símbolos.
• Conexiones
• Interfaces.
• Bloques de texto.Easy CASE como herramienta CASE
Características:
• Cubre las fases de análisis y diseño estructurado
• Permite obtener de forma rápida prototipos y sistemas de alta calidad fáciles de documentar.
Módulos:
• EasyCASE Professional
• DDMU Mantenimiento del diccionario de datos
• DBE: Easy CASE Database Engineer.
Los pasos básicos para crear un diagrama son:
• Colocar símbolos.
• Nombrar los símbolos.
Microsoft Project (o MSP)
• Añadir y nombrar conexiones.
• Definir símbolos y conexiones en el diccionario de datos.
• Establecer las relaciones con otros diagramas, registros, elementos y tablas de control.
es un software de administración de proyectos diseñado, desarrollado y comercializado por Microsoft para asistir a administradores de proyectos en el desarrollo de planes, asignación de recursos a tareas, dar seguimiento al progreso, administrar presupuesto y analizar cargas de trabajo.
http://unidad4-desarrollo-de-software-lisr.blogspot.mx/2013/05/46-herramientas-case-para-el-diseno.htm
