Transcript PPT - unistmo

Ingeniería de Software
Unidad 4
Diseño e implementación del
software
Unidad 4
Contenido



El diseño en la ingeniería de software
Aplicación del diseño estructurado
 El proceso del diseño estructurado
 Fundamentos del diseño estructurado
 Diseño arquitectónico
 Diseño de interfaces de usuario
 Diseño procedimental
 Documento de especificación
Introducción al diseño orientado a objetos
 Diseño estructurado frente al diseño orientado a objetos
 Estrategias de diseño
Ingeniería de software
El diseño en la ingeniería de
software



El diseño, en general, se puede definir como el
proceso de aplicar distintas técnicas y principios con
el propósito de definir un producto o sistema de
ingeniería con suficiente nivel de detalle como para
permitir su realización física.
En lo que concierne al diseño del software, se
puede decir que esta en constante evolución debido
al surgimiento de nuevos métodos, mejores análisis
y perspectivas más amplias
Sin embargo, los conceptos y principios
fundamentales del diseño del software son
aplicables independientemente del paradigma de
programación utilizado.
Unidad 4
El diseño en la ingeniería de
software … (2)



En la ingeniería de software, el propósito del diseño
es construir soluciones (modelos) que satisfagan los
requerimientos del software.
El modelo que surge del diseño es un refinamiento
y formalización adicional al modelo del análisis,
donde ahora se toman en cuenta las consecuencias
del ambiente de implementación.
Se requiere de un modelo de diseño, ya que el
modelo del análisis no es lo suficientemente formal
para alcanzar el código fuente, es decir, la
implementación.
Ingeniería de software
Aplicación del diseño
estructurado

Cada uno de los elementos del modelo del análisis proporciona
información necesaria para crear un modelo de diseño .
Descripción
de los
objetos de
datos
Especificación
del proceso
Diagrama
EntidadRelación
Diagrama
de Flujo de
Datos
Diccionario
de datos
Diagrama de
Transición
de Estado
Especificación
de control
El modelo del Análisis
Diseño
Procedimental
Diseño
de Interfaz
Diseño
Arquitectónico
Diseño
de Datos
El modelo del Diseño
Transformación del modelo de análisis en el modelo del diseño
Unidad 4
El proceso del diseño
estructurado

El proceso del diseño estructurado es más bien un
proceso de muchos pasos que se centra en cuatro
atributos distintos de un programa:





Estructura de datos
Arquitectura del software
Representaciones de interfaz
Detalle procedimental
Se trata de un proceso iterativo que inicia con una
estrecha relación y abstracción con los requisitos y
finaliza con una relación más sutil con los requisitos
pero con una relación mas directa con la
implementación.
Ingeniería de software
Unidad 4
El proceso del diseño
estructurado … (2)

El proceso de diseño se puede dividir en dos enfoques, el
enfoque de datos y el enfoque funcional.
Enfoque de
datos
ERS
PROCESO DE DISEÑO
E-R y DD
DFD y DTE
Diseño de
alto nivel
(arquitectónico)
Diseño
detallado
Organización
lógica
Modelo lógico de
datos
Arquitectura de
procesos
Modelo físico de
datos
Estructura detallada:
programas y módulos
Implementación
(codificación)
Ingeniería de software
Enfoque
funcional
Consideraciones
de rendimiento y
control
Unidad 4
El proceso del diseño
estructurado … (3)
Existen tres características que sugieren como
directrices para la evaluación de un buen diseño:




Ingeniería de software
El diseño debe implementar todos los requisitos explícitos
contenidos en el modelo de análisis y debe acomodar
todos los requisitos implícitos que desea el cliente.
El diseño debe ser una guía que puedan leer y entender
los que construyan el código y los que prueban y
mantienen el software.
El diseño debería proporcionar una completa idea de lo
que es el software, enfocando los dominios de datos,
funcional y de comportamiento desde la perspectiva de
implementación.
Unidad 4
El proceso del diseño
estructurado … (4)

Para tener un buen diseño se aconseja:







El diseño debería ser modular; es decir, se debería hacer una partición
lógica del software en elementos que realicen funciones y subfunciones
específicas.
Un diseño debería contener abstracciones de datos y procedimientos.
Un diseño debería producir módulos que presenten características
funcionales independientes.
Un diseño debería conducir a interfaces que reduzcan la complejidad de las
conexiones entre los módulos y el entorno con el exterior.
Se debería producir un diseño usando un método que pudiera repetirse
según la información obtenida durante el análisis de requisitos del software.
Un diseño debería presentar una organización jerárquica que haga un uso
inteligente del control entre los componentes del software.
La última característica va más de la mano con el paradigma
estructurado, sin embargo, esto no es precisamente así en un buen
diseño bajo el paradigma orientado a objetos.
Ingeniería de software
Unidad 4
El proceso del diseño
estructurado … (5)

En el proceso del diseño la capacidad
creativa, la experiencia acumulada, el sentido
de un buen software y un empeño global en
la calidad son factores críticos para el éxito
del diseño.
Ingeniería de software
Unidad 4
Fundamentos del diseño
estructurado

Los principios básicos del diseño permiten conducirse dentro del
proceso de diseño, algunos de estos son:
 El diseñador debe considerar diferentes enfoques alternativos
tomando en cuenta: requisitos, recursos y conceptos de diseño.
 Se debería poder seguir los pasos del diseño hasta el análisis.
 El diseño no debe inventar lo que ya esta inventado
(reutilización).
 El diseño debería presentar uniformidad e integración.
 El diseño debería estructurarse para aceptar cambios .
 Un programa bien diseñado no debería “tronar” nunca, debería
estructurase incluso para condiciones operativas aberrantes.
 El diseño no es escribir código y escribir código no es diseñar.
 Se debería valorar la calidad del diseño mientras se crea, no
después de terminarlo.
Ingeniería de software
Unidad 4
Fundamentos del diseño
estructurado … (2)

Conceptos del diseño



Los conceptos fundamentales del diseño del software aportan un
fundamento desde el cual se pueden aplicar los métodos de diseño más
sofisticados.
Además proporcionan la estructura necesaria para no solo hacer que los
programas funcionen, sino que funcionen y lo hagan bien.
Dentro de estos conceptos se pueden enunciar:











Ingeniería de software
Abstracción
Refinamiento
Modularidad
Arquitectura del software
Jerarquía de control
Estructura de datos
Partición estructural
Procedimiento del software
Ocultamiento de la información
Diseño modular efectivo
Independencia funcional
Unidad 4
Fundamentos del diseño
estructurado … (3)

Abstracción





Cuando se considera una solución modular para cualquier problema, se pueden
plantear muchos niveles de abstracción.
A nivel superior de abstracción se establece una solución en términos que utilicen el
lenguaje del contexto del problema.
A niveles más bajos, se toma una orientación más procedimental.
Se conjuga la terminología orientada al problema con la terminología orientada a la
implementación para plantear una solución final.
Ejemplo:

La abstracción (de alto nivel) Abrir una puerta implica:



Ir hacia la puerta, tomar la perilla, girarla y empujar la puerta (Abstracción procedimental).
Por otro lado puerta comprendería una serie de atributos que describen la puerta: dirección de
apertura, mecanismo de apertura, peso, dimensiones, etc. (Abstracción de datos).
Refinamiento



Se trata de una estrategia de diseño descendente donde la arquitectura del programa
se desarrolla refinando sucesivamente niveles de detalle procedimental.
Se desarrolla una jerarquía descomponiendo un enunciado macroscópico de función
al estilo paso a paso hasta que se llega a los enunciados del lenguaje de
programación.
La abstracción y el refinamiento son conceptos complementarios.


Ingeniería de software
La abstracción permite a un diseñador especificar procedimientos y datos y aún así,
suprimir detalles de bajo nivel.
El refinamiento ayuda a revelar detalles de bajo nivel a medida que progresa el diseño.
Unidad 4
Fundamentos del diseño
estructurado … (4)

Modularidad



El software se divide en componentes identificables y tratables por separado,
denominados módulos, que están integrados para satisfacer los requisitos del
programa.
Se dice que la modularidad del software es el atributo que permite a un programa ser
manejable de forma inteligente.
Se deben tomar en cuenta cinco criterios para tener un diseño modular eficaz







Capacidad de descomposición modular.
Capacidad de empleo de componentes modulares.
Capacidad de comprensión modular.
Continuidad modular.
Protección modular.
Cabe mencionar que un programa se puede diseñar modularmente, aunque su
implementación tenga que ser monolítica.
Arquitectura del software



La arquitectura del software alude a la estructura global del software y las maneras en
que esa estructura proporciona integridad conceptual a un sistema.
En su forma más simple la arquitectura es la estructura jerárquica de los componentes
del programa (módulos), la manera de interactuar de estos componentes, y la
estructura de los datos utilizados por estos componentes.
En un sentido más amplio los componentes pueden generalizarse para representar los
elementos principales del sistema y sus interacciones.
Ingeniería de software
Unidad 4
Fundamentos del diseño
estructurado … (5)

Jerarquía de control


Representa la organización de componentes del programa e implica una
jerarquía de control.
La jerarquía de control representa dos características sutilmente diferentes
de la arquitectura del software:



Visibilidad: indica el conjunto de componentes de programa que pueden
invocarse o utilizar sus datos por otro componente dado, incluso cuando esto
se realiza indirectamente.
Conectividad: indica el conjunto de componentes que son invocados
directamente o que sus datos son usados por un componente determinado.
Estructura de datos



La estructura de datos es una representación de la lógica entre los
elementos individuales de los datos.
La estructura de datos dicta las alternativas de organización, métodos de
acceso, capacidad de asociación y procesamiento de la información.
Es importante resaltar que las estructuras de datos pueden representarse a
diferentes niveles de abstracción.

Ingeniería de software
Por ejemplo: una pila es un modelo conceptual de una estructura de datos
que puede implementarse como un vector o una lista enlazada. Dependiendo
del nivel de detalle del diseño, los procesos internos de la pila pueden
especificarse o no.
Unidad 4
Fundamentos del diseño
estructurado … (6)

Partición estructural

La estructura del programa debería partirse tanto horizontalmente como
verticalmente.


La partición vertical define ramas separadas de la jerarquía modular para
cada función principal del programa.
La partición horizontal sugiere que el control y el trabajo se distribuyan
descendentemente en la arquitectura del programa.
Módulos de
toma de
decisiones
Módulos
“de trabajo”
Función 1
Ingeniería de software
Función 2
Función 3
Unidad 4
Fundamentos del diseño
estructurado … (7)

Procedimiento del software



Se centra en los detalles de procesamiento de cada módulo
individualmente.
Debe proporcionar una especificación exacta del procesamiento, incluyendo
la secuencia de acontecimientos, puntos exactos de decisión, operaciones
repetitivas e incluso la organización y/o estructura de los datos.
Una representación procedimental del software se distribuye en capas, el
procesamiento para cada módulo debe incluir una referencia a todos los
módulos subordinados al módulo que se describe.
Procedimiento para
el módulo superior
Procedimiento para
el módulo
subordinado
Procedimiento para el
último módulo
subordinado
Ingeniería de software
Unidad 4
Fundamentos del diseño
estructurado … (8)

Ocultamiento de la información




El principio del ocultamiento de la información sugiere que los módulos se
caractericen por decisiones de diseño que haga que cada uno oculte a los
demás.
En otras palabras, se deberían especificar y diseñar los módulos para que la
información (procedimiento y datos) contenida dentro de un módulo sea
inaccesible a otros módulos que no necesitan esa información.
Los módulos deben ser independientes y la comunicación entre ellos solo
se debe dar transmitiendo únicamente la información necesaria para
conseguir la función del software.
Diseño modular efectivo



La modularidad se ha convertido en un enfoque admitido por todas las
disciplinas de la ingeniería.
Un diseño modular reduce la complejidad, facilita los cambios y hace más
fácil la implementación al fomentar el desarrollo en paralelo de diferentes
partes de un sistema.
Los conceptos fundamentales del diseño descritos anteriormente sirven
para crear diseños modulares.
Ingeniería de software
Unidad 4
Fundamentos del diseño
estructurado … (9)

Independencia funcional
 El concepto de independencia funcional es un producto directo
de la modularidad y de los conceptos de abstracción y
ocultamiento de información.
 Se consigue desarrollando módulos con una función única y una
aversión a excesiva interacción con otros módulos.
 Es la clave para un buen diseño y el diseño es la clave para
lograr la calidad del software.
 Se mide usando dos criterios cualitativos:

Cohesión


Acoplamiento


Ingeniería de software
Un módulo con cohesión debería (idealmente) hacer una sola cosa sin
depender tanto de los otros módulos del sistema. Se intenta conseguir el
mayor nivel de cohesión.
Es una medida de la interdependencia relativa entre los módulos. Se
intenta conseguir el menor nivel posible de acoplamiento.
Hay que buscar conexiones sencillas entre módulos
Unidad 4
Diseño arquitectónico




El objetivo primario del diseño arquitectónico es desarrollar una
estructura de programa modular y representar las relaciones de
control entre los módulos.
Combina la estructura del programa y las estructuras de datos,
definiendo interfaces que permiten el flujo de datos a través del
programa, tomando como base los principios de abstracción,
modularidad y ocultamiento de la información.
El diseño arquitectónico tiene sus orígenes en antiguos
conceptos de diseño que defendían la modularidad, el diseño
descendente y la programación estructurada. Para ello se
propuso el diseño de software basado en el flujo de datos a
través de un sistema.
El diseño orientado al flujo de datos permite una cómoda
transición desde el modelo de análisis (DFD) a una descripción
del diseño de la estructura del programa (Diagramas de
Estructura <DE>).
Ingeniería de software
Unidad 4
Diseño arquitectónico … (2)

Diagramas de Estructura (DE)
 Son una herramienta gráfica que permite representar la
descomposición de un sistema en módulos funcionales.
 Tiene forma de árbol, en el cuál cada uno de los nodos se
corresponde con un módulo, de tal forma que se expresa la
jerarquía de control que se establece entre los módulos.
 También refleja la comunicación de datos que se da entre dichos
módulos.
 La notación gráfica que conforma a estos diagramas es la
siguiente:
Módulo
Obtener datos
Clientes
Ingeniería de software
Módulo de biblioteca
Imprimir
Cheque de
Pago
Conector
1
Almacenes
de datos
Dispositivos
físicos
Nombre
Dispositivo
Unidad 4
Diseño arquitectónico … (3)

Diagramas de estructura …
 La conexión entre los módulos se representa por una línea.


Un módulo A llama a un módulo B, entonces B hace su función y
retorna a A inmediatamente después del lugar donde se produjo su
llamada.
Se puede decir que se tienen tres tipos de conexiones:
(a) Conexión y llamado entre
módulos
A
Módulo que llama
(b) Conexión y llamado entre
módulos de forma alternativa
A
Ingeniería de software
Módulo llamado
A
Estructura
alternativa
Conexión
B
(c) Conexión y llamado entre
módulos de forma repetitiva
B
Estructura
repetitiva
B
Unidad 4
Diseño arquitectónico … (4)

Diagramas de estructura …

El siguiente es un ejemplo parcial de un DE para una aplicación que gestiona una
biblioteca:
GESTIONAR
BIBLIOTECA
GESTIONAR
DEVOLUCIONES
LEER
SERVICIO
LEER
LIBROS
DISPONIBLES
GESTIONAR
PEDIDOS
ESCRIBIR
LIBROS
DISPONIBLES
GESTIONAR
DEVOLUCIONES
GESTIONAR
DEVOLUCIONES
ESCRIBIR
FICHAS
PRESTAMO
ESCRIBIR
LIBROS
DISPONIBLES
Ingeniería de software
CALCULAR
SANCIÓN
ACTUALIZAR
STOCK
ESCRIBIR
LIBROS
DEVUELTOS
LEER
LIBROS
DISPONIBLES
LEER
FICHAS
PRÉSTAMO
ESCRIBIR
SANCIÓN
Unidad 4
Diseño arquitectónico … (5)

Diagramas de estructura …

Cuando un módulo invoca o llama a otro
se está comunicando, y eso produce un
intercambio de información. La
información que se intercambia puede ser
de dos tipos:



Se procesan
Son la información compartida por los
módulos, donde la posición de la flecha
señala el sentido de la comunicación.
Tienen importancia para el mundo exterior,
debido a que están directamente
relacionados con el problema
Campo alfabético
correcto
EOF
Obtener datos
clientes
Control (flags)



Ingeniería de software
Datos
Datos


Flags o control
Solo sirven para comunicar condiciones de
estado entre los módulos y deben ir siempre
en sentido ascendente
Los flags tienen importancia en la
comunicación al interior de los módulos para
sincronizar su ejecución.
no siempre se muestran los flags en los
diagramas de estructura
Campo
correcto
Campo
EOF Campo
Obtener campo
siguiente
Validar campo
alfabético
Unidad 4
Diseño arquitectónico … (6)

Estrategias para obtener el DE
 Definen los pasos a seguir para obtener un buen diseño a partir
de un DFD de procesos primitivos. Sin embargo, también se
puede hacer uso de los DFD’s de niveles más altos.
 Se debe diseñar el DE de tal forma que los módulos de nivel
superior tomen las decisiones (controlen), mientras que los
módulos de nivel inferior realicen la mayor parte del trabajo de
entrada, cálculo y salida.
 Finalmente el DE debe refinarse utilizando fundamentalmente los
criterios de cohesión y acoplamiento.
 Las estrategias para construir el DE a partir del DFD son dos:


Ingeniería de software
El análisis de transformaciones
El análisis de transacciones
Unidad 4
Diseño arquitectónico … (7)

Análisis de transformación
 Esta estrategia permite obtener una primera aproximación al
diseño final del sistema .
 El análisis de transformación aísla el centro de la transformación,
especificando los límites del flujo de llegada y de salida.
 Los pasos a seguir para llegar al DE a partir del DFD son los
siguientes:
1. Realizar el primer corte del DFD. Para ello habrá que identificar las
funciones centrales, es decir, el centro de la transformación.
2. Convertir el DFD en una primera aproximación o corte al DE.
3. Refinar el DE del programa mediante los fundamentos y criterios del
diseño.
4. Comprobar que el DE final cumple con los requerimientos del DFD
inicial.
Ingeniería de software
Unidad 4
Diseño arquitectónico … (8)

Análisis de transformación …
El centro de la transformación es la parte del DFD que contiene las
funciones esenciales de la propia transformación y es independiente
de una implementación particular de la entrada y/o salida (paso 1).
Con el primer corte o aproximación se pretende conseguir una
primera versión del DE del sistema (paso 2).


a
1.
1
1.
2
3
b
2.
1
2.
2
Flujo de llegada
z
4.
1
Flujo de
transformación
4.
2
MC
Flujo de salida
ME
Ingeniería de software
MT
MS
Unidad 4
Diseño arquitectónico … (9)
Transformación

Análisis de transformación …


a
El paso siguiente (3) es hacer una
revisión de la primera aproximación
realizándose los refinamientos necesarios
y asegurándose de que cumple con el
paso 4.
Para nuestro ejemplo:






Ingeniería de software
En las ramas de entrada/salida añadir
los módulos de lectura y escritura
necesarios para acceder a las fuentes de
información
Las ramas de entrada y salida deben
factorizarse y reorganizarse
Factorizar, si es necesario, la
transformación central utilizando como
guía los diferentes niveles de DFD
Revisión de la congruencia en los
nombres de los módulos
Adicionar los flags que sean necesarios
Y comprobar los criterios para un diseño
modular efectivo.
1.1
1.2
3
b
z
4.1
4.2
2.2
2.1
Entrada
Salida
MC
ME
1.2
2.2
1.1
2.1
a
MS
3
4.1
4.2
z
b
Leer
a
MT
Leer
b
Escribir
z
Unidad 4
Diseño arquitectónico … (10)

Análisis de transacciones
 Una transacción se evalúa y basándose en ese valor, se inicia el
flujo a lo largo de uno de muchos caminos de acción.
 El centro de información del que se parten los caminos de acción
se denomina centro de la transacción.
 El análisis del flujo de transacciones identifica el centro de la
transacción y también las características del flujo de cada
camino de acción, así como el flujo de entrada.
2.
1
1
3.
1
Centro de
Transacción
4.
1
Ingeniería de software
2.
2
3.
2
4.
2
Camino de acción 1
Camino de acción 2
Camino de acción 3
Unidad 4
Diseño arquitectónico … (11)

Análisis de transacciones …
 Los pasos a seguir para llegar al DE a partir del DFD
prácticamente son los mismos que para el flujo de
transformación.


En un primer paso se identifica el centro de la transacción y con ello
el flujo de entrada.
En un segundo paso se construye la primera aproximación al DE
Centro de
Transacción
a
A
b
MC
D
P
Q
ME
MD
R
z
MC1
Camino 3
Camino 1
Camino 2
Ingeniería de software
MC2
MC3
Unidad 4
Diseño arquitectónico … (12)

Análisis de transacciones …

Finalmente, después de aplicar la revisión y refinamiento utilizando los
criterios de diseño a la primera aproximación obtenemos el DE equivalente.
En el camino 1 se detecto un flujo de transformación (entre P y R, siendo Q
el centro de la transformación), el cual es reflejado en el diagrama de
estructura final.
MC
Centro de
Transacción
a
A
ME
b
D
P
A
Q
z
Camino 1
Camino 2
Ingeniería de software
MC1
MC2
MC3
a
R
Camino 3
MD
Leer
a
P
Q
R
z
b
Leer
b
Escribir
z
Unidad 4
Diseño de interfaces de
usuario

Reflexión:

“Los diseñadores de software no son los usuarios
finales”
Ingeniería de software
Unidad 4
Diseño de interfaces de usuario
… (2)

Una interfaz con problemas de diseño tiene
su costo

Los costos pueden ser medidos de forma directa
o indirecta

¿Cuánto cuesta un cliente insatisfecho?


¿Cuánto cuesta un defecto en la interfaz que provoca
un retraso de 3 minutos diarios en la productividad de
un usuario?

Ingeniería de software
Es difícil medirlo en dinero, pero es un costo que ninguno
querría pagar.
Disminuye en un .75% la productividad por usuario a la
semana; y si son 10 usuarios de un departamento?
Unidad 4
Diseño de interfaces de usuario
… (3)

Interfaz de usuario


Cuando se usa una herramienta, o accede e
interactúa con un sistema, suele haber “algo”
entre el usuario mismo y el objeto de la
interacción.
La interfaz de usuario puede verse como “algo”
que nos informa que acciones se pueden realizar,
el estado actual del sistema y los cambios
producidos, y además ese “algo” permite una
comunicación interactiva con el sistema o
herramienta.
Ingeniería de software
Unidad 4
Diseño de interfaces de usuario
… (4)

La usabilidad del sistema se da a través de la interfaz de usuario
 Usabilidad es una medida de la utilidad, facilidad de uso,
facilidad de aprendizaje y apreciación para una tarea, un
usuario y un contexto dado.

Utilidad


Facilidad de uso


Es una medida del tiempo requerido para trabajar con cierto grado de
eficiencia en el uso de la herramienta (conocimiento fácilmente retenido).
Apreciación

Ingeniería de software
Permite al usuario efectuar más operaciones por unidad de tiempo y
disminuye la probabilidad de errores.
Facilidad de aprendizaje


Capacidad que tiene una herramienta para ayudar a cumplir tareas
específicas.
Es una medida de las percepciones, opiniones, sentimientos y actitudes
generadas en el usuario por la herramienta o sistema.
Unidad 4
Diseño de interfaces de usuario
… (5)

El diseño de interfaces pertenece a un campo mayor del conocimiento
humano, de origen altamente interdisciplinario, llamado Human
Computer Interaction (HCI). Las áreas y profesiones relacionadas son:

Factores humanos y ergonomía



Diseño gráfico


Los condicionamientos o convenciones culturales y la apreciación estética,
junto con los factores humanos y la ergonomía, pueden potenciar o
desalentar el uso y la venta de un sistema o herramienta.
Interacción y ciencias cognitivas


Se denomina así al estudio de las características de los sentidos, percepción,
antropometría y acción de los seres humanos.
Esta disciplina relaciona la fisiología con la percepción, el procesamiento de
esas percepciones y las acciones posibles.
Las ciencias cognitivas estudian los procesos de la mente humana: cómo
aprendemos, cómo recordamos, cómo procesamos la información y qué
hacemos con ella.
Ciencias de la computación

Ingeniería de software
El profesional responsable de la implementación de la interfaz puede ayudar
con una evaluación certera del balance entre una interfaz ideal (sin
limitaciones) y una no ideal (con limitaciones pero alcanzable).
Unidad 4
Diseño de interfaces de usuario
… (6)

Ergonomía del diseño de la interfaz desde el
enfoque del profesional de la computación:



El diseño de pantallas comienza con una discusión con el
usuario (cliente) haciéndolo participe en el proceso del
diseño de la interfaz.
Es importante cultivar la satisfacción personal del usuario
y, consecuentemente, mejorar la aceptación del sistema,
permitiendo que las personas mejoren sus conocimientos
mientras utilizan el sistema.
Para diseñar un buen trabajo, la interfaz debe ser, entre
otras cosas, lo más fácil, amigable y agradable posible
creando un dialogo con el sistema lo más natural posible.
Ingeniería de software
Unidad 4
Diseño de interfaces de usuario
… (7)

Consideraciones a la hora de diseñar pantallas:

Simplicidad, claridad y facilidad de comprensión


Ubicación de la información


Utilizar los tipos, tamaños y fuentes de letra apropiados.
Recopilación completa y correcta de información



Poner solo la información esencial para la toma de una decisión o ejecución de una
acción (no se debe inundar con información, pero tampoco hay que obligar al usuario a
recordar información importante).
Cómo formatear la información


Fijar un punto de partida obvio (esquina superior izquierda), reservar áreas especificas
para presentar diferentes tipos de información y proporcionar una composición que guste
visualmente (equilibrada, simétrica y simple).
Qué información presentar


Será necesario tener claridad visual, de forma que los elementos estén agrupados de
forma comprensible y con significado.
La interfaz debería incluir una protección contra entradas incorrectas o aberrantes.
Además se debe recopilar la información necesaria con un mínimo de pulsaciones y sin
redundancia.
Uso de colores

Ingeniería de software
Añade una nueva dimensión a la facilidad de uso ya que atrae la atención del usuario si
se usa de forma adecuada. Si se abusa del uso de colores provocara distracción.
Diseño de interfaces de usuario
… (8)

Consideraciones a la hora de diseñar pantallas …

Ejemplo: [GNOME Human Interface Guidelines 2.0 ]
Unidad 4
Diseño de interfaces de usuario
… (9)

El diseño de pantallas es un proceso ordenado que inicia con los
requisitos y finaliza con la implementación.
Análisis de los requisitos
Perfil del
usuario
Análisis de
las tareas
Restricciones
Principios
Generales
De diseño
Objetivos de
Facilidad de uso
Diseño, prueba y desarrollo
Diseño
conceptual
Maqueta
del diseño
conceptual
Evaluación
iterativa
Ingeniería de software
Guía de
estilo
Guía de
estilo
Normas
del diseño
de pantallas
Diseño
Detallado
de pantallas
Prototipado
Y evaluación
interactiva
Evaluación
iterativa
Instalación
Funcionalidad
completa
Implementación
Instalación y feedback
del usuario
Unidad 4
Diseño procedimental



El diseño procedimental se realiza después de los
diseños de datos, arquitectónico y de interfaz.
En un mundo ideal, la especificación procedimental
necesaria para definir los detalles de los algoritmos
se expresarían en un lenguaje natural, sin embargo,
los detalles procedimentales no deben tener
ambigüedades, y la falta de ambigüedad en el
lenguaje natural no es nada natural.
El detalle procedimental frecuentemente es
representado por pseudocódigo, aunque también se
cuenta con una notación gráfica de diseño acorde a
los principios de la programación estructurada.
Ingeniería de software
Unidad 4
Diseño procedimental … (2)


La notación gráfica dice más que mil palabras, describen de
forma excelente el detalle procedimental. Sin embargo, debe
emplearse correctamente ya que una notación gráfica incorrecta
conducirá a software incorrecto.
El diagrama de flujo fue en su día la representación más
ampliamente utilizada para el diseño procedimetal.
Desgraciadamente, también fue el método del que más se
abuso.
Secuencia
Selección
Repetición
V
F
V
V
F
V
F
Ingeniería de software
V
F
V
F
F
Unidad 4
Diseño procedimental … (3)

Otra herramienta de diseño gráfico son los diagramas de cajas
 También son conocidos como diagramas N-S (por sus creadores
Nassi y Shneiderman)
 Surgieron con la finalidad de desarrollar una representación
procedimental que no viole las construcciones estructuradas.
 Tienen las siguientes características:




Dominio funcional bien definido y claramente definido en una
notación gráfica
La transferencia de control arbitrario es imposible
El alcance de los datos locales se puede determinar fácilmente
La recursividad es fácil de representar
Selección
Secuencia
Condición
Primera línea
F
V
Repetición
Condición
Valor
Valor
Condición del ciclo
...
Siguiente tarea
Siguiente tarea +1
Condición del ciclo
Ingeniería de software
Unidad 4
Diseño procedimental … (4)

Otra forma de especificación para el diseño detallado es un
lenguaje de diseño de programas, también conocido como
pseudocódigo
 Es un lenguaje que utiliza un vocabulario reducido de un
lenguaje como el inglés o el español y la sintaxis de un lenguaje
de programación estructurado.
 Estos lenguajes de diseño estructurado deberían tener las
siguientes características:




Ingeniería de software
Una sintaxis fija de palabras clave para todas las construcciones
estructuradas, declaraciones de datos y características de
modularidad.
Sintaxis libre en lenguaje natural que describa las características del
procesamiento.
Facilidades para la declaración de datos que debería incluir tanto
estructuras de datos simples como complejas.
Definición de subprograma y técnicas de invocación que soporten
varios modos de descripción de interfaz.
Unidad 4
Documento de especificación

Puede utilizarse una plantilla
[Pressman, 2002] para el
documento de especificación.
 Cada párrafo numerado trata
diferentes aspectos del modelo
del diseño.
 Las secciones numeradas de la
especificación del diseño se
completan a medida que el
diseñador refina su
representación del software.
 Mucha de la información
utilizada se obtiene de la
especificación del sistema y del
modelo del análisis.
Ingeniería de software
Presentación
Tabla de contenido
Índice de figuras
Índice de tablas
I. Ámbito
A. Objetivos del sistema
B. Principales requisitos del software
C. Restricciones de diseño
II. Diseño de datos
A. Objetos de datos y estructuras de datos resultantes
B. Estructuras de archivo y bases de datos
1. Estructura externa de archivo
a. Estructura lógica
b. Descripción del registro lógico
c. Método de acceso
2. Datos globales
3. Referencias cruzadas de datos y archivo
III. Diseño arquitectónico
A. Revisión de datos y flujo de control
B. Estructura del programa
IV. Diseño de la interfaz
A. Especificación de la interfaz hombre-máquina
B. Normas de diseño de la interfaz hombre-máquina
C. Diseño de la interfaz externa
1. Interfaces con datos externos
2. Interfaces con sistemas o dispositivos externos
D. Normas de diseño de la interfaz interna
V. Diseño procedimental
Por cada módulo
A. Descripción del proceso
B. Descripción de la interfaz
C. Descripción del lenguaje de diseño (u otro)
D. Módulos usados
E. Estructuras de datos internos
F. Comentarios/restricciones/limitaciones
VI. Referencias cruzada de requisitos
VII. Recursos de pruebas
1. Directrices para las pruebas
2. Estrategias de integración
3. Consideraciones Especiales
VIII. Notas especiales
IX. Apéndices
Introducción al diseño
orientado a objetos


Al igual que para el diseño estructurado, para el diseño orientado
a objetos también es posible definir una pirámide de diseño de
software.
Capa de subsistema


Capa de clases y objetos


Contiene la jerarquía de clases, que permiten al
sistema ser creado usando generalizaciones y cada
vez especializaciones más acertadas.
Capa de mensajes


Contiene una representación de cada uno de los
subsistemas, necesarios para conseguir los requisitos
definidos por el cliente e implementar la infraestructura
que soporte los requerimientos.
Contiene los detalles de diseño, que permiten a cada
objeto comunicarse con sus colaboradores.
Capa de responsabilidades

Contiene estructuras de datos y diseños algorítmicos
para todos los atributos y operaciones de cada objeto.
Diseño
de responsabilidades
Diseño
de mensajes
Diseño
de clases y objetos
Diseño
de subsistemas
El modelo del Diseño
Introducción al diseño orientado
a objetos… (2)

Cada uno de los elementos del modelo del análisis proporciona
información necesaria para crear un modelo de diseño .
Modelo de
tarjetas
CRC
Atributos,
operaciones,
colaboraciones
Modelo de
objetos
relacionales
Casos de
uso
Modelo de
comportamiento
de objetos
Diseño
de responsabilidades
Diseño
de mensajes
Diseño
de clases y objetos
Diseño
de subsistemas
El modelo del Análisis
El modelo del Diseño
Transformación del modelo de análisis en el modelo del diseño
Diseño estructurado frente al
diseño orientado a objetos


El diseño del software ha evolucionado del
paradigma de programación estructurada al
paradigma orientado a objetos.
Las características en comunes entre ambos
paradigmas son:




Un mecanismo para la transformación de un modelo de
análisis en una representación del diseño
Una notación para representar componentes funcionales y
sus interfaces
Heurísticas para el refinamiento y la partición, y
Consejos para valorar la calidad.
Diseño estructurado frente al diseño
orientado a objetos… (2)


Las fases de obtención de requisitos se corresponden en ambos
paradigmas.
Las clases del paradigma orientado a objetos, obtenidas en la fase de
análisis, se corresponden con el diseño arquitectónico del paradigma
estructurado.


Esto es así ya que las clases se toman como los módulos principales del software.
A partir del diseño detallado se requiere tener conocimiento del ambiente de
implementación para llevar a cabo las consideraciones de rendimiento y
control, así, el diseño orientado a objetos se corresponde con el diseño
detallado.
Estrategias de diseño

Es recomendable tomar decisiones
generales sobre las estrategias de diseño a
seguir. Estas decisiones se relacionan con
los siguientes aspectos:




Arquitectura
Robustez
Reuso
Extensibilidad
Estrategias de diseño… (2)

Arquitectura




Se refiere a la organización de las clases dentro del sistema.
Se debe refinar y detallar el modelo arquitectónico definido durante el análisis,
pudiéndose cambiar algunos aspectos considerados inicialmente.
El conocimiento y funcionalidad asignada a cada clase se ve como la inteligencia de
cada clase dentro del sistema.
Es responsabilidad del diseño decidir como distribuir la inteligencia entre las clases.
Se consideran tres alternativas:

Minimizar el número de clases inteligentes



La gran mayoría de las clases con inteligencia similar



En el caso más extremo solo se requiere comprender el flujo de control del objeto principal para
entender toda la aplicación.
Este enfoque vuelve más compleja la extensibilidad del sistema, ya que cualquier cambio en el
objeto principal afecta potencialmente la lógica de la aplicación.
Lograr este enfoque es muy complicado ya que los objetos varían en cuanto a sus
responsabilidades, su razón de ser depende de la aplicación en si.
La ventaja estribaría en que los objetos serían mas pequeños y fáciles de comprender. La
desventaja es que aún así deberían ser objetos muy especializados, lo cual dificulta la
extensibilidad del sistema.
Un balance entre los dos enfoques anteriores


Solo se busca inteligencia similar entre las clases de control
Las clases de borde y entidad no deberían se inteligentes, esto permitirá mantener la lógica
introducida durante el modelo de requisitos y el modelo del análisis.
Estrategias de diseño… (3)

Robustez
 Debe ser uno de los objetivos principales del diseño.
 El sistema debe estar protegido contra errores y ofrecer
diagnósticos que permitan identificar las fallas.
 Consideraciones relacionadas con la robustez





El sistema debe estar protegido contra parámetros incorrectos
proporcionados por el usuario.
El sistema no debe optimizarse hasta que este funcione de manera
correcta.
El sistema debe incluir estructuras de datos de tamaño variable, sin
límites predefinidos.
El sistema debe instrumentar un monitoreo de rendimiento y
búsqueda de errores.
El encapsulamiento es fundamental para la robustez del sistema.
Estrategias de diseño… (4)

Reuso


Es un aspecto fundamental del diseño. Cuanto más se
pueda reutilizar el código mejor será la robustez del
sistema.
Estrategias para mejorar el reuso:
 Uso apropiado de la herencia



Se toman los aspectos comunes a clases similares utilizando
superclases comunes.
Este enfoque es efectivo si las diferencias entre clases son
pequeñas y la similitud grande.
El encapsulamiento


Es muy efectivo para lograr el reuso
Se aplica a nivel objeto y componentes
Estrategias de diseño… (5)

Extensibilidad


La mayor parte de los sistemas son extendidos de forma
imprevista
Perspectivas de extensibilidad:
 Se deben encapsular las clases para ocultar su estructura
interna a las otras clases.
 No se deben exportar estructuras de datos desde un
método.
 Una clase solo se debe comunicar de forma directa con sus
clases vecinas.
 Se deben evitar expresiones que requieran un
conocimiento explícito de los tipos de objetos (usar
polimorfismo).
 Se debe distinguir entre operaciones privadas y públicas.