Guía 1 Escuela de Proyecto Desarrollo Software

Tecnología

Fase de Transición

Tema Nº12:
RUP Y SUS FASES
TEMA 01 Teoría de los
Indicador de logro Nº12:
TEMA Nº1:
Diseña y estructura el modelado de Diseño con el diagrama estructural del lenguaje
de modelamiento unificado para la implementación y prueba de un software,
aplicando las buenas prácticas de Testeo validando la calidad del software y
1
funcionalidad de la aplicación.
.
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

ARQUITECTURA DE SOFTWARE
Subtema 1.1:
Conceptos
La Arquitectura del Software AS es la parte de la ingeniería del software que se ocupa de
la descripción y el tratamiento de un sistema como un conjunto de componentes, que
facilite su organización en los diferentes subsistemas que lo forman. Esto es útil, entre
otros aspectos, para poder asignarlos a equipos de trabajo y que puedan llevar a cabo el
desarrollo del sistema de una manera organizada y eficiente. Este campo surge ante la
necesidad de describir sistemas software complejas, descomponerlos en un conjunto de
componentes y ver qué relaciones existen entre ellos. Por lo tanto, la AS aporta una visión
abstracta de alto nivel, posponiendo el detalle de cada uno de los módulos definidos a
pasos posteriores del diseño.
Aunque intuitivamente el concepto de AS es bastante claro, no se ha dado hasta el
momento una definición que satisfaga por completo a todos aquellos que trabajan en este
campo. Quizás, para obtener una visión de conjunto, lo más adecuado sea considerar
varias definiciones a la vez. A continuación, se mencionan varias de ellas ordenadas
cronológicamente:
 Posiblemente, la primera definición fue la dada en 1993 por David Garlan y
Mary Shaw en la que exponen objetivos y aspectos a tener en cuenta en la AS:
“Más allá de los algoritmos y estructuras de datos, la computación, el diseño
y especificación de la estructura global del sistema emerge como un nuevo
tipo de problema. Los detalles estructurales incluyen: la organización
general y la estructura de control global; los protocolos de comunicación,
sincronización y acceso a datos; la asignación de funcionalidad a los
elementos de diseño; la distribución física; la composición de los elementos
de diseño; su escalabilidad y los aspectos de rendimiento; y la selección
entre alternativas de diseño”.
 Se puede considerar una segunda definición, quizás la más breve y sencilla, y a
la vez la más aceptada, dada por David Garlan y Dewayne Perry en 1995: “La
arquitectura del software está compuesta por la estructura de los componentes
de un programa o sistema, sus interrelaciones, y los principios y reglas que
gobiernan su diseño y evolución a lo largo del tiempo”
 A continuación, se presenta la definición dada por Clements en 1996 que puede
considerarse como una definición general, amplia y flexible, aunque por ello
pueda parecer incompleta y algo ambigua. Sin embargo, es válida tanto para
aquellos que desean una visión descriptiva de la AS (punto de vista
representado por Garlan) como para los que utilizan una visión de proceso
(representada por Perry):

2
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

“La arquitectura del software es, a grandes rasgos, una vista del sistema
que incluye los componentes principales del mismo, la conducta de esos
componentes según se percibe desde el resto del sistema, y las formas en
que los componentes interactúan y se coordinan para alcanzar el objetivo
del sistema. La vista arquitectónica es una vista abstracta de un sistema,
aportando el más alto nivel de compresión y la supresión del detalle
inherente a la mayor parte de abstracciones”.
 Otra definición que ha sido utilizada por la comunidad de ingeniería de software
es la de RUP, citada por Phillipe Kruchten en 1995, que define lo siguiente:
“La arquitectura de software abarca un conjunto de decisiones significativas
sobre la organización del sistema de software. Estas decisiones abarcan: la
selección de los elementos estructurales y sus interfaces, con los que se
compone el sistema, junto con su comportamiento tal como se especifica en
las colaboraciones entre esos elementos, la composición de esos
elementos estructurales y de comportamiento en subsistemas
progresivamente más grandes, y el estilo arquitectónico que guía esta
organización”.
 En el año 2000 se acordó definir oficialmente la AS según figura en el
documento IEEE Std 1471-2000: “La arquitectura del software es la
organización fundamental de un sistema encarnada en sus componentes, las
relaciones entre ellos y el entorno, y los principios que dirigen su diseño y
evolución.
Subtema 1.2:
Importancia
Para empezar, de una u otra forma, muchos stakeholders están interesados en la
arquitectura:
 El analista de sistemas, que lo utiliza para organizar y articular los requisitos
y comprender las limitaciones tecnológicas y riesgos.
 Los usuarios finales o clientes, que lo utilizan para visu alizar en un alto
nivel lo que están comprando.
 El gerente de proyecto de software, que lo utiliza para organizar el equipo y
el plan de desarrollo.
 Los diseñadores, que la utilizan para comprender los principios subyacentes
y localizar los límites de su propio diseño.
 Otras organizaciones de desarrollo (si el sistema es abierto), que lo utilizan
para comprender cómo interactuar con él.
 Arquitectos, que la usan para razonar acerca de la evolución o la
reutilización. Al respecto, Bass y sus colegas (2003), en un libro dedicado a

3
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

la arquitectura de software, identifican tres razones clave por las cuales la

arquitectura del software es importante:
 Las representaciones de la arquitectura del software permiten la
comunicación entre los diferentes stakeholders.
 La arquitectura resalta las decisiones iniciales relacionadas con el diseño
que tendrán un impacto en todo el proceso de desarrollo posterior.
 La arquitectura encarna un modelo relativamente pequeño, intelectualmente
tratable, de la forma en que un sistema se estructura y sus componentes se
entienden entre sí; este modelo e s transferible a través de sistemas; en
particular, se puede aplicar a otros sistemas que exhiben requisitos
parecidos y puede promover reutilización en gran escala.

Subtema 1.3:
Creación del modelo de diseño: Capas y Realizaciones de Diseño
El modelo de diseño es usado para el control que se debe ejercer desde el sistema.
Algunos controles se determinarán por medio de diferentes parámetros de sistemas tales
como las aplicaciones y las entradas. Probablemente se necesite diseñar ciertos controles
de calidad. Por ejemplo, todas las entradas deben preparase en forma consistente para
mantener la confianza del sistema y evitar posibles errores en los procedimientos.
Características:
 Facilita la identificación de componentes en un modelo físico y concreto,
como paso previo a la implementación.
 Estructurado por capas y realizaciones de diseño mediante clases
estereotipadas de diseño y subsistemas.
 Utilizado por los desarrolladores para la realización del diseño del sistema 
Debe mantenerse en todo el ciclo de vida del software
 Da forma al sistema para su implementación y funcionalidad
Ejm: Utilizando el RSA para la creación del modelo de diseño

4
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

A cada paquete se le asigna el estereotipo <>

Subsistemas y librerías

Subtema 1.4:
Estructura interna de un subsistema y librerías de diseño
En la siguiente tabla se muestra el contenido de cada subsistema y librerías compuesto
por las clases de diseño y estereotipos:

5
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

Subsistemas y librerías

Subtema 1.4:
Arquitectura del diseño para post implementación
Presenta los diferentes diagramas del diseño en donde se asocian los artefactos del
diseño según las capas y subsistemas de aplicación Estereotipos de Asociaciones
 LINK: Relación entre la página cliente y un recurso del lado del servidor.
 BUILD: Relación entre la página servidor y una página cliente. Identifica la salida
del HTML durante la ejecución de una página servidor.
 SUBMIT: Relación entre el formulario y una página servidor.
 REDIRECT: Relación entre una página cliente o servidor y otra página.
 FORWARD: Relación entre una página servidor y otra página servidor.
 INCLUDE: Entre una página servidor y otra página servidor. Durante la ejecución
de la página esta asociación indica que la página incluida es procesada.
 OBJECT: Relación dibujada entre la página cliente y otra clase (esta puede ser
un applet, activex o cualquier componente).

6
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

Capa de Presentación:

Ejemplo Diagrama de Navegación:

Diagrama de Navegación

7
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

Capa de Control
Representación del diseño de la Clase Control (Modelo de Análisis)

Servlets, clases Java que procesan dinámicamente las solicitudes y construyen respuestas.

Capa del Modelo

Representación del diseño de la Clase Entity (Modelo de Análisis)

Subtema 1.4:
Patrones de diseño
Como analistas y programadores vamos desarrollando a diario nuestras habilidades para
resolver problemas usuales que se presentan en el desarrollo del software. Por cada
problema que se nos presenta pensamos distintas formas de resolverlo, incluyendo
soluciones exitosas que ya hemos usado anteriormente en problemas similares. Es así
que a mayor experiencia que tengamos, nuestro abanico de posibilidades para resolver
un problema crece, pero al final siempre habrá una sola solución que mejor se adapte a
nuestra aplicación. Si documentamos esta solución, podemos reutilizarla y compartir esa
información que hemos aprendido para resolver de la mejor manera un problema
específico.

8
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

Los patrones del diseño tratan los problemas del diseño que se repiten y que se
presentan en situaciones particulares del diseño, con el fin de proponer soluciones a ellas.
Por lo tanto, los patrones de diseño son soluciones exitosas a problemas comunes.
Asimismo, son descripciones de clases cuyas instancias colaboran entre sí. Cada patrón
es adecuado para ser adaptado a un cierto tipo de problema. Para describir un caso
debemos especificar:
 Nombre
 Propósito o finalidad
 Sinónimos (otros nombres por los que puede ser conocido)
 Problema al que es aplicable
 Estructura (diagrama de clases)
 Participantes (responsabilidad de cada clase)
 Colaboraciones (diagrama de interacciones)
 Implementación (consejos, notas y ejemplos)
 Otros patrones con los que está relacionado
Patrones GOF
El catálogo más famoso de patrones se encuentra en “Design Patterns: Elements
of Reusable Object-Oriented Software”, de Erich Gamma, Richard Helm, Ralph
Johnson y John Vlissides, 1995, Addison-Wesley, también conocido como el libro
GOF (Gang-Of-Four).
Los autores de este patrón recopilaron 23 patrones que son utilizados por muchos
diseñadores de software orientado a objetos.

Patrones de diseño según GOF

9
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

En la figura se muestra la clasificación de los patrones GOF considerando dos aspectos:

el propósito para el que han sido definidos y el ámbito. Según el propósito para el que han
sido definidos, existen 3 tipos:
 Creacionales: Solucionan problemas de creación de instancias. Nos ayudan
a encapsular y abstraer dicha creación.
 Estructurales: Solucionan problemas de composición (agregación) de
clases y objetos.
 De Comportamiento: Dan soluciones respecto a la interacción y
responsabilidades entre clases y objetos, así como los algoritmos que
encapsulan.
Según el ámbito, se clasifica en patrones de clase y de objeto, es así que se cuenta
con 6 tipos:
Creacionales
 Creacional de la Clase Los patrones creacionales de Clases usan la
herencia como un mecanismo para lograr la instanciación de la Clase. Por
ejemplo, el método Factoría.
 Creacional del objeto Los patrones creacionales de objetos son más escala
bles y dinámicos comparados de los patrones creacionales de Clases. Por
ejemplo, la Factoría abstracta y el patrón Singleton.
Estructurales
 Estructural de la Clase
Los patrones estructurales de Clases usan la herencia para proporcionar
interfaces más útiles combinando la funcionalidad de múltiples Clases. Por
ejemplo, el patrón Adaptador (Clase).
 Estructural de Objetos
Los patrones estructurales de objetos crean objetos complejos agregando
objetos individuales para construir grandes estructuras. La composición del
patrón estructural del objeto puede ser cambiado en tiempo de ejecución, el
cual nos da flexibilidad adicional sobre los patrones estructurales de Clases.
Por ejemplo el Adaptador (Objeto), Facade, Bridge, Composite.
Comportamiento
 Comportamiento de Clase
Los patrones de comportamiento de Clases usan la herencia para distribuir
el comportamiento entre Clases. Por ejemplo, Interpreter.
 Comportamiento de Objeto

10
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

Los patrones de comportamiento de objetos nos permiten analizar los

patrones de comunicación entre objetos interconectados, como objetos
incluidos en un objeto complejo. Ejemplo Iterator, Observer, Visitor.
La figura 11.1b muestra la plantilla que utilizan los autores de patrones GOF para
describir un patrón.

Plantilla de Patrones GOF.

Subtema 1.5:
Patrones J2EE
Con la aparición del J2EE, todo un nuevo catálogo de patrones de diseño apareció.
Desde que J2EE es una arquitectura por sí misma que involucra otras arquitecturas,
incluyendo servlets, JavaServer Pages, Enterprise JavaBeans, y más, merece su propi o
conjunto de patrones específicos para diferentes aplicaciones empresariales.
De acuerdo al libro "J2EE PATTERNS Best Practices and Design Strategies", existen 5
capas en la arquitectura J2EE:
Cliente: Esta capa corresponde a lo que se encuentra en el computador del cliente. Es la
interfaz gráfica del sistema y se encarga de interactuar con el usuario. J2EE tiene soporte
para diferentes tipos de clientes incluyendo clientes HTML, applets Java y aplicaciones
Java.
 Presentación: La capa de presentación es la que ve el usuario, comunica y
captura la información proveniente de él.
 Negocio: Es donde reside el núcleo del sistema. Se comunica con la capa de
presentación para recibir y enviar los datos al usuario.

11
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

 Integración: La capa de integración es donde residen los datos y es la

encargada de acceder a los mismos. Contiene uno o más gestores de base
de datos. Recibe solicitudes de almacenamiento o recuperación de
información desde la capa de negocio.
 Recurso: Es la capa donde reside la base de datos y sistemas legados.
Nombre Quiénes la componen Dónde se ubica
Capa Cliente Aplicaciones cliente, applets, PC Cliente
aplicaciones y otras GUIs
Capa de JSP, Servlet y otras UIs Servidor J2EE
Presentación
Capa de Negocios EJBs y otros objetos de Servidor J2EE
negocios
Capa de JMS, JDBC Servidor J2EE
Integración
Capa de Bases de Datos, Sistemas Servidor BD
Recursos Legados
Tabla Capas de la Arquitectura J2EE
Existen 15 patrones J2EE que están divididos en 3 de las capas descritas: presentación,
negocio e integración. Cabe señalar que todos estos patrones poseen tanto
características de diseño como de arquitectura.
Capa de Presentación
Patrón Descripción
Decorating Filter / Un objeto que está entre el cliente y los
Intercepting Filter componentes Web. Este procesa las
peticiones y las respuestas.
Front Controller/ Front Un objeto que acepta todos los
Component requerimientos de un cliente y los direcciona
a manejadores apropiados. El patrón Front
Controller podría dividir la funcionalidad en 2
diferentes objetos: el Front Controller y el
Dispatcher. En ese caso, El Front Controller
acepta todos los requerimientos de un
cliente y realiza la autenticación, y el
Dispatcher direcciona los requerimientos a
manejadores apropiada.
View Helper Un objeto helper que encapsula la lógica de

12
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

acceso a datos en beneficio de los

componentes de la presentación. Por
ejemplo, los JavaBeans pueden ser usados
como patrón View Helper para las páginas
JSP.
Composite view Un objeto vista que está compuesto de otros
objetos vista. Por ejemplo, una página JSP
que incluye otras páginas JSP y HTML
usando la directiva include o el action
include es un patrón Composite View.
Service To Worker El Controlador actúa como Front Controller,
pero con un factor importante: aquí el
Dispatcher (el cual es parte del Front
Controller) usa View Helpers a gran escala y
ayuda en el manejo de la vista.
Dispatcher View Es con el controlador actuando como Front
Controller, pero con un asunto importante:
aquí el Dispatcher (el cual es parte del Front
Controller) no usa View Helpers y realiza
muy poco trabajo en el manejo de la vista. El
manejo de la vista es manejado por los
mismos componentes de la Vista.

Capa de Negocio
Patrón Descripción
Business Delegate Un objeto que reside en la capa de
presentación y en beneficio de los otros
componentes de la capa de presentación
llama a métodos remotos en los objetos de la
capa de negocios.
Value Object/ Data Transfer Un objeto serializable para la transferencia
Object/ Replicate Object de datos sobre la red.
Session Façade/ Session Entity El uso de un bean de sesión como una
Façade/ Distributed Façade fachada (facade) para encapsular la
complejidad de las interacciones entre los
objetos de negocio y participantes en un flujo
de trabajo. El Session Façade maneja los
objetos de negocio y proporciona un servicio

13
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

de acceso uniforme a los clientes.

Aggregate Entity Un bean entidad que es construido o es
agregado a otros beans de entidad.
Value Object Assembler Un objeto que reside en la capa de negocios
y crea Value Objets cuando es requerido.
Value List Handler/ Page-byPage Es un objeto que maneja la ejecución de
Iterator/ Paged List consultas SQL, caché y procesamiento del
resultado. Usualmente implementado como
beans de sesión.
Service Locator Consiste en utilizar un objeto Service Locutor
para abstraer toda la utilización JNDI y para
ocultar las complejidades de la creación del
contexto inicial, de búsqueda de objetos
home EJB y recreación de objetos EJB.
Varios clientes pueden reutilizar el objeto
Service Locutor para reducir la complejidad
del código, proporcionando un punto de
control.

Capa de Integración
Patrón Descripción
Data Access Object Consiste en utilizar un objeto de acceso datos para
abstraer y encapsular todos los accesos a la fuente de
datos. El DAO maneja a conexión con la fuente de datos
para obtener y almacenar datos.
Service Activator Se utiliza para recibir peticiones y mensajes asíncronos
de los clientes. Cuando se recibe un mensaje, el Service
Activator localiza e invoca a los métodos de los
componentes de negocio necesarios para cumplir la
petición de forma asíncrona.

Subtema 1.6:

14
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

Extensiones de UML para aplicaciones WEB (WAE)

En 1998, Jim Conallen (empleado de Rational Software Corporation) definió una
extensión de UML para representar aplicaciones Web, a la que denominó WAE (Web
Application Extension). Esta extensión es la convención más difundida y aceptada hasta
nuestros días y podríamos decir que define el estándar de facto. Lo primero que se
planteó Jim es que las aplicaciones Web presentan elementos que UML no contemplaba
para su representación. UML no facilitaba la tarea de diferenciar código cliente (scripts) de
código servidor. Así fue que a partir de UML extendió una nueva semántica: estereotipos,
listados de etiquetas (tags) y restricciones (constraints).
Estereotipos: Define una nueva semántica al modelo.
 Lista de etiquetas: Consiste en una lista de campo-valor.
 Restricciones: Definen las reglas para trabajar con determinados
estereotipos.
En los siguientes puntos, se describirá cómo representar los elementos de una aplicación
web en diagramas de clases, diagrama de componentes y diagrama de secuencia.
Diagramas de clases
1. Estereotipos en clases
Estereotipos en clases define los siguientes estereotipos:
 < Server Page> Son las páginas que contienen scripts o código
ejecutable por el servidor. (.php , .asp , .jsp)
 <Cliente Page> Son las páginas que están en el lado del cliente,
normalmente páginas HTML y scripts (jsvasc ript).
 <Form> Es la representación de un formulario. Es código HTML que
contiene etiquetas de formulario como:<input>,<applet> o Flash,etc.
2. Estereotipos en relaciones
Define los siguientes estereotipos para las relaciones de asociación
unidireccionales:
 <build> Es una asociación unidireccional entre una página servidor y
una página cliente. La página servidor " construye" a la página cliente.
 <link> s una asociación unidireccional entre una página y otra página
del sistema (página servidor o página cliente).
 <submit> Es una asociación unidireccional entre un formulario y una
página servidor.

15
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

 <redirect> Es también una asociación unidireccional que indica que una

página Web redirige hacia otra. En c aso de que la página origen sea
una “client page” esta asociación corresponderá con la etiqueta “META”
y valor HTTP-E QUIV de “Refresh”.
 <forward> Es una asociación unidireccional entre una página servidor y
otra página servidor o una página cliente. Esta asociación representa la
delegación de procesamiento de la solicitud de un cliente para un
recurso a otra página del lado del servidor.
 <object> Es una relación entre una página cliente y una clase,
normalmente, uno que representa a un applet, el control ActiveX u otro
componente.
 <include> Se da entre una página servidor y otra página servidor o
página cliente. Durante la ejecución de la página, esta asociación indica
que la página incluida es procesada.
En las siguientes figuras, se muestra dos diagramas de clases que utilizan los diferentes
estereotipos descritos para clases y relaciones.

Diagrama de clases con páginas y relaciones <bult> y <sumit>.

16
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

Diagrama de clases con páginas y relaciones <buld> y <redirect>.

Diagrama de Componentes
Ilustran las piezas del software que conformarán un sistema. Un componente
puede ser un ejecutable, una librería estática o dinámica, clases de Java, etc.
Un componente abstrae un conjunto de clases para que pueda el componente
ser utilizado como una unidad, esto es el API que todo componente debe
proveer. Su funcionamiento es igual que con UML 2.0. En WAE se construye
un diagrama de componentes tanto para mostrar el flujo de navegación de la
aplicación como para representar los componentes que contiene el servidor.

Flujo de navegación.
En la siguiente figura, se ilustra un componente para abstraer el hecho de que
una página servidor genera una página de cliente; por ello, <server page> y
<client page> se modela agrupándolos como un componente. Asimismo, se
define el estereotipo <> en un paquete para representar el contenedor de los
componentes de la aplicación web.

17
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

Diagrama de componentes de una aplicación web

Diagrama de secuencia
Describe el comportamiento de los casos de uso en función del tiempo. Su uso
respecto a UML no cambia. En este diagrama se escriben las líneas de tiempo
de los actores y componentes implicados. Los actores y componentes se
envían mensajes entre ellos describiendo el comportamiento del sistema. Las
páginas del cliente pueden enviarse mensajes así mismo (funciones javascript
donde el servidor no interviene), pero si vemos fechas asíncronas que van
desde el cliente hasta el servidor solo pueden ser interpretadas por el
programador como el uso de AJAX, ya que la tecnología web es síncrona.
3. Realización de diseño de casos de uso con patrón arquitectónico MVC y
patrón de diseño DAO
En la siguiente tabla, se muestra la organización de las clases de diseño e
interfaces en capas, subsistemas y librerías que utilizaremos en el curso,
aplicando patrón arquitectónico MVC y patrón de diseño DAO:

Capa Subsistema/Librerías Elementos de diseño

Clases estereotipadas:
 Páginas HTML: <client
page>
Páginas JSP: <Sever
page>, <Client page> y
<HTML Form>

18
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

Clase estereotipada para

servlets: <Http Servlet>

 Clases de diseño:
servicios, beans y clases
 DAO. Interfaces que
presentan las
operaciones de acceso a
una tabla.
Clases de diseño: clase
abstracta DAOFactory y
sus clases hijas.

Clases de diseño: clases

utilitarias.

Capas, subsistemas, librerías y elementos de diseño post implementación

19
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

CASO PROPUESTO
De la Especificación del Caso de Uso Mantener Cajeros, crearemos los diagramas de la
realización de diseño del caso de uso.

ESPECIFICACIÓN DE CASO DE USO: Mantener cajeros

1. Descripción
El caso de uso permite mantener actualizado el registro de los cajeros de la clínica.
De acuerdo a su necesidad, el administrador de la clínica puede agregar, actualizar
y desactivar un cajero.
2. Actor(es)
Administrador
3. Flujo de Eventos
a. Flujo Básico
 El caso de uso se inicia cuando el Administrador selecciona la opción
“Cajeros” en la interfaz del menú principal.
 El sistema muestra la interfaz “MANTENER CAJERO” con la lista de
cajeros con los campos: código, nombres, apellido paterno, apellido
materno, teléfono, correo, dirección, fecha de registro, fecha de
actualización y estado. Además, muestra las opciones: Agregar
Cajero, Actualizar Cajero y Desactivar Cajero.
 Si el Administrador elige un cajero a. Si elige “Actualizar” ver el
Subflujo Actualizar Cajero. b. Si elige “Desactivar” ver el Subflujo
Desactivar Cajero.
 Si el Administrador NO elige un cajero a. Si elige “Agregar” ver el
Subflujo Agregar Cajero.
 El Administrador selecciona “Salir” y el caso de uso finaliza.
b. Subflujos
i. Agregar Cajero
1. El sistema muestra la interfaz CAJERO con los siguientes campos:
código (solo lectura), nombres, apellido paterno, apellido materno,
teléfono, correo, dirección, fecha de registro (solo lectura) y fecha de
actualización (solo lectura). Además, muestra las opciones: Aceptar y
Cancelar.

20
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

2. El Administrador ingresa los datos del Cajero.

3. El Administrador selecciona la opción Aceptar.
4. El sistema valida los datos ingresados.
5. El sistema genera un nuevo código de cajero y obtiene la fecha del
sistema para la fecha de registro y la fecha de actualización
6. El sistema graba un nuevo registro de cajero y muestra el MSG
“Cajero creado con código Nro. 999999”.
7. El Administrador cierra la interfaz CAJERO y regresa a la interfaz
MANTENER CAJERO con la lista de cajeros actualizada y el subflujo
finaliza.
ii. Actualizar Cajero
1. El sistema muestra los datos del cajero seleccionada en la interfaz
CAJERO: código (solo lectura), nombres, apellido paterno, apellido
materno, teléfono, correo, dirección, fecha de registro (solo lectura) y
fecha de actualización (solo lectura). Además, muestra las opciones:
Aceptar y Cancelar.
2. El Administrador actualiza los datos del cajero.
3. El Administrador selecciona la opción Aceptar
4. El sistema valida los datos ingresados del cajero.
5. El sistema obtiene la fecha del sistema para la fecha de
actualización, actualiza el registro de cajero, y muestra el MSG
“Cajero actualizado satisfactoriamente”.
6. El Administrador cierra la interfaz CAJERO y regresa a la interfaz
MANTENER CAJERO con la lista de cajeros actualizada y el subflujo
finaliza.
iii. Desactivar Cajero
1. El sistema muestra el MSG: “¿Está seguro que des ea desactivar
el(los) cajero(s) seleccionado(s)?”.
2. El Administrador selecciona la opción YES para confirmar la
desactivación.
3. El sistema actualiza el registro del(los) cajero(s) en estado
“Desactivado”.
4. El sistema muestra la interfaz MANTENER CAJERO con la lista de
cajeros actualizada y termina el subflujo.
c. Flujos Alternativos

21
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

1. Datos del Cajero Inválidos

Si los datos ingresados son nulos o inválidos, tanto en los subflujos
Agregar como en Actualizar Cajero, el sistema muestra el MSG: “Se han
encontrado datos inválidos” y los subflujos continúan en el paso 2. 2.
2. Cajero ya existe
Si el sistema detecta que el cajero ya existe en el paso 4 del subfujo
Agregar Cajero, muestra el MSG: “Cajero ya existe” y el subflujo finaliza.
3. No confirma Desactivación
Si el Administrador selecciona NO en el paso 2 del subflujo Desactivar
Cajero, finaliza el subflujo.
4. Precondiciones
1. El Administrador está identificado en el sistema.
2. Lista disponible de Cajeros.

5. Poscondiciones
1. En el sistema quedará registrado el nuevo Cajero.
2. En el sistema quedará actualizado el registro del Cajero.
3. En el sistema quedará desactivado el Cajero.
6. Puntos de Extensión
Ninguno.
7. Requisitos Especiales
Ninguno.
A continuación, se muestra los siguientes artefactos de la realización de diseño de caso
de uso:
1. Realización del Diseño

22
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

2. Diagrama de clases de diseño del CU Mantener Cajeros

3. Diagrama de secuencia

23
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

ACTIVIDAD PROPUESTA
Elabore el diagrama de secuencia para los subflujos agregar, actualizar y desactivar
cajeros y de los métodos del DAO del caso de uso Mantener Cajeros.
A partir de la Especificación del Caso de Uso del Sistema Comercial crearemos los
diagramas de clases de análisis, diagrama de clases de diseño y diagrama de
secuencia de la ECU Evaluar Solicitud de Préstamo.

24
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

Especificación de Caso de Uso: Evaluar Solicitud de Préstamo

Breve Descripción
El caso de uso permite al Jefe de Crédito Evaluar una Solicitud de préstamo para un
socio, pudiendo aprobar o denegar el préstamo.
Actor(es)
Jefe Créditos
Flujo de Eventos
a) Flujo Básico
1. El caso de uso comienza cuando el Jefe de Crédito Solicita “Evaluar Solicitud de
Préstamo” en el menú principal.
2. El sistema muestra la interfaz “Lista de Solicitudes “en la Interfaz se muestra la
Lista de todas las Solicitudes de Préstamo que aún no fueron evaluadas. La lista
de solicitudes contiene los datos: Numero de Solicitud, Código y Nombre del Socio,
Monto del Préstamo y Tipo de préstamo
3. El Jefe de Crédito selecciona una Solicitud para Evaluar
4. El sistema muestra la Interfaz “Solicitud de Crédito“ donde se muestra
detalladamente los siguientes datos:
o Solicitud de préstamo: Número, fecha, tipo de préstamo, monto y
duración.
o Datos del Socio: Código, DNI, nombres y apellidos, domicilio, sexo e
ingresos económicos
o Adicionalmente incluye también 2 Opciones de selección (Aprobar y
Denegar) y los botones Grabar y Salir.
5. El Jefe de Crédito selecciona Aprobar y selecciona grabar.
6. El sistema actualiza la Solicitud de préstamo como aprobada.
b) Flujos Alternativos
Solicitud Denegada
1. Si en el punto 5, el Jefe de Crédito selecciona Denegar y selecciona grabar.
2. El sistema actualiza la Solicitud de préstamo como Denegada

Precondiciones

25
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

- El Jefe de Creditos esta logeado en el sistema

- Lista de solicitudes de prestamo, no evaluadas.
Poscondiciones
- En el sistema, quedará registrada la solicitud en estado “aprobada” o “denegada”
Puntos de Extensión
- Ninguna.
Prototipo

26
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

27
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

SOLUCION DEL CASO PROPUESTO

DIAGRAMA DE CLASES DE ANALISIS

28
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

DIAGRAMA DE CLASES DE DISEÑO

29
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

DIAGRAMA DE SECUENCIA
Flujo básico Evaluar

30
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

BIBLIOGRAFÍA
FUENTES BIBLIOGRÁFICAS
 Charette, R. N. (1989), Software Engineering Risk Analysis and Management,
McGraw-HillDntertext.
 G. Kotonya and I.(2000) Sommerville, Requirements Engineering: Processes and
Techniques, John Wiley & Sons
 IEEE Computer Society, (2014), SWEBOK (Guide to the Software Engineering
Body of Knowledge), Version 3.0. ISBN-10: 0-7695-5166-1
 Jacobson, Ivar; Booch, Grady; Rumbaugh, James (2000) (en Español). El Proceso
Unificado de Desarrollo de Software. Pearson Addisson-Wesley.
 Piattini, Mario G. (1996), Análisis y diseño detallado de aplicaciones informáticas de
gestión. 1ª ed. RAMA Editorial, Madrid, 1996
 Pressman, R. (2010). Ingeniería de Software un Enfoque práctico, Séptima Edición.
ISBN 978-607-15- 0314-5.
 Sommerville, Lan. (2011) Ingeniería de software, novena edición. Pearson, México.
ISBN 0137035152 | 9780137035151
 Sommerville, Lan (2005), Ingeniería de software, séptima edición, Pearson
Educación, Madrid (España) ISBN: 84-7829-074-5
 [Wasserman, 1996] Wasserman, A. “Toward a Discipline of Software Engineering”.
IEEE Software, 13(6):23-31. November/December 1996
 PRESSMAN, Roger. “Ingeniería del Software. Un Enfoque Práctico”. 5ª ed.
México: McGraw-Hill Latinoamericana, 2002. ISBN: 8448132149.
 BOOCH, Grady et tal. “El Proceso Unificado de Desarrollo de Software”. 1ª ed.
España: Editorial Addison-Wesley.
 LARMAN, Craig. UML y Patrones – Introducción al Análisis y Diseño Orientado a
Objetos. 1ª ed. España: Pearson Educación.
 SENN, James. “Análisis y Diseño de Sistemas de Información”. México: Mc Graw
Hill. ISBN: 9684229917.
 BRAUDE, J. “Ingeniería de Software: Una Perspectiva Orientada a Objetos” Ra-
ma. ISBN: 8478975756. ISBN-13: 9788478975754.
 SOMMERVILLE, Ian “Ingeniería de Software: Un enfoque practico”, Eddison
Wesley, México, 692 p.
 FONTELA, CARLOS (2011), UML Modelado de Software para profesionales.
Editorial Alfa Omega.
 CRAIG LARMAN (2000), “UML y Patrones”, Editorial Prentice Hall.
 JACOBSON, BOOCH, RUMBAUGH (2000), “El Lenguaje Unificado de Modelado”.
Editorial Addison-Wesley.
 KENDALL y KENDALL (2010), “Análisis y Diseño Sistemas”, 8va Ed. Editorial
Prentice Hall Hispanoamericana S.A.
 LAUDON, Kenneth y LAUDON, Jane (2002),”Administración de los Sistemas de
Información”. Editorial Prentice Hall Hispanoamericana S.A.
 JACOBSON, BOOCH, RUMBAUGH (2000), “El proceso unificado de desarrollo de
Software”. Editorial Addison-Wesley,
 Martin FOWLER - Kendall SCOTT (1999), “UML Gota a Gota”. Editorial Pearson.
 PRESMAN, Roger S (2005), “Ingeniería de Software”, 5ta Ed.; Mc Graw Hill.

31
Guía 1 Escuela de Proyecto Desarrollo Software
Tecnología

FUENTES DIGITALES
 Barzana, A & Menéndez, R. (2005), Gestión de Riesgos en Ingeniería de Software.
Consultado el 29 de febrero de 2016 de
http://www.wikilearning.com/curso_gratis/gestion_de_riesgos_en_ingenieria_del_so
ftwareintroduccion/3620-1
 IEEE Computer Society, (2004), Software Engineering Body of Knowledge,
Consultado el 09 de noviembre de 2015 de: http://www.swebok.org
 IEEE Computer Society, (2014), SWEBOK (Guide to the Software Engineering
Body of Knowledge), Version 3.0. ISBN-10: 0-7695-5166-1, consultado el 09 de
noviembre de 2015 de: http://www.computer.org/web/swebok/v3-guide
 ISO/IEC 25000, SQuaRE, (2014). Consultado el 09 de noviembre de 2015 de:
System and Software Quality Requirements and Evaluation.
 Real Academia Española, Asociación de Academias de la Lengua Española.
Diccionario de la lengua española, 23.ª ed., Edición del Tricentenario, [en línea].
Madrid: Espasa, 2014.
 Diccionario WordReference Copyright / derecho de autor © 2016
WordReference.com. http://www.wordreference.com/definicion/dise%C3%B1o

FUENTES BASES DE DATOS ESPECIALIZADAS

 http://scholar.google.es/
 http://dialnet.unirioja.es/
 http://www2.ebsco.com/es-es/Pages/index.aspx
 https://cgrw01.cgr.go.cr/rup/RUP.es/SmallProjects/core.base_rup/workproducts/
rup_design_model_2830034D.html
 http://www.redalyc.org/

32