DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN

INGENIERIA EN SISTEMAS COMPUTACIONALES

INVESTIGACION DE LA UNIDAD 2 - DISEÑO
INGENIERIA DE SOFTWARE
PROFESORA: MARIA GUADALUPE
Introducción

El diseño de software, es una de las etapas que deben componer el ciclo de vida
del software, casi de una forma obligatoria, aunque algunas metodologías no le den
la importancia que requiere.

Básicamente, después de haber analizado a mano y papel los requisitos que se

tienen para nuestro sistema a desarrollar, es entonces cuando entra en juego el
diseño de software. Su objetivo será armar el cascarón bajo el cual se estará
implementando el código o realizando la programación. Pues no puedes empezar a
programar en el aire sin saber hacia dónde va tu software.

Para definir el diseño de software con una sola palabra, posiblemente Calidad sea
la indicada. Pues si realmente deseas tener un software que supere básicamente
cualquier error y que esté hecho a la perfección como el cliente le pide, el diseño de
software es fundamental. Pues en él, estaremos analizando cada una de las
especificaciones solicitadas por el cliente, además estaremos seccionando el
software, viendo sus funciones, como se mostrará en pantalla y muchas cosas más
que conlleva el diseño de software, por si pensabas que era una etapa sencilla y
que no tendría complejidad alguna.
2.1 Diseño de procesos propuestos

El Proceso para el desarrollo de software, también denominado ciclo de vida del

desarrollo de software es una estructura aplicada al desarrollo de un producto de
software. Hay varios modelos a seguir para el establecimiento de un proceso para
el desarrollo de software, cada uno de los cuales describe un enfoque diferente para
diferentes actividades que tienen lugar durante el proceso. Algunos autores
consideran un modelo de ciclo de vida un término más general que un determinado
proceso para el desarrollo de software. Por ejemplo, hay varios procesos de
desarrollo de software específicos que se ajustan a un modelo de ciclo de vida de
espiral.

La gran cantidad de organizaciones de desarrollo de software implementan

metodologías para el proceso de desarrollo. Muchas de estas organizaciones
pertenecen a la industria armamentística, que en los Estados Unidos necesita un
certificado basado en su modelo de procesos para poder obtener un contrato.

El estándar internacional que regula el método de selección, implementación y

monitoreo del ciclo de vida del software es ISO 12207.

Durante décadas se ha perseguido la meta de encontrar procesos reproducibles y

predecibles que mejoren la productividad y la calidad. Algunas de estas soluciones
intentan sistematizar o formalizar la aparentemente desorganizada tarea de
desarrollar software. Otros aplican técnicas de gestión de proyectos para la creación
del software. Sin una gestión del proyecto, los proyectos de software corren el riesgo
de demorarse o consumir un presupuesto mayor que el planeado. Dada la cantidad
de proyectos de software que no cumplen sus metas en términos de funcionalidad,
costes o tiempo de entrega, una gestión de proyectos efectiva es algo
imprescindible.

Algunas organizaciones crean un grupo propio (Software Engineering Process

Group, abreviado SEPG) encargado de mejorar los procesos para el desarrollo de
software en la organización.
2.1.1 Herramientas CASE para diseño

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.

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

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.

Las herramientas CASE evolucionan hacia tres tipos de integración:

La integración de datos permite disponer de herramientas CASE con diferentes

estructuras de diccionarios locales para el intercambio de datos.

La integración de presentación confiere a todas las herramientas CASE el mismo

aspecto.

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

 Ada-Assured (GrammaTech, Inc.)

 AdaTEST (Information Processing Ltd.)

 Design Maintenance System [DMS] (Semantic Designs, Inc.)

 Tau Logiscope (Telelogic AB)

 Understand for Ada (Scientific Toolworks, Inc.)

 Cradle (3SL)

Analysis

 case/4/0 (microTOOL GmbH)

 objectiF (microTOOL GmbH)

  ProxyDesigner (ProxySource.com)

 Cradle (3SL)

 DataManager/ControlManager (Allen Systems Group, Inc.)

 GDPro (Advanced Software Technologies, Inc.)

 ManagerView (Allen Systems Group, Inc.)

 objectIF (Computer Systems for Business International Eastern Europe Ltd.)

 PacDesign (CGI Systems, Inc.)

 Principia/SSADM (British Aerospace Ltd. Software Tools Group)

 StP/UML (Aonix)

 Vista (Allen Systems Group, Inc.)

Back-end

 Application Factory (Cortex Corp.)

 DesignMachine 2.0 (Optima, Inc.)

 DesignVision 1.7 (Optima, Inc.)

 Objectworks\C++ (ParcPlace Systmems)

 Objectworks\Smalltalk (ParcPlace Systmems)

 Panorama C/C++ (International Software Automation, Inc.)

 HIBOL (Matterhorn, Inc.)

 Life Cycle Productivity System (American Management Systems, Inc.)

 Maestro (Softlab, Inc.)

 ProMod Series (ProMod, Inc.)

  SuperCase (Advanced Technology International, Inc.)

Benchmarking

 SQLBench Workbench (SQLBench International)

 TestWeb (Eastern Systems Inc.)

C++

 Cantata++ (Information Processing Ltd.)

 case/4/0 (microTOOL GmbH)

 Design Maintenance System [DMS] (Semantic Designs, Inc.)

 INNOVATOR CASE Workbench for Object Orientation (MID GmbH)

 Objecteering (Softeam)

 objectiF (microTOOL GmbH)

 Panorama OO-Browser (International Software Automation, Inc.)

 Panorama OO-Playback (International Software Automation, Inc.)

 QAC++ (Programming Research Inc.)

 Resource Standard Metrics (M Squared Technologies)

 SourcePublisher C++ (Scientific Toolworks, Inc.)

 Tau Logiscope (Telelogic AB)

 Understand for C++ (Scientific Toolworks, Inc.)

 Visual Classworks (Step Ahead Software)

 BX (Integrated Computer Solutions)

  Code Navigator for C++ (Quintessoft Engineering, Inc.)

 Cradle (3SL)

 Enterprise Architect 3.10 (Sparx Systems)

 GDPro (Advanced Software Technologies, Inc.)

 Glg Toolkit (Generic Logic, Inc.)

 StP/ClassCapture (Aonix)

 StP/UML (Aonix)

 Texel-sf (ISDE Metasoft Ltd.)

 Texel-sf (VSF NA Inc.)

 ViewKit (Integrated Computer Solutions)

Cartography

 Amarco Tools (Sysoft SA)

Client/server

 NETRON/Catalyst (Netron, Inc.)

 SQA Suite (Eastern Systems Inc.)

 Kappa ; renamed to PowerModel (IntelliCorp)

 Cradle (3SL)

 NETRON/Connect (Netron, Inc.)

 PowerModel (IntelliCorp)

 TestWeb (Eastern Systems Inc.)

COBOL
  case/4/0 (microTOOL GmbH)

 Design Maintenance System [DMS] (Semantic Designs, Inc.)

 Test Coverage (Semantic Designs, Inc.)

 CoFac (Coding Factory)

 DB-MAIN (University of Namur Computer Sciences Department)

 MAGEC (MAGEC Software)

Code generation

 Select Enterprise (Princeton Softech)

 Visual Classworks (Step Ahead Software)

 BridgePoint Generator (Project Technology, Inc.)

 BW*Wizard (Bridgewater Consultants, Inc)

 CASE Studio 2 (CHARONWARE s.r.o.)

 CoFac (Coding Factory)

 Cradle (3SL)

 Enterprise Architect 3.10 (Sparx Systems)

 GDPro (Advanced Software Technologies, Inc.)

 SILDEX (TNI)

 StP/ACD (Aonix)

 Texel-sf (ISDE Metasoft Ltd.)

 Texel-sf (VSF NA Inc.)

 XpertGen (Attar Software Limited)

Cooperative processing

 FOUNDATION (Accenture)

CORBA

 objectiF (microTOOL GmbH)

 SilkPilot (Segue Software, Inc.)

CORBA IDL

 INNOVATOR CASE Workbench for Object Orientation (MID GmbH)

Debugging

 xSlice (Bellcore)

Development environment for embedded systems

 VADS (Rational Software Corporation)

Distributed systems

 Wilde (Wilde Technologies)

Embedded real time systems

 EventStudio 1.0 (EventHelix.com Inc.)

 ReaGeniX Programmer (OBP Research Oy)

 GOOFEE Diagrammer (GOOFEE Systems Pty Ltd)

Formal object oriented requirements

 Clyder (Sema Group)

FORTRAN
  Design Maintenance System [DMS] (Semantic Designs, Inc.)

 Tau Logiscope (Telelogic AB)

FORTRAN

 Understand for FORTRAN (Scientific Toolworks, Inc.)

Front -end

 Analyst/RT (Mentor Graphics Corp.)

 Application Factory (Cortex Corp.)

 Auditor (Mentor Graphics Corp.)

 Checkpoint (Software Productivity Research, Inc.)

 CorVision (Cortex Corp.)

 Designer (Mentor Graphics Corp.)

 DesignMachine 2.0 (Optima, Inc.)

 DesignVision 1.7 (Optima, Inc.)

 Principia (British Aerospace Ltd. Software Tools Group)

 PSL/PSA (Meta Systems)

 QuickSpec (Meta Systems)

 Report Specification Interface (Meta Systems)

 SPQR/20 (Software Productivity Research, Inc.)

 Structured Architect (Meta Systems)

 Structured Architect-Integrator (Meta Systems)

 TurboCASE 3.0 (StructSoft, Inc.)

  View Integration System (Meta Systems)

 vsDesigner (Visual Software, Inc.)

 vsObject Maker (Visual Software, Inc.)

 vsSQL (Visual Software, Inc.)

 Analyst/Designer Toolkit (Yourdon, Inc.)

 Design Generator (Computer Sciences Corp)

 KangaTool Series (Institute for Information Industry)

 Life Cycle Productivity System (American Management Systems, Inc.)

 MacBubbles (StarSys, Inc.)

 Maestro (Softlab, Inc.)

 Multi/CAM (AGS Management Systems, Inc.)

 OpenSELECT CASE (Meridian Software Systems, Inc.)

 Principia/SSADM (British Aerospace Ltd. Software Tools Group)

 ProMod Series (ProMod, Inc.)

 Software through Pictures (Aonix)

 SYLVA Series (The CADWARE Group, Ltd)

I-CASE

 Pacbase (CGI Systems, Inc.)

 RIDL* (IntelliBase nv/sa)

Informix 4GL

 FourGen CASE Tools (Gillani, Inc.)

  FourGen iDesktop (Gillani, Inc.)

 FourGen Menu's (Gillani, Inc.)

 FourGen Report Generator (Gillani, Inc.)

 FourGen Screen Generator (Gillani, Inc.)

 GOOEY (LTG, Inc.)

Java

 case/4/0 (microTOOL GmbH)

 Design Maintenance System [DMS] (Semantic Designs, Inc.)

 HOW (Riverton Software)

 INNOVATOR CASE Workbench for Object Orientation (MID GmbH)

 Objecteering (Softeam)

 objectiF (microTOOL GmbH)

 Resource Standard Metrics (M Squared Technologies)

 Test Coverage (Semantic Designs, Inc.)

 BW*Wizard (Bridgewater Consultants, Inc)

 BX (Integrated Computer Solutions)

 Enterprise Architect 3.10 (Sparx Systems)

 Glg Toolkit (Generic Logic, Inc.)

 JVISION (Object Insight, Inc.)

 StP/UML (Aonix)

 Elixir IDE (Elixir Technology Pte Ltd)

  JClass (KL Group Inc.)

 JClass BWT (KL Group Inc.)

 JClass Chart (KL Group Inc.)

 JClass LiveTable (KL Group Inc.)

 Glg Toolkit for Java (Generic Logic, Inc.)

Macintosh

 Object Plant (Midius Art&Science)

 MacA&D (Excel Software)

 QuickCRC (Excel Software)

Open source

 Codestriker (Sitsky, David)

 CCCC (Littlefair, Tim)

ORACLE

 case/4/0 (microTOOL GmbH)

 CASE Studio 2 (CHARONWARE s.r.o.)

Parallel programming

 Parallel Language for Symbolic Expression [PARLANSE] (Semantic Designs,

Inc.)

Porting Unix programs to Windows NT

 NuTCRACKER (DataFocus Incorporated)

Smalltalk

 INNOVATOR CASE Workbench for Object Orientation (MID GmbH)

  StP/ClassCapture (Aonix)

SQL code generation

 objectiF (microTOOL GmbH)

 SSADM4+sf (ISDE Metasoft Ltd.)

 SSADM4+sf (VSF NA Inc.)

UML

 DES OSD tool (LG Soft Lab)

 HAT (E2S)

 INNOVATOR Business Workbench for Business Process Engineering (MID

GmbH)

 INNOVATOR CASE Workbench for Object Orientation (MID GmbH)

 iUML (Kennedy Carter Ltd.)

 Object Plant (Midius Art&Science)

 Objecteering (Softeam)

 ObjectGEODE (Telelogic AB)

 objectiF (microTOOL GmbH)

 ProxyDesigner (ProxySource.com)

 Select Enterprise (Princeton Softech)

 Together ControlCenter (Borland, Inc.)

 Visual Paradigm for UML (Visual Paradigm)

 ARTiSAN Real-time Studio (ARTiSAN Software Tools)

 Cradle (3SL)
 Enterprise Architect 3.10 (Sparx Systems)

 GDPro (Advanced Software Technologies, Inc.)

 MagicDraw UML (No Magic, Inc.)

 MEGA Development (MEGA International)

 Object Technology Workbench (OTW Software, Inc.)

 Object Technology Workbench (OWiS Software GmbH)

 OEW 3.0 for C++ and Java (Innovative Software)

 SmartDraw (SmartDraw.com)

 StP/UML (Aonix)

 Visual Case (Artiso Corp)

 Wilde (Wilde Technologies)

2.2 Diseño arquitectónico

Para la transformación del modelo de análisis en un modelo de diseño

del sistema, se definen los objetivos de diseño del proyecto, se
descompone el sistema en subsistemas más pequeños que pueden
ser realizados por diferentes equipos y se seleccionan estrategias para
la construcción del sistema como elegir la plataforma de hardware y
software en la que se ejecutará, el formato y el sistema de
almacenamiento de datos persistentes, la arquitectura estructural , el
flujo de control global o la política de control de acceso e interfaz…

El modelo de diseño:

Descripción clara de las estrategias.

Descomposición en subsistemas.

Diagramas que muestran la

correspondencia entre
hardware y software.

Modelo de objetos que

describe la realización física
de los casos de uso.

Muestra el impacto en el sistema de requisitos

funcionales, no funcionales y restricciones.

Sirve de abstracción de la implementación del sistema,

convirtiéndose en la entrada fundamental de las actividades de
implementación.
Ventajas del modelo de diseño:

Reutilización a gran escala: posibilidad de tener partes ya hechas del

sistema.

Gestión de la complejidad: descomposición del problema.

Herramienta de comunicación entre los participantes.

Análisis más detallado del sistema.

Calidad y Diseño del software.

Un diseño de calidad proporciona representaciones del software en las que se

puede evaluar la calidad del mismo, permite una “traducción” correcta de
los requisitos en un programa y sirve como fundamento para las
actividades posteriores (implementación, prueba y mantenimiento).

Sin diseño se corre el riesgo de construir un sistema inestable, no escalable y

difícil de probar. Por norma general la falta de diseño provoca grandes
dificultades en la gestión del proyecto y aumenta considerablemente el tiempo
que se dedica a las pruebas.

El resultado de un proyecto sin diseño es la construcción de un sistema poco

fiable que se escapa al control de sus creadores y que por lo tanto es difícil de
corregir y mejorar, sistemas ineficientes que no optimizan los recursos y que
posiblemente no se ajusten ni a las necesidades del cliente ni a las condiciones
económico-temporales del proyecto.
Los sistemas sin un diseño de calidad suelen ser poco flexibles y por lo tanto
difíciles de mantener, hasta un 70% del coste del proyecto se puede llegar a
emplear en el mantenimiento del sistema.

Diseño Arquitectónico.

Los grandes sistemas siempre se

descomponen en subsistemas que
proporcionan conjuntos de servicios
relacionados.

El proceso de diseño inicial que

identifica estos subsistemas y establece
como se lleva a cabo su control y
comunicación se llama diseño
arquitectónico.

Las actividades principales del Diseño

arquitectónico son decisiones:

Estructuración del sistema en varios subsistemas principales.

Descomposición modular donde cada subsistema se divide en

componentes o módulos interconectados.

Modelado del control o estructuración de un plan de control para la

ejecución del sistema por partes.
 El diseño arquitectónico construye una salida que no es otra cosa que
una serie de documentos con diversas perspectivas de la arquitectura
del sistema:

Modelo estructural estático. Describe subsistemas o

componentes a desarrollar como unidades separadas.

Modelo de proceso dinámico. Describe la

organización del sistema en tiempo de ejecución.

Modelo de interfaz. Describe la definición de los

servicios ofrecidos por cada subsistema a través de
su interfaz pública.

Modelos de relación. Describe las relaciones

entre los distintos módulos o subsistemas, por
ejemplo: los flujos de datos entre subsistemas.

Modelo de distribución. Describe como se distribuyen

los subsistemas entre los componentes físicos
(computadores, nodos de red…).
2.3 Diseño de datos

El diseño de datos es la primera de las tres actividades de diseño, los datos bien
diseñados pueden conducir a una mejor estructura de programa, a una modularidad
efectiva y a una complejidad procedimental reducida. Por ejemplo: La utilización de
una lista enlazada multicircular puede satisfacer los requisitos de datos, pero puede
también conducir a un diseño de software difícil de manejar. Una organización o
estructura de datos alterna puede llevar a mejores resultados.

PRINCIPIOS PARA EL DISEÑO DE DATOS.

1.- Deben identificarse todas las estructuras de datos y las operaciones que se han
de realizar sobre cada una de ellas.

2.- Debe establecerse y usarse un diccionario de datos para definir el diseño de los
datos del programa.

3.- El diseño de datos de bajo nivel debe realizarse hasta el diseño detallado.

4.- El lenguaje de programación debe soportar la especificación y la realización de

tipos abstractos de datos.

El diseño de datos consiste en descubrir y la definir completamente de los procesos

y características de los datos de la aplicación. El diseño de datos es un proceso de
perfeccionamiento gradual que abarca desde la cuestión más elemental, "¿Qué
datos requiere la aplicación?", hasta los procesos y estructuras de datos precisos
que proporcionan dichos datos. Si el diseño de datos es bueno, el acceso a los
datos de la aplicación será rápido y fácil de mantener, y podrá aceptar sin problemas
las futuras mejoras de los datos.

El proceso de diseño de datos incluye la identificación de los mismos, la definición

de tipos de datos y mecanismos de almacenamiento concretos, y la tarea de
garantizar la integridad de los datos mediante el uso de reglas de empresa y otros
mecanismos de exigencia en tiempo de ejecución.
Esta sección no constituye una metodología formal para modelar datos, aunque
utiliza terminología relacional. Más bien, presenta algunos conceptos y procesos
que surgen normalmente durante el diseño de los datos de la aplicación.

Este tema no realiza suposiciones sobre la tecnología ocasional de almacenamiento

de datos utilizada para almacenar y recuperar los datos de la aplicación. Después
de todo, no siempre se puede determinar con precisión, al principio del diseño de
una aplicación, cómo y cuándo se van a almacenar los datos exactamente. Aunque
la mayoría de las metodologías formales de modelado de datos prevén el uso de un
motor de base de datos relacional, una aplicación empresarial tiene muchas
opciones para almacenar los datos, incluidos los archivos relacionales, jerárquicos
de gran sistema y VSAM, los archivos AS/400, y otras muchas estructuras de datos
distribuidas de archivos.

En las siguientes secciones encontrará información sobre algunos conceptos

generales de gran utilidad para el diseño de datos de empresa.

Diseño de datos: representación de estructuras de datos a las que se tiene acceso

por medio de los componentes

Diseño

Anteriormente se mencionó que la etapa de diseño es cuando se traducen los

requerimientos funcionales y no funcionales en una representación de software. El
diseño es el primer paso en la fase de desarrollo de cualquier producto o sistema
de ingeniería. De acuerdo con Pressman, el objetivo del diseño es producir un
modelo o representación de una entidad que se va a construir posteriormente
[PRR98].

De acuerdo con McGlaughlin [MCG91], hay tres características que sirven como
parámetros generales para la evaluación de un buen diseño. Estos parámetros son
los siguientes:
El diseño debe implementar todos los requisitos explícitos obtenidos en la etapa de
análisis.

El diseño debe ser una guía que puedan leer y entender los que construyen el
código y los que prueban y mantienen el software.

El diseño debe proporcionar una idea completa de lo que es el software.

En la sección siguiente se establecen tipos diferentes de diseño que la etapa de

diseño del proceso de ingeniería de software produce.

Diseño del Software

El diseño del software desarrolla un modelo de instrumentación o implantación

basado en los modelos conceptuales desarrollados durante el análisis del sistema.
Implica diseñar la decisión sobre la distribución de datos y procesos [MAJO97].

El diseño es la primera de las tres actividades técnicas que implica un proceso de

ingeniería de software; estas etapas son diseño, codificación (en el caso de este
proyecto Desarrollo e Implementación) y pruebas. Generalmente la fase de diseño
produce un diseño de datos, un diseño arquitectónico, un diseño de interfaz, y un
diseño procedimental [PRR98].

El diseño de datos esencialmente se encarga de transformar el modelo de dominio

de la información creado durante el análisis [PRR98].

En el caso particular de este proyecto el diseño de datos no juega un papel

determinante dado que la herramienta de software propuesta, de la manera en que
será físicamente desarrollada e implementada, no requiere de estructuras de datos
complejas, ni de un esquema de base de datos por ejemplo.

En el diseño arquitectónico se definen las relaciones entre los principales elementos

estructurales del programa [PRR98]. Para una herramienta de software basada en
el desarrollo e implementación de ambientes virtuales éste es un aspecto
fundamental dado que en esta representación del diseño se establece la estructura
modular del software que se desarrolla. Dado que este proyecto pretende proponer
una metodología de tratamiento al trastorno de lateralidad y ubicación espacial a
través de Realidad Virtual, la codificación y generación de ambientes y entornos
virtuales es esencial. Cuando se utiliza VRML 2.0 es necesario codificar cada una
de las instrucciones que crearán un objeto determinado con sus propias
características y atributos. Si se pretendiera codificar por completo toda una escena
virtual dentro de un mismo archivo, el archivo crecería superlativamente y su
manipulación, adaptación, y mantenimiento se volverían tareas bastante complejas
e incomodas.

Afortunadamente, a través del nodo Inline de la especificación 2.0 de VRML puede

darse un alto nivel de modularidad a los mundos virtuales dado que cada objeto
puede describirse o codificarse por separado, para posteriormente ser referenciado
dentro de la escena virtual contenedora. El nodo Inline se detalla en el capítulo
siguiente.

El diseño de interfaz describe cómo se comunica el software consigo mismo, con

los sistemas que operan con él, y con los operadores que lo emplean [PRR98]. En
el caso de la herramienta de software propuesta por este estudio la interfaz del
software consigo mismo se lleva a cabo de 2 maneras:

Nodos de VRML 2.0 se comunican con otro nodos

Nodos que se comunican con Scripts de comportamiento descritos en Java o en

JavaScript.

Es diseñado específicamente para integrarse a la plataforma de Internet. Es por

este que para los fines de este proyecto se antoja lógico el desarrollar la interfaz
con los operadores del software a través de HTML, VRML, JavaScript, o cualquier
otra tecnología que puede incorporarse a las especificaciones de esta plataforma.
De acuerdo con Pressman, el diseño procedural transforma elementos estructurales
de la arquitectura del programa en una descripción procedural de los componentes
del software [PRR98].
2.4 Diseño de interfaz de usuario

El tema de las interfaces hombre máquina se han configurado como una de las
áreas de investigación críticas para el desarrollo de la sociedad de la información.
No en vano, la interfaz de usuario regula la interacción entre ambos elementos del
sistema.

Esta interfaz tiene que ser amigable, la amigabilidad se refiere a su facilidad de uso.
Esa facilidad de uso es relativa al tipo de usuario; pero de una manera general
podemos decir que una interfaz es tanto más amigable cuanto más fácil de usar
resulta para una mayor proporción de usuarios de una población dada. Esta
facilidad de uso está muy relacionada con otro concepto, el de interactividad. Una
interfaz es interactiva si dialoga con el usuario, si le proporciona feedback
comunicativo.

El diseño de la interacción toma prestados muchos conceptos y modelos de las

disciplinas de ergonomía, semiótica, inteligencia artificial, ciencia cognitiva y teatro.

La interfaz de usuario es un medio de comunicación entre una persona usuaria de

un sistema informático y este último, refiriéndose, en particular, al empleo de los
dispositivos de entrada/salida con software de soporte. Entre los ejemplos se
pueden citar el uso de un ratón con gráficos en mapa de bits y la utilización de
ventanas.

Del diseño de la interfaz de usuario al diseño de la interfaz gráfica de usuario:

diseño de la interacción.

El diseño para el Web es diferente del diseño tradicional de interfaces de usuario

(IU) para software; principalmente porque el diseñador de Web tiene que dar el
control y compartir la IU con los usuarios y con el software/hardware del cliente.
También hay similitudes entre ambos diseños: al nivel más básico, ambos sistemas
son interactivos, son diseños de software y no son diseños de objetos físicos. En el
diseño tradicional de una interface gráfica de usuario (GUI – graphic user interface),
se puede controlar cada píxel de la pantalla: cómo presentar una caja de diálogo,
para que en todas las pantallas de los usuarios sean exactamente la misma. Se
sabe para qué sistema se está diseñando, las fuentes de las letras que están
instaladas, el tamaño de la pantalla, y se tiene la guía de estilo del vendedor que
nos dice las reglas para combinar las distintas interacciones. En el Web, todos estos
supuestos fallan. Los usuarios pueden acceder al Web con ordenadores, una gran
variedad, pero también podrían acceder usuando WebTV, teléfonos con tecnología
WAP (Wireless Application Protocol), o UMTS (Universal Mobile
Telecommunications System). En el diseño tradicional, la diferencia de tamaño de
pantalla entre un ordenador personal y una workstation tiene un factor 6. En el Web,
encontramos un factor 100 entre las pantallas de lo teléfonos móviles y las
workstations, y un factor 1000 en el ancho de banda entre los modems y conexiones
T-3.

Cualquier diseño Web parecerá muy diferente en cada uno de estos dispositivos:
claramente el WYSIWYG (lo que ves es lo que obtienes) está muerto. Cuanto más
especializado sea el dispositivo o cuanto más baja sea su gama (un PC386, por
ejemplo), más estrictos serán los requerimientos para el Web. La única manera de
hacer esto es que los diseñadores den el control y que dejen que la presentación
de sus páginas sea determinada por un conjunto de especificaciones de página y
de preferencias en el dispositivo del cliente.

Hacer un diseño de interface de usuario diferente para cada plataforma es bastante

complicado. Es recomendable separar significado y presentación y usar hojas de
estilo para especificar la presentación, pero haciendo más hincapié en el contenido
informacional que en las interacciones. El diseño satisfactorio de cualquier tipo de
interacción para el medio informático requiere equilibrar la viabilidad tecnológica con
la integridad del contenido.
Un buen elemento de interacción tiene una construcción invisible y una interfaz
gráfica de usuario eficaz. Un diseñador debe integrar el diseño de la interacción en
una estructura de contenido; sin contenido, el diseño de la interacción es sólo un
desfile de formas parpadeantes.

Una interfaz gráfica de usuario (GUI), es donde coinciden el diseño de la interacción

y el de la interfaz. Una interfaz es sólo la manifestación visual de "inter" actividades;
sólo es un aspecto del diseño de interacción, no el mismo diseño de la interacción.

Objetivos cambiantes

Una interfaz gráfica de usuario puede ser tan simple como un icono que parpadee
o tan compleja como unos grandes almacenes en Internet. En un diseño tradicional
de GUI, el diseñador puede controlar todas las peticiones del usuario. Puede
deshabilitar opciones de los menús en el estado actual, decolorándolas- si
aparecen con letra oscura, se ponen en gris claro-, y puede mostrar una ventana de
diálogo para que el usuario conteste cuestiones. En el Web, el usuario controla su
navegación por las páginas. Puede tomar “caminos” no previstos por el diseñador:
por ejemplo, pueden “saltar” a cualquier página de un sitio web desde un motor de
búsqueda sin haber pasado por la página principal.

Los diseñadores de Webs necesitan acomodarse a la navegación controlada por

los usuarios. Por supuesto, se puede forzar a los usuarios a pasar por ciertas
páginas, antes de acceder a otras. Por ejemplo, antes de descargar un programa
se puede obligar al usuario a registrarse. Pero, para evitar esa sensación de
dominio, es mejor diseñarlo con libertad de movimientos y, por ejemplo, poner un
logotipo (unido a la página principal) en cada página que proporciona el contexto y
navegación a los usuarios que han entrado al sitio web en cualquier página del
mismo.
Bibliografías

http://unidad4-desarrollo-de-software-lisr.blogspot.mx/2013/05/46-herramientas-
case-para-el-diseno.html

https://www.fing.edu.uy/tecnoinf/mvd/cursos/ingsoft/material/teorico/is06-
DisenioIU.pdf

https://www.ecured.cu/Dise%C3%B1o_de_Interfaces_de_Usuario

https://eseida.wikispaces.com/file/view/Tema+4++Dise%C3%B1o+Arquitect%C3%
B3nico.pdf

https://es.slideshare.net/jpbthames/diseo-arquitectnico-9443843

http://www.monografias.com/trabajos102/ingenieria-del-software/ingenieria-del-
software.shtml