domingo, 19 de mayo de 2013

4.1 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 esta en como abordamos esos retos de diseño. Estudios demuest    ran que nos enfocamos en resolver los problemas de manera individual alejándonos cada vez mas 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 esta 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 que 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!!!


FUENTE; http://blog.acaddemia.com/estrategias-de-diseno/http://blog.acaddemia.com/estrategias-de-diseno/

4.2 DISEÑO ORIENTADO A OBJETOS


•    Consiste en representar un modelo de datos que pueda ser fácilmente implantable con algún lenguaje de programación orientado a objetos.
•    Los objetos son componentes potencialmente reutilizables, lo que hace que el software sea más fácil de mantener.
•    El proceso general para el diseño orientado a objetos tiene varias etapas:
1.    Comprender y definir el contexto y los modos de utilización del sistema.
2.    Diseñar la arquitectura del sistema.
Identificar los objetos principales en el sistema
4.    Desarrollar los modelos de diseño.
5.    Especificar las interfaces de los objetos.
No es un proceso sistematizado al 100%, por lo que necesita refinarse con varias iteraciones.
El primer paso consiste en identificar los tipos de relaciones definidos en el sistema, los cuales pueden ser internos y externos. Estas relaciones pueden ser dos:
El contexto del sistema: es un modelo estático que describe a los otros sistemas en ese entorno.
El modelo que el sistema utiliza: es un modelo dinámico que describe cómo interactúa el sistema con su entorno.
Con el diseño de contexto se puede crear fácilmente el diseño arquitectónico de la aplicación.
Existen diversas técnicas para identificar objetos:
•    Utilizar un análisis gramatical de la descripción en lenguaje natural de un sistema.
•    Utilizar entidades tangibles (cosas).
•    Utilizar un enfoque de comportamiento.
Utilizar un análisis basado en escenarios.
•    Existen dos tipos de modelos de diseño para describir un diseño orientado a objetos:
•    Modelos Estáticos.
•    Modelos Dinámicos.
•    Ejemplos de algunos modelos:
•    Los modelos de subsistemas
•    Los modelos de secuencia
•    Los modelos de máquinas de estado
•    La encapsulación de las clases hace que los sistemas evolucionen de forma rápida y sencilla.

Fuente: http://www.itescam.edu.mx/principal/webalumnos/sylabus/asignatura.php?clave_asig=SCC-1007&carrera=ISIC-2010-224&id_d=97http://www.itescam.edu.mx/principal/webalumnos/sylabus/asignatura.php?clave_asig=SCC-1007&carrera=ISIC-2010-224&id_d=97

4.3 DISEÑO DE SISTEMA

 El diseño de sistemas se ocupa de desarrollar las directrices propuestas durante el análisis en términos de aquella configuración que tenga más posibilidades de satisfacer los objetivos planteados tanto desde el punto de vista funcional como del no funcional (lo que antes hemos denominado constricciones).

El proceso de diseño de un sistema complejo se suele realizar de forma descendente:
• Diseño de alto nivel (o descomposición del sistema a diseñar en subsistemas menos complejos).
• Diseño e implementación de cada uno de los subsistemas:
o Especificación consistente y completa del subsistema de acuerdo con los objetivos establecidos en el análisis.
o Desarrollo según la especificación.
o Prueba.
• Integración de todos los subsistemas.
• Validación del diseño.

Dentro del proceso de diseño de sistemas hay que tener en cuenta los efectos que pueda producir la introducción del nuevo sistema sobre el entorno en el que deba funcionar, adecuando los criterios de diseño a las características del mismo. En este contexto está adquiriendo una importancia creciente la adaptación de todo sistema-producto a las capacidades de las personas que van a utilizarlo, de forma que su operación sea sencilla, cómoda, efectiva y eficiente.

De estas cuestiones se ocupa una disciplina, la ergonomía, que tiene por objeto la optimización de los entornos hombre-máquina. Si bien en un principio estaba centrada en los aspectos antropométricos de la relación hombre-máquina, en la actualidad ha pasado a intervenir con fuerza en todos los procesos cognitivos (análisis, interpretación, decisión, comunicación y representación del conocimiento).

Así, con respecto al diseño de herramientas software, la ergonomía tiene mucho que decir en cuestiones relacionadas con la disposición de informaciones en pantalla, profundidad de menús, formato de iconos, nombres de comandos, control de cursores, tiempos de respuesta, manejo de errores, estructuras de datos, utilización de lenguaje natural, etc.

FUENTE: http://eduardoummma.galeon.com/cvitae1770704.htmlhttp://eduardoummma.galeon.com/cvitae1770704.html

4.4 REVISION DEL DISEÑO

Según la IEEE 610.12, una revisión es un proceso o reunión durante la cual un producto de trabajo, un conjunto de productos de trabajo o la evidencia de la ejecución de un proceso se presenta al equipo del proyecto, a los administradores, usuarios, clientes u otras partes interesadas para su comentario o aprobación.

Las revisiones al diseño de los productos de software se realizan por demanda con el objetivo de detectar e identificar no conformidades en el diseño antes de pasar a la codificación, así como también identificar aspectos de mejoramiento. Entre otros, en esta actividad se verifica la arquitectura y utilización de patrones en el diseño.

FUENTE: http://www.greensqa.com/portal/index.php/soluciones/calidad-de-productos/49-revisiones-de-diseno-

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.

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. 
•    Será necesario mantener registros.
Explicación:
Revisión de diseño y desarrollo:
Mantenga los datos de registro de las reuniones de revisión del proyecto. Estas reuniones deberían realizarse según el plan del proyecto.
Deberían tener lugar, como mínimo, con la frecuencia definida en su plan, o más a menudo. Su plan debería indicar quién debe participar en las reuniones de revisión del proyecto.
Estas “reuniones” pueden ser encuentros formales, e-mails, conferencias telefónicas u otros medios de comunicación del grupo.
Una checklist de las reuniones de revisión y sus respectivas fechas, con las actas adjuntas, sirve para coordinar esta parte de los requisitos.
http://www.normas9000.com/iso-9000-37.htmlhttp://www.normas9000.com/iso-9000-37.html

4.5 DIAGRAMA DE SECUENCIAS DEL DISEÑO

La fase de diseño (y los modelos UML resultantes) expande y detalla los modelos de análisis tomando en cuenta todas las implicaciones y restricciones técnicas. El propósito del diseño es especificar una solución que trabaje y pueda ser fácilmente convertida en código fuente y construir una arquitectura simple y fácilmente extensible. Las clases definidas en el análisis fueron detalladas, y se añadieron nuevas clases para manejar áreas técnicas como base de datos, interfaz del usuario, comunicación, dispositivos, etc.

Diagrama de secuencia

Los casos de uso deben ser realizados durante esta etapa. Para describir el comportamiento dinámico del sistema, cualquiera de los diagramas de interacción del UML pueden ser utilizados. Debido a que Rational Rose no soporta los diagramas de actividad y ofrece soporte limitado para los diagramas de colaboración (en notación completa del UML) usaremos diagramas de secuencia.





4.6 HERRAMIENTAS CASE PARA EL DISEÑO


HERRAMIENTAS CASE
 
 
Concepto de las herramientas CASE
 
La herramienta CASE (Computer-Aided Systems Engineering ) cuyo significado en español es ingeniería de sistemas asistida por ordenador, es la aplicación de tecnología informática a las actividades, las técnicas y las metodologías propias de desarrollo de sistemas y al igual que las herramientas CAD (Diseño Asistido por Computadora) o CAM (Manufactura Asistida por Computadora) su objetivo es acelerar el proceso para el que han sido diseñadas, en el caso de CASE para automatizar o apoyar una o mas fases del ciclo de vida del desarrollo de sistemas. La primera herramienta CASE como hoy la conocemos fue Excelerator en 1984, era para PC. Actualmente la oferta de herramientas CASE es muy amplia y tenemos por ejemplo el EASYCASE o WINPROJECT.
 
Tecnología de las herramientas CASE
 
La tecnología CASE supone la automatización del desarrollo del software, contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de información. Para mejorar la calidad y la productividad de los sistemas de información a la hora de construir software se plantean los siguientes objetivos :
  • Permitir la aplicación práctica de metodologías estructuradas, las cuales al ser realizadas con una herramienta conseguimos agilizar el trabajo.
  • Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones.
  • Simplificar el mantenimiento de los programas.
  • Mejorar y estandarizar la documentación.
  • Aumentar la portabilidad de las aplicaciones.
  • Facilitar la reutilización de componentes software.
  • Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilización de gráficos.
Componentes de una herramienta CASE
De una forma esquemática podemos decir que una herramienta CASE se compone de los siguientes elementos:
  • Repositorio (diccionario) donde se almacenan los elementos definidos o creados por la herramienta, y cuya gestión se realiza mediante el apoyo de un Sistema de Gestión de Base de Datos (SGBD) o de un sistema de gestión de ficheros.
  • Metamodelo (no siempre visible), que constituye el marco para la definición de las técnicas y metodologías soportadas por la herramienta.
  • Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez, alimentar otros sistemas. Este elemento proporciona así un medio de comunicación con otras herramientas.
  • Comprobación de errores, facilidades que permiten llevar a cabo un análisis de la exactitud, integridad y consistencia de los esquemas generados por la herramienta.
  • Interfaz de usuario, que constará de editores de texto y herramientas de diseño gráfico que permitan, mediante la utilización de un sistema de ventanas, iconos y menús, con la ayuda del ratón, definir los diagramas, matrices, etc. que incluyen las distintas metodologías.
Estructura general de una herramienta CASE
La estructura CASE se basa en la siguiente terminología :
  • CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases finales o superiores del ciclo de vida del desarrollo de sistemas como la planificación de sistemas, el análisis de sistemas y el diseño de sistemas.
  • CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida como el diseño detallado de sistemas, la implantación de sistemas y el soporte de sistemas.
  • CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen actividades como la gestión de proyectos y la estimación.
 
Futuro de las Herramientas CASE
 
Las herramientas CASE evolucionan hacia tres tipos de integración:
  1. La integración de datos permite disponer de herramientas CASE con diferentes estructuras de diccionarios locales para el intercambio de datos.
  2. La integración de presentación confiere a todas las herramientas CASE el mismo aspecto.
  3. La integración de herramientas permite disponer de herramientas CASE capaces de invocar a otra herramienta CASE de forma automática.
Clasificación de programas de herramientas CASE
de acuerdo a su aplicación y fabricante.
Ada
Analysis
Back-end
Benchmarking
C++
Cartography
Client/server
COBOL
Code generation
Cooperative processing
CORBA
CORBA IDL
Debugging
Development environment for embedded systems
Distributed systems
Embedded real time systems
Formal object oriented requirements
FORTRAN
FORTRAN
Front -end
I-CASE
Informix 4GL
Java
Macintosh
Open source
ORACLE
Parallel programming
Porting Unix programs to Windows NT
Smalltalk
SQL code generation
UML