Ingeniería de Software II

Lic. Mario Alfredo Guevara

Ingeniería de Software II
Aspectos sobre el diseño de los sistemas.
•El diseño de Software requiere de una serie de
técnicas y estándares para su elaboración
adecuada.
•Hoy en día, se emplean técnicas que ayudan a la
notación y claridad del diseño, con el fin de que
sean transparentes para el usuario como para el
ingeniero de software.

Lic. Mario Alfredo Guevara 3

 OBJETIVO

Proporcionar al estudiante
los conocimientos teórico-
técnicos sobre el diseño de
sistemas.

Lic. Mario Alfredo Guevara 4

La notación es muy importante para la
comunicación, una notación estandarizada
permitirá una comunicación fácil y adecuada
entre las partes involucradas en el desarrollo
de software. El estándar mundial que se
emplea es el UML.

Lic. Mario Alfredo Guevara 5

Arquitectura de Software

Especificación de Requerimientos del sistema (SRS)

En este camino hay mucho por hacer.

¿Comenzamos a programar para terminar lo
antes posible?
- ¿Cuáles serían los riesgos?

Sistema instalado y funcionando

Lic. Mario Alfredo Guevara
 ¿Qué es UML?

•El Lenguaje Unificado de Modelado (UML) fue creado para

forjar un lenguaje de modelado visual común y semántica y
sintácticamente rico para la arquitectura, el diseño y la
implementación de sistemas de software complejos, tanto en
estructura como en comportamiento. UML tiene aplicaciones
más allá del desarrollo de software, p. ej., en el flujo de
procesos en la fabricación.
•UML no es un lenguaje de programación, pero existen
herramientas que se pueden usar para generar código en
diversos lenguajes usando los diagramas UML. UML guarda
una relación directa con el análisis y el diseño orientados a
objetos.
Lic. Mario Alfredo Guevara 7
 La finalidad de UML

• Brindar a arquitectos de sistemas, ingenieros y

desarrolladores de software las herramientas para el
análisis, el diseño y la implementación de sistemas basados
en software, así como para el modelado de procesos de
negocios y similares.
•Hacer progresar el estado de la industria permitiendo la
interoperabilidad de herramientas de modelado visual de
objetos. No obstante, para habilitar un intercambio
significativo de información de modelos entre
herramientas, se requiere de un acuerdo con respecto a la
semántica y notación.

Lic. Mario Alfredo Guevara 8

 Diagramas de casos de uso

• El diagrama de casos de uso representa la forma en cómo un cliente

(actor) opera con el sistema en desarrollo, además de la forma, tipo y
orden en como los elementos interactúan (operaciones o casos de
uso).

Lic. Mario Alfredo Guevara 9

 Diagramas de casos de uso

Como ejemplo a la
definición anterior.
tenemos el caso de un
sistema de ventas en
que el rol de vendedor
Una definición previa, es
con respecto al sistema
que un actor es un rol que
un usuario juega con puede ser realizado por
respecto al sistema. Es un vendedor o bien por
importante destacar el uso el jefe de local.
de la palabra rol, pues con
esto se especifica que un
actor no necesariamente
representa a una persona en
particular. sino más bien la
labor que realiza frente al
sistema.
Lic. Mario Alfredo Guevara 10
 Diagramas de casos de uso

Es una operación/tarea
específica que se realiza
tras una orden de algún
agente externo, sea desde
una petición de un actor a
bien desde la invocación
desde otro caso de uso.

Lic. Mario Alfredo Guevara 11

 Diagramas de casos de uso
Asociación
Es el tipo de relación más
básica que indica la
invocación desde un actor o
caso de uso a otra operación
(caso de uso). Dicha relación
se denota con una flecha
Lic. Mario Alfredo Guevara
Dependencia
o Es una forma muy particular
Instanciación de relación entre clases. en
la cual una clase depende
de otra, es decir, se
instancia(se crea) Dicha
relación se denota con una
flecha punteada
12
 Diagramas de casos de uso

Generalización Este tipo de relación es uno Extends

de los más utilizados. se recomienda
cumple una doble función utilizar cuando un
dependiendo de su caso de uso es
estereotipo, que puede ser
de uso o de herencia similar a otro
Este tipo de relación está
(características)
orientado exclusivamente
para casos de uso (y no para
actores)

Lic. Mario Alfredo Guevara 13

 Diagramas de casos de uso

Use se recomienda utilizar

cuando se tiene un
conjunto de
características que son
similares en más de un
caso de uso y no se
desea mantener copiada
la descripción de la
característica.

De lo anterior cabe mencionar que tiene el mismo paradigma

en diseño y modelamiento de clases, en donde está la duda
clásica de usar o heredar.
Lic. Mario Alfredo Guevara 14
 Ejemplo:
• Como ejemplo está el caso de una máquina recicladora:

• Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o
aceptar:
• Registrar el número de ítems ingresados.
• Imprimir un recibo cuando el usuario lo solicita:
• Describe lo depositado.
• El valor de cada ítem.
• Total.
• El usuario/cliente presiona el botón de comienzo.
• Existe un operador que desea saber lo siguiente:
• Cuántos ítems han sido retornados en el día.
• Al final de cada día el operador solicita un resumen de todo lo depositado en el día.
• El operador debe además poder cambiar:
• Información asociada a ítems.
• Dar una alarma en el caso de que:
• Ítem se atora.
• No hay más papel.
Lic. Mario Alfredo Guevara 15
 Ejemplo:

Como una primera aproximación se identifican a los actores

que interactúan con el sistema

Lic. Mario Alfredo Guevara 16

 Ejemplo:

Luego, se sabe que un cliente puede depositar ítem y un

operador puede cambiar la información de un ítem o bien
puede imprimir un informe

Cambiar un ítem
Depositar un ítem

Generar reporte
Lic. Mario Alfredo Guevara
diario 17
 Ejemplo:

Además se puede notar que un ítem puede ser una botella,

un tarro o una jaba:

Depositar un ítem
<<extends>>
<<extends>> <<extends>>

Depositar Botella Depositar tarro Depositar jaba

Lic. Mario Alfredo Guevara 18
 Ejemplo:
Otro aspecto es la impresión de comprobantes, que puede ser realizada
después de depositar algún ítem por algún cliente o bien puede ser
realizada a petición de un operador.

Depositar un ítem Generar reporte

Diario
<<uses>>
<<uses>>

Imprimir
Lic. Mario Alfredo Guevara 19
 Ejemplo:

El diseño completo del

diagrama de uso es:

Lic. Mario Alfredo Guevara 20

 21
Lic. Mario Alfredo Guevara
 Diseño de la Interfaz de Usuario

•Normalmente no se contratan
especialistas.
•Hay casos en los cuales es más normal:
videojuegos y sitios web.
•Entonces, también hay que diseñar la
interfaz de usuario y diseñar el
software que la implementa.
Lic. Mario Alfredo Guevara
 Algunas Consideraciones

1. La interfaz de usuario debe ser diseñada

considerando las habilidades, experiencia y
expectativas de los usuarios.
2. Los usuarios muchas veces juzgan al sistema por su
interfaz más que por su funcionalidad.
3. Una interfaz “mal” diseñada puede causar que un
usuario cometa errores catastróficos.
4. Muchos sistemas nunca son usados debido a un mal
diseño de la interfaz de usuario.
Lic. Mario Alfredo Guevara
 Principios Generales
1. Familiaridad: utilizar términos familiares a los usuarios.
2. Consistencia: menús y comandos con el mismo formato y significado en toda la aplicación.
3. Mínima sorpresa: misma acción en contextos comparables produzcan efectos
comparables.
4. Recuperabilidad: permitir la recuperación frente a errores cometidos por el usuario,
brindar:
1. Confirmación de acciones destructivas.
2. Recursos para deshacer en varios niveles.
5. Guía al usuario: proveer ayuda en varios niveles y formas (por ejemplo, ayuda sensitiva al
contexto).
6. Diversidad de usuarios: tener en cuenta distintos tipos de usuarios (discapacidades,
usuarios expertos, usuarios inexpertos, etc.).
Lic. Mario Alfredo Guevara
 Aspectos Importantes

• Dos aspectos son clave para diseñar la interfaz de usuario

• Forma de interacción del usuario con el sistema.
• Forma de presentar la información al usuario.
• Una interfaz coherente debe integrar las dos
• Eso puede ser difícil y hay que llegar a soluciones de compromiso
entre los que podemos mencionar:
• Forma de interacción.
• Estilo de presentación.
• Experiencia de los usuarios.
• Equipos disponibles.
• Otros.

Lic. Mario Alfredo Guevara

 Presentación de la Información

Una buena guía de diseño es mantener separado el software de

presentación de la propia información

Información que se Presentación

mostrara software

Display

Lic. Mario Alfredo Guevara

 Tener en Cuenta

•Al diseñar la presentación tener en cuenta:

•¿El usuario está interesado en la información en forma
precisa o relaciones entre valores de datos?
•¿Los cambios en los datos deben ser mostrados
inmediatamente al usuario?
•¿El usuario debe realizar alguna acción si la información
cambia?
•¿El usuario debe interactuar con los datos desplegados
mediante manipulación directa en la interfaz?
•¿La información debe ser desplegada textual o numérica?
Lic. Mario Alfredo Guevara
 Acerca de los Mensajes de Error

• El diseño de los mensajes de error es

crítico. Mensajes de error mal diseñados
pueden significar que un usuario rechace
el sistema.
• Los mensajes deben ser educados,
concisos, consistentes y constructivos.

Lic. Mario Alfredo Guevara

Factores para Diseño de Mensajes

Cultura
Estilo

Nivel de
Habilidad
Experiencia

Contexto

Lic. Mario Alfredo Guevara

 ¿Cuál es Mejor para el Usuario?

Error #27

? Identificador de paciente no válido

Aceptar Cancelar

El paciente J. Bates no está registrado

Seleccione:
Pacientes para listado de pacientes registrados
Reintentar para reingresar el nombre del paciente
Ayuda para más información

Pacientes Ayuda Reintentar Cancelar

Lic. Mario Alfredo Guevara

 Prototipado de Interfaz de Usuario

•Prototipado que involucra al usuario es la única forma

práctica de diseñar y desarrollar las interfaces de
usuario gráficas.
•Experiencia directa por parte de usuarios con la
interfaz.
•Puede ser en papel en primeras etapas del
desarrollo.
•Luego son prototipos automáticos.

Lic. Mario Alfredo Guevara