.
INTRODUCCION ................................................................ ¡Error! Marcador no definido. DISEÑO .............................................................................. ¡Error! Marcador no definido. CARACTERÍSTICAS PARA EVALUAR UN DISEÑO ..................................................... 5 IMPORTANCIA DEL DISEÑO........................................................................................ 6 DISEÑO ARQUITECTÓNICO ........................................................................................ 6 DISEÑO DE DATOS .................................................................................................. 6 Estilos Arquitectónicos ............................................................................................... 7 Arquitectura centrada en datos .............................................................................. 7 Arquitectura de flujo de dato................................................................................... 7 Arquitectura de Llamada y retorno ......................................................................... 7 Arquitectura de programa/subprograma ................................................................. 7 Arquitectura Orientada a Objetos ........................................................................... 7 Arquitectura estratificada ........................................................................................ 7 Arquetipos .................................................................................................................. 8 Evaluación de los diseños arquitectónicos alternos.................................................... 8 Herramientas de software .......................................................................................... 8 DISEÑO AL NIVEL DE COMPONENTES ...................................................................... 9 ¿Qué es un componente? .......................................................................................... 9 Los componentes pueden ser de tres tipos .............................................................. 10 Diseño de componentes basados en clases ............................................................ 10 Cohesión .................................................................................................................. 11 Acoplamiento ........................................................................................................... 12 Herramientas de software ........................................................................................ 12 UML/OCL ................................................................................................................. 12 DISEÑO DE LA INTERFAZ DE USUARIO................................................................... 13 Existen tres reglas de oro en el diseño de la interfaz de usuario .............................. 13 Herramientas de software ........................................................................................ 14 Referencias Bibliograficas .................................................. ¡Error! Marcador no definido.
Revista Singularidad La ingeniería de software desde sus comienzos ha sido una rama Director Luis Enrique Rangel.
con
muchos
sobre
sus
cuestionamientos, basamentos
Redacción Manuel Martino Del Molino
metodológicos, ha sido un proceso arduo, que por
Consejo Académico Asesor
rápidamente cambia, se pudiera llegar a pensar que ni
Yamila Gascón
hecho es una de las ramas más ricas en cuanto a
Nelsy Vivenes
metodologías se trata, una de ellas, vital diría yo, es el
Jonathan Vásquez
proceso de diseño de software, es una parte fundamental
Editor Responsable:
en mi opinión para poder desarrollar un software de
Luis E. Rangel y Manuel Martino Del Molino. Las ideas y opiniones expresadas en esta revista son responsabilidad única y exclusiva de los autores, la revista no se responsabilizara por dichas opiniones. Avenida Universidad Los Guaritos. Maturín, Monagas, Venezuela Teléfono: +58 (0291) 6417755 Correo electrónico: m1bff7e2@alum.udo.edu.v e RIF: G-20000052-0
tratarse de una de las ramas de las ingenierías que más
siquiera posee algunos, pero la realidad es otra, y de
calidad y con nivel de ingeniería, este proceso surge en las primeras instancias de un proyecto de software, antes de empezar a codificar, un proyecto de tener bien definido estos lineamientos.
Normalmente entre la comunidad desarrolladora, existe un concepto que se adapta a esta falta de formalidad al momento de escribir código, se le llama “software artesanal”, claro, como todo campo del conocimiento empezó como una práctica empírica, posteriormente fue evolucionando a planos más altos.
El concepto de diseño de software, hoy en día es una rama vital del desarrollo de software y sistemas, tal es su impacto que actualmente ningún proyecto de software serio puede iniciar si no se poseen los marcos estructurales de diseño para la codificación. Siempre y cuando obedeciendo a las reglas de diseño, orientados al paradigma por donde se trabaje.
1. El diseño debe implementar todos los requisitos explícitos contenidos en el modelo del El diseño es lo que casi cualquier ingeniero quiere hacer. Es el sitio donde manda la creatividad, donde los requisitos del cliente, las necesidades
de
negocio
y
las
consideraciones técnicas se unen en la formulación de un producto o sistema. El diseño crea una diferencia del modelo de análisis (que se enfoca en la descripción de los datos, las funciones
y
el
comportamiento
requerido), el modelo
de diseño
proporciona detalles acerca de las estructuras
de
datos,
las
arquitecturas, las interfaces y los componentes del software que son necesarios
para
implementar
el
sistema.
CARACTERÍSTICAS PARA EVALUAR UN DISEÑO McGlaughlin Sugiere
tres
[MCG91].
características
que
sirven como guía en la evaluación de un buen diseño;
análisis,
y
debe
ajustarse
todos los requisitos implícitos que desea el cliente. 2. El diseño debe ser una guía legible y comprensible para quienes
generan
código,
quienes realizan pruebas y, en consecuencia, dan soporte al software. 3. El diseño debe proporcionar una
imagen
completa
del
software- dando dirección a los dominios de datos, funcionales y de comportamiento desde una
perspectiva
implementación.
de
la
IMPORTANCIA DEL DISEÑO Es importante porque permite que un equipo de software evalué la calidad
del
implementarlo,
software es
antes
decir,
en
de
o
inconsistencias
software, las propiedades visibles externamente de esos componentes y las relaciones entre ellos.
un
momento en el que los errores, omisiones
que incluyen los componentes del
son
fáciles de corregir y no resultan caras.
DISEÑO DE DATOS Este
proceso
traduce
los
objetos de datos obtenidos en el modelo de análisis en estructuras globales a nivel de componentes de software. Estilos arquitectónicos: 1. Un conjunto de componentes que realizan una función requerida por el sistema. 2. un conjunto de conectores que permiten cooperación
la
comunicación,
y coordinación
entre
componentes
DISEÑO ARQUITECTÓNICO Representa la estructura de datos y los componentes necesarios para
construir
computacional.
un El
sistema diseño
arquitectónico inicia con el diseño de datos y luego pasa a la derivación de una o más representaciones de la estructura arquitectónica del sistema. La arquitectura de software son las estructuras del sistema o estructura
3. Restricciones que definen como se integran los componentes para formar el sistema. 4. modelos semánticos que permiten al diseñador del sistema comprender las propiedades generales de un sistema.
Arquitectura de programa/subprograma
Estilos Arquitectónicos
Arquitectura Arquitectura centrada en datos Un
almacén
de
procedimiento
datos
se
de
llamada
a
Es
un
remoto.
programa/subprograma en los cuales
encuentra en el centro de esta
algunos
arquitectura
instalados en un ordenador distinto
subprogramas
están
Arquitectura de flujo de dato Esta
arquitectura
se
utiliza
Sub-Programa Controlador
cuando los datos de entrada se empiezan a transformar en datos de salida
mediante
componentes
una
para
el
serie
de
cálculo
o
Sub-Programa de Aplicacion Sub-Programa de Aplicacion
Programa Principal
Sub-Programa de Aplicacion
Sub-Programa Controlador
Sub-Programa de Aplicacion
manipulación.
Sub-Programa de Aplicacion
Arquitectura Orientada a Objetos Los
componentes
de
un
sistema encapsulan los datos y las operaciones que deben aplicarse
Ejemplo de una arquitectura de Flujo de Datos
para
manipular
datos
la
comunicación se efectúa por colas de mensajes.
Arquitectura de Llamada y retorno Esta
permite
tener
Arquitectura estratificada una
Se compone en distintas capas
arquitectura que es relativamente fácil
definidas cada una de ellas realiza
de modificar y cambiar de tamaño y
operaciones
existen dos categorías
progresivamente
que
se al
encargan
conjunto
instrucciones de la máquina.
de
4. evaluar los atributos de calidad al
Arquetipos Un arquetipo es una clase o patrón
que
representa
una
abstracción central importantísima en el diseño de una arquitectura para el
considerar cada atributo de manera aislada 5. identificar la sensibilidad de los atributos de calidad respecto varios atributos
sistema destino.
arquitectónicos
para
un
estilo arquitectónico específico. 6. Analizar las arquitecturas alternas empleando análisis de sensibilidad aplicado al paso 5.
Herramientas de software Existen
un
sinfín
de
herramientas dedicadas al diseño de
Evaluación de los diseños
arquitecturas,
muchas
basadas
el
en
de
ellas
lenguaje
UML,
arquitectónicos alternos
estándar actual para la formulación
La SEI ha desarrollado un método de
de todos los diseños y planos del
análisis de compensación para la
software.
arquitectura MACA y se realizan las siguientes actividades de manera
Enterprise
Architect,
iterativa
desarrollado por Sparx Systems, con
1. recopilar escenarios
base en Australia, desarrollado en el
2. Deducir requisitos, restricciones y
Lenguaje C++, se perfila como una
descripción de entornos
de las herramientas más potentes de
3.
describir
los
lenguaje
de
Estilos/patrones
modelado unificado
arquitectónicos que se han
hoy en dia.
elegido
para
dirigir
escenarios y requisitos.
los
Objectif,
desarrollada
microTOOL
GmbH,
es
por
DISEÑO AL NIVEL DE
una
COMPONENTES
herramienta de diseño UML que lleva a
arquitecturas
(por
ejemplo,
Coldfusion, J2EE, fusebox) sensibles a la ingeniería de software basadas
El diseño a nivel de componentes define las estructuras de datos, los algoritmos, las características de la interfaz
en componentes.
y
comunicación Umbrello,
una
herramienta
open source, para la plataforma GNU/Linux, específicamente para los entornos de escritorio KDE. Umbrello maneja gran parte de los diagramas estándar UML pudiendo además
de
los
mecanismos
asignados
a
de cada
componente de software. Esta fase permite revisar si los detalles de diseño son correctos y consistentes con las representaciones iniciales de diseño.
crearlos,
¿Qué es un componente?
manualmente,
importándolos a partir de código en
Es
C++,
modular par el software de cómputo.
Java,
Python,
IDL,
Pascal/Delphi, Ada
un
bloque
de
construcción
Una parte modular desplegable y reemplazable de un sistema que encapsula implementación y expone un conjunto de interfaces.
Rational desarrollada
Rose por
IBM,
Modeler, es
una
herramienta de diseño basado en UML que soporta todos los aspectos del diseño arquitectónico
Los componentes pueden ser Diseño de componentes
de tres tipos 1.
Componente
de
control
basados en clases
que
coordina la invocación de todos los demás componentes del dominio del
Cuando se elige un método de
problema.
ingeniería de software basado en
2.
componentes el nivel de diseño de
un componente del dominio del
problema
que
implementa
una
estos se concentra en la elaboración
función parcial o completa requerida
de clases de análisis y la definición y
por el cliente.
afinación de clases de infraestructura.
3. un componente de infraestructura responsable
que
Hay cuatro principios básicos
soportan el procesamiento requerido
basados en el nivel de diseño de
en el dominio del problema.
componentes:
A
de
continuación
funciones
se
presenta
un
1. El principio abierto cerrado PAC un
ejemplo de un diseño a nivel de
módulo
debe
componentes utilizando UML
extensiones
estar pero
abierto cerrado
para para
modificaciones. Sistema de Administracion de Trabajo
Leer Datos de Trabajo de impresion
Calcular Costo de Pagina
Seleccionar la funcion de manejo de trabajo
Desarrolar Costo de Trabajo
Construir Orden de Trabajo
Calcular Costo de Papel.
Calcular Costo de Producto
Enviar Trabajo o Produccion
Revisar Prioridad
Pasar Trabajo a Produccion.
2. Principio de sustitución de Liskov
al tener demasiadas usar círculos en
PSL debe tenerse la opción de
vez de rectángulos y mostrar solo las
sustituir las subclases con sus clases
más importantes
principales.
3. Las dependencias de izquierda a
3. Principio de la inversión de la
derecha y las herencias la clase
dependencia PID dependa de las
principal arriba y derivadas abajo
abstracciones
no
concreciones,
de
las
mientras
un
componentes dependa más de otros componentes concretos es más difícil extenderlos.
es
Implica que un componente o una clase encapsulan únicamente atributos y operaciones relacionadas estrechamente entre sí y con la clase
4. Principio de la segregación de la interfaz
Cohesión
mejor
tener
del propio componente.
muchas
interfaces específicas del cliente que una interfaz de propósito general.
Existen distintos tipos de cohesión Funcional, cuando un módulo realiza un
Existen distintas líneas generales
solo
y
devuelve
el
resultado
que se pueden seguir durante el diseño de componentes:
calculo
De capa, cuando una capa superior tienen acceso a una inferior pero no al revés.
1. Los componentes deben definirse convenciones
de
asignación
de
nombres, los cuales provengan del dominio del sistema y tener algún significado para los participantes 2.
Interfaces
proporcionan
información importante acerca de la comunicación y colaboración, aun que al tener muchas se puede crear confusión en el diagrama UML por lo que se recomienda entre otras cosas
De comunicación, todas las operaciones con acceso a los mismos datos se definen dentro de una clase. Secuencial, las operaciones están agrupadas manera
de que
primero permita la
entrada
al
sucesivamente.
siguiente
y
así
diseño, que van más allá de la generación de diagramas UML y
Acoplamiento Es una medida cualitativa del
expresiones OCL.
grado al que las clases se conectan entre sí a medida que las clases se vuelven más interdependientes el acoplamiento aumenta. Acoplamiento común, del contenido, de control, de estampa, de datos, de llamada a rutina, uso de rutina, uso de tipo, de
DRESDEN
OCL
TOOLKIT,
desarrollado por Frank Finger en la Universidad Tecnológico de Dresden, es un juego de herramientas basadas en un compilador OCL que abarca varios módulos que analizan, revisan el tipo y las restricciones OCL.
incursión o aportación y externo.
OCL PARSER, desarrollado por IBM,
Herramientas de software
está escrito en Java y está disponible
MIDDLEWARE e ingeniería de
gratuitamente
para
comunidad
software basadas en componentes.
orientada a objeto con fin de que se
Uno de los elementos clave que lleva
estimule
al éxito o en componentes es la
modeladores UML.
disponibilidad de meddleware. Esta es una colección de componentes de infraestructura que permite que los componentes
de
dominio
del
programa se comuniquen con otros en una red o dentro de un sistema completo.
UML/OCL ARGOUML,
distribuido
por
Tigress. org, da soporte a ULM y OCL completo, herramientas
e de
incluye ayuda
varias para
el
el
uso
de
OCL
con
DISEÑO DE LA INTERFAZ DE
resultado frustrante para el usuario. Para ello se deben definir:
USUARIO
El diseño de la interfaz se concentra
que
en tres partes 1.
Diseño
interfaces
entre
2. Diseño de interfaces entre el y
otros
productores
y
consumidores de información que no son humanos 3.
el
usuario
acciones de
componentes
software
Modos de interacción de forma
Interfaz entre
ser humano
y
computadora
no
realice
innecesarias
o
indeseables
una interacción flexible
incluir opciones de interrumpir y deshacer
permitir que se personalice la interacción
ocultar elementos técnicos a usuario usual.
La creación de una interfaz entre el
Diseñar interacción directa con los objetos que aparecen en la
ser humano y la computadora crea un
pantalla
mecanismo efectivo de comunicación, la interfaz debe estar construida de la mejor forma para que motive el uso y ayude
al
éxito
del
sistema
de
2. Reducir la carga de memoria del usuario. El sistema debe recordar las cosas y no el usuario un sistema que
software.
Existen tres reglas de oro en el diseño de la interfaz de
dependa
constructor introduce limitaciones que ayuden a hacer más fácil el trabajo de construcción puede influir en un
usualmente
Reducir
la
demanda
de
memoria a corto plazo
Definir valores a corto plazo que tengan significado
desea manejar el sistema y no que este lo maneje a el de modo que si el
usuario
cometerá más errores.
usuario 1. Dar el control al usuario. El usuario
del
Definir intuitivos
accesos
directos
El formato visual de la interfaz
MOTIF
COMMON
DESKTOP
debe basarse en una metáfora
ENVIRONMENT,
tomada de la interfaz
The Open Group, es una interfaz
Desglosar la información de
gráfica de usuario integrada para
manera progresiva.
sistemas abiertos de computación de
desarrollado
por
escritorio. Entrega una interfaz gráfica 3.
Lograr
que
consistente,
la
la
interfaz
sea
información
en
pantalla debe estar organizada de acuerdo
a
un
mantenga
en
presentaciones mecanismos
estándar
de de
que
estándar,
para
la
administración de datos, archivos y aplicaciones.
se
todas
las
pantalla,
los
entrada
simple,
deben
restringirse a un conjunto limitado que se utilice durante toda la aplicación.
Herramientas de software
POWERDESIGNER/POWERBUILDE R, desarrollo por Sybase, es un
Desarrollo de interfaces de usuario
conjunto
muy
completo
de
herramientas CASE, que incluyen MACROMEDIA
AUTHORWARE,
desarrollado por Macromedia Inc. se ha diseñado para la creación de interfaces y entornos de aprendizaje electrónico.
muchos opciones para el diseño y la construcción de interfaces graficas de usuario.
Referencias Bibliográficas
[Pressman, 2002] Pressman, R. S. “Ingeniería del Software: Un Enfoque Práctico”. 5ª Edición. McGraw-Hill. 2002 [Pressman, 2006] Pressman, R. S. “Ingeniería del Software: Un Enfoque Práctico”. 6ª Edición. McGraw-Hill. 2006 [Rumbaugh J, et als 2000] Rumbaugh, J. Jacobson, I. Booch, G. “Lenguaje unificado de Modelado”. Addison-Wesley. 2000