Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Unidad 2 Diseno
Unidad 2 Diseno
Equipo 1
INTEGRANTES:
- Manuel Alfredo Gómez Zepeda
- Juan Daniel Asís Ortega
- Demetrio García Zuñiga
- Óscar Fernando López Hernández
PROFESOR:
- Marco Antonio Vázquez Romero
Fecha de entrega:
18/Septiembre/2017
Índice
Introducción ......................................................................................................................................................... 3
2.1 Diseño de procesos propuestos ..................................................................................................................... 4
2.1.1 Herramientas CASE para diseño .................................................................................................................. 5
2.2 Diseño arquitectónico ..................................................................................................................................16
2.3 Diseño de datos ............................................................................................................................................19
2.4 Diseño de interfaz de usuario .......................................................................................................................22
Comentarios y Conclusiones...............................................................................................................................24
Bibliografías ........................................................................................................................................................24
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.
De una forma esquemática podemos decir que una herramienta CASE se compone de los
siguientes elementos:
Metamodelo (no siempre visible), que constituye el marco para la definición de las técnicas
y metodologías soportadas por la herramienta.
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.
Ada
Cradle (3SL)
Analysis
ProxyDesigner (ProxySource.com)
Cradle (3SL)
StP/UML (Aonix)
Back-end
C++
Objecteering (Softeam)
Cradle (3SL)
StP/ClassCapture (Aonix)
StP/UML (Aonix)
Cartography
Client/server
Cradle (3SL)
PowerModel (IntelliCorp)
COBOL
Code generation
Cradle (3SL)
Enterprise Architect 3.10 (Sparx Systems)
SILDEX (TNI)
StP/ACD (Aonix)
Cooperative processing
FOUNDATION (Accenture)
CORBA
CORBA IDL
Debugging
xSlice (Bellcore)
Distributed systems
FORTRAN
Front -end
I-CASE
Informix 4GL
Java
Objecteering (Softeam)
objectiF (microTOOL GmbH)
StP/UML (Aonix)
Macintosh
Open source
ORACLE
Parallel programming
Smalltalk
StP/ClassCapture (Aonix)
UML
HAT (E2S)
Objecteering (Softeam)
ProxyDesigner (ProxySource.com)
Cradle (3SL)
SmartDraw (SmartDraw.com)
StP/UML (Aonix)
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:
Descomposición en subsistemas.
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.
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:
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.
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.
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.
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
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.
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.
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].
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:
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.
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 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.
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.
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.
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.p
df
https://es.slideshare.net/jpbthames/diseo-arquitectnico-9443843
http://www.monografias.com/trabajos102/ingenieria-del-software/ingenieria-del-
software.shtml