Introducción al

diseño de software
El análisis y diseño de sistemas son importantes
dentro del ciclo de vida del software porque
permiten definir la arquitectura del software,
componentes, módulos y datos de un sistema
software para satisfacer ciertos requisitos
acordados previamente.
Adicionalmente, en el mundo actual, tan
dependiente de los sistemas software, en
todos sus ámbitos, tanto social, industrial
como económico, las etapas de análisis y
diseño son la base para lograr desarrollarlos
con altos estándares de calidad. Por lo tanto,
bienvenidos el interesante mundo del análisis
y diseño de sistemas.

SUMILLA COMPETENCIAS DE
La Unidad Didáctica pertenece a las
competencias específicas y es carácter UNIDAD DIDÁCTICA
teórico - práctico, su propósito es generar en
el estudiante los conocimientos necesarios Aplicar de manera adecuada los principios,
para capturar, analizar requisitos y diseñar técnicas, herramientas y métodos del
arquitecturas de software factibles de modelado orientado a objetos para el análisis
implementación, con buenas prácticas de y diseño de un producto software, de acuerdo
programación y políticas de seguridad de la a los diseños funcionales y estándares
organización. internacionales de TI.
Se desarrollan los siguientes contenidos:
técnicas de modelado orientado a objetos para
el análisis de requisitos y diseño de software,
aplicando la metodología de desarrollo de
software RUP (Rational Unified Process) y el
estándar UML (Unified Modeling Language).
UNIDADES DE APRENDIZAJE

1 Introducción al Análisis y Diseño 2 Metodología de desarrollo del

UNIDAD DE
APRENDIZAJE
Orientado a Objetos UNIDAD DE
APRENDIZAJE
Proceso Unificado de Rational (RUP)

3 Introducción al Lenguaje de 4 Requisitos Funcionales como Casos

de Uso del Sistema (CUS).
UNIDAD DE
APRENDIZAJE
Modelado Unificado (UML) UNIDAD DE
APRENDIZAJE

5 Modelo de Casos de Uso del

Sistema: Realización de CUS
6 Modelo de comportamiento de los
UNIDAD DE
APRENDIZAJE
UNIDAD DE
APRENDIZAJE
CUS: Diagramas de Secuencia

7 Modelo de clases de análisis. 8 Diseño estructural del sistema:

UNIDAD DE
APRENDIZAJE
UNIDAD DE
APRENDIZAJE
Modelo de Dominio

9 Diseño dinámico del sistema: Vista

de Interacción.
10 Diseño dinámico del sistema:
UNIDAD DE
APRENDIZAJE
UNIDAD DE
APRENDIZAJE
Modelo de Estado.
 PRESENTACIÓN COMPETENCIA
El desarrollo de un sistema software, sin Reconoce cada uno de los fundamentos
importar su tamaño, sus características básicos del paradigma orientado a objetos
funcionales ni la tecnología elegida para su para comprender su aplicación en el modelado
fabricación, consta de una serie de etapas que orientado a objetos.
se extienden desde su concepción hasta su
entrega y mantenimiento, que definen lo que CAPACIDADES
se conoce como el ciclo de vida del software. • Reconoce y demuestra sus habilidades en el
Existen diferentes modelos de ciclo de vida, uso de principios básicos de la orientación a
cada uno con sus propias particularidades, objetos
adaptándose unos mejor que otros a los • Reconoce y demuestra habilidad en el
distintos paradigmas o estilos de programación. reconocimiento de clases y objetos
Un paradigma de programación es una manera • Reconoce y describe las características de
de resolver problemas usando la programación. encapsulamiento, herencia y polimorfismo
El paradigma de programación orientada a de la orientación a objetos.
objetos (POO) es uno de ellos, y se caracteriza
porque toda gira en torno a objetos, que tienen
ACTITUDES
propiedades y comportamientos. • Tener actitud positiva hacia su estudio
Dentro de los modelos de desarrollo hay • Tiene habilidades para administrar su
muchos que se fundamentan en el paradigma tiempo y organizarse.
o método orientado a objetos, en donde las • Toma decisiones con respecto a opciones
etapas de análisis y diseño del sistema son de curriculares.
mucha importancia, ya que son las etapas en
donde se analiza y valida con los clientes, qué
TEMAS
es lo que se quiere que haga el sistema, para
resolver un problema o implementar una idea, 1
TEMA
Principios del método
orientado a objetos
con el objetivo de mejorar procesos y metas del
negocio. También se diseña una arquitectura
que sirve de puente entre lo que se requiere
resolver en el dominio del problema y cómo se
2
TEMA
Objetos y Clases

implementará en el dominio de la solución.

En esta Unidad de Aprendizaje introductoria
se describirán los principios del método o
3
TEMA
Encapsulamiento
paradigma Orientado a Objetos, a nivel básico,
no con la intención de hacer un curso de
programación orientada a objetos, sino para 4
TEMA
Herencia
conocer estos principios que ayudarán mucho
en la compresión de las técnicas de análisis
y diseño que se explicarán en las siguientes 5
TEMA
Polimorfismo
Unidades de Aprendizaje
UNIDAD 1 - TEMA 1
Principios del método orientado a objetos
El marco de desarrollo de un sistema software La Abstracción
está centrado en tres fases tradicionales: La abstracción forma parte de los elementos
análisis, diseño e implementación. fundamentales en el modelo de objetos.
El análisis es la fase cuyo objetivo es estudiar La abstracción son las características específicas
y comprender el dominio del problema,es de un objeto, aquellas que lo distinguen de los
decir, el análisis se centra en responder al demás tipos de objetos y que logran definir
interrogante ¿Qué hacer? límites conceptuales entre objetos, se enfoca
El diseño, por su parte, dirige sus esfuerzos en la visión externa de un objeto, separa el
en desarrollar la solución a los requisitos comportamiento específico de un objeto, a
planteados en el análisis, es decir, el diseño se esta división se le conoce como la barrera de
centra en el espacio de la solución, intentando abstracción.
dar respuesta a la pregunta ¿Cómo hacer? El método OO se basa en la noción de
Por último, la fase de implementación se representar elementos del mundo real como
encarga de la traducción del diseño de la objetos, sin embargo, cualquier elemento del
aplicación al lenguaje de programación elegido, mundo real tiene una cantidad considerable de
adaptando por tanto la solución a un entorno propiedades y comportamiento. Ahora bien,
operativo concreto. para lidiar con esta complejidad, se utiliza la
El método Orientado a Objeto (OO) es un abstracción, un mecanismo a través del cual
enfoque de desarrollo de sistemas software nos enfocamos en los aspectos esenciales
de los mas populares y de gran aceptación en o distintivos de algo, ignorando detalles
el desarrollo de proyectos, hace ya décadas irrelevantes. Por supuesto, la abstracción
que este paradigma tomó su lugar en el siempre se hace desde alguna perspectiva
desarrollo de software y eso persiste hoy en particular, ya que lo que en algunos casos
día. En la siguiente figura se visualizan las fases es irrelevante, en otros puede ser que no lo
principales del desarrollo orientado a objetos. sea. Un ejemplo se observa en la siguiente
figura, donde un gato es abstraído desde dos
perspectivas diferentes, las del veterinario y la
de su dueño.

Los principios fundamentales que se

deben entender para poder ser buenos
desarrolladores OO, y que constituyen la base
de todo desarrollo de software orientado a
objetos, son: la Abstracción, el Encapsulamiento,
la Herencia y el Polimorfismo.
La abstracción en OO se representa con A lo anterior es a lo que se llama abstraer la
objetos que se asocian a objetos de la vida real, realidad, de un objeto real, decidir cuáles serán
que tienen la misma estructura, características, sus propiedades y comportamientos en una
comportamiento y semántica, lo que permiten clase.
agruparlos en una clase de objetos similares. Otro clásico ejemplo es el del inventario de
Así que, lo que un objeto puede saber (estado) una tienda, ¿qué es lo que tiene un producto?,
o hacer (comportamiento), está determinado bueno pues tiene nombre, categoría, marca, y
por la clase a la que pertenece. precio, y ¿Cuáles son sus comportamientos?, se
Otra forma de ver la abstracción, es definirla pueden comprar, almacenar, vender, etc.
como el proceso de simplificar un problema En la siguiente figura se representa la
complejo enfocándose tan sólo en los aspectos abstracción del objeto carro, con sus
relevantes para la solución, por ello en el propiedades o características (marca, color,
desarrollo de software orientado a objetos, modelo, peso) y sus comportamientos o
esto significa centrarse en lo que es y hace funciones (encender, acelerar, frenar).
un objeto, antes de decidir cómo debería ser
implementado.
Cuando se dice abstraer la realidad suena a
algo confuso, si bien programar requiere de
mucha creatividad, el nombre de este concepto
parece más difícil de lo que es en realidad. Por
ejemplo, si se quiere representar un punto
usando POO, lo primero es preguntarse ¿Qué
es lo que tiene un punto? Geométricamente
se puede representar en un plano si tienes La representación de la abstracción a través de
sus coordenadas x y y, entonces ya se tienen los objetos y clases se detallarán en el tema 2
sus propiedades, una x y una y. Ahora si se de esta unidad de aprendizaje.
quiere dibujar una línea (otro objeto), esto se
puede hacer con dos puntos (dos objetos).
El Encapsulamiento
Adicionalmente con 3 o más líneas se pueden
Con la abstracción se agrupan los objetos,
tener figuras geométricas, las cuales no solo
asociados a objetos de la vida real, que
tendrán las propiedades dadas por sus puntos,
tienen la misma estructura, propiedades,
sino que también tendrán comportamientos,
comportamientos y semántica, en una clase de
entre ellos, cómo obtener la base, la altura,
objetos similares.
el área, cómo girar la figura, hacerla crecer o
Con el encapsulamiento, en general, se ocultan
encoger, etc.
las propiedades y comportamientos (métodos)
de un objeto, de manera que sólo se puedan
cambiar mediante las operaciones definidas
para ese objeto. Esto se puede entender como
un mecanismo de protección o aislamiento,
es decir, se protege a los datos asociados de
un objeto contra su modificación por quien
no esté autorizado a acceder a ellos. De esta
forma el usuario de la clase puede obviar la
implementación de los métodos y propiedades
para concentrarse sólo en cómo usarlos.
Por otro lado, se evita que el usuario pueda
cambiar su estado de maneras imprevistas e
incontroladas.
Un ejemplo de encapsulamiento es cuando
queremos llamar por celular a alguien, y el
celular no nos hace saber cómo hace para
realizar la llamada, y encapsula la información,
ya que a nosotros solo nos interesa que la
persona a la que llamamos nos conteste.
Otro ejemplo, cuando alguien se pone a ver En la siguiente figura se puede observar un
televisión no se preocupa del modo como ejemplo de herencia, en el cual las clases
éste funciona, o lo que hace para cambiar de Moto y Coche heredan las propiedades
canal o aumentar el volumen, a menos que sea y comportamientos de una clase base o
experto en electrónica o técnico en televisores, superclase llamada Vehículo, lo cual significa
simplemente no lo sabe y no le importa; sólo que tanto la Moto como el Coche, tendrán las
sabe que al presionar un botón ocurre que se propiedades de una velocidad máxima, un
prende. número de ruedas, una marca y un modelo que
El encapsulamiento se encarga de mantener heredaron de la clase Vehículo. Adicionalmente
ocultos los procesos internos que necesita a estas propiedades heredadas, la Moto tendrá
para hacer lo que sea que haga, dándole al una propiedad que describe la cilindrada y el
programador acceso sólo a lo que necesita. Coche una propiedad que describe la tracción.
Esto da dos ventajas iniciales: Hace que el
usuario puede ser controlado internamente
(incluso sus errores), evitando que todo colapse
por una intervención indeseada, siguiendo con
el ejemplo de ver televisión, no se quiere que
alguien, que no tiene ni idea de electrónica, abra
el televisor y empiece a jugar con los circuitos
para cambiar los canales manualmente. La
segunda ventaja es que, al hacer que la mayor
parte del código esté oculto, puedes hacer
cambios y/o mejoras sin que eso afecte el modo La herencia permite que se puedan definir
como los usuarios van a utilizar tu código. Sólo nuevas clases basadas de unas ya existentes
tienes que mantener igual la forma de acceder a fin de reutilizar el código, generando así una
a él (en el caso del control de la tele, que los jerarquía de clases dentro de una aplicación.
botones sigan siendo los mismos). Si una clase deriva de otra, esta hereda sus
El encapsulamiento permite el ocultamiento de atributos y métodos y puede añadir nuevos
la información de un objeto, para asegurar que atributos, métodos o redefinir los heredados.
el contenido de un objeto se pueda ocultar del No hay nada mejor en programación que poder
mundo exterior, solo dejándose ver lo que cada usar el mismo código una y otra vez para hacer
objeto necesita hacer público. nuestro desarrollo más rápido y eficiente.
El concepto de herencia ofrece mucho al
respecto, gracias a ella, lograremos un código
mucho más limpio, estructurado y con menos
líneas de código, lo que lo hace más legible.

La Herencia
Cuando se habla de herencia en programación
se trata de uno de los pilares fundamentales
de la programación orientada a objetos. Es
el mecanismo por el cual una clase permite
heredar las características (propiedades
(atributos) y comportamientos (métodos)) de
otra clase.
 El Polimorfismo
Los objetos pueden adoptar más de una forma En síntesis, este concepto permite enlazar
según el contexto. El programa determinará el mismo nombre de operador a dos o más
qué significado o uso es necesario para implementaciones diferentes del operador,
cada ejecución de ese objeto, reduciendo la dependiendo del tipo de objetos a los que éste
necesidad de duplicar código. se aplique.
El polimorfismo consiste en conseguir que Por ejemplo, en la siguiente figura se
un objeto de una clase se comporte como muestran dos subclases de la clase Forma, que
un objeto de cualquiera de sus subclases, representa las formas geométricas, que tienen
dependiendo de la forma de llamar a los los mismos comportamientos o métodos, pero
métodos de dicha clase o subclases. que se implementan de diferente manera,
no se comporta igual dibujar un círculo que
dibujar un cuadrado, pero en el método que
implementa este comportamiento se llama
igual, dibujar ().
 RESUMEN DEL TEMA
Un proyecto de desarrollo de software no consiste sólo en programar, primero
necesitamos saber cuáles son las necesidades del cliente, identificar los requisitos,
anotarlos, analizarlos y validarlos, luego necesitamos diseñar una solución, es decir,
diseñar la arquitectura del software. Estas actividades importantes son las que se
realizan en las etapas de análisis y diseño.
Que este marco de desarrollo sea válido tanto para los desarrollos tradicionales
(desarrollos estructurados) como para los desarrollos orientados a objeto, no significa
que la realización de las actividades propias de cada fase se lleve a cabo de la misma
manera. De hecho, en los desarrollos estructurados hay mucha distancia entre las fases
de análisis de diseño, e incluso entre los diferentes modelos generados en una misma
fase, esta separación se conoce con el nombre de gap semántico, y es la barrera que la
orientación a objeto intenta eliminar difuminando la frontera entre las diferentes fases.
Los métodos orientados a objeto acortan la distancia existente entre el espacio de
conceptos (lo que los expertos o usuarios conocen) y el espacio de diseño (lo que
conocen los desarrolladores) e implementación, ya que los objetos del mundo real
tienen una correspondencia bastante clara con los objetos del sistema informático,
evitando así los grandes abismos existentes entre el análisis y el diseño en el enfoque
estructurado, esto es la falta de continuidad en la representación de los conceptos en
una y otra fase.
Los desarrollos orientados al objeto se tiene una mayor continuidad entre las diferentes
fases, con unas fronteras entre fases muy poco marcadas que dan lugar a desarrollos
más iterativos e incrementales. Todo esto es posible gracias a una característica de vital
importancia, el modelo subyacente a todas las fases es el mismo, el modelo objeto,
que tiene como elemento central al objeto, que es la entidad que encapsula elementos
estructurales y de comportamiento. De esta forma, los objetos semánticos identificados
en la fase de análisis se refinarán durante la fase de diseño e implementación, a la vez
que se añaden objetos de interfaz y de utilidad para constituir la aplicación final.

LA IDEA PRINCIPAL
Los buenos analistas y diseñadores comprenden sus principios fundamentales:
Abstracción, Encapsulamiento, Herencia y Polimorfismo
UNIDAD 1 - TEMA 2
Objetos y Clases
Este tema tiene como objetivo principal explicar Objeto como abstracción
los elementos básicos del desarrollo orientado El paradigma de la orientación a objetos es
a objetos (POO), en particular, se describe qué una abstracción que busca representar, en el
es una clase y cuáles son los miembros de una software, los conceptos del mundo real. De
clase (atributos y métodos), qué es un objeto, hecho, la palabra objeto refiere a algo que es
qué significa instanciar, qué son el estado y palpable. Tales conceptos pueden ser algo muy
el comportamiento de un objeto, y qué es un concreto, como, por ejemplo, “estudiante”, o
mensaje. algo abstracto, como decir “matrícula”.
Dentro de este tema se explica, mediante Los objetos son o representan cosas, pueden
diferentes ejemplos, cómo estos elementos se ser simples o complejos, pueden ser reales o
relacionan con el mundo real haciendo así más imaginarios.
sencillo y natural el diseño de aplicaciones. Los objetos contienen dos aspectos
fundamentales: sus atributos y su
Objetivos comportamiento. Por ejemplo, si pensamos en
Los objetivos a lograr en este tema son los un objeto simple, como una pelota, podríamos
siguientes: definirla por algunos atributos, entre ellos:
• Saber diferenciar entre un objeto y una color, volumen, peso. De igual forma, las
clase, y comprender la relación que existe pelotas tienen algunos comportamientos, muy
entre ellos. relacionados con sus atributos, como: “hacerla
• Conocer y entender las partes que rodar”, “pintarla”, “pesarla”, “medirla”. No
componen una clase, es decir, los atributos todas, pero quizás algunas pudieran permitirse
y los métodos. “hacerla rebotar”.
• Saber algunos conceptos relacionados Los objetos tienen identidad, es decir, todo
con un objeto, como: identidad, estado y objeto es único. Además, presentan un estado,
comportamiento e instancia el cual se define por los valores que tienen
sus atributos en un momento determinado.
Es por ello que una pelota roja es distinta de
otra pelota roja, aunque tengan el mismo color,
peso y volumen, es decir, aunque el estado de
un objeto sea igual que el de otro objeto, nunca
se tratará del mismo objeto. Piense usted en
dos personas que sean mellizas y verá con más
claridad el significado de lo anterior.
 Clases como clasificación de objetos
A pesar de que los objetos son independientes,
pueden clasificarse de una forma general. Nombre de Libro
Podemos decir que todas las facturas, o todas la clase
las pelotas pueden describirse de una forma Atributos Autor, Número de páginas,
general. Ya sabemos que los objetos tienen Capítulos, Anexos, ISBN,
atributos y comportamiento. A partir de ello Resumen
siempre trataremos de identificar, de forma
general, cuáles atributos y qué comportamiento Operaciones Consultar, Ver resumen,
pueden tener todos los objetos de una clase Obtener Autor, Pasar página,
particular. Pasar Capítulo
La clase viene a ser un concepto muy
importante del paradigma de orientación a En muchas ocasiones se tienen que modelar
objetos, pues a través de éstas lograremos conceptos más abstractos, algunos que se
describir todos los objetos pertenecientes encuentran en una organización, como, por
a una misma clase. Gráficamente, una clase ejemplo, una orden de trabajo, que es una
consta de tres secciones: tarea o actividad que una persona debe hacer
• El nombre. y a la cual se le debe dar un seguimiento, esto
• Los atributos. se puede representar con la siguiente clase.
• Las operaciones o métodos.
Los métodos son los que tienen que ver con el Nombre de Orden de trabajo
comportamiento de los objetos. la clase
En la siguiente figura, se observa la clase Pelota,
representando los objetos de este tipo Atributos Usuario que origina,
descripción del trabajo, fecha
de solicitud, encargado, estado
de la orden (sin asignar, en
proceso, cancelada, finalizada),
fecha de asignación, fecha de
estado final
Operaciones Solicitar trabajo, asignar,
cancelar, finalizar

Esta característica de poder definir clases para

los objetos, nos coloca ante un panorama
particular en el ámbito del paradigma de
orientación a objetos: para definir los conceptos
En esta figura se observan las tres secciones relevantes dentro del dominio de un problema
mencionadas anteriormente. por resolver, debe pensarse en sus atributos y
Todas las pelotas que vayan a crearse comportamiento como un todo.
a partir de esta clase, tendrán esos En lo práctico, se debe pensar
atributos y esas operaciones. Esto que los objetos serán parte de
representa algo muy poderoso un código de software, y esos
dentro de esta forma de visualizar objetos contendrán los datos
nuestras abstracciones, ya que que requieren (atributos) y
muchas cosas en el mundo real sus procesos (operaciones)
las podemos representar de esa residiendo en el mismo espacio,
manera. esta característica es la llamada
encapsulamiento, que se
Por ejemplo, si pensamos un libro, detallará en el próximo tema.
de igual forma podemos pensar en
sus atributos y las operaciones que
podemos hacer con éste.
 Objeto como instancia de una Clase
Como ya se ha descrito, los objetos son
ejemplares de una clase. Así pues, a la hora de
crear un objeto, debemos seguir los siguientes
pasos:
1. Declarar el objeto. Ejemplo:
Persona persona1;
2. Instanciar el objeto (crear un objeto a partir
de una clase):
persona1 = new Persona(“David”);
En la mayoría de lenguajes, para instanciar/
crear un objeto nuevo debemos escribir
la palabra new seguida de uno de los
constructores de la clase. En este caso,
hemos usado uno de los dos constructores
con argumentos, pero también podríamos
haber usado el constructor por defecto.
3. En este momento ya tenemos el objeto
persona1 del tipo Persona creado en
memoria. Así pues, ya podemos acceder a
sus atributos y métodos.
Los pasos 1 y 2 se pueden agrupar en un
único paso:
Persona persona1 = new Persona(“David”);
Debido a que la acción de crear un objeto
a partir de una clase se le llama instanciar,
muchas veces a los objetos se les llama
instancia. Por lo tanto, persona1 es una
instancia o un objeto de la clase Persona.
 RESUMEN DEL TEMA
Antes de entrar en el desarrollo de los temas del Análisis y Diseño Orientado a Objetos,
es conveniente hacer un breve repaso del paradigma de orientación a objetos.
Este repaso no se hace desde un punto de vista histórico, es decir, no nos detendremos
en conocer cómo surge este paradigma, cómo se desarrolla o cómo se consolida, más
bien se hace desde el punto de vista de la utilidad que tendrá para este libro, en la
medida que es uno de los fundamentos de la metodología y técnicas que vamos a
estudiar.
De esta forma se revisan las principales características que definen este paradigma: la
abstracción que lo fundamenta y la clasificación de Objetos en Clases.
Este tema tiene como objetivo principal explicar los elementos básicos del desarrollo
orientado a objetos (POO), en particular, se describe qué es una clase y cuáles son los
miembros de una clase (atributos y métodos), qué es un objeto, qué significa instanciar,
qué son el estado y el comportamiento de un objeto, y qué es un mensaje.
En lo práctico, se debe pensar que los objetos serán parte de un código de software,
y esos objetos contendrán los datos que requieren (atributos) y sus procesos
(operaciones) residiendo en el mismo espacio.

LA IDEA PRINCIPAL
Las Clases agrupan Objetos, con sus atributos y comportamiento, como un todo.
UNIDAD 1 - TEMA 3
Encapsulamiento
Hay muchos datos que no tiene que conocerlos
Niveles de encapsulamiento
aquel que esté usando una clase, ya que
• Nivel cerrado: los atributos y métodos del objeto
son inherentes al objeto y solo controlan su
sólo es accesible desde la misma clase.
funcionamiento interno; por ejemplo, cuando
• Nivel protegido: los atributos y métodos del
alguien ve a una Persona (clase) puede saber
objeto sólo es accesible desde la clase y las
inmediatamente si es hombre o mujer (propiedad o
clases que heredan
atributo) o puede hablarte y obtener una respuesta
• Nivel abierto: los atributos y métodos del objeto
procesada (método); también puede conocer el
puede ser accedido desde cualquier clase.
color de tu cabello y ojos.
Estos niveles se manejan mediante los
Por otro lado, jamás sabrá qué cantidad de energía
modificadores de acceso: privado (privated),
exacta tienes o cuantas neuronas te quedan, ni
protegido (protected) y público (public).
siquiera preguntándote ya que ninguna de tus
propiedades externas visibles o funciones de
comunicación al público te permiten saber esos Ejemplo de Encapsulamiento
datos. Crearemos una clase Persona, como atributos:
Esto es encapsulamiento; hacer las variables, que nombre, fecha de nacimiento y edad, como
son innecesarias para el tratamiento del objeto, métodos: registrar persona y calcular edad.
pero necesarias para su funcionamiento, de tipo Bien, como dice la teoría, la encapsulación es
privadas, así como las funciones que no necesitan un mecanismo de protección o aislamiento
interacción del usuario o que solo pueden ser de atributos y métodos de un objeto contra
llamadas por otras funciones dentro del objeto modificaciones imprevistas o incontroladas. Para
(como, por ejemplo, palpitar). ello, se debe tener criterio para aplicar el nivel de
El encapsulamiento es muy conveniente, ya que encapsulamiento de los atributos o métodos del
permite colocar en funcionamiento nuestro objeto objeto/clase.
en cualquier tipo de sistema, de una manera Por lo tanto, teniendo criterio y aplicando
modular y escalable, que son algunas de las buenas conocimientos de abstracción, el atributo nombre,
prácticas de la ingeniería del software. fecha de nacimiento, y el método registrar persona,
En general, el objetivo del encapsulamiento se deben de tener la posibilidad de ser accedida desde
refiere al ocultamiento de los datos miembros fuera de la clase, así poder asignar valores e invocar
de un objeto, es decir, encapsular los atributos y el método del objeto. Entonces estos atributos y el
métodos del objeto, de manera que sólo se pueda método deben de ser públicos.
cambiar mediante las operaciones definidas para Por otro lado, el atributo edad y método calcular
ese objeto. edad, solo deben ser accedidas por la misma clase;
así la propia clase asignaría el valor de la edad de
la persona, como también usar el método para
calcular la edad a partir de la fecha de nacimiento de
la persona y la fecha actual (edad exacta asignado
por la propia clase, además recuerden que la edad
no siempre será el mismo, cambia al pasar los años).
En cambio, si la edad tiene el modificador de acceso
en público, este atributo puede ser accedido desde
cualquier parte, y así tener la posibilidad asignar la
edad con datos erróneos.
 RESUMEN DEL TEMA
Con el encapsulamiento, en general, se ocultan las propiedades y comportamientos
(métodos) de un objeto, de manera que sólo se puedan cambiar mediante las
operaciones definidas para ese objeto. Esto se puede entender como un mecanismo
de protección o aislamiento, es decir, se protege a los datos asociados de un objeto
contra su modificación por quien no esté autorizado a acceder a ellos. De esta forma
el usuario de la clase puede obviar la implementación de los métodos y propiedades
para concentrarse sólo en cómo usarlos. Por otro lado, se evita que el usuario pueda
cambiar su estado de maneras imprevistas e incontroladas.
El encapsulamiento se encarga de mantener ocultos los procesos internos que necesita
para hacer lo que sea que haga, dándole al programador acceso sólo a lo que necesita.

LA IDEA PRINCIPAL
El encapsulamiento permite el ocultamiento de la información de un objeto, solo
dejándose ver lo que cada objeto necesita hacer público.
UNIDAD 1 - TEMA 4
Herencia
Muchas veces en un problema de software Tal como se observa, cada una de las clases
se puede encontrar un concepto que tiene, representadas, puede manejar los clientes
por una parte, atributos o comportamientos físicos o jurídicos en un contexto determinado.
comunes, pero de ese mismo problema, No obstante, puede notarse también que
se derivan también algunos atributos o existen muchos atributos y operaciones
comportamientos que son específicos de comunes en ellos. Esto se debe a que, debido
ese problema en particular. En este caso, a que el concepto de cliente es un concepto
para resolver el problema se debe acudir general, por cada uno de los tipos de clientes
a la capacidad de herencia que tiene este que encontremos, tales características
paradigma. generales se repiten.
La herencia es un mecanismo muy poderoso Por lo tanto, otra estrategia que podemos
que permite agrupar en una característica realizar es crear una jerarquía donde
llamada superclase, los atributos y operaciones una superclase llamada Cliente reúna las
que son comunes a una o varias clases características comunes a todos los clientes
derivadas, las cuales heredan la definición de y dos clases derivadas, Cliente Físico y Cliente
dicha superclase. Jurídico, que representen la especialización
Supongamos el ejemplo de una empresa que para cada uno de estos. En la siguiente figura
maneja clientes. se representa esta jerarquía:
Los clientes pueden ser de dos categorías:
• Clientes naturales (personas)
• Clientes jurídicos (organizaciones,
empresas, corporaciones)
Para representar a los clientes de esta
compañía, dentro del software, se puede
recurrir a dos estrategias.
La primera sería crear una clase para cada una
de los tipos que describimos. En la siguiente
figura encontramos una ilustración de esta
estrategia.

En esta figura se observa cómo la clase Cliente

reúne los atributos y operaciones que son
comunes a todos los tipos de cliente que el
software vaya a manejar.
Para cada una de las clases derivadas, tal como
se representan en las clases de Cliente Físico
o Cliente Jurídico, se encuentran solamente los
atributos y operaciones que son propios de
cada uno de éstas. La jerarquía debe indicarnos
que cada una de las clases derivadas de la
superclase tiene, también todos los atributos y
operaciones de esta superclase.
Por ejemplo, todos los tipos de clientes tienen Tipos de herencias de clases
una identificación (sea cédula de identidad Existen dos tipos de herencia:
o cédula jurídica), una dirección postal, un • Herencia por especialización.
teléfono o un correo electrónico. No obstante, • Herencia por generalización.
solamente un cliente físico tendrá un apellido En realidad, la herencia es la misma, esta es una
y nombre, contrario a un cliente jurídico diferenciación puramente conceptual sobre la
que tendrá una razón social y un tipo de forma en que se ha llegado a ella.
organización (pública, privada, entre otras). Una herencia por especialización es la que
Además, todas las operaciones que se definan se realiza cuando necesitamos crear una
para Cliente serán también operaciones para clase nueva que disponga de las mismas
Cliente Físico o Cliente Jurídico. características que otra pero que le añada
Lo anterior tiene la ventaja de que por cada funcionalidades. Por ejemplo, si tenemos
tipo de cliente que estemos encontrando, nos una clase que genera un botón simple, y
enfocaremos en identificar las diferencias, sin necesitamos crear un botón que sea igual que
preocuparnos por detalles que ya la superclase el anterior pero que además añada un efecto al
ha resuelto. ser clicado.
La herencia por generalización es la que
Otro ejemplo realizamos cuando tenemos muchas clases que
Supongamos que tenemos una clase “Persona” comparten unas mismas funcionalidades y por
con los métodos y propiedades básicas de un homogeneizar las partes comunes se decide
objeto persona como podrían ser “caminar” o crear una clase que implemente toda esa parte
“hablar”, podríamos tener otras clases como común y se dejan solo las partes especificas
“Guillermo” o “Elder” que comparten todas en cada clase. Por ejemplo, si tenemos clases
las características de una “Persona” pero que para dibujar formas geométricas todas ellas
añaden características propias. disponen de las mismas propiedades (un color
Debido a lo anterior, “Pedro” y “Pablo” pueden de fondo, color de linea, etc.), todas estas
realizar las mismas funciones que puede características pueden estar en una clase
realizar una “Persona” y además cada una general de la que hereden todas las clases
puede realizar las suyas propias, por ejemplo, concretas, evitando tener que escribir todo ese
“Pedro” sabe nadar, pero “Pablo” no, y “Pablo” código común en todas ellas.
sabe bailar reggaetón, pero “Pedro” no. Una consideración importante a tener en
En términos de programación para describir cuenta de la herencia es que una clase no
lo anterior, estaríamos diciendo que “Pedro” hereda las propiedades o métodos privados,
y “Pablo” son dos clases especializadas por lo que no tendrán acceso a ellas. Si se
que heredan o extienden de la superclase necesita heredar propiedades o métodos que
“Persona”. no se quiere que sean accesibles desde fuera
de las clases se deben definir como “protected”.
 RESUMEN DEL TEMA
La herencia de clases es uno de los conceptos básicos del paradigma orientado a
objetos.
Muchas veces en un problema de software se puede encontrar un concepto que tiene,
por una parte, atributos o comportamientos comunes, pero de ese mismo problema,
se derivan también algunos atributos o comportamientos que son específicos de ese
problema en particular. En este caso, para resolver el problema se debe acudir a la
capacidad de herencia que tiene este paradigma.
La herencia es un mecanismo muy poderoso que permite agrupar en una característica
llamada superclase, los atributos y operaciones que son comunes a una o varias clases
derivadas, las cuales heredan la definición de dicha superclase.
Decir que una clase hereda de otra, quiere decir que esa clase obtiene los mismos
métodos y propiedades de la clase base, permitiendo de esta forma añadir a las
características heredadas, las suyas propias.
En el desarrollo de software este concepto de herencia es muy útil tanto para el análisis
de requisitos del problema como para el diseño e implementación de la solución.

LA IDEA PRINCIPAL
Heredar propiedades y comportamiento de una clase por parte de otra, es de
mucha utilidad.
UNIDAD 1 - TEMA 5
POLIMORFISMO
Piense por un momento que tantas veces en En el paradigma de orientación a objetos, la
la vida hacemos cosas que, como acciones característica de que un objeto pueda realizar
expresadas en verbos, las llamamos de forma una determinada acción, llamada igual, pero
semejante, pero que pueden resultar con que puede diferenciarse por un conjunto de
efectos u objetivos distintos. parámetros distintivos, se llama polimorfismo.
Por ejemplo, cada uno de nosotros tiene un El polimorfismo y la herencia son dos conceptos
ritmo natural y propio para caminar. estrechamente relacionados. Se puede
Si salimos de nuestra casa para ir a algún lado, implementar polimorfismo en jerarquías de
iremos caminando con esa forma propia de clasificación que se dan a través de la herencia.
cada uno (no es extraño que alguien exprese
algo como “ese es el caminado de fulano de
¿Para qué nos sirve en la práctica el
tal”). Sin embargo, muchas veces tenemos que
polimorfismo?
modificar la forma en que caminamos y, si bien
Usemos un ejemplo para explicarlo.
se trata de caminar, ciertamente debemos
Se tienen las clases “Largometraje” y “Cine”. En
tener en cuenta otros parámetros a la acción. Si
un cine se reproducen largometrajes.
nos encontramos ante una situación de peligro
Se pueden tener varios tipos de largometrajes,
podríamos caminar de forma precavida o bien
como películas o documentales, etc.
acelerada. Dependiendo de algo en especial,
Quizás las películas y documentales tienen
como pasar por una vitrina y darnos cuenta que
diferentes características, distintos horarios
algo nos interesó, podríamos caminar hacia
de audiencia, distintos precios para los
atrás para poder ver el objeto que llamó nuestra
espectadores y por ello has decidido que
atención. Entonces, lograríamos expresar la
tu clase “Largometraje” tenga clases hijas o
acción de caminar con distintos parámetros,
derivadas como “Película” y “Documental”.
y siempre nos estaríamos refiriendo a una
acción que se llama igual. En la siguiente tabla
encontramos algunos ejemplos de ello.

Acción Parámetros Lo que expresa

Caminar Ninguno Nuestro caminar
normal
Caminar Velocidad Caminar lenta o
rápidamente En la clase “Cine” se crea un método que se
llama “reproducir ()”, el cual podrá recibir como
Caminar Velocidad, C a m i n a r con parámetro aquello que quieres emitir en una
Dirección una velocidad sala de cine y podrán llegarte a veces objetos
determinada, hacia de la clase “Película” y otras veces objetos de la
atrás o hacia delante clase “Documental”.
Caminar Velocidad, Caminar con una Sin usar todavía polimorfismo, debido a que los
D i r e c c i ó n , velocidad y dirección métodos declaran los tipos de los parámetros
Forma determinadas, de que reciben, se tiene que hacer algo como esto,
forma normal o para reproducir una película y un documental,
precavida respectivamente:
• reproducir (Película película para Entonces lo que se debe hacer es declarar
Reproducir) el método “reproducir ()” indicando que el
• reproducir (Documental documenta para parámetro que vas a recibir es un objeto de
Reproducir) la clase padre “Largometraje”, pero donde
realmente el lenguaje y compilador aceptan
Probablemente el código de ambos métodos cualquier objeto de la clase hija o derivada
sea exactamente el mismo: (“Película”, “Documental”, etc.), tal como se
• Poner la película en el proyector muestra a continuación:
• Darle al play • reproducir (Largometraje elemento para
• Crear un registro con el número de entradas Reproducir)
vendidas Se podremos crear películas y reproducirlas,
• Parar la cinta cuando llega al final, etc. también crear documentales para luego
Preguntas que surgen: reproducir y lo interesante de este ejemplo
• ¿Realmente es necesario hacer dos de aplicación, es que todos estos objetos son
métodos? aceptados por el método “reproducir ()” gracias
• Igual no es tanto problema, pero ¿Si mañana a la relajación del sistema de tipos, que permite
mandan otro tipo de cinta a reproducir, el polimorfismo. Incluso, si mañana se quiere
como una grabación en 3D? reproducir otro tipo de cinta, no se tendrá que
• ¿Se tendrá que crear un nuevo método tocar la clase “Cine” ni el método “reproducir ()”,
reproducir () sobre la clase “Cine”, ¿que siempre que aquello que se quiera reproducir
acepte ese tipo de grabación? sea de la clase “Largometraje” o una clase hija,
• ¿Es posible ahorrarnos todo ese el método lo aceptará.
mantenimiento del software?
Aquí es donde el polimorfismo entra en acción y
ayuda a responder las anteriores interrogantes.
Se podría crear un método “reproducir ()” que
recibe un largometraje y donde podrás recibir
todo tipo de ellos; películas, documentales y
cualquier otra cosa similar que sea creada en
el futuro.
 RESUMEN DEL TEMA
Distintas formas de hacer cosas parecidas, eso es el polimorfismo.
En el paradigma de orientación a objetos, la característica de que un objeto pueda
realizar una determinada acción, llamada igual, pero que puede diferenciarse por un
conjunto de parámetros distintivos, se llama polimorfismo.
Piense por un momento que tantas veces en la vida hacemos cosas que, como acciones
expresadas en verbos, las llamamos de forma semejante, pero que pueden resultar
con efectos u objetivos distintos.
Por ejemplo, cada uno de nosotros tiene un ritmo natural y propio para caminar, pero
se llama igual: caminar, se diferencia por ciertos parámetros con los que la podemos
evaluar: por ejemplo, velocidad al caminar y sentido de la dirección en la cuál estamos
caminando.
El polimorfismo y la herencia son dos conceptos estrechamente relacionados. Se
puede implementar polimorfismo en jerarquías de clasificación que se dan a través de
la herencia.

LA IDEA PRINCIPAL
Un objeto pueda realizar una determinada acción, llamada igual, pero que puede
diferenciarse por parámetros distintivos.
 LECTURAS RECOMENDADAS
• https://profile.es/blog/que-es-la-programacion-orientada-a-objetos/
• Libro: El Paradigma de Objetos a tu Alcance: Aprendiendo a resolver problemas,
pensando en objetos (Edición en español).

ACTIVIDADES Y EJERCICIOS
• Leer el Silabo
• Reconocer y explicar ejemplos de clases y objetos en la vida real
• Reconocer y explicar con ejemplos prácticos los principios de encapsulamiento,
herencia y polimorfismo en clases y objetos.
• Reconocer y explicar con código ejemplo, en lenguaje Java, la aplicación de
estos principios.
• Se realizará en los entornos virtuales.
 INTRODUCCIÓN ACTITUDES
La disciplina de la Ingeniería de Software • La voluntad de perseverar y terminar las
ha tratado siempre de proveer una serie de tareas
metodologías que puedan facilitar el proceso de • Haga preguntas cuando sea necesario
construcción de una solución. Ese proceso ha • Tener la capacidad de pensar y trabajar
buscado adaptarse a la naturaleza cambiante independientemente
de los proyectos y de las soluciones. • Tiene habilidades para administrar su
Al inicio de un proyecto, por lo general, se tiempo y organizarse.
tiene una idea un tanto vaga de lo que se
quiere, aunque no se dude de la importancia TEMAS
de lo que desea obtenerse. De igual forma, el
cliente podrá saber, de forma muy general, qué
solución de software quiere que le desarrollen,
porque ella es fundamental para los objetivos
de su organización.
1
TEMA
Proceso Unificado de
Rational (RUP)
Un proceso de desarrollo que busque
identificar los factores críticos, y por ende
más riesgosos, que permita ir en un proceso
incremental de la solución, es altamente
deseable. Precisamente, el llamado Proceso
2
TEMA
por qué el RUP es
orientado a casos de uso
Unificado de Rational (RUP, de sus siglas en
inglés) es una forma de desarrollo de software
que permite ir creando una solución de forma
robusta, con un adecuado manejo del riesgo y
de forma incremental.
3
TEMA
por qué el RUP se centra en
la arquitectura
COMPETENCIA
Comprende la metodología de desarrollo de
software RUP, para realizar el análisis y diseño
de un sistema.
4
TEMA
por qué el RUP es
iterativo e incremental
CAPACIDADES
•

•
Comprende y demuestra sus habilidades en
la comprensión de la metodología RUP.
Comprende e interpreta la importancia de
5
TEMA
relación entre
UML y RUP
las disciplinas en el RUP
• Comprende la utilidad de los casos de uso
en la metodología RUP
UNIDAD 2 - TEMA 1
Qué es el Proceso
Unificado de Rational (RUP)
Un proceso de desarrollo de software es un El proceso de ciclo de vida de RUP se divide en
enfoque para el desarrollo, construcción, y cuatro fases bien conocidas llamadas Inicial,
mantenimiento de software (Larman, 2003). Elaboración, Construcción y Transición. Esas
Para ello, el Proceso Unificado de Rational fases se dividen en iteraciones, cada una de
(en adelante RUP, por sus siglas en inglés), las cuales produce una pieza de software
se presenta como uno de los procesos de demostrable. La duración de cada iteración
desarrollo de software más difundidos, que puede extenderse desde dos semanas hasta
busca aprovechar las ventajas del paradigma seis meses.
de orientación a objetos, en las disciplinas de
Análisis y Diseño, el cual llamaremos Análisis/ Las fases son:
Diseño Orientado a Objetos (ADOO). 1. Fase Inicial o Concepción:
El RUP es un proceso de ingeniería del software • Se especifican los objetivos del ciclo de
que proporciona un acercamiento disciplinado vida del proyecto, las necesidades de
a la asignación de tareas y responsabilidades cada participante.
en una organización de desarrollo. Su propósito • Se establece el alcance y las condiciones
es asegurar la producción de software de alta de límite y los criterios de aceptabilidad.
calidad que se ajuste a las necesidades de sus • Se identifican los casos de uso que
usuarios finales con unos costos y calendario orientarán la funcionalidad.
predecibles. • Se diseñan las arquitecturas candidatas
El RUP es una metodología de desarrollo y se estima la agenda y el presupuesto
de software que intenta integrar todos los de todo el proyecto, en particular para la
aspectos a tener en cuenta durante todo siguiente fase de elaboración.
el ciclo de vida del software, con el objetivo • Típicamente es una fase breve que
de hacer abarcables tanto pequeños como puede durar unos pocos días o unas
grandes proyectos software. Además, RUP pocas semanas.
proporciona herramientas para todos los 2. Elaboración.
pasos del desarrollo, así como documentación • Se analiza el dominio del problema y se
en línea para sus clientes. define el plan del proyecto.
• Brinda una arquitectura suficientemente
sólida junto con requerimientos y planes
bastante estables.
• Se describen en detalle la infraestructura
y el ambiente de desarrollo, así
como el soporte de herramientas de
automatización.
• Se debe identificar la mayoría de los
casos de uso y los actores, debe quedar
descripta la arquitectura de software y
se debe crear un prototipo de ella.
• Al final de la fase se realiza un análisis
para determinar los riesgos y se
evalúan los gastos hechos contra los
originalmente planeados.
3. Construcción. Además de estos flujos de trabajo, RUP define
• Se desarrollan, integran y verifican algunas prácticas comunes:
todos los componentes y rasgos de la • Desarrollo iterativo de software. Las
aplicación. iteraciones deben ser breves y proceder
• Esta fase es un proceso de manufactura, por incrementos pequeños. Esto
en el que se debe poner énfasis en permite identificar riesgos y problemas
la administración de los recursos y el tempranamente y reaccionar frente a ellos
control de costos, agenda y calidad. en consecuencia.
• Los resultados de esta fase (las versiones • Administración de requerimientos.
alfa, beta y otras versiones de prueba) se Identifica requerimientos cambiantes y
crean tan rápido como sea posible. postula una estrategia disciplinada para
• Se debe probar también una versión de administrarlos.
entrega. • Uso de arquitecturas basadas en
• Es la fase más prolongada de todas. componentes. La reutilización de
4. Transición. componentes permite asimismo ahorros
• Comienza cuando el producto está sustanciales en tiempo, recursos y esfuerzo.
suficientemente maduro para ser • Modelado visual del software. Se deben
entregado. construir modelos visuales, porque
• Se corrigen los últimos errores y se los sistemas complejos no podrían
agregan los rasgos pospuestos. comprenderse de otra manera. Utilizando
• La fase consiste en prueba beta, piloto, una herramienta como UML, la arquitectura
entrenamiento a usuarios y despacho y el diseño se pueden especificar sin
del producto a mercadeo, distribución y ambigüedad y comunicar a todas las partes
ventas. involucradas.
• Se produce también la documentación. • Prueba de calidad del software. RUP pone
• Se llama transición porque se transfiere bastante énfasis en la calidad del producto
a las manos del usuario, pasando del entregado.
entorno de desarrollo al de producción. • Control de cambios y trazabilidad. La
A través de las fases se desarrollan en paralelo madurez del software se puede medir por
nueve flujos de trabajo o disciplinas: Modelado la frecuencia y tipos de cambios realizados.
del Negocio, Requisitos, Análisis y Diseño,
Implementación, Pruebas, Implantación
Características de RUP
o Despliegue, Gestión de Cambios y
Configuración, Gestión del Proyecto y Ambiente Las características de RUP son las siguientes:
o Entorno. Estas disciplinas se agrupan en dos
grupos: i. Para el Desarrollo del sistema y ii.
Para la gestión del proyecto, como se ilustra en
la siguiente figura.
• Flujos de trabajo para el desarrollo del
sistema
• Modelado del negocio
• Requisitos
• Análisis y diseño
• Implementacion
• Pruebas
• Plantacion Las principales son las siguientes, las cuales
• flujos de trabajo para la gestion del se explicarán en los siguientes temas de esta
proyecto Unidad de Aprendizaje:
• Configuración y • Se orienta a casos de uso.
administración de • Se centra en la arquitectura.
cambios • Es iterativo e incrementa.
• Administración del • Utilización de UML (Lenguaje de Modelado
proyecto Unificado).
• Ambiente o entorno
 RESUMEN DEL TEMA
El RUP es una metodología de desarrollo de software que intenta integrar todos los
aspectos a tener en cuenta durante todo el ciclo de vida del software, con el objetivo
de hacer abarcables tanto pequeños como grandes proyectos software. Además, RUP
proporciona herramientas para todos los pasos del desarrollo, así como documentación
en línea para sus clientes.
El proceso de ciclo de vida de RUP se divide en cuatro fases bien conocidas llamadas
Inicial, Elaboración, Construcción y Transición. Esas fases se dividen en iteraciones,
cada una de las cuales produce una pieza de software demostrable.
A través de las fases se desarrollan en paralelo nueve flujos de trabajo o disciplinas:
Modelado del Negocio, Requisitos, Análisis y Diseño, Implementación, Pruebas,
Implantación o Despliegue, Gestión de Cambios y Configuración, Gestión del Proyecto
y Ambiente o Entorno. Estas disciplinas se agrupan en dos grupos: i. Para el Desarrollo
del sistema y ii. Para la gestión del proyecto.
Las principales son las siguientes, las cuales se explicarán en los siguientes temas de
esta Unidad de Aprendizaje:
• Se orienta a casos de uso.
• Se centra en la arquitectura.
• Es iterativo e incrementa.
• Utilización de UML (Lenguaje de Modelado Unificado).

LA IDEA PRINCIPAL
RUP es un estándar como metodología de desarrollo de software, en conjunto con
el lenguaje de modelado unificado UML.
UNIDAD 2 - TEMA 2
Comprender por qué el RUP
es orientado a casos de uso
Casos de Uso Se puede decir, entonces, que los casos de
Los Casos de Uso (CU) son una técnica de uso pueden interpretarse como las tareas del
captura de requisitos que fuerza a pensar sistema que se llevan a cabo, originadas por
en términos de importancia para el usuario alguien.
y no sólo en términos de funciones que seria Ahora bien, ¿Quién es ese alguien? Ese alguien
bueno contemplar. Se define un CU como un son los llamados actores en el sistema.
fragmento de funcionalidad del sistema que Un actor corresponde a un perfil de usuario, el
proporciona al usuario un valor añadido. Los cual puede ser una persona u otros sistemas.
CU representan los requisitos funcionales del El propósito de identificar actores es saber
sistema. quiénes son los usuarios del sistema y cómo
En RUP los casos de uso no son sólo una vamos a categorizarlos.
herramienta para especificar los requisitos Un actor es todo aquel (persona) o aquello
del sistema, también guían su diseño, (sistema, dispositivo) que usa el sistema, ya sea
implementación y prueba. Los casos de uso para alimentarlo o para recibir salidas de éste,
constituyen un elemento integrador y una guía por lo tanto, lo podemos conceptualizar, ya sea
del trabajo como se muestra en las siguientes que se trate de una persona, un dispositivo
figuras. u otro sistema, como algo o alguien que usa
o produce datos e información del o para el
sistema.

Ejemplo
Ejemplo clásico: cajeros automáticos.
Todo sistema debe poder caracterizarse por los
servicios que va a brindar a quienes se sirven
de él.
En este caso, podemos pensar que un cliente
podrá acceder a servicios como:
• “retirar efectivo”.
• “transferir fondos”
• “consultar saldo”
• “realizar pagos”, entre otros.
Estos servicios pueden verse como los objetivos
de un sistema de cajero automático.
Cada uno de los servicios que se le ofrecen a un
cliente podrán ser vistos como casos de uso:
• El caso de uso de “Retirar efectivo”.
Se entienden los casos de uso como la • El caso de uso de “Transferir fondos”.
interacción que tienen los usuarios del sistema • El caso de uso de “Consultar saldo”.
con éste. Para identificar los casos de uso • El caso de uso de “Realizar pagos”.
pueden listarse las funciones, actividades u Con respecto a los actores, se puede pensar en
objetivos que tiene un usuario particular en el el cliente, como un actor del sistema de cajeros
sistema. automáticos.
El cliente interactúa con este sistema y, en El sistema bancario debe, además, apoyar
gran medida, para él es quien se ha creado el las acciones de registro de transacciones,
sistema. de actualización de saldos, de comunicar a
No obstante, se puede pensar que existen otros otras entidades relacionadas con los servicios
actores importantes del sistema. Usted ha visto ofrecidos en el cajero automático entre
que en ciertos momentos llegan funcionarios muchos.
del banco o entidad financiera dueña de los Identificar los casos de uso nos da una
cajeros automáticos a realizar procesos en forma de poder ir listando los objetivos y los
ellos, tales como alimentarlos de efectivo, requerimientos del sistema por parte de una
descargar la información almacenada, realizar serie de interesados, en este caso, los actores
mantenimiento, entre otras acciones. que podamos encontrar en el sistema.
Con respecto a un funcionario, al cual Un caso de uso es una forma relativamente
denominaremos operario, encontramos sencilla de especificar los objetivos de un
otras funcionalidades en este sistema y como sistema. Por eso constituye una de las bases
tal, también estamos identificando otro principales del RUP.
actor del sistema. Las funcionalidades como Para visualizar gráficamente los casos de uso,
“Descargar información almacenada”, “Realizar se recurre a un diagrama de casos de uso,
mantenimiento”, “Alimentar efectivo” se donde se ven las interacciones de los actores
pueden ver como casos de uso. con los casos de uso identificados. Para el
Por último, podemos pensar que el cajero caso del cajero automático, puede hacerse
automático es un sistema que se relaciona con un diagrama de casos de uso como el que se
un sistema bancario central: todas las acciones muestra en la siguiente figura.
que se dan en el cajero deben estar apoyadas
por el sistema bancario central donde, entre El diagrama de casos de uso ayuda a
muchas cosas, se encuentra la información de comprender y visualizar cómo interactúan los
la o las cuentas asociadas con la tarjeta que se actores del sistema. Adicionalmente los casos
emplea para el uso del cajero. de uso también representan los objetivos del
sistema expresados como las funcionalidades
que esperamos obtener. Por lo tanto, en los
diagramas de casos de uso podemos ubicar
tales objetivos del sistema de una forma
relativamente sencilla.
 RESUMEN DEL TEMA
Los Casos de Uso (CU) son una técnica de captura de requisitos que fuerza a pensar
en términos de importancia para el usuario y no sólo en términos de funciones que
sería bueno contemplar. Se define un CU como un fragmento de funcionalidad del
sistema que proporciona al usuario un valor añadido. Los CU representan los requisitos
funcionales del sistema.
El hecho de que el RUP se base en casos de uso, tiene la ventaja que esta técnica ayuda
a identificar todas las funcionalidades de un software en perspectiva de los objetivos
de los usuarios.
Los casos de uso son una forma relativamente sencilla de especificar los objetivos de
un sistema.
Igualmente, los casos de uso en RUP, constituyen la base para validar el trabajo técnico
que se realizará posteriormente por los ingenieros de software, en las fases de análisis
y diseño del sistema.
Por lo anterior, se puede afirmar que los casos de uso constituyen un elemento
integrador y una guía del trabajo.

LA IDEA PRINCIPAL
RUP utiliza los casos de uso como base para recabar los requisitos, así como, para
validar otras etapas del ciclo de vida del software.
UNIDAD 2 - TEMA 3
COMPRENDER POR QUÉ EL RUP
SE CENTRA EN LA ARQUITECTURA
ARQUITECTURA DEL SISTEMA ORGANIZAR EL DESARROLLO
Cuando se piensa en el término “arquitectura”, Cuando se habla de organizar el desarrollo,
se puede referir a un concepto de solidez, de puede decirse que se busca dividir el problema
que existe un esfuerzo de ordenar y dar una en un conjunto de elementos previendo, eso sí,
solución de espacio, de funcionalidad a un que tales elementos puedan luego integrarse.
problema o requerimiento de un cliente. Tal división puede hacerse, en grandes
Una arquitectura se necesita para: proyectos, a través de subsistemas. En una
• Comprender el sistema. organización puede hablarse de un subsistema
• Organizar el desarrollo. financiero, un subsistema de relaciones con el
• Fomentar la reutilización. cliente, un subsistema de aprovisionamiento,
• Hacer evolucionar el sistema. entre muchos otros. Claro está, que si bien
cada uno de estos subsistemas tiene funciones
y objetivos específicos, deben comunicarse y,
COMPRENDER EL SISTEMA
de hecho, están íntimamente relacionados.
Para comprender un sistema se requiere
Es así como, por ejemplo, en una empresa
“entrenar” a las personas involucradas en él,
fabricante, los insumos, el proceso de
desde los clientes, pasando por los analistas,
fabricación de sus productos, los gastos de
desarrrolladores, hasta los técnicos en soporte,
publicidad y mercadeo, las ventas, etc., afectan
etc., de tal forma que puedan comunicarse
el subsistema financiero y debe preverse que
por medio de modelos donde se expresa la
estos se comunican para garantizar el buen
solución que va logrando obtenerse. El UML,
funcionamiento de la empresa.
a través de sus diagramas, ayuda a que esta
En el caso de nuestro sistema del cajero
comprensión se dé. Piense que en un proyecto
automático, ¿qué subsistemas podemos
grande pueden intervenir muchas personas
encontrar? Si bien podría aparentar ser
las cuales, incluso, pueden estar dispersas
un sistema pequeño, hay elementos muy
geográficamente. Por lo tanto, tal comunicación
especializados los cuales, por esa naturaleza,
estandarizada, que provoque una mayor
podrían separarse para su desarrollo: el manejo
comprensión del trabajo que se está llevando
de los dispositivos como el lector de tarjetas,
a cabo, es sumamente importante.
el contador de efectivo, la comunicación con
el servidor del banco, entre otros. De todas
formas, al igual que se separan tareas, deberán
preverse las uniones o interfaces, mediante las
cuales el producto requerido será armado.
A lo interno de los subsistemas, igualmente,
encontraremos elementos que usaremos
o desarrollaremos para conseguir lo que
requerimos para el producto que necesitamos
crear. Hay algunos elementos esenciales que se
combinan en su diseño y funcionamiento: los
objetos agrupados en clases.
 FOMENTAR LA REUTILIZACIÓN En este libro nos enfocaremos principalmente
Por fomentar la reutilización, debemos en el desarrollo de modelos de clases,
entender que un objetivo que se persigue en como parte de la formación fundamental
la ingeniería de software, es que las soluciones que debemos aprender para diseñar una
(o parte de ellas) que se han generado para un arquitectura fuerte en el ámbito del problema
problema particular, puedan ser reutilizadas en que tratamos. Más adelante estudiaremos con
la solución de otro problema. detalle cómo hacer tales modelos.
Precisamente, una arquitectura busca crear Dentro de lo que estudiaremos, cabe señalar,
componentes de software que bien que es fundamental comenzar siempre
pueden acomodarse en soluciones por identificar los conceptos (clases
pertenecientes a otros dominios conceptuales) que vayamos
del problema. reconociendo dentro de
No es de esperar que una los requerimientos que se
organización tenga que hacer especifican en el problema que
un subsistema financiero, cada necesitamos resolver.
vez que inicia el desarrollo Al tener identificado
de un sistema nuevo. Ya sea un concepto, debemos
para un sistema de ventas, de preguntarnos cómo se relaciona
aprovisionamiento, de matrícula, con otros conceptos y, de alguna
o lo que fuere que emprenda la forma, qué características de
organización, esta sabrá que existe atributos y comportamiento podría
un software orientado a las operaciones tener el concepto identificado. Esto quizás
financieras que podrá darles servicio en cada llevará algún tiempo, pero en un proceso
problema de software que tengan que resolver. de muchas iteraciones, podríamos tener un
panorama completo del o de los conceptos
involucrados, los cuales se expresarían
HACER EVOLUCIONAR EL SISTEMA mediante modelos de componentes, de clases
Todo sistema está sujeto a cambios. La y de interacción. Tales modelos se explicarán a
utilización misma del sistema, la formulación lo largo del libro y, veremos, como en ellos son
de nuevos objetivos, la experiencia de la fundamentales los casos de uso.
organización, la respuesta a nuevos retos, Con estos modelos tendremos dos visiones de
harán que exista la necesidad de que éste la arquitectura. Por una parte, una arquitectura
evolucione. Por lo tanto, es crucial tener una estática, la cual muestra la disposición y
arquitectura bien planteada, fuerte, flexible, organización de los elementos del sistema y,
donde el impacto del cambio pueda manejarse por otra parte, la arquitectura dinámica la cual
convenientemente, y donde la ampliación de permite ver cómo interactúan esos elementos
las funciones pueda darse minimizando los para poder resolver un objetivo particular del
efectos sobre lo que ya está hecho. sistema. Ese objetivo particular ha sido definido
Sabemos que los retos a los que se somete una previamente, como un caso de uso.
arquitectura son muy altos. Es necesario, por lo En la siguiente figura se ilustra la evolución de
tanto, que aprendamos a visualizar que todos la arquitectura durante las fases de RUP. Se
los elementos que vayamos construyendo, tiene una arquitectura más robusta en las fases
tengan un proceso de construcción que permita finales del proyecto. En las fases iniciales lo que
obtener una arquitectura con características se hace es ir consolidando la arquitectura por
como las que se han señalado anteriormente. medio de líneas de base y se va modificando
Los casos de uso son importantes en ese dependiendo de las necesidades del proyecto.
objetivo, porque permitirán identificar
aspectos claves de la arquitectura. Algunos
de esos casos de uso son esenciales en la
arquitectura, porque constituyen elementos
clave en la funcionalidad esperada del sistema
y, por lo tanto, harán que se pueda visualizar
qué aspectos en cuanto a subsistemas,
componentes, clases, entre muchos otros, son
vitales.
 RESUMEN DEL TEMA
Una arquitectura se necesita para comprender el sistema, organizar el desarrollo.,
fomentar la reutilización y hacer evolucionar el sistema.
Para comprender un sistema se requiere que las personas involucradas puedan
comunicarse por medio de modelos donde se expresa la solución que va logrando
obtenerse.
Con la arquitectura se busca dividir el problema en un conjunto de elementos,
previendo que tales elementos puedan luego integrarse, esto puede hacerse a través
de subsistemas.
Se debe entender que un objetivo que se persigue en la ingeniería de software, es que
las soluciones (o parte de ellas) que se han generado para un problema particular,
puedan ser reutilizadas en la solución de otro problema.
Debido a que todo sistema está sujeto a cambios es muy importante tener una
arquitectura bien planteada, fuerte, flexible, donde el impacto del cambio pueda
manejarse convenientemente, y donde la ampliación de las funciones pueda darse
minimizando los efectos sobre lo que ya está hecho.

LA IDEA PRINCIPAL
En RUP tiene como objetivo diseñar una arquitectura modular y adaptable
definida a través de modelos.
UNIDAD 2 - TEMA 4
COMPRENDER POR QUÉ EL RUP
ES ITERATIVO E INCREMENTAL
Abordar una solución de software implica El proceso iterativo e incremental consta de una
muchos riesgos. Uno de los más importantes secuencia de iteraciones, cada iteración aborda
es, sin duda, no comprender bien los una parte de la funcionalidad total, pasando
requerimientos del usuario y, por ende, por todos los flujos de trabajo relevantes y
desarrollar una aplicación errónea. Al afirmar refinando la arquitectura.
que es errónea, se asume que esta puede estar Cada iteración se analiza cuando termina, se
diseñada, codificada y probada de la forma puede determinar si han aparecido nuevos
más depurada técnicamente hablando, requisitos o han cambiado los existentes,
pero que lastimosamente no responde afectando a las iteraciones siguientes.
a las necesidades del cliente. Durante la planificación de los
Para minimizar este riesgo, el detalles de la siguiente iteración,
RUP plantea que el desarrollo del el equipo también examina cómo
software sea iterativo, es decir, afectarán los riesgos que aún
que los proyectos de software se quedan al trabajo en curso.
dividan en ciclos. Estos deben ser de Toda la retroalimentación de la
una duración relativamente corta, en iteración pasada permite reajustar
general de 4 a 6 semanas. los objetivos para las siguientes
El equilibrio correcto entre los Casos de iteraciones.
Uso y la Arquitectura es algo muy parecido Se continúa con esta dinámica hasta que se
al equilibrio de la forma y la función en el haya finalizado por completo con la versión
desarrollo del producto, lo cual se consigue con actual del producto.
el tiempo. RUP divide el proceso en cuatro fases, dentro
Para esto, la estrategia que se propone en RUP de las cuales se realizan varias iteraciones en
es tener un proceso iterativo e incremental número variable según el proyecto y en las
en donde el trabajo se divide en partes más que se hace un mayor o menor hincapié en los
pequeñas o mini proyectos, permitiendo que distitas actividades, estas cuatro fases fueron
el equilibrio entre casos de uso y arquitectura explicadas en el tema 1 de esta Unidad de
se vaya logrando durante cada mini proyecto, Aprendizaje.
así durante todo el proceso de desarrollo.
Cada mini proyecto se puede ver como
una iteración (un recorrido más o menos
completo a lo largo de todos los flujos de
trabajo fundamentales) del cual se obtiene un
incremento que produce un crecimiento en el
producto.
Se pasa por los flujos fundamentales
(Requisitos, Análisis, Diseño, Implementación
y Pruebas), también existe una planificación
de la iteración, un análisis de la iteración y
algunas actividades específicas de la iteración.
Al finalizar se realiza una integración de los
resultados con lo obtenido de las iteraciones
anteriores.
 VENTAJAS
De acuerdo con Larman (2003), algunas de las
ventajas de adoptar este enfoque son:
• Involucra continuamente a los usuarios para
evaluación, retroalimentación y requisitos.
• Aborda aspectos de alto riesgo en las
primeras iteraciones.
• Construye, en las primeras iteraciones,
una arquitectura que constituye un núcleo
primario consistente.
• Verifica la calidad continuamente, ya
que se desarrollan pruebas, oportuna y
frecuentemente.
El riesgo de hacer un mal trabajo se reduce,
pues este se circunscribe a una sola iteración,
en vez de arrastrar mucho tiempo un error,
evitando así, que se descubra únicamente al
final de todo el proceso. Esas características
son muy valiosas para desarrollar un software
que responda a las necesidades planteadas.
 RESUMEN DEL TEMA
El desarrolllo de software implica muchos riesgos.
Uno de los más importantes es, sin duda, no comprender bien los requerimientos del
usuario y, por ende, desarrollar una aplicación errónea. Al afirmar que es errónea, se
asume que esta puede estar diseñada, codificada y probada de la forma más depurada
técnicamente hablando, pero que lastimosamente no responde a las necesidades del
cliente.
Para minimizar este riesgo, el RUP plantea que el desarrollo del software sea iterativo,
es decir, que los proyectos de software se dividan en ciclos.
El proceso iterativo e incremental consta de una secuencia de iteraciones, cada
iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de
trabajo relevantes y refinando la arquitectura.
RUP plantea que el desarrollo del software sea iterativo para minimizar riesgos, entre
ellos el de no adaptarse a cambios en los requisitos del sistemas, que en algunos casos
pueden ser muy volátiles. Para ello, se involucra continuamente a los usuarios para
evaluación, retroalimentación y requisitos.

LA IDEA PRINCIPAL
El proceso iterativo e incremental de RUP minimiza los riesgos durante el proceso
de desarrollo.
UNIDAD 2 - TEMA 5
COMPRENDER RELACIÓN
ENTRE UML Y RUP
¿QUÉ ES EL LENGUAJE DE MODELADO UNIFICADO (UML) Y CUÁL ES SU RELACIÓN CON
RUP?
El Lenguaje Unificado de Modelación (o UML, junto con UML, tratan de mejorar el desarrollo
por sus siglas en inglés) es una familia de de software no solo con una serie de pasos
diagramas orientados a apoyar el proceso de establecidos, si no combinando varios modelos,
Análisis y Diseño Orientado a Objetos (ADOO), esto dependiendo de las necesidades del
se utiliza para representar casos de uso, clases, cliente que solicite el desarrollo del sistema.
la interacción entre objetos de una clase,
la configuración de un sistema, entre otras
muchas aplicaciones. UML es el resultado de
un acuerdo entre varios precursores del ADOO
en dotar esta metodología de una notación
estándar.
El RUP, al basarse en las ventajas del paradigma
de orientación a objetos, se apoya, a su vez, en
la notación que proporciona el UML.
El RUP es un proceso de desarrollo de software
y junto con el Lenguaje de Modelado Unificado
UML, constituye la metodología estándar más
utilizada para el análisis, implementación y
documentación de sistemas orientados a
objetos.
UML es un lenguaje de modelado para
visualizar, especificar, construir y documentar
partes de un sistema software desde distintos
puntos de vista:
• Puede usarse con cualquier proceso OBJETIVO DE UML
de desarrollo, a lo largo de todo el ciclo El objetivo de UML es la unificación de los
de vida y puede aplicarse a todos los métodos de modelado de objetos por medio
dominios de aplicación y plataformas de de:
implementación. • La identificación y definición de la semántica
• También puede usarse en otras áreas, de los conceptos fundamentales y elección
como la ingeniería de negocio y modelado de una representación gráfica con una
de procesos gracias a los mecanismos de sintaxis simple, expresiva e intuitiva.
adaptación/extensión mediante perfiles
que incorpora.
U M L p r o p o r c i o n a m e c a n i s m o s d e LO QUE NO ES UML
modelamiento visual (diagramas) de tal UML no es una notación propietaria.
forma que permite desarrollar e intercambiar • UML no es un método, ni un proceso ni una
modelos con significado de acuerdo al metodología.
problema a resolver y la solución a desarrollar.
RUP para el desarrollo de software moderno
 DIAGRAMAS Y VISTAS UML
Un modelo captura una vista de un sistema El código fuente del sistema es el modelo más
del mundo real. Es una abstracción de dicho detallado del sistema (y además es ejecutable).
sistema, considerando su propósito. Sin embargo, se requieren otros modelos.
Un diagrama es una representación gráfica Varios modelos aportan diferentes vistas de un
de una colección de elementos de modelado. sistema, los cuales nos ayudan a comprenderlo
Un proceso de desarrollo de software debe desde varios frentes.
ofrecer un conjunto de modelos que permitan UML define varios modelos para la
expresar el producto desde cada una de las representación de los sistemas que pueden
perspectivas de interés. Es aquí donde se hace verse y manipularse mediante un conjunto de
evidente la importancia de UML en el contexto diagramas diferentes, divididos en diagramas
de un proceso de desarrollo de software, como estructurales y diagramas de comportamiento,
el RUP. tal como se muestran en la siguiente figura.

Conforme vayamos avanzando en el libro,

se irán introduciendo los diagramas que nos
apoyan en cada parte de la teoría que vaya
desarrollándose, para así comprender y
manejar las herramientas para hacer análisis y
diseño orientado a objetos.
 RESUMEN DEL TEMA
El Lenguaje Unificado de Modelación es una familia de diagramas orientados a apoyar
el proceso de Análisis y Diseño Orientado a Objetos (ADOO), se utiliza para representar
casos de uso, clases, la interacción entre objetos de una clase, la configuración de un
sistema, entre otras muchas aplicaciones.
El Lenguaje Unificado de Modelación (UML) es un estándar para cualquier metodología
de desarrollo que use el paradigma orientado a objetos. Puede usarse con cualquier
proceso de desarrollo, a lo largo de todo el ciclo de vida y puede aplicarse a todos los
dominios de aplicación y plataformas de implementación.
También puede usarse en otras áreas, como la ingeniería de negocio y modelado de
procesos.
El RUP, al basarse en las ventajas del paradigma de orientación a objetos, se apoya, a
su vez, en la notación que proporciona el UML.

LA IDEA PRINCIPAL
RUP y UML son estándares en el análisis y diseño de sistemas bajo el paradigma
orientado a objetos.
 LECTURAS RECOMENDADAS
• RUP Best Practices: http://www.scribd.com/doc/41153/RUP-Best-Practices?query2
=rup+test+report+template
• Ivar Jacobson, Grady Booch y James Rumbaugh, El Proceso Unificado de Desarrollo
de Software (RUP), Editorial Addison Wesley, España 2000

ACTIVIDADES Y EJERCICIOS
• Analizar y comprender un caso de estudio de uso de la metodología RUP.
• Diferenciar entre las disciplinas del ciclo de vida del software y las de gestión
del proyecto
• Evaluar y comprender la importancia y utilidad de los casos de uso en RUP.
• Se realizará en los entornos virtuales.
 INTRODUCCIÓN ACTITUDES
El UML está compuesto por diversos • La capacidad de pensar y trabajar por
elementos gráficos que se combinan para cuenta propia.
conformar diagramas. Debido a que el • Puede adaptarse a ambientes de estudio
UML es un lenguaje, cuenta con reglas para nuevos.
combinar tales elementos. La finalidad de los • Toma decisiones con respecto a opciones
diagramas es presentar diversas perspectivas curriculares.
de un sistema, a las cuales se les conoce como • El alumno es una persona libre en un
modelo. Recordemos que un modelo es una ambiente y entorno propicio.
representación de la realidad; el modelo UML
describe lo que hará un sistema software.
TEMAS
Un modelo captura una vista de un sistema
del mundo real, es una abstracción de dicho
sistema, considerando su propósito. El
modelo describe completamente aquellos
1
TEMA
Diagramas de casos de uso
aspectos del sistema que son relevantes al
propósito del mismo, y a un apropiado nivel
de detalle. Esta descripción del sistema es
la que nos permite el uso de UML durante
el desarrollo de un sistema software.
2
TEMA
Diagramas de clases
La primera regla de la creación de modelos
es que el código y el texto consumen tiempo,
y no queremos pasar una gran cantidad de
tiempo creando documentos de texto que
nadie leerá. Lo que sí queremos hacer es
3
TEMA
Diagramas de actividad
captar con lo más exacto posible las partes
importantes del problema y una solución.

COMPETENCIA
Demuestra el manejo básico del lenguaje de
4
TEMA
Diagramas de secuencia
modelado unificado (UML) para usarlo en el
modelado de análisis y diseño de sistemas.

CAPACIDADES 5
TEMA
Diagramas de colaboración
• Demostrar el manejo básico de uso de
diferentes diagramas UML
• Realizar diagramas básicos de UML, con
cualquier herramienta UML.
UNIDAD 3 - TEMA 1
Diagramas de casos de uso
¿QUÉ ES UN CASO DE USO? COMPONENTES DE LOS CASOS DE USO
Los casos de uso describen bajo la forma de Los casos de uso son una técnica para la
acciones y reacciones el comportamiento de especificación de requisitos funcionales
un sistema desde el punto de vista del usuario. propuesta inicialmente por Ivar Jacobson (1987)
Definición en UML: “Un caso de uso especifica e incorporada a UML.
un conjunto de secuencias de acciones, Modela la funcionalidad del sistema tal como
incluyendo variantes, que el sistema puede la perciben los agentes externos, denominados
ejecutar y que produce un resultado observable actores, que interactúan con el sistema desde
de valor para un particular actor.” un punto de vista particular.
¿Para qué se utilizan? Sus componentes principales y sus estereotipos
• Los casos de uso son descripciones de la son:
funcionalidad del sistema independientes • Sistema: sistema que se modela.
de la implementación.
• Es una herramienta valiosa dado que es una
técnica de aciertos y errores para obtener
los requerimientos del sistema, desde el
punto de vista del usuario.
• Un caso de uso es una técnica de modelado
utilizada para describir lo que un nuevo
sistema debe hacer o lo que un sistema
existente ya hace.
¿Para quién está orientado?
Están basado en el lenguaje natural, es decir,
son accesibles por los usuarios. Un caso de • Casos de uso: unidades funcionales
uso es una descripción de las acciones de un completas.
sistema desde el punto de vista del usuario.

• Actores: entidades externas que interactúan

con el sistema.
• Relaciones: interacción entre actores y casos de usos y entre casos de uso.

El sujeto se muestra como una caja negra que proporciona los casos de uso.
El modelo de casos de uso se representa mediante los diagramas de casos de uso.

DIAGRAMAS DE CASOS DE USO

Los diagramas de caso de uso modelan la
funcionalidad del sistema usando actores y
casos de uso.
Los casos de uso son servicios o funciones
provistas por el sistema para sus usuarios.
Un modelo de casos de uso se construye
mediante un proceso iterativo durante las
reuniones entre los desarrolladores del
sistema y los clientes (y/o los usuarios finales)
conduciendo a una especificación de requisitos
sobre la que todos coinciden.
Un caso de uso captura algunas de las acciones
y comportamientos del sistema y de los actores.
Los diagramas de casos de uso son
responsables principalmente de documentar
los macro requisitos del sistema. Piense en
los diagramas de casos de uso como la lista
de las capacidades o funciones que debe
proporcionar el sistema.
Un diagrama de casos de usos general se
representa en la siguiente figura:
 RESUMEN DEL TEMA
“Un caso de uso especifica un conjunto de secuencias de acciones, incluyendo variantes,
que el sistema puede ejecutar y que produce un resultado observable de valor para un
particular actor.”
Un caso de uso es una técnica de modelado utilizada para describir lo que un nuevo
sistema debe hacer o lo que un sistema existente ya hace.
Un caso de uso es la típica interacción entre un usuario y un sistema informático.
El diagrama de Casos de Uso es un diagrama sencillo que tiene como finalidad dar
una visión global de toda la aplicación de forma que se pueda entender de una forma
rápida y gráfica tanto por usuarios como por desarrolladores. El diagrama de casos de
uso es parte de los diagramas estáticos de UML.
El diagrama de casos de usos es el diagrama integrador de los flujos de trabajos de la
metodología RUP, durante el ciclo de vida del software.

LA IDEA PRINCIPAL
Un diagrama de caso de uso representa la interacción
entre los usuarios y las funcionalidades de un sistema
informático
UNIDAD 3 - TEMA 2
Diagramas de clases
¿QUÉ ES UN DIAGRAMA DE CLASE? Un diagrama de clases está formado por varios
Los diagramas de clases describen la estructura rectángulos de este tipo conectados por líneas
estática de un sistema. Describe la definición de que representan las asociaciones o maneras en
cada uno de los posibles objetos pertenecientes que las clases se relacionan entre sí.
al sistema. Siguiendo con el ejemplo de la clase Aviones,
Muestra las clases del sistema, sus atributos, se muestra a continuación como se representa
operaciones (o métodos), y las relaciones entre gráficamente:
los objetos.
Es un diagrama desarrollado por analistas,
diseñadores y desarrolladores.
Las cosas que existen y que nos rodean se
agrupan naturalmente en categorías. Una clase
es una categoría o grupo de cosas que tienen
atributos (propiedades) y acciones similares
(comportamientos).
Un ejemplo puede ser la clase “Aviones”:
Que tiene atributos como:
• “modelo de avión”
• “la cantidad de motores”,
• “la velocidad de crucero”
• “la capacidad de carga útil”. En el área superior figura el nombre de la clase
Entre las acciones de las cosas (objetos) de esta que utilizamos como ejemplo, en la central
clase se encuentran: están sus atributos y en la inferior las acciones
• “acelerar” que ella realiza. Note que las acciones llevan
• “elevarse” paréntesis al final del nombre dado que las
• “girar” “descender” mismas son funciones y por lo tanto devuelven
• “desacelerar”. un valor.

REPRESENTACIÓN GRÁFICA DE UNA CLASE ASOCIACIONES

Un rectángulo es el símbolo que representa a la Las asociaciones son las que representan a las
clase, y se divide en tres áreas. relaciones estáticas entre las clases.
Las clases se representan con rectángulos El nombre de la asociación va por sobre o por
divididos en tres áreas: la superior contiene debajo de la línea que la representa.
el nombre de la clase, la central contiene los Una flecha rellena indica la dirección de la
atributos y la inferior las acciones, tal como se relación.
ilustra en la siguiente figura:
 MULTIPLICIDAD La Composición es un tipo
Las notaciones utilizadas para señalar la especial de agregación que
multiplicidad se colocan cerca del final de una denota una fuerte posesión
asociación. de la Clase “Todo”, a la Clase
Estos símbolos indican el número de instancias “Parte”. Se grafica con un rombo
de una clase vinculadas a las instancias de la diamante relleno contra la clase
otra clase. que representa el todo. Si la
Por ejemplo, una empresa puede tener uno o Clase “Todo” se elimina, las Clases “Parte” por si
más empleados, pero cada empleado trabaja solas no tienen sentido. La Composición es una
para una sola empresa solamente. asociación con la semántica “compuesto por/es
componente de”.
Se muestra a continuación el ejemplo de Libro
representando una Clase “Todo” y la Clase
Capitulo una Clase “Parte”. Si se elimina la Clase
Libro no tiene sentido que siga existiendo la
Clase Capitulo.

GENERALIZACIÓN
Generalización es otro nombre
AGREGACIÓN Y COMPOSICIÓN para herencia.
La Agregación es una relación en la que la Se refiere a una relación entre
Clase “Todo” juega un rol más importante que dos clases en donde una Clase
la Clase “Parte”, pero las dos clases no son “Específica” es una versión
dependientes una de otra. Se grafica con un especializada de la otra, o Clase
rombo diamante vacío contra la Clase “Todo”. Si “General” o “Base”.
la Clase “Todo” se elimina, no necesariamente Por ejemplo, Honda es un tipo de auto, por lo
desaparecen las Clases “Parte”. La Agregación que la Clase “Honda” va a tener una relación de
es una asociación con la semántica “formado generalización con la Clase “Auto”.
por/forma parte de”.
EJEMPLO BÁSICO DE UN
DIAGRAMA DE CLASES
En un proceso de negocio en donde se realicen
actividades de compras de productos a un
proveedor, para mantener el stock deseado, se
podría observar esta relación de Clases con sus
respectivos atributos.
Se puede leer de la siguiente manera: Una
Se muestra a continuación el ejemplo de Compra se asigna o pertenece a un Proveedor,
Ordenador representando una Clase “Todo” y contiene uno o muchos Productos. A su vez,
y sus componentes como Clases “Parte”. Si ese Producto puede ser adquirido en una o
se elimina la Clase Ordenador podrían seguir más compras.
existiendo las Clases “Parte”, ya que pueden
existir independientemente.
 RESUMEN DEL TEMA
Es el diagrama de clases es el más común en modelos en el análisis y diseño orientados
a objetos, describen la estructura estática de un sistema y la definición de cada uno de
los posibles objetos pertenecientes al sistema.
Los diagramas de clases se usan para mostrar las clases de un sistema y las relaciones
entre ellas. Una sola clase puede mostrarse en más de un diagrama de clases y no es
necesario mostrar todas las clases en un solo diagrama monolítico de clases.
El mayor valor de estos diagramas es mostrar las clases y sus relaciones desde varias
perspectivas, de una manera que ayude a transmitir la comprensión más útil del
sistema.
Los diagramas de clases muestran una vista estática del sistema; no describen los
comportamientos o cómo interactúan los objetos de las clases. Para describir los
comportamientos y las interacciones entre los objetos de un sistema, se usan los
diagramas de interacción.

LA IDEA PRINCIPAL
El diagrama de clases es de los más importantes diagramas usados en el Análisis
y Diseño Orientado a Objetos.
UNIDAD 3 - TEMA 3
DIAGRAMAS DE ACTIVIDAD
¿QUÉ SON LOS DIAGRAMAS DE ACTIVIDAD?
Los diagramas de actividad permiten describir
como un sistema implementa su funcionalidad,
mostrando el flujo de actividades asociado a
dicha funcionalidad.
Modelan el comportamiento dinámico de un
procedimiento, transacción o caso de uso
haciendo énfasis en el proceso que se lleva a
cabo.
Se usan para analizar los procesos y, si es
necesario, volver a realizar la ingeniería de los
procesos.
Es uno de los elementos de modelado que son
mejor comprendidos por todos, ya que son
herederos directos de los diagramas de flujo,
pero son más expresivos que los diagramas de
UTILIDAD DE UN DIAGRAMA DE ACTIVIDAD
flujo.
Son útiles para:
Desde un punto de vista conceptual, el
• Ilustrar un proceso de negocios o flujo de
diagrama de actividades muestra cómo fluye el
trabajo entre los usuarios y el sistema.
control de unas clases a otras con la finalidad
• Demostrar la lógica de un algoritmo.
de culminar con un flujo de control total que se
• Describir los pasos realizados en un caso de
corresponde con la consecución de un proceso
uso (permiten describir como un sistema
más complejo.
implementa su funcionalidad)
Gráficamente un diagrama de actividad será un
• Simplificar y mejorar cualquier proceso
conjunto de arcos y nodos.
clarificando casos de uso complicados.
• Modelar elementos de arquitectura de
EJEMPLO DE UN DIAGRAMA DE ACTIVIDAD software, tales como método, función y
Consideremos el caso de uso “Hallar alimento” operación.
para un Actor acampando en una cueva en una Un diagrama de actividades es una herramienta
montaña. excelente para analizar problemas que,
al final, el sistema deberá resolver. Como
una herramienta de análisis, no queremos
empezar resolviendo el problema en un nivel
técnico mediante la asignación de clases, pero
podemos usar los diagramas de actividades
para entender el problema e incluso refinar los
Con el diagrama de actividad lo que se quiere procesos que comprenden el problema.
es describir gráficamente el flujo de acciones Cuando se trata de un caso de uso asociado con
que se necesitan realizar para alcanzar el un requisito de un sistema software, se deben
objetivo de la función, en este caso, hallar el revisar los flujos asociados a este caso de uso y
alimento que necesita ingerir. A continuación, describirlos gráficamente con esta herramienta
se describe ese flujo. de modelación de análisis y diseño.
 RESUMEN DEL TEMA
Los diagramas de actividad permiten describir como un sistema implementa su
funcionalidad, mostrando el flujo de actividades asociado a dicha funcionalidad.
Modelan el comportamiento dinámico de un procedimiento, transacción o caso de uso
haciendo énfasis en el proceso que se lleva a cabo.
Se usan para analizar los procesos y, si es necesario, volver a realizar la ingeniería de
los procesos.
Es uno de los elementos de modelado que son mejor comprendidos por todos, ya que
son herederos directos de los diagramas de flujo, pero son más expresivos que los
diagramas de flujo.
Desde un punto de vista conceptual, el diagrama de actividades muestra cómo fluye el
control de unas clases a otras con la finalidad de culminar con un flujo de control total
que se corresponde con la consecución de un proceso más complejo.
• Tienen mucha utilidad para:
• Modelar el comportamiento de determinados procesos del sistema.
• Modelar el comportamiento de procesos complejos que engloben varios
subprocesos.
• Representar el flujo de negocio del sistema.
• Describir los pasos realizados en un caso de uso (permiten describir como un
sistema implementa su funcionalidad)
• Simplificar y mejorar cualquier proceso clarificando casos de uso complicados.
• Modelar elementos de arquitectura de software, tales como método, función y
operación.

LA IDEA PRINCIPAL
El diagrama de actividad permite modelar los flujos de procesos de interés para
el análisis y diseño de sistemas.
UNIDAD 3 - TEMA 4
DIAGRAMAS DE SECUENCIA
¿QUÉ SON LOS DIAGRAMAS DE SECUENCIA? Fin de una “línea de vida”.
Los diagramas de clases representan
información estática. No obstante, en un
sistema funcional, los objetos interactúan Como ejemplo, se muestra el siguiente
entre sí, y tales interacciones suceden con diagrama de secuencia, que representa la
el tiempo. El diagrama de secuencias UML interacción entre un Actor Usuario con un
muestra la mecánica de la interacción con base Cajero para sacar dinero.
en tiempos.
Muestra la interacción entre componentes del
sistema desde el punto de vista temporal.
La interacción se representa desde el punto
de vista de paso de mensajes entre objetos o
actores a lo largo del tiempo.
Son útiles para describir procesos internos entre
diferentes módulos y describir comunicaciones
con otros sistemas o con actores.

ELEMENTOS DE UN DIAGRAMA DE
SECUENCIA
Actor/Objeto.
El rol de la clase describe la manera en que un
objeto se va a comportar en el contexto. No se
listan los atributos del objeto.

Objeto en ejecución (activo).

Actores/Objetos desconocidos.
Veamos otro ejemplo:
Representar mediante un diagrama de
secuencia el proceso de una llamada. Tenemos
3 objetos: emisor, receptor y centralita. El
proceso es el siguiente:
1. El emisor descuelga el teléfono y espera a
que la centralita de tono.
2. El emisor marca el número y espera a que la
centralita de tono de llamada.
3. Al mismo tiempo que la centralita da tono
de llamada, hace sonar el teléfono del
receptor.
4. Una vez el receptor descuelga el teléfono,
en menos de un segundo su teléfono deja
de sonar y el emisor deja de oír el tono de
llamada.
 RESUMEN DEL TEMA
Los diagramas de clases representan información estática. No obstante, en un sistema
funcional, los objetos interactúan entre sí, y tales interacciones suceden con el tiempo.
El diagrama de secuencias UML muestra la mecánica de la interacción con base en
tiempos, entre componentes del sistema.
La interacción se representa desde el punto de vista de paso de mensajes entre objetos
o actores a lo largo del tiempo.
Son útiles para describir procesos internos entre diferentes módulos y describir
comunicaciones con otros sistemas o con actores
En un sistema funcional, los objetos, que son instancias de una clase, interactúan entre
sí, y tales interacciones ocurren en el tiempo.

LA IDEA PRINCIPAL
Los diagramas de secuencia describen en el tiempo, los procesos internos entre
diferentes módulos de un sistema y las comunicaciones con otros sistemas o
con actores.
UNIDAD 3 - TEMA 5
DIAGRAMAS DE COLABORACIÓN
¿QUÉ SON DIAGRAMAS DE COLABORACIÓN? Rol de las Asociaciones.
Los diagramas de interacción modelan la Los roles de asociación describen cómo se va
comunicación entre los diferentes elementos a comportar una asociación en una situación
del sistema, a diferencia de los diagramas de particular. Se usan líneas simples etiquetadas
comportamiento, muestran la comunicación con un estereotipo.
entre distintos componentes, en lugar de entre
elementos de un mismo componente.
Existen 2 tipos de diagramas de interacción,
los cuales pueden transformarse el uno en el Mensajes.
otro de forma directa: Diagramas de Secuencia Cuando dos objetos establecen una
y Diagramas de Colaboración, el primero ya se comunicación, se incluye un en l ace,
trató en el tema anterior, ahora corresponde representado por una línea, entonces los
describir el segundo. mensajes se muestran superpuestos al enlace
Los diagramas de colaboración muestran y el orden de ejecución de los mensajes se
la interacción entre objetos desde el punto muestra junto a su texto descriptivo.
de vista espacial, esto es, sólo se centra en el
paso de mensajes, para ello, utiliza los mismos
elementos que los diagramas de secuencia, a
excepción de las “líneas de vida”.
Los diagramas de colaboración son útiles para:
• Identificar los diferentes objetos del sistema
y su relación con los demás.
• Describir el paso de mensajes entre los Contrariamente a los diagramas de secuencias,
objetos o roles. los diagramas de colaboración no tienen una
El diagrama de colaboración describe las manera explícita para denotar el tiempo, por
interacciones entre los objetos en términos de lo que entonces numeran a los mensajes en
mensajes secuenciados. orden de ejecución.
Los diagramas de colaboración representan La numeración puede anidarse; por ejemplo,
una combinación de información tomada de los para mensajes anidados al mensaje número 1:
diagramas de clases, de secuencias y de casos 1.1, 1.2, 1.3, etc.
de uso, describiendo el comportamiento, tanto La condición para un mensaje se suele
de la estructura estática, como de la estructura colocar entre corchetes. Para indicar un loop
dinámica de un sistema. (repetición) se usa * después de la numeración.

ELEMENTOS DE LOS
DIAGRAMAS DE COLABORACIÓN
Rol de la Clase.
El rol de la clase describe cómo se comporta un
objeto. Los atributos del objeto no se listan.
Un mensaje se puede expresar en lenguaje Ejemplo 3.
natural o en pseudocódigo, incluyendo Representar mediante un diagrama de
condiciones o llamadas a funciones. colaboración el proceso de consulta de datos
a un Servicio Web (WS de su nombre en inglés
Web Service).
Tenemos 2 objetos: servicio Web y base
de datos, así como 1 actor. El proceso es el
siguiente:
EJEMPLOS DE UN DIAGRAMA DE 1. El actor envía al servicio web la petición de
COLABORACIÓN (COMUNICACIÓN) validación.
Ejemplo 1. 2. El servicio consulta en BBDD los datos de
Este ejemplo agrega un velocímetro al conjunto usuario.
de clases que constituyen a un “Avión”. Al • Si los datos no son correctos, devuelve
alcanzar una cierta velocidad el velocímetro vacío al servicio, el cual mandará un
indicará al timón que debe elevarse y al tren de error al usuario.
aterrizaje que debe retraerse. 3. La base de datos devuelve los datos de
usuario y el servicio responde con OK.
4. El usuario manda la petición de obtención
de datos.
5. El servicio web hace la consulta en BBDD y
esta los devuelve.
6. El servicio manda la respuesta al usuario.

Ejemplo 2.
Representar mediante un diagrama de
colaboración el proceso de una llamada. Este
ejemplo se hizo con un diagrama de secuencia
en el tema anterior.
Tenemos 3 objetos: emisor, receptor y
centralita. El proceso es el siguiente:
1. El emisor descuelga el teléfono y espera a
que la centralita de tono.
2. El emisor marca el número y espera a que la
centralita de tono de llamada.
3. Al mismo tiempo que la centralita da tono
de llamada, hace sonar el teléfono del
receptor.
4. Una vez el receptor descuelga el teléfono,
en menos de un segundo su teléfono deja
de sonar y el emisor deja de oír el tono de
llamada.
 RESUMEN DEL TEMA
Como se ha explicado en los dos últimos temas de esta Unidad de Aprendizaje,
existen dos tipos de diagramas de interacción: de secuencia y de colaboración. Ambos
transmiten la misma información, empleando una perspectiva un poco diferente.
Los diagramas de secuencia muestran las clases a lo largo de la parte superior y los
mensajes enviados entre esas clases, modelando un solo flujo a través de los objetos
del sistema y los diagramas de colaboración usan las mismas clases y mensajes, pero
organizados en una disposición espacial.
Un diagrama de secuencia implica un ordenamiento en el tiempo al seguir la secuencia
de mensajes desde arriba a la izquierda hasta abajo a la derecha. Debido a que en el
diagrama de colaboración no se indica en forma visual un ordenamiento en el tiempo,
numeramos los mensajes para indicar el orden en el cual se presentan.
Algunas herramientas convertirán de manera automática los diagramas de interacción
entre secuencia y colaboración, pero no es necesario crear los dos tipos de diagramas
en las etapas de análisis y diseño del sistema. En general, se percibe que un diagrama
de secuencia es más fácil de leer y más común.
Los diagramas de colaboración representan una combinación de información
tomada de los diagramas de clases, de secuencias y de casos de uso, describiendo el
comportamiento, tanto de la estructura estática, como de la estructura dinámica de un
sistema.

LA IDEA PRINCIPAL
El diagrama de colaboración modela la misma información que uno de
secuencia, pero empleando una perspectiva espacial.
 LECTURAS RECOMENDADAS
• VRumbaugh, James. El Lenguaje Unificado De Modelado. 2a. ed., 2006
• Liliana Favre, UML and the Unified Process, 2003 Idea Group Inc (IGI)

ACTIVIDADES Y EJERCICIOS
• Revisar videos tutoriales sobre diagramas UML.
• Realizar un diagrama de casos de uso con una herramienta UML
• Realizar un diagrama de clases con una herramienta UML
• Realizar un diagrama de actividad con una herramienta UML.
 INTRODUCCIÓN CAPACIDADES
La tarea de análisis de los requisitos es un • Comprender fundamentos del análisis de
proceso de descubrimiento y refinamiento, el requisitos.
• Elaborar los diagramas de casos de uso
cliente y el desarrollador tienen un papel activo
para representar los requisitos funcionales
esta fase de requisitos de software. El cliente
del sistema.
intenta plantear un sistema que en muchas
ocasiones es confuso para él, sin embargo,
es necesario que describa los datos, que
ACTITUDES
especifique las funciones y el comportamiento • La capacidad de pensar y trabajar por
del sistema que desea. El objetivo es que el cuenta propia
desarrollador actúe como un negociador, • Solucionadores de problemas
un interrogador, un consultor, o sea, como • Ser guiado por objetivos.
persona que consulta y propone para resolver
las necesidades del cliente. TEMAS
Dentro de la metodología RUP, es sus flujos
de trabajo, las actividades de análisis y
especificación de los requisitos funcionales se
1
TEMA
fundamentos de Captura y
Análisis de Requisitos
basan en los casos de uso del sistema (CUS), en
sus diagramas y realizaciones textuales. Esto se
estará describiendo en la presente Unidad de 2
TEMA
identificar los casos de uso
y actores de un sistema
Aprendizaje.

COMPETENCIA 3
TEMA
Elaborar Casos de Uso de las
funcionalidades del sistema
Comprende fundamentos del análisis de
requisitos y elabora diagramas de casos de
usos para especificar los requisitos funcionales 4 Relaciones entre
casos de uso
del sistema. TEMA

5
TEMA
Validación de
Requisitos
UNIDAD 4 - TEMA 1
fundamentos de Captura y
Análisis de Requisitos
¿QUÉ SON REQUISITOS DE UN SISTEMA?
Comencemos recalcando que un desarrollador TIPOS DE REQUISITOS
de software debe desarrollar soluciones a
La clasificación más usada es la siguiente:
problemas y que una buena solución puede
• Requisitos Funcionales.
solo ser desarrollada si se tiene un buen
Son aquellos que describen las funciones o los
entendimiento del problema, dentro de su
servicios que se espera que el sistema provea.
entorno de negocio.
Describen lo que es sistema debe realizar para
Luego que se tiene un buen conocimiento de lo resolver el problema planteado.
que se quiere resolver, se debe pasar a la fase Los requisitos funcionales de un sistema, son
de captura y análisis de requisitos, fase muy aquellos que describen cualquier actividad
importante dentro del ciclo de vida del software, que este deba realizar, en otras palabras,
porque de ella dependerán las siguientes fases el comportamiento o función particular
de diseño, codificación, pruebas y entrega al de un sistema, cuando se cumplen ciertas
cliente y usuarios. condiciones.
Comencemos por definir qué es un requisito, Por lo general, estos deben incluir funciones
para luego comprender para que nos sirven los desempeñadas por pantallas específicas,
casos de uso para su captura y especificación, descripciones de los flujos de trabajo a
dentro de la metodología de desarrollo RUP. ser desempeñados por el sistema y otros
Un requisito es una valoración clara de las requerimientos de negocio.
necesidades que un sistema debe alcanzar. Es La gestión de los requisitos funcionales
una condición o capacidad que debe cumplir deficiente, es citada como una de las causas
o poseer un sistema para satisfacer una más frecuentes en el fracaso de los proyectos,
especificación acordada con el cliente. es por ello que es importante entender que
Un requisito debe indicar: son los requerimientos funcionales, bajo qué
• Qué necesita el sistema, basado en metodologías deben identificarse y gestionarse
condiciones actuales y previsibles. para asegurar el logro de los objetivos.
• Qué rasgos del sistema servirán para Por lo tanto, los requisitos funcionales:
satisfacer el contexto del requisito. • Expresan las capacidades o cualidades
• Cómo el sistema debe ser construido. que debe tener la solución para
El conjunto de requisitos forma la base para el satisfacer los requerimientos de los
desarrollo de un sistema o un componente de interesados del proyecto.
un sistema. • Se expresan en términos de cuál debe
ser el comportamiento de la solución y
que información debe manejar.
• Deben proporcionar una descripción lo
suficientemente detallada para permitir
el desarrollo e implementación de la
solución.
• Son los que más influyen en si la solución
será aceptada o no por los usuarios.
Algunos ejemplos de requisitos funcionales:
• El sistema enviará un correo electrónico
cuando se registre alguna de las
siguientes transacciones: pedido de
venta de cliente, despacho de mercancía
al cliente, emisión de factura a cliente y
registro de pago de cliente.
• Se permitirá el registro de pedidos
de compra con datos obligatorios
incompletos, los cuales podrán
completarse posteriormente
modificando el pedido. Antes de poder
aprobarse los datos del pedido deben
estar completos.
• Al aprobar un pedido, la solicitud pasará • Requisitos No Funcionales:
al siguiente paso del flujo de trabajo Los requisitos no funcionales representan
(workflow) de aprobación configurado características generales y restricciones de la
en el sistema. aplicación o sistema que se esté desarrollando.
• El sistema permitirá a los usuarios Son los que especifican criterios para evaluar
autorizados el ingresar planes y la operación de un servicio de tecnología
cronogramas de proyecto. de información, en contraste con los
• El sistema permitirá aprobar, cambiar requerimientos funcionales que especifican los
o actualizar planes y cronogramas de comportamientos específicos.
proyecto. Suelen presentar dificultades en su definición
• El sistema permitirá el envío dado que su conformidad o no conformidad
automatizado de cartas de entrega de podría ser sujeto de libre interpretación, por lo
órdenes directamente al almacén. cual es recomendable acompañar su definición
• A cada orden se le asignará un con criterios de aceptación que se puedan
identificador único, que será utilizado medir.
para identificarla en todos los procesos
subsecuentes que se realicen sobre esta. Entre los ejemplos de requisitos no
• Al ingresar ordenes de entrega, toda funcionales, tenemos los referidos a
orden de entrega estará asociada a un atributos como la eficiencia, seguridad,
pedido de venta. mantenibilidad y usabilidad del sistema.
• La facturación de pedidos de venta se También hay requerimientos no funcionales
realizará en lotes, por medio de una organizacionales y externos.
pantalla de pedidos pendientes de Algunos ejemplos de requisitos no funcionales:
facturación, la cual mostrará los pedidos • El sistema debe ser capaz de procesar N
no facturados. Una vez facturados los transacciones por segundo. Esto se medirá
pedidos no se mostrarán en esta lista. por medio de la herramienta SoapUI
aplicada al Software Testing de servicios
web.
• Toda funcionalidad del sistema y transacción
de negocio debe responder al usuario en
menos de 5 segundos.
• El sistema debe ser capaz de operar
adecuadamente con hasta 100.000 usuarios
con sesiones concurrentes.
• Los datos modificados en la base de
datos deben ser actualizados para todos
los usuarios que acceden en menos de 2
segundos.
• Los permisos de acceso al sistema
podrán ser cambiados solamente por el
administrador de acceso a datos.
• El nuevo sistema debe desarrollarse ANÁLISIS DE REQUISITOS Y CASOS DE USO
aplicando patrones y recomendaciones La técnica por excelencia para la captura y
de programación que incrementen la análisis de requisitos funcionales en el análisis
seguridad de datos. y diseño orientado a objeto es la realizada con
• Todos los sistemas deben respaldarse los Casos de Uso.
cada 24 horas. Los respaldos deben ser En la siguiente figura podemos describir esta
almacenados en una localidad segura fase con el modelo de requisitos.
ubicada en un edificio distinto al que reside
el sistema.
• Todas las comunicaciones externas entre
servidores de datos, aplicación y cliente del
sistema deben estar encriptadas utilizando
el algoritmo RSA.
• Si se identifican ataques de seguridad o
brecha del sistema, el mismo no continuará
operando hasta ser desbloqueado por un
administrador de seguridad.
• El tiempo de aprendizaje del sistema por un
usuario deberá ser menor a 4 horas. Y según la metodología de desarrollo RUP,
• La tasa de errores cometidos por el que hemos estudiado en una unidad anterior,
usuario deberá ser menor del 1% de las estos son los artefactos (modelos, diagramas,
transacciones totales ejecutadas en el documentos) que se deben generar en esta
sistema. etapa.
• El sistema debe contar con manuales de
usuario estructurados adecuadamente.
• El sistema debe proporcionar mensajes de
error que sean informativos y orientados a
usuario final.
• El sistema debe contar con un módulo de
ayuda en línea.
• La aplicación web debe poseer un diseño
“Responsive” a fin de garantizar la adecuada
visualización en múltiples computadores Como se observa de estos artefactos, el
personales, dispositivos tableta y teléfonos principal es el llamado Modelo de Casos de Uso
inteligentes. del Sistema, que se detallará en el siguiente
• El sistema debe poseer interfaces gráficas tema.
bien formadas.
 RESUMEN DEL TEMA
Los requisitos juegan un papel importante en el desarrollo de sistemas, ya que:
• Forman la base de la arquitectura del sistema y las actividades de diseño.
• Forman la base para las actividades de verificación.
• Actúan como punto de referencia para la validación y la aceptación del sistema de
las partes interesadas.
• Proporcionan un medio de comunicación entre los diferentes técnicos que
interactúan a lo largo del proyecto, entre ellos y con los clientes y usuarios.
Así pues, un requisito, o mejor dicho, el conjunto de requisitos que conforman
el sistema, nos sirve para que un cliente describa claramente lo que quiere, que el
desarrollador entienda lo que ese cliente requiere, que se eviten vueltas atrás en la
etapa de diseño o de desarrollo (por falta de entendimiento) y que se tenga una base
sobre la que probar y validar el producto final.

LA IDEA PRINCIPAL
Un buena captura y análisis de requisitos es la base sólida
para un buen desarrollo de un sistema software.
UNIDAD 4 - TEMA 2
identificar los casos de uso y
actores de un sistema
Modelado de CUS Guía para generar el Modelo de CUS
Para modelar los requisitos funcionales del Para generar el Modelo de Casos de Uso del
sistema a través de los casos de uso, se deben Sistema, que se obtiene del análisis de los
tener claro los siguientes principìos: mismos, se deben realizar los siguientes pasos
• Un caso de uso especifica un para la captura de requisitos, según RUP:
comportamiento deseado del sistema. • Identificación de Casos de uso y Actores.
• Representan los requisitos funcionales del • Priorizar Casos de Uso.
sistema. • Detallar Casos de Uso.
• “Un caso de uso especifica un conjunto • Estructurar el MCU.
de secuencias de acciones, incluyendo • Prototipar la interfaz de usuario (GUI).
variantes, que el sistema puede ejecutar y
que produce un resultado observable de Identificación de Casos de Uso y Actores
valor para un particular actor. (Definición del Sistema
en UML). Como punto de partida del proceso de
• Describen qué hace el sistema, no cómo lo construcción de software, identificar y definir
hace. los casos de uso ayudará a desarrollar
• Un caso de uso es una descripción desde el eficientemente un proyecto, considerando
punto de vista del usuario. siempre las necesidades de los usuarios del
• Los casos de uso son una herramienta sistema.
valiosa dado que es una técnica de aciertos Los casos de uso se observan como objetivos
y errores para obtener los requisitos del y funcionalidades esperadas de los distintos
sistema, justamente desde el punto de vista actores que estarán interactuando con el
del usuario. software que se crea.
• Los diagramas de casos de uso modelan la Al considerar el RUP (que es un proceso
funcionalidad del sistema usando actores y guiado por casos de uso), se espera, por
casos de usos. lo tanto, que los esfuerzos que se realizan
• Los casos de uso son servicios o funciones estén comprendidos en un marco de trabajo
provistas por el sistema para sus usuarios. que se haya definido de acuerdo a lo que se
ha identificado por parte de los clientes, en
cuanto a los objetivos que deben cumplirse.
Al inicio del proyecto, deberá hacerse un
esfuerzo importante para poder identificar los
casos de uso del sistema.
Para ilustrar los conceptos que se desarrollarán
seguidamente, se estará utilizando el ejemplo
de una biblioteca de una universidad que
da servicio a estudiantes, docentes y demás
funcionarios de ésta.
Seguidamente vamos a recordar cómo se lleva
a cabo el proceso de préstamo de un libro en
esta biblioteca universitaria que se usará de
ejemplo, como punto de partida para ilustrar
los conceptos que vamos a desarrollar.
1. El usuario puede consultar la lista Al buscar los casos de uso de un sistema,
de materiales bibliográficos que hay debemos plantearnos:
disponibles. Esos materiales pueden ser:
• Cuáles son sus objetivos.
libros, revistas, periódicos, videos, etc.
• Bajo qué condiciones pueden lograrse.
2. Producto de la consulta, el usuario puede
• Quiénes intervienen en su ejecución.
averiguar si el material está disponible para
Los objetivos son importantes, porque nos
préstamo, el tipo de restricción que hay
ayudan a identificar claramente qué es lo que
para prestarlo, así como si se le permite
persigue el sistema. En nuestro caso:
llevárselo fuera de la biblioteca o bien si es
• ¿Buscará el sistema manejar la base
un material para ser consultado únicamente
bibliográfica de la biblioteca, con el registro
dentro del recinto de la Biblioteca.
del material, sus autores, editores, la copia
3. En el caso de los libros, si no es material
de cada uno de éstos?
restringido, la persona interesada puede ir
• ¿Tendrá que representarse la complejidad
a los estantes y ubicar el libro, o solicitar la
de la información que representa un libro
ayuda de un bibliotecario.
o cualquier material bibliográfico para
4. En el caso de los libros para sala,
cumplir con los objetivos del
revistas y videos, el usuario
sistema?
deberá ser atendido por
Pareciera que este no es el
un bibliotecario, para que
caso. Nuestro asunto se
ubique el material.
limita a poder manejar lo
5. Para realizar el préstamo,
referente a los préstamos
el bibliotecario lee
de un material (que
los datos del material
corresponde al objetivo del
solicitado con un lector de
sistema que hemos tomado
códigos de barra.
como ejemplo), por lo cual, las
6. Posteriormente asigna el
acciones por desarrollar deben
tiempo de préstamo, dependiendo
limitarse a ello.
de las restricciones del material:
• Si el material puede prestarse fuera de la
biblioteca, el bibliotecario asignará 3, 5,
7 ó 14 días, de acuerdo con la demanda
de uso. A mayor demanda, menos días
se prestaría.
• Si el material es de uso exclusivo dentro
de la biblioteca, se asignarán 4 horas de
préstamo en sala.
7. Además, para poder prestar un material,
debe comprobarse que el usuario no
tenga cargos por morosidad. De ser así,
se le impide el préstamo fuera de sala y
solo podrá consultar el material dentro
de la biblioteca. Un cargo por morosidad
se genera en el proceso de devolución del
material prestado.
8. Cuando el usuario lo devuelve, se corrobora
sí que lo está entregando lo hace dentro
del plazo establecido. De lo contrario, la
biblioteca genera el cargo.
9. El usuario puede cancelar sus deudas
en la biblioteca. Esta última genera,
regularmente, estados financieros
para reflejar los trámites de morosidad
generados y para identificar cuáles no han
sido aún cancelados.
Claro está, este subsistema deberá Es importante indicar que dicho rol puede ser
comunicarse con el sistema bibliográfico de la asumido por distintos elementos físicos. Más
biblioteca, para poder referenciar el material claramente, en el caso de las personas, si por
que se tramite. ejemplo Pedro Pérez Pereira es bibliotecario
Debe reconocerse en la descripción del sistema, en el sistema que especificamos, igualmente
algunas acciones importantes que pueden podría ser usuario en el momento en el que
resaltarse, tales como: éste solicite el préstamo de un material para
√ Consultar disponibilidad de material ser consultado por él mismo en su casa.
bibliográfico por parte del usuario. Como hemos podido observar, los actores
√ Leer datos del material bibliográfico, por persiguen distintos objetivos dentro del
parte del bibliotecario. sistema. Por ejemplo, para un bibliotecario,
√ Consultar morosidad del usuario, por parte su objetivo sería prestar material, registrar
del bibliotecario. las devoluciones, comprobar que los morosos
√ Registrar la acción de préstamo, por parte no podrán tener servicio hasta tanto no
del bibliotecario. cumplan con los requisitos exigidos para tal
√ Registrar la acción de devolución, por parte efecto, etc. Un usuario, por su parte, podrá
del bibliotecario. consultar el catálogo de material y, mediante
√ Generar un registro de morosidad, al la intermediación de un bibliotecario, podrá
procesarse la devolución, por parte del recibir préstamos del servicio de bibliotecas.
bibliotecario. El Sistema Financiero podrá conseguir los
√ Procesar registros de morosidad, por parte registros contables relativos a las cuentas por
del Sistema Financiero. cobrar y los registros de los pagos realizados
Todas estas acciones están enmarcadas por los usuarios morosos.
dentro del objetivo del sistema de brindar y Todos esos objetivos se logran a través de
administrar el servicio de préstamo de material los casos de uso que se desarrollarán en el
bibliográfico en esa universidad. sistema. De ello estaremos hablando en el
Note igualmente que, además de enumerarse siguiente tema.
esas acciones, a la par se está especificando
quién hace la acción. En el fondo, lo que se
está tratando de identificar, son los actores
del sistema, a los que nos referiremos a
continuación.
De acuerdo con Booch et al (2001), los actores
son el entorno del sistema.
Con ello se hace referencia a que es todo “ente”
que interactuará con el sistema. Estos actores
pueden ser personas, otros sistemas, hardware
etc. Un actor asume un rol en el entorno del
sistema.
 RESUMEN DEL TEMA
Como punto de partida del proceso de construcción de software, identificar y definir los
casos de uso ayudará a desarrollar eficientemente un proyecto, considerando siempre
las necesidades de los usuarios del sistema.
Los casos de uso se observan como objetivos y funcionalidades esperadas de los
distintos actores que estarán interactuando con el software que se crea.
El objetivo o propósito del sistema es importante tenerlo bien identificado, porque nos
ayudará a identificar claramente qué es lo que persigue el sistema.
Este objetivo genera acciones que están enmarcadas dentro del objetivo, las cuales se
logran a través de los casos de uso que se desarrollarán en el sistema.
Igualmente, además de identificarse esas acciones, a la par se está especificando quién
hace la acción. En el fondo, lo que se está tratando de identificar, son los actores del
sistema.

LA IDEA PRINCIPAL
La identificación de casos de uso y actores es la base de la
especificación de los requisitos.
UNIDAD 4 - TEMA 3
Elaborar Casos de Uso de las
funcionalidades del sistema
Se ha hablado previamente de los casos de
uso. Se ha dicho que se trata de algo así como
“historias” de lo que ocurre en el sistema. El
sentido de afirmar que son historias, se debe
a que éstos tienen la especificación de lo que
el usuario desea del sistema. Por lo tanto, es
importante que quedemos con este concepto:
un caso de uso es la descripción de lo que el
usuario desea del sistema.
El proceso de identificar casos de uso, puede
apoyarse visualizándolos “espacialmente”. En
UML, lo anterior se logra mediante el desarrollo
de un diagrama de casos de uso. Ello puede ser
un ejercicio en el cual, conforme se comienzan
a identificar los actores, los objetivos y las Observe que los casos de uso se representan
funcionalidades del sistema, se procede a a través de un óvalo y los actores mediante la
plasmarlos gráficamente. figura de una persona.
Un diagrama consiste en colocar en él La interacción entre el actor y un caso de uso en
los actores y los casos con los que éstos particular se expresa por medio de una línea.
interactúan. Como puede notar, esto es muy sencillo. Sin
En la siguiente figura se muestra un ejemplo embargo, esa sencillez es una forma muy
de un diagrama de éste tipo. Este ejemplo poderosa de poder corroborar entre el cliente
no pertenece a ningún ámbito de ningún y un analista lo que se requiere, en cuanto a
problema. En éste simplemente ilustramos la funcionalidades de un sistema, dado que la
notación utilizada. comunicación, usando un diagrama así, puede
realizarse de una forma muy simple.
En el caso de nuestro ejemplo de préstamos
de una biblioteca, vamos a procurar tener
claros los objetivos, las funcionalidades y
los actores que están involucrados en su
desarrollo, precisamente mediante la actividad
de especificar los casos de uso.
Algo importante que debe considerarse antes
de entrar en mayores detalles, es que la esencia
de los casos de uso se basa en escribirlos, es
decir, en especificarlos.
El diagrama es una ayuda visual muy
importante para entender, o poder plasmar
el entorno del sistema y las funcionalidades
esperadas. No obstante, al escribir, podemos
medir si realmente estamos entendiendo los
objetivos del sistema.
 Hay varias cosas que debemos analizar de la
figura anterior.
• En primera instancia, note cómo todas las
funcionalidades que listamos previamente
aparecen como casos de uso del sistema.
• También observe cómo aparecen cuatro
actores, los cuales fueron identificados,
también previamente, relacionados con la
funcionalidad:
ο El Bibliotecario.
ο El Usuario.
ο El Sistema Bibliotecario.
ο El Sistema Financiero. Estos dos últimos
se refieren a actores que no son
personas.
• Ahora los actores interactúan con el sistema
Todos, en general, podemos escribir acerca de a través de los casos de uso. En este caso:
algo con propiedad, si logramos comprender ο El Bibliotecario interactúa con los casos
sobre lo que estamos escribiendo. Sobre la de uso de Registrar Préstamo y Registrar
especificación de los casos de uso estaremos Devolución.
hablando en la próxima Unidad de Aprendizaje. ο El Usuario lo hará a través de Consultar
Regresando nuestro ejemplo del sistema de Material Bibliográfico.
administración de préstamos de la biblioteca, ο El Sistema Financiero lo hará mediante
considerando los objetivos y funcionalidades el caso de Procesar Registros de
detalladas, nos sería fácil esbozar el siguiente Morosidad.
diagrama de casos de uso. ο El Sistema Bibliotecario apoyará los
procesos de Consulta de Material
Bibliográfico y Leer Datos Material.
Como resumen, podemos decir que los casos de
usos se visualizan en diagramas que contienen
comúnmente los siguientes elementos:
• Casos de Uso (CU)
• Actores
• Relaciones: entre Actores y Casos de Uso y
entre Casos de Uso.
 RESUMEN DEL TEMA
Se dice que los casos de uso son algo así como “historias” de lo que ocurre en el sistema.
El sentido de afirmar que son historias, se debe a que éstos tienen la especificación de
lo que el usuario desea del sistema. Por lo tanto, es importante que quedemos con este
concepto: un caso de uso es la descripción de lo que el usuario desea del sistema.
El proceso de identificar casos de uso, puede apoyarse visualizándolos “espacialmente”.
En UML, lo anterior se logra mediante el desarrollo de un diagrama de casos de uso.
Ello puede ser un ejercicio en el cual, conforme se comienzan a identificar los actores,
los objetivos y las funcionalidades del sistema, se procede a plasmarlos gráficamente.
Un diagrama consiste en colocar en él los actores y los casos con los que éstos
interactúan
Por lo que, la forma como se visualizan o modelan los CUS, a través de los diagramas de
CUS, es una ayuda visual muy importante para entender, o poder plasmar el entorno
del sistema y las funcionalidades esperadas.

LA IDEA PRINCIPAL
En el modelado de los Casos de Usos del Sistema se visualizan los
CU, los actores y las relaciones.
UNIDAD 4 - TEMA 4
Relaciones entre
casos de uso
En el diagrama de CUS del ejemplo del tema Inclusión (“Include”)
anterior, sobre sistema de administración de Un caso de uso base incorpora explícitamente
préstamos de la biblioteca, se puede notar que el comportamiento de otro en algún lugar de su
algunos casos de uso se relacionan entre sí. secuencia.
Un primer tipo de relación se establece en el La relación de inclusión sirve para enriquecer
sentido de que, para poder realizar el objetivo un caso de uso con otro y compartir una
planteado para un caso de uso, necesita usarse funcionalidad común entre varios casos de uso,
otro objetivo. Este tipo de relación se denomina también puede utilizarse para estructurar un
“uses” (también conocida como “include”). caso de uso describiendo sus subfunciones. El
Véase en el diagrama varios ejemplos de ello. caso de uso incluido existe únicamente con ese
Uno de ellos puede ser el caso de que, para propósito, ya que no responde a un objetivo de
poder registrar un préstamo, necesita leerse un actor.
de cuál material bibliográfico se trata. Permite factorizar un comportamiento en un
Adicionalmente, puede existir otro tipo caso de uso aparte y evitar repetir un mismo
de relación en el cual, un caso de uso es la flujo en diferentes casos de uso.
especialización de otro. Por ejemplo, Registrar Esta relación se representan mediante
Devolución con Morosidad es, en esencia, lo una flecha discontinua con el estereotipo
mismo que Registrar Devolución, pero incluye <<include>>.
la capacidad de poder registrar un cargo de Algunos casos de uso típicos de inclusión
morosidad por una devolución tardía. Esta son: comprobar, verificar, buscar, validar,
relación se denomina “extends”. autentificar o login. En principio, no deberíamos
Realizar un diagrama de casos de uso nos abusar de este tipo de relación, para no hacer
ayuda a visualizar, tal y como se mencionó una descomposición funcional del sistema.
anteriormente, de qué forma los usuarios A partir de UML 1.3 la relación <<include>>
(actores) interactuarán con el sistema. reemplazó al denominado <<uses>>.
Veamos un ejemplo de inclusión entre casos de
uso.
Tipos de relaciones
Comunicación
Relación (asociación) entre un actor y un
caso de uso. El estereotipo de la relación de
comunicación es: <<communicate>> aunque
generalmente no se estipula ningún nombre,
como podemos apreciar en el siguiente ejemplo
de comunicación.
Extensión (“Extend”) Especialización y Generalización
Un caso de uso base incorpora implícitamente Un caso de uso (subcaso) hereda el
el comportamiento de otro caso de uso en el comportamiento y significado de otro, es decir
lugar especificado indirectamente por este otro las relaciones de comunicación, inclusión y
caso de uso. extensión del super-caso de uso.
Es una relación que amplía la funcionalidad de En muchas ocasiones este super-caso de uso es
un Caso de Uso mediante la extensión de sus abstracto y corresponde a un comportamiento
secuencias de acciones. parcial completado en el subcaso de uso, o
En el caso de uso base, la extensión se hace dicho de otra manera, los casos de uso “hijo”
en una serie de puntos concretos y previstos son una especialización del caso de uso “padre”.
en el momento del diseño, llamados puntos Veamos un ejemplo de generalización
de extensión, los cuáles no son parte del flujo
principal.
La relación de extensión sirve para modelar:
la parte opcional del sistema, un subflujo que
sólo se ejecuta bajo ciertas condiciones o varios
flujos que se pueden insertar en un punto
determinado.
Este tipo de relación produce confusión y no
debería utilizarse en exceso. Conviene su uso
sólo para insertar un nuevo comportamiento
no previsto en un caso de uso existente.
Estas relaciones se representan mediante
una flecha discontinua con el estereotipo
<<extend>>. Como podemos ver en este último ejemplo
Veamos un ejemplo de extensión: también pueden existir vínculos de
generalización o herencia entre actores.
Los actores especializados (Abogado y
Psicólogo) heredan los casos de uso del actor
general (Profesional). La punta de flecha
apunta al actor más general. Hay que reseñar
que los actores especializados pueden tener
otros casos de uso propios que no estarán
disponibles para los demás actores. Este
tipo de herencia entre actores si que se usa
frecuentemente puesto que nos simplifica
considerablemente el diagrama, nos ahorra
un número importante de relaciones de
En este ejemplo usamos la relación de comunicación entre actores y casos de uso
extensión entre los casos de uso Abrir acción y nos sirve para esclarecer visualmente la
de mejora y Resolver consulta. En este caso jerarquía entre actores del sistema.
tendremos el punto de extensión “resolución
retrasada” (en el caso de uso Resolver consulta) Las cuatro relaciones descritas anteriormente
debido a que cuando haya pasado un tiempo se pueden resumir en la siguiente tabla.
estipulado por la organización (por ejemplo 3
días laborales) se abrirá una acción de mejora
para dejar constancia del retraso y realizar
posteriormente las acciones pertinentes, de ahí
que digamos que el caso de uso Abrir acción de
mejora es una subfunción de uso que puede
extender al caso de uso Resolver consulta.
 RESUMEN DEL TEMA
En el diagrama de CUS del ejemplo del tema anterior, sobre sistema de administración
de préstamos de la biblioteca, se puede notar que algunos casos de uso se relacionan
entre sí. Un primer tipo de relación se establece en el sentido de que, para poder
realizar el objetivo planteado para un caso de uso, necesita usarse otro objetivo. Este
tipo de relación se denomina “uses” (actualmente “include”). Uno ejemplo de ella, puede
ser el caso de que, para poder registrar un préstamo, necesita leerse de cuál material
bibliográfico se trata. Adicionalmente, puede existir otro tipo de relación en el cual,
un caso de uso es la especialización de otro. Por ejemplo, Registrar Devolución con
Morosidad es, en esencia, lo mismo que Registrar Devolución, pero incluye la capacidad
de poder registrar un cargo de morosidad por una devolución tardía. Esta relación se
denomina “extends”. Realizar un diagrama de casos de uso nos ayuda a visualizar, tal
y como se mencionó anteriormente, de qué forma los usuarios (actores) interactuarán
con el sistema. Por ello, muy importante saber distinguir que tipo de relación es la que
existe entre los CUS y entre los Actores y CUS, identificándolas de las acciones descritas
como necesarias para cumplir con las funcionalidades del sistema.

LA IDEA PRINCIPAL
Identificar y especificar bien los tipos de relaciones existentes entre actores y CUS
y entre los CUS.
UNIDAD 4 - TEMA 5
VALIDACIÓN DE REQUISITOS
¿Qué es validación de requisitos? Consistencia.
Ante todo es una actividad de Aseguramiento No debe haber restricciones o contradicciones
de Calidad de Software (SQA, siglas en inglés), entre unos requisitos y otros.
en particular de Control de Calidad. Completitud.
El objetivo principal de esta actividad es Deben estar todos los requisitos, debe incluir
comprobar que el sistema software descrito requisitos que definan todas las funciones y
por la especificación de requisitos del restricciones propuestas por el usuario del
sistema, a través del modelo de requisitos, sistema. Esto es imposible en un desarrollo
se corresponde con las necesidades de iterativo, pero, al menos, deben estar
negocio de clientes y usuarios, obteniendo su disponibles todos los requisitos de la iteración
aprobación y permitiendo generar una línea en curso.
base de los requisitos, para poder llevar a cabo Realismo.
la trazabilidad de los mismos. Se pueden implementar con la tecnología
En pocas palabras, la validación de requisitos actual, con el presupuesto y tiempo disponible.
es el proceso por el cual se determina si la Con esto validar el estudio de factibilidad inicial.
especificación de los mismos es consistente Verificabilidad.
con las necesidades del cliente. Tiene que existir alguna forma de comprobar
La validación de requisitos sirve para demostrar que cada requisito se cumple.
que éstos realmente definen el sistema que el La validación debe asegurar que cada
cliente desea. Asegura que los requisitos están especificación puede ser rastreada hasta su
completos, son correctos y consistentes. Debe requerimiento en el documento de definición y
garantizar que lo descrito es lo que el cliente viceversa, es decir, se chequea en la definición
pretende ver en el producto final. para ver si cada requerimiento es rastreable
Esta validación es importante porque la hasta la especificación.
detección de errores durante el proceso de
análisis de requisitos reduce mucho los costos
del producto software.
Si se detecta un cambio en los requisitos una
vez que el sistema está hecho, los costos son
muy altos, ya que significa volver a cambiar
el diseño, modificar la implementación del
sistema y probarlo nuevamente.

Parámetros a validar en los requisitos:

Validez.
No basta con preguntar a un usuario, todos
los potenciales usuarios pueden tener puntos
de vista distintos y necesitar otros requisitos.
En el análisis se pueden identificar requisitos
adicionales o diferentes a los solicitados
inicialmente. El compromiso es validar con el
cliente/usuarios que es lo que quieren.
 El recorrido de los CU para validar requisitos.
Existen varias técnicas de validación de
requisitos, entre ellas unas muy usadas, tales
como:
• Revisiones Técnicas
• Recorrido de CU
• Prototipado de Interfaces de Usuario.
En la siguiente figura se observan los
participantes y los artefactos utilizados para la
validación de requisitos.

Hablaremos un poco sobre la técnica de Durante las sesiones de recorrido, el autor

Recorrido (walkthrough) de los CU. del producto recorre el producto a revisar en
El recorrido o walkthrough es una técnica detalle, permitiendo que los participantes
de revisión de productos tradicionalmente pongan de manifiesto sus opiniones sobre el
asociada a la inspección de código fuente, para mismo
encontrar conflictos en el código que se revisa, Aplicado a la validación de requisitos, permite
de forma que puedan plantearse alternativas a clientes y usuarios comprender el significado
de solución y los participantes aumenten su de cada requisito y manifestar su acuerdo o
conocimiento del código. desacuerdo con los mismos.
Además, aplicando esta técnica a los casos
de uso, se puede validar de manera natural
la secuencia de pasos de un caso de uso
al recorrerlos todos los participantes, y así
asegurar que todos están de acuerdo con las
especificaciones de las funcionalidades del
sistema, para proceder a ir a la siguiente fase:
el diseño.
 RESUMEN DEL TEMA
La validación de requisitos es una actividad de Aseguramiento de Calidad de Software
(SQA, siglas en inglés), en particular de Control de Calidad.
La validación de requisitos es el proceso por el cual se determina si la especificación de
los mismos es consistente con las necesidades del cliente.
Como parámetros a validar en los requisitos se tienen: validez, consistencia,
completitud, realismo y verificabilidad.
Una de las técnicas más usadas para validar los requisitos especificados se tiene la
técnica del recorrido de los casos de usos, donde se puede validar la secuencia de
pasos de un caso de uso al recorrerlos todos los participantes, y así asegurar que todos
están de acuerdo con las especificaciones de las funcionalidades del sistema, para ir a
la siguiente fase de diseño.

LA IDEA PRINCIPAL
La detección de errores durante el proceso de análisis de requisitos reduce
mucho los costos del software.
 LECTURAS RECOMENDADAS
• Kendall, Kenneth E. y Kendall, Julie E. Análisis y Diseño de Sistemas. Pearson
Educación, México, 2011.
• https://www.academia.edu/37350338/Manual_de_Usuario_Rational_Rose

ACTIVIDADES Y EJERCICIOS
• Comprender y listar la captura de requisitos funcionales y no funcionales de un
sistema de ventas de una pollería.
• Elaborar el diagrama de los CUS de los requisitos funcionales del caso de
estudio anterior.
 INTRODUCCIÓN ACTITUDES
Una vez se han diagramado los casos de • Tener la capacidad de administrar bien el
uso del sistema es necesario establecer una tiempo
especificación detallada de lo que hace cada • Puede adaptarse a ambientes de estudio
uno de éstos. Esa especificación consiste nuevos.
en indicar, los aspectos relevantes de los • Toma decisiones con respecto a opciones
casos de uso, sus flujos de trabajo básico curriculares.
y alternativo, sus pre y post condiciones.
Logrado este avance en la especificación, se TEMAS
consigue tener una mejor comprensión de lo
que debe realizar el sistema. Además, pueden
visualizarse cuáles son los casos de usos
críticos para el desarrollo, por su rol dentro del
1
TEMA
Especificación básica de
los casos de uso
sistema o por las complejidades que acarrea,
y, por lo tanto, cuáles son de mayor riesgo.
También es importante usar un diagrama de
comportamiento como el diagrama de actividad
2
TEMA
Especificación detallada
de los casos de uso
para modelar los casos de usos del sistema.
COMPETENCIA
Realiza la especificación textual y el diagrama
3
TEMA
Diagrama de actividad
de actividad de los casos de uso para completar
el modelo de casos de uso del sistema.

CAPACIDADES 4
TEMA
Elementos del diagrama
de actividad
• Realizar la especificación detallada de los
casos de usos
• Realizar un diagrama de actividades de
acuerdo a los flujos de la especificación de
5
TEMA
Diagramas de actividad de
los casos de uso
los CU.
UNIDAD 5 - TEMA 1
Especificación básica de los
casos de uso
En el proceso de definición de los casos de uso,
debe establecerse una especificación de lo que
hace cada uno de éstos.
Siguiendo con el ejemplo de la administración
de préstamos de la biblioteca, se desarrollará
una especificación básica de los casos de uso
involucrados en este sistema. Recordemos que
una especificación básica consiste en indicar,
en pocas palabras, aspectos relevantes de los
casos de uso.
Veámoslo en el siguiente ejemplo.

Logrado este avance en la especificación,

consigue tenerse una mejor comprensión de lo
que debe realizar el sistema.
Además, pueden visualizarse cuáles son los
casos de uso críticos para el desarrollo, por su
rol dentro del sistema o por las complejidades
que acarrea, y, por lo tanto, cuáles son de
mayor riesgo.
Los de mayor riesgo son los que deberán ser
tratados con especial cuidado.
Siguiendo este razonamiento, habría que
enfocarse en dos aspectos críticos relacionados
con el ejemplo que estamos desarrollando: el
préstamo y la devolución de libros.
Estos casos de uso, además, relacionan muchos
otros que también son importantes de detallar.
Para los que no se especifiquen, usted ya tendrá
suficiente guía de cómo podría profundizar más
en ellos. En este caso también consideramos
que, al detallar las funcionalidades de préstamo
y la devolución, prácticamente se estaría
definiendo toda la arquitectura necesaria para
sostener el sistema, esto es, también, todos los
casos de uso.
 RESUMEN DEL TEMA
En la definición de los casos de uso, debe establecerse una especificación de lo que
hace cada uno de éstos.
Esa especificación básica consiste en indicar, en pocas palabras, los aspectos relevantes
de los casos de uso.
Logrado este avance en la especificación, se consigue tener una mejor comprensión de
lo que debe realizar el sistema.
Además, pueden visualizarse cuáles son los casos de usos críticos para el desarrollo,
por su rol dentro del sistema o por las complejidades que acarrea, y, por lo tanto,
cuáles son de mayor riesgo.

LA IDEA PRINCIPAL
Con la especificación básica de los CUS, pueden visualizarse
cuáles de ellos son los críticos para el desarrollo del sistema.
UNIDAD 5 - TEMA 2
Especificación detallada de los
casos de uso
La especificación básica anterior debería cerrar Elementos de una especificación detallada
un punto del proyecto en la cual ya podemos Booch y otros (2001), sugieren estructurar
tener resultados en cuanto a: la especificación de los casos de uso con los
• Identificar actores del sistema. siguientes elementos y detalles:
• Los objetivos. • Las condiciones previas que deben
• Las funcionalidades y comprender cada una cumplirse para que el caso de uso pueda
de ellas. ejecutarse.
No obstante, en mucho, la comprensión de un • Una secuencia o flujo básico, normalmente
trabajo de software debe ir convergiendo de lo ordenada y numerada de los pasos que se
general a lo específico. En ese sentido también dan dentro del caso de uso. El primer paso
podemos ir descubriendo detalles cada vez debería indicar cómo y cuándo empieza el
más importantes y reveladores del problema caso de uso. En cada paso deberá indicarse,
por solucionar. cuando sea conveniente, qué acciones
Es así como, en un segundo momento de no son permitidas y qué aspectos son
especificación de casos de uso, debemos responsabilidad del actor y cuáles son del
detallar, aún más, su especificación para: sistema. Veamos cómo terminan los casos
• Descubrir mayor información en cuanto de uso.
a las necesidades y consecuencias en el • Las acciones o flujos alternativos que
sistema de la ejecución de éstos. puedan ocurrir en la ejecución de los casos
• Intentar que proporcionen una guía de uso, producto de situaciones anómalas
para poder definir varios aspectos de la (excepciones) u otras consideraciones.
arquitectura y del proceso general de diseño • El estado en que queda el sistema y
e implementación del software. las acciones generadas en éste, como
Esta especificación es crucial en el contexto que consecuencia de la ejecución del caso de
estamos trabajando. Recordemos que el RUP uso (visto como condiciones posteriores).
es guiado por los casos de uso. Veamos a continuación como se describen estos
elementos en una plantilla de especificación
detallada de los casos de uso.
Para el caso de uso Registrar préstamo, del ejemplo que venimos trabajando, la especificación en
detalle quedaría en la plantilla como se muestra a continuación.
 RESUMEN DEL TEMA
La comprensión de un trabajo de software debe ir convergiendo de lo general a lo
específico. En ese sentido también podemos ir descubriendo detalles cada vez más
importantes y reveladores del problema por solucionar.
Es así como, en un segundo momento de especificación de casos de uso, debemos
detallar, aún más, su especificación para descubrir mayor información en cuanto a las
necesidades y consecuencias en el sistema de la ejecución de esto y para proporcionar
una guía para poder definir varios aspectos de la arquitectura y del proceso general de
diseño e implementación del software.
La información de la especificación detallada de los casos de uso va, ciertamente,
logrando el mayor detalle de la descripción del caso de uso, haciendo resaltar controles,
responsabilidades del sistema y de los actores, así como condiciones que deben darse
previa y posteriormente al caso de uso.
Pero otro elemento poderoso de esta especificación detallada es que está escrita en
lenguaje natural, por lo que puede ser validado junto con el cliente del sistema.

LA IDEA PRINCIPAL
La especificación detallada de los CUS está escrita en lenguaje natural, por lo que
puede ser validada junto con el cliente.
UNIDAD 5 - TEMA 3
Diagrama de actividad
Los diagramas de actividad son usados para Desde un punto de vista conceptual, el
representar el comportamiento del sistema diagrama de actividad muestra cómo fluye el
o del negocio, mostrando sus actividades y control de unas clases a otras con la finalidad
procesos. de culminar con un flujo de control total que se
Estos diagramas modelan principalmente: corresponde con la consecución de un proceso
» Condiciones y flujos alternativos. más complejo.
» Tareas y procesos concurrentes En la siguiente figura se muestra un diagrama
» Responsabilidades sobre ciertas actividades de actividad típico, cuyos elementos serán
Se utilizan en análisis de negocio para capturar descritos en detalle en el siguiente tema.
procesos de alto nivel y para el análisis de
requisitos.
Son útiles para:
• Ilustrar un proceso de negocios o flujo de
trabajo entre los usuarios y el sistema.
• Demostrar la lógica de un algoritmo.
• Describir los pasos realizados en un caso de
uso (permiten describir como un sistema
implementa su funcionalidad).
• Simplificar y mejorar cualquier proceso
clarificando los casos de uso complicados.
• Modelar elementos de arquitectura de
software, tales como método, función y
operación.
Gráficamente un diagrama de actividad es un
conjunto de arcos y nodos que muestra el flujo
de actividad.

El Diagrama de Actividad es un diagrama de

flujo del proceso multi-propósito que se usa
para modelar el comportamiento del sistema.
Los diagramas de actividad se pueden usar
para modelar un Caso de Uso, o una clase, o un
método complicado.
Un diagrama de actividad es parecido a un
diagrama de flujo; la diferencia clave es que
los diagramas de actividad pueden mostrar
procesamiento paralelo. Esto es importante
cuando se usan diagramas de actividad
para modelar procesos ‘bussiness’ algunos
de los cuales pueden actuar en paralelo, y
para modelar varios hilos en los programas
concurrentes.
Usando Diagramas de Actividad para modelar Cuando se modela el comportamiento de una
Casos de Uso. clase, un diagrama de estado de UML se suele
Los Diagramas de Actividad ofrecen una usar normalmente para modelar situaciones
herramienta gráfica para modelar el proceso donde ocurren eventos asincrónicos. El
de un Caso de Uso. Se pueden usar como un diagrama de actividad se usa cuando todos o
añadido a una descripción textual del caso de la mayoría de los elementos, representan el
uso, o para listar los pasos del caso de uso. Una desarrollo de los pasos dados por las acciones
descripción textual, código, u otros diagramas generadas internamente. Se deben asignar
de actividad pueden detallar más la actividad. actividades a las clases antes de terminar con
Usando Diagramas de Actividad para modelar el diagrama de actividad.
Clases. Otro ejemplo de diagrama de actividad se
muestra a continuación: Compra de ticket de
avión.
 RESUMEN DEL TEMA
Los diagramas de actividad son usados para representar el comportamiento del
sistema o del negocio, mostrando sus actividades y procesos.
Estos diagramas modelan principalmente: condiciones y flujos alternativos. tareas y
procesos concurrentes y responsabilidades sobre ciertas actividades.
Se utilizan en análisis de negocio para capturar procesos de alto nivel y para el análisis
de requisitos.
Son útiles para: ilustrar un proceso de negocios o flujo de trabajo entre los usuarios y el
sistema, demostrar la lógica de un algoritmo, describir los pasos realizados en un caso
de uso (permiten describir como un sistema implementa su funcionalidad), simplificar
y mejorar cualquier proceso clarificando los casos de uso complicados., modelar
elementos de arquitectura de software, tales como método, función y operación.
Se pueden usar como un añadido a una descripción textual (especificación) del caso
de uso, o para listar los pasos del caso de uso. Una descripción textual, código, u otros
diagramas de actividad pueden detallar más la actividad.

LA IDEA PRINCIPAL
Los Diagramas de Actividad son una herramienta gráfica para modelar
el proceso de un Caso de Uso.
UNIDAD 5 - TEMA 4
Elementos del diagrama de
actividad
Componentes de un diagrama de actividad
Actividad. Nodo Inicial.
Es la especificación de una secuencia de Un nodo inicial o de comienzo se describe por
comportamiento. un gran punto negro.
Muestra un rectángulo con las puntas
redondeadas adjuntando todas las acciones,
flujos de control y otros elementos que
constituyen la actividad.

Nodo Final de actividad.

Se describe como un círculo con un punto
Acciones. dentro del mismo. Denota el final de todos los
Representa un solo paso dentro de una flujos finales dentro de la actividad.
actividad. Las acciones se denotan por
rectángulos con las puntas redondeadas.
Las acciones incluyen llamadas a otras
operaciones, envío de señales, creación o
destrucción de objetos o simples cálculos.
Ej. Enjabonar, enjuagar y secar un coche son
acciones de la actividad “Lavar un coche”.

Flujo de Control
Muestra el flujo de control de una acción a
otra. Su notación es una línea con una punta
de flecha.|
Nodo Final de flujo. Nodos de Bifurcación y Unión (Nodos de
Se describe como un círculo con una cruz sincronización).
dentro del mismo. Denota el final de un solo Tienen la misma notación: una barra
flujo de control. horizontal o vertical, si el flujo de control va de
arriba hacia abajo o de izquierda a derecha,
respectivamente.
Estos indican el comienzo y final de hilos
actuales de control.
Una unión sincroniza dos flujos de entrada y
produce un solo flujo de salida, el cual no se
puede ejecutar hasta que todos los flujos se
hayan recibido.

Nodos de Decisión y Combinación

Ambos tienen la misma notación: forma de
diamante.
Los flujos de control que provienen de un
nodo de decisión tendrán condiciones que
permitirán el control para fluir si la condición Envío y recepción de señales.
se cumple o no Las señales representan interacciones del
En una combinación pasa cualquier flujo de proceso con operadores, sistemas u otros
control directamente a través de esta. Si dos procesos externos.
o más flujos de entrada se reciben en una Cuando un receptor de señales tiene flujo de
combinación, la acción a la que el flujo de salida entrada significa que cuando el flujo le llega, se
apunta se ejecuta dos o más veces habilita para aceptar una única señal.
Cuando no tiene flujo de entrada, significa que
puede aceptar uno o muchas señales.
 RESUMEN DEL TEMA
UML es muy útil para visualizar y documentar sistemas de software, pero la terminología
puede resultar abrumadora para una persona que no esté familiarizada con UM,
por ello hemos descrito a nivel básico, y también en detalle, varios de los diagramas
UML que nos permiten realizar análisis y diseño orientado a objetos. El diagrama de
actividad no escapa al uso de su propia terminología y elementos, por ello detallamos
su descripción, uno a uno, en este tema, para lograr su mayor comprensión, de tal
manera que sea fácil su uso en la realización de los diagramas.
Para hacer un diagrama de actividad hay un grupo bien definido de elementos, que
deben saber usarse para poder lograr modelar en este diagrama de comportamiento
las diversas acciones que se realizan en los diversos escenarios de los casos de uso del
sistema.
Un diagrama de actividades puede incluir alguno de los siguientes elementos:
Acción, que representa la realización de un solo paso de un flujo de trabajo.
Transiciones, que representan el paso de una actividad a otra.
Decisiones, también conocidas como guardas. Estas condiciones de guarda controlan
hacia dónde va el flujo una vez que una actividad concluye, es decir, para que una
transición que tiene una guarda se pueda ejecutar, se debe evaluar a verdadero.
Barras de sincronización, permiten modelar actividades concurrentes o en paralelo.
Un diagrama de actividades puede ser dividido en carriles (swinlanes) utilizando líneas
verticales. Cada carril representa a un responsable de ejecutar las actividades que
contiene.

LA IDEA PRINCIPAL
Para poder realizar un diagrama de actividad es necesario conocer la
utilidad de cada uno de sus elementos.
UNIDAD 5 - TEMA 5
Diagramas de actividad de los
casos de uso
Tomemos, de nuevo, el ejemplo que Advierta también que se está estableciendo, en
corresponde al caso de uso de Registrar las excepciones del caso de uso, una específica
préstamo. Recordemos su descripción para el paso 1, la cual establece que: En el
detallada en el tema 3. paso 1, de comprobarse que el Usuario no
Note que en la descripción se establece una está registrado en la Biblioteca, el caso de uso
secuencia de cinco (5) pasos, en los cuales termina.
pueden inferirse actividades. Dado el conocimiento que tenemos ya del
Por ejemplo, en el paso 1 se indica que: “El Sistema, no solamente es el hecho que esté
caso de uso comienza cuando el Bibliotecario o no registrado en el Sistema, sino también
ingresa al Sistema la identificación del Usuario. que pueda estar moroso o no estarlo. Todo
El Sistema le indica si el Usuario es válido”. ello debe averiguarse en la siguiente actividad
Ahí podemos encontrar varios elementos que del proceso e, igualmente, debe hacerse una
nos pueden servir para nuestro diagrama comprobación que podría dar por terminado
de actividad. Por una parte, se establece la ejecución del caso de uso.
claramente un inicio y cuál actividad se ejecuta En otro caso se seguiría con la siguiente
primero (el caso de uso comienza cuando actividad descrita en el paso 3: obtener el
el Bibliotecario ingresa la identificación del código del material en préstamo usando el
Usuario). Por lo tanto, en un primer momento, lector código de barras.
podemos tener una construcción como la que Vamos a visualizar cómo iría resultando, hasta
sigue: este punto, nuestro diagrama de actividad.

Posteriormente, con respecto al paso 3 y

relacionado con la lectura del código de barras
del material bibliográfico, puede surgir una
excepción: que este no pueda leerse mediante
este dispositivo. Por lo tanto, también debe
darse una verificación si pudo leerse o no fue
posible leer el código de barras del material. Si
la respuesta es afirmativa, se prosigue, de lo
contrario, el bibliotecario tendrá que ingresar
dicho código mediante el teclado.
El diagrama se vería de esta forma. Sabemos que por cada préstamo puede haber
muchos materiales que pueden prestarse. Por
lo tanto, lo que se expresa en esa excepción ya
no es válido y debería modificarse. Pareciera
que en el momento en que se escribió ese
caso de uso, se pensaba que solo podía haber
un material prestado por préstamo. Por
consiguiente, tanto el paso, como la excepción,
deberían modificarse como sigue:
“Una vez comprobados los pasos anteriores,
el Bibliotecario lee del Sistema Bibliotecario la
información del material que va a prestarse,
a través de un lector de código de barras En
ningún caso puede prestarse otra copia del
mismo material al mismo usuario, lo cual se
comprueba, por parte del Sistema, cuando se
hace esta lectura el proceso se repite por cada
uno de los materiales que el Usuario solicita”.
Se destaca que el proceso es repetitivo, por lo
En el diagrama de la figura anterior vemos puede asociarse a un préstamo varias copias
cómo, una vez que se comprueba que ha de materiales. Por otra parte, en cuanto a la
podido leerse (o que no ha podido leerse) el excepción se tendría lo siguiente:
código del material con el lector de código de En el paso 3, de comprobarse que el usuario
barras, se pasa a la actividad de comprobar el ya tiene una copia del mismo material asignado
material para préstamo. Fijémonos bien en la en otro préstamo, no se incluye en el préstamo
excepción que se enunció originalmente: “En el que está siendo procesado. Acá se varía la
paso 3, de comprobarse que el Usuario ya tiene excepción: el caso de uso no termina, sino
una copia del mismo material asignado en otro que puede seguirse con la solicitud de otros
préstamo, el caso de uso termina”. De nuevo, materiales para el préstamo.
debemos pensar en la evolución que ha tenido Podemos ver el diagrama resultante, como
nuestro conocimiento del sistema y lo que se sigue.
ha resuelto (en teoría) junto con el cliente.
Con el fin de completar la visión que se da a Por lo tanto, en el caso de la excepción, debería
partir de las modificaciones que realizamos reescribirse así: “En el paso 4, luego de indicarle
en el paso 3 y su correspondiente excepción, al usuario las restricciones del préstamo, éste
hemos agregado también lo que se indica en puede decidir no aceptar las condiciones, por
el punto 4. Observe que, después de que se lo cual el Bibliotecario prosigue con los otros
comprueba en la decisión llamada “Usuario materiales solicitados”.
tiene copia prestada”, en el caso de que sea Advierta, entonces que, en el diagrama
positiva dicha comprobación, se pregunta si anterior, se ejecuta una condición en la cual
quiere continuar agregando materiales a la el Bibliotecario indica si el Usuario está de
solicitud. Si se dice que sí, entonces se procede acuerdo (o no lo está) con las condiciones
a leer el código de otra copia de un material. del préstamo. Si este indica que sí, se agrega
En caso que la comprobación de que si una la copia del material solicitado al trámite y, si
copia del material ya ha sido prestada al la respuesta es negativa, se prosigue con la
usuario resulta negativa, se sigue con los pasos decisión de continuar agregando materiales en
que se dan en el paso 4: “El Sistema indica si la solicitud de préstamo.
el material puede ser prestado solo para uso Finalmente debe completarse el proceso,
interno de la biblioteca y el tiempo que puede ejecutando el paso 5. Dicho paso debiera estar
ser prestado en cualquier caso”. Además, su a continuación de la decisión de agregar (o
correspondiente excepción indica que: “En no agregar) más materiales a la solicitud de
el paso 4, luego de indicarle al usuario las préstamo. Por lo tanto, si se indica que no se
restricciones del préstamo, éste puede decidir agregarán más, entonces se da la actividad de
no aceptar las condiciones, por lo cual el registrar el préstamo.
Bibliotecario termina la ejecución del caso de El diagrama completo de este caso de uso
uso”. quedaría de la siguiente manera.
Acá también nos encontraremos con que
deben realizarse modificaciones, las cuales ya
en el diagrama anterior están materializadas.
Un usuario podría no aceptar las condiciones
del préstamo para un material en particular,
pero sí para otros que le interesan.
 RESUMEN DEL TEMA
Un diagrama de actividad puede ayudarnos a documentar, de una forma conveniente
y relativamente sencilla, los casos de uso, considerando, además, lo pertinente a las
condiciones (vistas como decisiones) y a los ciclos que pueden darse en el proceso.
Por ello, en este tema tomamos nuevamente, el ejemplo que corresponde al caso de
uso de Registrar préstamo, para, como caso de estudio, realizar un su diagrama de
actividad, para lo cual debemos recordar su descripción detallada en el tema 3.
En esa descripción se establece una secuencia de cinco (5) pasos, en los cuales pueden
inferirse actividades, las cuales se diagraman para ir conformando el diagrama de
actividad.

LA IDEA PRINCIPAL
Un diagrama de actividad ayuda a documentar los casos de uso,
considerando todas las acciones que pueden darse en el mismo.
 LECTURAS RECOMENDADAS
• Rumbaugh, James. El Lenguaje Unificado De Modelado. 2a. ed., 2006
• Paul Kimmel Manual de UML, Guía de Aprendizaje

ACTIVIDADES Y EJERCICIOS
1. Realizar la especificación en detalle, según plantilla, de los CUS de los requisitos
funcionales de un sistema de ventas de una pollería.
2. Realizar el diagrama de actividades de los CUS del punto anterior
 INTRODUCCIÓN ACTITUDES
Los diagramas de secuencia son un tipo de • Los alumnos en educación a distancia
diagrama en UML, los cuales permiten modelar forman grupos heterogéneos en edad,
la interacción surgida a partir de un evento en intereses, ocupación, motivaciones,
el sistema, que desencadena un actor.
experiencias y aspiraciones.
Describen la interacción de objetos que
requiere la funcionalidad de los distintos • Están altamente motivados al logro.
escenarios de un Caso de Uso. Estos objetos
son representados con su ciclo de vida dentro TEMAS
de una serie temporal.
En la presente Unidad de Aprendizaje se
tratan temas sobre la utilidad de los diagramas
de secuencia dentro del modelado del
1
TEMA
modelado del
comportamiento
comportamiento en el tiempo de los casos
de uso del sistema y cómo se elaboran de los
casos de uso de un caso de estudio. 2
TEMA
Diagrama de
Secuencia de CUS
COMPETENCIA
Elabora los diagramas de secuencia para
comprender la utilidad de este artefacto dentro 3
TEMA
Elementos del diagrama
de secuencia
del modelo de comportamiento de los casos de
uso.
CAPACIDADES 4
TEMA
Cómo elaborar diagramas
de secuencia
• Elabora un diagrama de secuencia de
actividades de los casos de uso, útil para el
análisis y diseño del software 5 Elaborar diagramas de secuencia
de los CUS – Caso de estudio
• Comprende la importancia de los diagramas TEMA

de secuencia como artefacto de análisis y

diseño.
UNIDAD 6 - TEMA 1
Modelado del comportamiento
No existen sistemas en aislamiento. Cada sistema En los diagramas de interacción los objetos
interactúa con la gente o sistemas automatizados interactúan para realizar colectivamente los servicios
para el mismo propósito. Estas interacciones ofrecidos por las aplicaciones.
resultan en algún tipo de resultado predecible. Este Los diagramas de interacción muestran cómo se
resultado predecible es el comportamiento del comunican estos objetos en una interacción. Estos
sistema. diagramas conforman las etapas de análisis y diseño
Los casos de uso son los mecanismos para capturar de la aplicación, y se crean a partir de los diagramas
el comportamiento deseado, esto es, bajo el de Casos de Uso.
desarrollo, pero no especifica cómo debe ser Existen dos tipos de diagramas de interacción:
implementado el comportamiento. UML especifica • El Diagrama de Secuencia es más adecuado
un modelo para comunicar el comportamiento del para observar la perspectiva cronológica de las
sistema, el modelo de caso de uso. interacciones.
Antes de iniciar el diseño lógico, es decir, comenzar • El Diagrama de Comunicación ofrece una
a definir cómo funcionará el software, se debe mejor visión espacial mostrando los enlaces de
investigar e identificar su comportamiento, como comunicación entre objetos.
una “caja negra”, a través de los escenarios y las En esta Unidad de Aprendizaje trataremos sobre los
interacciones entre los objetos. diagramas de secuencia como parte del modelo de
Como una “caja negra” significa lograr una comportamiento de los casos de uso del sistema,
descripción de lo que el sistema hace, no de cómo como se ilustra en la siguiente figura, en donde
lo hace. se ilustran los artefactos que la metodología RUP
Los casos de uso indican cómo los actores considera como necesarios y útiles para representar
interactúan con el sistema, indicando que es lo que los conceptos del dominio del problema, dentro del
en realidad se desea desarrollar, eso nos aproxima modelo de casos de uso.
al Modelo Conceptual del sistema, pero se requiere
desarrollar un entendimiento más detallado del
sistema, instanciando casos de uso, usando las
clases ya identificadas, e identificando asociaciones,
operaciones y nuevas clases. La instanciación es
hecha a través de los escenarios de los casos de usos.
Cada escenario provee una secuencia específica de
interacciones entre los actores y las entidades en
el sistema, basándose en la secuencia genérica de
eventos que define el caso de uso correspondiente.
Un escenario es una elaboración textual de un caso
de uso, que puede ser representada gráficamente,
a través de diagramas UML, con una descripción
gráfica de las interacciones del actor y de las El modelado de la interacción es importante ya que
operaciones que dan origen. ayuda a identificar las necesidades de los usuarios.
Estas interacciones se modelan a través de El modelado de interacción de sistema a sistema
los diagramas de interacción, que describen resalta los problemas de comunicación que puedan
interacciones entre clases, modeladas como surgir.
intercambios de mensajes, para cumplir algún
comportamiento deseado.
 RESUMEN DEL TEMA
Antes de comenzar a definir cómo funcionará el software (modelo lógico), se debe
identificar su comportamiento, a través de los escenarios y las interacciones entre los
objetos.
Los casos de uso indican cómo los actores interactúan con el sistema, indicando que es
lo que en realidad se desea desarrollar, eso nos aproxima al modelo lógico del sistema,
pero se requiere desarrollar un entendimiento más detallado del sistema, instanciando
casos de uso, usando las clases ya identificadas e identificando asociaciones,
operaciones y nuevas clases. La instanciación es hecha a través de los escenarios de
los casos de usos.
Cada escenario provee una secuencia específica de interacciones entre los actores y las
entidades en el sistema, basándose en la secuencia genérica de eventos que define el
caso de uso correspondiente.
Un escenario es una elaboración textual de un caso de uso, que puede ser representada
gráficamente, a través de diagramas UML, con una descripción gráfica de las
interacciones del actor y de las operaciones que dan origen.
Estas interacciones se modelan a través de los diagramas de interacción, que describen
interacciones entre clases, modeladas como intercambios de mensajes, para cumplir
algún comportamiento deseado. Los objetos interactúan para realizar colectivamente
los servicios ofrecidos por las aplicaciones.
Los diagramas de interacción muestran cómo se comunican estos objetos en una
interacción
Existen dos tipos de diagramas de interacción:
• El Diagrama de Secuencia es más adecuado para observar la perspectiva cronológica
de las interacciones.
• El Diagrama de Comunicación ofrece una mejor visión espacial mostrando los
enlaces de comunicación entre objetos.

LA IDEA PRINCIPAL
El modelado de la interacción del usuario es importante ya que
ayuda a identificar las necesidades de los usuarios.
UNIDAD 6 - TEMA 2
DIAGRAMA DE SECUENCIA DE CUS
Los diagramas de secuencia son parte Un diagrama de secuencia describe la
de la UML y se utilizan para modelar las interacción de objetos que requiere la
interacciones entre los actores y los objetos funcionalidad de los distintos escenarios de un
dentro de un sistema, muestran la secuencia Caso de Uso. Los objetos son representados
de interacciones que tienen lugar durante un con su ciclo de vida dentro de una serie
caso de uso en particular o un caso de uso de temporal. Cada posible escenario de un Caso
instancia. Los objetos y los actores involucrados de Uso puede representarse con un diagrama
están listados en la parte superior del diagrama, de secuencia.
con una línea de puntos trazada verticalmente En muchos casos se utiliza un diagrama
a partir de estos y las interacciones entre los de secuencia para ilustrar realizaciones de
objetos se indican mediante flechas anotadas. casos de uso, es decir, para mostrar cómo
Los diagramas de secuencia representan una interactúan los objetos para llevar a cabo el
interacción entre objetos de manera secuencial comportamiento de todo o parte de un caso de
en el tiempo. Muestran la participación de uso. Uno o más diagramas de secuencia pueden
objetos en la interacción entre sus “líneas de ilustrar las interacciones de objetos que llevan
vida” (desde que son instancias) y los mensajes a cabo un caso de uso. Una organización típica
que ellos organizadamente intercambian en el tiene un diagrama de secuencia para el flujo de
tiempo. El responsable o actor es quien inicia el sucesos principal y un diagrama de secuencia
ciclo interactuando inicialmente con la interfaz para cada subflujo independiente del caso de
de usuario, en seguida se inician todos los uso.
objetos que intervienen en el funcionamiento Es el tipo más común de diagrama de
de la secuencia. En este diagrama se comienza interacción que se centra en el intercambio de
a observar el comportamiento del sistema a mensajes entre líneas de vida (objetos).
partir de los eventos generados por los actores, Los diagramas de secuencia son especialmente
en ellos se interactúa con instancias, no con importantes para los diseñadores, puesto
clases. que aclaran los roles de los objetos de
un flujo, proporcionando así la entrada
básica para determinar las interfaces y las
responsabilidades de las clases.
A diferencia de un diagrama de comunicación,
un diagrama de secuencia incluye secuencias
cronológicas, pero no incluye relaciones de
objetos. Los diagramas de secuencia y los
diagramas de comunicación expresan una
información similar, pero de modos diferentes.
Los diagramas de secuencia muestran la
secuencia explícita de mensajes y resultan más
adecuados cuando lo importante es visualizar
el orden de tiempo de los mensajes. Cuando
le interesen las relaciones entre las instancias
de una interacción, utilice un diagrama de
comunicación.
Los diagramas de secuencia pueden ser En este curso de Diseño de Software,
referencias útiles para los desarrolladores, ya básicamente se trata el escenario de uso,
que se usan para: es decir, para el análisis de la lógica de cada
• Representa los detalles de un caso de uso escenario de los casos de uso del sistema.
en UML. Algunos ejemplos de diagramas de secuencia
• Modelar la lógica de una operación, una se muestran a continuación.
función o un procedimiento sofisticados.
• Ve cómo los objetos y los componentes Diagrama de secuencia para Ver la
interactúan entre sí para completar un información del paciente.
proceso.
• Planificar y comprender la funcionalidad
detallada de un escenario actual o futuro.
Los siguientes escenarios son ideales para usar
un diagrama de secuencia:
Escenario de uso: Un escenario de uso
es un diagrama de cómo se podría usar
potencialmente tu sistema. Es una excelente
manera de asegurar que has estudiado la lógica
de cada escenario de uso para el sistema.
Lógica del método: Al igual que utilizarías
un diagrama de secuencia UML para explorar
la lógica de un caso de uso, puedes usarlo
para explorar la lógica de cualquier función,
procedimiento o proceso complejo.
Lógica de servicio: Si consideras que un
servicio es un método de alto nivel empleado
por diferentes clientes, un diagrama de
secuencia es una forma ideal de trazarlo. Diagrama de secuencia para la transferencia
de datos.
 RESUMEN DEL TEMA
Los diagramas de secuencia son parte de la UML y se utilizan para modelar las
interacciones entre los actores y los objetos dentro de un sistema, muestran la
secuencia de interacciones que tienen lugar durante un caso de uso en particular o
un caso de uso de instancia. Los objetos y los actores involucrados están listados en la
parte superior del diagrama, con una línea de puntos trazada verticalmente a partir de
estos y las interacciones entre los objetos se indican mediante flechas anotadas.
Los diagramas de secuencia, comúnmente utilizados por los desarrolladores, modelan
las interacciones entre los objetos en un solo caso de uso.
Ilustran la forma en que las diferentes partes de un sistema interactúan entre sí para
llevar a cabo una función, y el orden en que se producen las interacciones cuando se
ejecuta un caso de uso concreto.
En palabras más sencillas, un diagrama de secuencia muestra diferentes partes de un
sistema trabajando en una “secuencia” para conseguir algo.
Los diagramas de secuencia son especialmente importantes para los diseñadores,
puesto que aclaran los roles de los objetos de un flujo, proporcionando así la entrada
básica para determinar las interfaces y las responsabilidades de las clases.
A diferencia de un diagrama de comunicación, un diagrama de secuencia incluye
secuencias cronológicas, pero no incluye relaciones de objetos. Los diagramas de
secuencia y los diagramas de comunicación expresan una información similar, pero
de modos diferentes. Los diagramas de secuencia muestran la secuencia explícita de
mensajes y resultan más adecuados cuando lo importante es visualizar el orden de
tiempo de los mensajes. Cuando le interesen las relaciones entre las instancias de una
interacción, utilice un diagrama de comunicación.

LA IDEA PRINCIPAL
El diagrama de secuencia es una técnica para modelar en una línea de
tiempo, el comportamiento de los casos de uso.
UNIDAD 6 - TEMA 3
ELEMENTOS DEL DIAGRAMA DE SECUENCIA
Un diagrama de secuencia está estructurado de Línea de vida de elemento de entidad
tal manera que representa una línea de tiempo Una línea de vida con un elemento de entidad
que comienza en la parte superior y desciende representa los datos del sistema. Por ejemplo,
gradualmente para marcar la secuencia de en una aplicación de servicio al cliente, la
interacciones. Cada objeto tiene una columna y entidad Cliente gestionaría todos los datos
los mensajes intercambiados entre ellos están relacionados con un cliente.
representados por flechas.
Para comprender qué es un diagrama de
secuencia y cómo hacerlos, se debe estar
familiarizado con sus símbolos y componentes.
Los diagramas de secuencia están formados
por los siguientes elementos e íconos:

Notación de línea de vida

El diagrama de secuencia está compuesto por Línea de vida con un elemento límite
varias de estas notaciones de línea de vida que (boundary)
deberían estar dispuestas horizontalmente Indica un límite del sistema/elemento de
en la parte superior del diagrama. Ninguna de software en un sistema; por ejemplo, las
las dos anotaciones de la línea de vida debe pantallas de la interfaz de usuario, las puertas
superponerse. Representan los diferentes de la base de datos o los menús con los que
objetos o partes que interactúan entre sí en el interactúan los usuarios son límites.
sistema durante la secuencia.

Línea de vida con un elemento de control

Línea de vida con un símbolo de elemento Indica una entidad controladora o gerente.
actor Organiza y programa las interacciones entre los
Se utiliza cuando el diagrama de secuencia límites y entidades y sirve de mediador entre
particular es propiedad de un caso de uso. ellos.
Barras de Activación • Mensaje asincrónico
La barra de activación es la caja que se coloca Un mensaje asíncrono se utiliza cuando un
en la línea de vida. Se utiliza para indicar que emisor que llama el mensaje no espera a que
un objeto está activo (o instanciado) durante el receptor lo procese y lo devuelva, antes de
una interacción entre dos objetos. La longitud enviar otros mensajes a otros objetos dentro
del rectángulo indica la duración de los objetos del sistema. La punta de la flecha utilizada para
que permanecen activos. mostrar este tipo de mensaje es una flecha de
En un diagrama de secuencia, una interacción línea como la que se muestra en el ejemplo a
entre dos objetos ocurre cuando un objeto continuación.
envía un mensaje a otro. El uso de la barra
de activación del Llamador de mensajes (el
objeto que envía el mensaje) y del Receptor
de mensajes (el objeto que recibe el mensaje)
indica que ambos están activos/están
instanciados durante el intercambio del
mensaje.

• Mensaje de retorno
Flechas de Mensajes Un mensaje de retorno se utiliza para indicar
Una flecha desde el Llamador de Mensajes que el receptor del mensaje ha terminado
hasta el Receptor de Mensajes especifica un de procesar el mensaje y está devolviendo el
mensaje en un diagrama de secuencia. control al objeto que llama el mensaje. Los
Un mensaje puede fluir en cualquier dirección; mensajes de retorno son piezas de notación
de izquierda a derecha, de derecha a izquierda opcionales, ya que una barra de activación que
o de vuelta al propio llamador de mensajes. se dispara por un mensaje sincrónico siempre
Mientras que en la flecha se puede describir el implica un mensaje de retorno.
mensaje que se está enviando de un objeto a Consejo: Puede evitar que sus diagramas se
otro, con diferentes puntas de flecha se puede desordenen minimizando el uso de mensajes
indicar el tipo de mensaje que se está enviando de retorno, ya que el valor de retorno puede
o recibiendo. especificarse en la propia flecha del mensaje
La flecha del mensaje viene con una descripción, inicial.
que se conoce como firma del mensaje, en ella.
El formato de la firma de este mensaje es el
siguiente. Todas las partes excepto el nombre
de mensaje son opcionales.
atributo = nombre_de_mensaje (argumentos):
tipo_retorno
• Mensaje sincrónico
Como se muestra en el ejemplo de las barras
de activación, un mensaje sincrónico se utiliza
cuando el emisor espera a que el receptor
procese el mensaje y vuelva, antes de continuar
con otro mensaje. La punta de la flecha
utilizada para indicar este tipo de mensaje es
sólida, como la que se muestra a continuación.
• Mensaje de creación del participante • Mensaje reflexivo
Los objetos no viven necesariamente durante Cuando un objeto se envía un mensaje a sí
toda la duración de la secuencia de eventos. Los mismo, se llama mensaje reflexivo. Se indica
objetos o participantes pueden ser creados de con una flecha de mensaje que comienza
acuerdo con el mensaje que se está enviando. y termina en la misma línea de vida como se
La anotación de la casilla de participante muestra en el ejemplo a continuación.
eliminado puede utilizarse cuando se necesita
mostrar que el participante en particular
no existía hasta que se envió la llamada de
creación. Si el participante creado hace algo
inmediatamente después de su creación, debe
añadir un cuadro de activación justo debajo del
cuadro del participante.

• Comentario
Los diagramas UML generalmente permiten la
anotación de comentarios en todos los tipos
de diagramas UML. El objeto del comentario es
un rectángulo con una esquina doblada como
se muestra a continuación. El comentario se
puede vincular al objeto relacionado con una
línea de puntos.

• Mensaje de destrucción del participante

Del mismo modo, los participantes cuando ya
no se necesiten también pueden ser eliminados
de un diagrama de secuencia. Esto se hace
añadiendo una ‘X’ al final de la línea de vida de
dicho participante.
 RESUMEN DEL TEMA
En los diagramas de secuencia se puede tener objetos e instancias de actor, junto con
mensajes que describan cómo interactúan. El diagrama describe lo que ocurre en los
objetos participantes, en términos de activaciones, y cómo se comunican los objetos
enviando mensajes entre sí. Se puede realizar un diagrama de secuencia para cada
variante del flujo de sucesos del caso de uso.
Un diagrama de secuencia está estructurado de tal manera que representa una línea
de tiempo que comienza en la parte superior y desciende gradualmente para marcar
la secuencia de interacciones.
Cada objeto tiene una columna y los mensajes intercambiados entre ellos están
representados por flechas.
Para comprender qué es un diagrama de secuencia y cómo hacerlos, es necesario estar
familiarizado con sus símbolos y componentes.

LA IDEA PRINCIPAL
Conocer el uso de cada elemento del diagrama de secuencia para
su correcta diagramación.
UNIDAD 6 - TEMA 4
CÓMO ELABORAR DIAGRAMAS DE SECUENCIA
Un diagrama de secuencia tiene dos En la siguiente figura, observaremos un
dimensiones, el eje vertical representa el ejemplo básico de un diagrama de secuencia,
tiempo y el eje horizontal los diferentes objetos. donde se representa la interacción entre el
El tiempo avanza desde la parte superior del actor Bibliotecario y el Sistema de Préstamo
diagrama hacia la inferior. Normalmente, Bibliotecario.
en relación al tiempo solo es importante la
secuencia de los mensajes, sin embargo, en
aplicaciones de tiempo real se podría introducir
una escala en el eje vertical. Respecto a los
objetos, es irrelevante el orden en que se
representan, aunque su colocación debería
poseer la mayor claridad posible.
Cada objeto tiene asociados una línea de vida
y focos de control. La línea de vida indica el
intervalo de tiempo durante el que existe ese
objeto. Un foco de control o activación muestra
el periodo de tiempo en el cual el objeto se
encuentra ejecutando alguna operación, ya sea
directamente o mediante un procedimiento
concurrente.
En la figura anterior se notan los elementos de ¿Cómo estos interactúan? Ellos lo hacen
un diagrama de secuencia. mediante mensajes, que se representan por
En primer lugar, a la izquierda, encontramos un medio de una flecha que parte del actor y tiene
actor, tal como lo hemos visto en el diagrama su llegada en el sistema.
de casos de uso. Específicamente vemos, en Ese mensaje tendrá un nombre y los que se
este caso, a un Bibliotecario que es actor de dirigen de izquierda a derecha (las entradas), se
nuestro sistema de préstamo bibliotecario. grafican con un trazo continuo. Los que van en
Seguidamente vemos una caja, con el nombre el sentido inverso (las respuestas del sistema),
Sistema. Al estar subrayado en este tipo de tendrán un trazo discontinuo.
diagrama, significa que se está tratando con Los mensajes se hacen en secuencia, de ahí el
una instancia, o bien, con un objeto Sistema. nombre de este tipo de diagrama: los mensajes
Deberá existir un concepto o una clase llamada se ejecutan en orden, de arriba hacia abajo.
Sistema en el contexto de la solución que está Con un poco más de detalle se puede visualizar,
desarrollándose. en la siguiente figura, el diagrama de secuencia
Debajo del actor Bibliotecario y del objeto para el caso de uso: Prestar un ejemplar del
Sistema “caen” unas líneas. Tales líneas podrán sistema de préstamos de una biblioteca.
sustentar las interacciones que se tendrá entre
el actor y el sistema.
 RESUMEN DEL TEMA
Un diagrama de secuencia tiene dos dimensiones, el eje vertical representa el tiempo
y el eje horizontal los diferentes objetos. El tiempo avanza desde la parte superior del
diagrama hacia la inferior. Normalmente, en relación al tiempo solo es importante
la secuencia de los mensajes, sin embargo, en aplicaciones de tiempo real se podría
introducir una escala en el eje vertical. Respecto a los objetos, es irrelevante el orden
en que se representan, aunque su colocación debería poseer la mayor claridad posible.
Cada objeto tiene asociados una línea de vida y focos de control. La línea de vida indica
el intervalo de tiempo durante el que existe ese objeto. Un foco de control o activación
muestra el periodo de tiempo en el cual el objeto se encuentra ejecutando alguna
operación, ya sea directamente o mediante un procedimiento concurrente.
Se explica con un ejemplo del caso de estudio que se ha seguido en el libro, los pasos
necesarios para elaborar un diagrama de secuencia.
Hay pasos de identificación de actores y objetos, sus activaciones en las líneas de vida
y secuencia de mensajes manejados entre ellos, que son necesarios para elaborar un
diagrama de secuencia de un CUS.

LA IDEA PRINCIPAL
Ejecución de los pasos necesarios para elaborar un diagrama de
secuencia de un CUS.
UNIDAD 6 - TEMA 5
ELABORAR DIAGRAMAS DE SECUENCIA DE
LOS CUS – CASO DE ESTUDIO
Los diagramas de secuencia son un tipo de La secuencia de pasos que se diagraman se
diagrama en UML, los cuales permiten modelar asemeja, en mucho, al escenario de un caso de
la interacción surgida a partir de un evento en uso.
el sistema que desencadena un actor. Esas Si nos fijamos en el escenario del caso de uso
interacciones pueden verse en distintos niveles de Registrar préstamo, podemos encontrar tal
de refinamiento. semejanza.
Veamos el nivel de refinamiento asociado a los El caso de uso comienza cuando el Bibliotecario
CUS, es decir, los diagramas de secuencia de ingresa al sistema la identificación del Usuario.
sistema. El Sistema le indica si el Usuario es válido.
En primer lugar, puede servir para ilustrar la El Sistema le indica, además, si el Usuario tiene
interacción entre el actor y el sistema, este algún registro de morosidad.
último visto como una caja negra: no se conoce Una vez comprobados los pasos anteriores,
mayor detalle de lo que ocurre a lo interno el Bibliotecario lee del Sistema Bibliotecario la
del sistema. Simplemente, se visualizan las información del material que va a prestarse, a
entradas y salidas que se dan en el contexto de través de un lector de código de barras.
lo que requiere hacerse por parte del actor. En ningún caso puede prestarse otra copia del
mismo material al mismo usuario, lo cual se
¿Qué podría darnos un insumo para comprueba por parte del Sistema cuando se
construir un diagrama de secuencia? hace esta lectura.
Nuevamente recurrimos a los casos de uso. El El Sistema indica si el material puede ser
escenario de un caso de uso muestra los pasos prestado solo para uso interno de la biblioteca y
que deben darse en esa interacción entre el el tiempo que puede ser prestado, en cualquier
actor y el sistema. El diagrama de secuencia lo caso.
componen varios elementos, ya descritos en El Bibliotecario registra el préstamo del material
temas anteriores. y el caso de uso termina.
Podemos, a partir de ello, comenzar a tener
una visión interesante de, por una parte,
documentar los casos de uso desde el punto
de vista de la interacción del sistema y, por
otra parte, comenzar a identificar una serie de
mensajes que pueden ir tomándose en cuenta
para crear algunas clases de diseño que más
adelante veremos.
A partir del escenario del caso de uso visto,
podemos replantear el diagrama tomando
como base la definición del escenario de
dicho caso y, además, ver otros aspectos del
diagrama.
Muy importante considerar que se trata Estos diagramas de secuencia son
de poner, dentro del diagrama, los pasos y relativamente sencillos, se pueden estructurar
acciones estipuladas dentro del escenario del a partir de los casos de uso y nos pueden
caso de uso. servir para identificar eventos del sistema que
Aprecie que en el diagrama anterior aparecen pueden darse en las clases de alguna capa
dos situaciones nuevas con respecto al o subsistema, dependiendo del patrón de
mostrado en el tema anterior. arquitectura que se use, por ejemplo, una capa
En primer lugar, se observa que el Sistema de interfaz en una arquitectura de n-capas.
se envía un mensaje a sí mismo. Allí se está
indicando que, por sí mismo, el sistema debe
verificar que un material solicitado por un
usuario de la biblioteca no esté previamente
prestado.
Por otra parte, observe algo importante: cuando
en un diagrama de secuencia usted halle
un rectángulo encerrando varios mensajes,
como sucede entre IngresaMaterialPréstamo
e IndicaCondicionesPréstamo, entonces nos
encontraremos en una serie de pasos que se
repiten, es decir, una iteración o ciclo.
 RESUMEN DEL TEMA
Los diagramas de secuencia permiten modelar la interacción surgida a partir de un
evento en el sistema que desencadena un actor. Esas interacciones pueden verse en
distintos niveles de refinamiento.
En este caso de estudio se ve el nivel de refinamiento asociado a los CUS, es decir, los
diagramas de secuencia de sistema.
En primer lugar, puede servir para ilustrar la interacción entre el actor y el sistema,
este último visto como una caja negra: no se conoce mayor detalle de lo que ocurre a
lo interno del sistema. Simplemente, se visualizan las entradas y salidas que se dan en
el contexto de lo que requiere hacerse por parte del actor.
Para lograr el insumo para construir un diagrama de secuencia se recurre nuevamente
a los casos de uso. El escenario de un caso de uso muestra los pasos que deben darse
en esa interacción entre el actor y el sistema. El diagrama de secuencia lo componen
varios elementos, ya descritos en temas anteriores.
La secuencia de pasos que se diagraman se asemeja, en mucho, al escenario de un
caso de uso.
En este tema en particular, se analiza con un caso de estudio, el nivel de refinamiento
asociado a los CUS, es decir, sus interacciones a través de un diagrama de secuencia.

LA IDEA PRINCIPAL
Se analizan las interacciones entre objetos de un caso de uso, a
través de la elaboración de un diagrama de secuencia.
 LECTURAS RECOMENDADAS
• Rumbaugh, James. El Lenguaje Unificado De Modelado. 2a. ed., 2006
• Paul Kimmel Manual de UML, Guía de Aprendizaje

ACTIVIDADES Y EJERCICIOS
1. Especificar y comprender cómo interactúan los objetos dentro de los
escenarios de los CUS
2. Elaborar un diagrama de secuencia de los CUS de un caso de estudio: sistema
de ventas de una pollería
 INTRODUCCIÓN TEMAS
El modelado de análisis orientado a objetos
es una técnica de diseño, la cual se caracteriza
por la determinación y delegación de
responsabilidades. Cuando un objeto se hace
1
TEMA
Modelo de análisis
Orientado a objetos
responsable por acciones específicas, entonces
se espera cierto comportamiento de su parte.
Durante el análisis y el diseño del sistema,
el modelo de Casos de Uso se transforma,
mediante un modelo de análisis, en un modelo
2
TEMA
diagrama de clase
de análisis
de diseño, comenzando con las realizaciones
de casos de usos en clases de análisis.

COMPETENCIA
Comprende y elabora un diagrama de clases de
3
TEMA
Elementos de los diagramas
de clases de análisis
análisis para tener la primera aproximación al
modelo de diseño de software.

•
CAPACIDADES
Comprender cómo se realizan los casos de
4
TEMA
Realización de los CU en
clases de análisis
uso en las clases de análisis, como primera
aproximación a las clases de diseño
• Elaborar diagramas de clases de análisis.
ACTITUDES 5
TEMA
Elaborar diagramas de clases
de análisis – Caso de estudio
• Puede adaptarse a ambientes de estudio
nuevos.
• Los procedimientos institucionales son
propicios para sus gestiones.
UNIDAD 7 - TEMA 1
Modelo de análisis Orientado a objetos
Generalidades El modelo de análisis.
El modelado de análisis orientado a objetos Es una especificación detallada de los requisitos
es una técnica de diseño, la cual se caracteriza del sistema, que permite comprender de forma
por la determinación y delegación de más precisa los Casos de Usos descritos en el
responsabilidades. Cuando un objeto se hace modelo de requisitos.
responsable por acciones específicas, entonces Este modelo define un modelo de objetos, que
se espera cierto comportamiento. describe la ejecución de casos de uso, que sirve
El Modelado Orientado a Objetos es la como abstracción del modelo de diseño, como
construcción de modelos de un sistema por su primera aproximación.
medio de la identificación y especificación de En la metodología de desarrollo RUP, el modelo
un conjunto de objetos relacionados, que se de análisis puede ser considerado una fase de
comportan y colaboran entre sí de acuerdo a transición entre el modelo de casos de usos y el
los requerimientos establecidos para el sistema modelo de diseño de clases, tal como se ilustra
de objetos. en la siguiente figura.

Los casos de uso en el modelo de análisis.

El conjunto completo de casos de uso especifica
todas las posibles formas de usar el sistema,
esto representa el comportamiento requerido.
Los Casos de Uso, como resultado de la captura
de requisitos, que especifican los requisitos
funcionales, son utilizados como entradas para
el análisis, diseño, implementación y pruebas
del sistema.
Durante el análisis y el diseño del sistema,
el modelo de Casos de Uso se transforma
mediante un modelo de análisis en un modelo
de diseño, comenzando con las realizaciones En el modelo de análisis.
de los casos de usos en diagramas de clases de Cada Caso de Uso se convertirá en una
análisis. realización a través de clases de análisis.
La dualidad Casos de Usos y su realización es
la base de una trazabilidad directa entre los
requisitos y el análisis.
Revisando cada Caso de Uso se pueden
identificar las clases que participan en la
realización del Caso de Uso.
Por ejemplo. Un Caso de Uso Sacar Dinero (de
un cajero automático) puede realizarse a través
de las siguientes clases de análisis:
• Cajero.
• Retirada de Efectivo.
• Cuenta.
Tal como se muestra en la siguiente figura.

Las responsabilidades en el Caso de Uso

se asignan a responsabilidades de las
clases de análisis. Del ejemplo del CU Sacar
Dinero, la clase entidad Cuenta tendría
como responsabilidad “restar cantidad de
la cuenta”, esta responsabilidad genera un
comportamiento esperado.
En conclusión, el modelo de análisis garantiza
un conjunto de clases que “realizan” los Casos
de Usos, esos en lo que estaremos tratando
en los temas de esta Unidad de Aprendizaje.
Adicionalmente, este modelo sirve de puente
entre una descripción del sistema en el dominio
del problema y el diseño del software en el
dominio de la solución, tal como se ilustra en la
siguiente figura.
 RESUMEN DEL TEMA
El modelado de análisis orientado a objetos es una técnica de diseño, la cual se
caracteriza por la determinación y delegación de responsabilidades. Cuando un
objeto se hace responsable por acciones específicas, entonces se espera cierto
comportamiento.
Por otro lado, el modelado Orientado a Objetos es la construcción de modelos de
un sistema por medio de la identificación y especificación de un conjunto de objetos
relacionados, que se comportan y colaboran entre sí de acuerdo a los requerimientos
establecidos para el sistema de objetos.
El conjunto completo de casos de uso en el modelo de análisis, especifica todas las
posibles formas de usar el sistema, esto representa el comportamiento requerido. Los
Casos de Usos, como resultado de la captura de requisitos, que especifican los requisitos
funcionales, son utilizados como entradas para el análisis, diseño, implementación y
pruebas del sistema.
Durante el análisis y el diseño del sistema, el modelo de Casos de Uso se transforma
mediante un modelo de análisis en un modelo de diseño, comenzando con las
realizaciones de los casos de usos en diagramas de clases de análisis.
Dicho modelo de análisis es una especificación detallada de los requisitos del sistema,
que permite comprender de forma más precisa los Casos de Usos descritos en el
modelo de requisitos. El modelo de análisis define un modelo de objetos, que describe
la ejecución de casos de uso, que sirve como abstracción del modelo de diseño, como
su primera aproximación.
Este modelo de análisis garantiza un conjunto de clases de análisis que “realizan” los
Casos de Usos, a las cuales se le asignan las responsabilidades de los Casos de Uso.

LA IDEA PRINCIPAL
El modelo de análisis garantiza un conjunto de clases de
análisis que “realizan” los Casos de Usos.
UNIDAD 7 - TEMA 2
diagrama de clase 0E de análisis
Es uno de los diagramas principales de análisis Ejemplo introductorio.
y diseño para un sistema. Como instrucción a la conversión de un caso
En este diagrama se especifican la estructura de uso en un diagrama de clases de análisis
y las relaciones de las clases conceptuales del comencemos con el siguiente ejemplo.
sistema. Se desarrollará un videojuego educativo dirigido
Durante el análisis del sistema, el diagrama se a los niños basándose en el funcionamiento
desarrolla buscando una solución ideal. del sistema inmunológico del ser humano, con
Durante la fase de diseño, se puede modificar el objetivo de lograr que el niño mientras se
el mismo diagrama para satisfacer los detalles distrae este adquiriendo conocimientos sobre
de la implementación del software. el funcionamiento de su sistema inmunológico.
El desarrollo del videojuego se basa en
Clases de análisis. demostrar que a través de los videojuegos
Estas clases especifican los elementos de un también se puede adquirir conocimientos
modelo conceptual temprano para objetos educativos y proponer una alternativa para el
del sistema que tienen responsabilidades y aprendizaje.
comportamiento. El modelo de Casos de Uso se compone por
Representan las clases prototípicas del sistema, varios objetos que intervienen en los procesos
y son un primer paso en la descripción de las que un sistema es capaz de ejecutar, los
abstracciones principales que el sistema debe cuales se describen mediante la identificación
manejar. de casos de uso, identificación de actores y
Se pueden mantener durante el diseño, si descripción de los casos de uso. En la siguiente
se desea una visión general de alto nivel y figura, se representa los requisitos funcionales
conceptual del sistema. del videojuego mediante el diagrama de casos
Generan las principales abstracciones del de uso.
diseño del sistema: las clases de diseño y los
subsistemas del sistema.

Su objetivo:
Las clases de análisis se utilizan para capturar
los principales “grupos de responsabilidad” del
sistema, de acuerdo a cada uno de los casos
de uso, a través de tres tipos de clases, que se
describirán posteriormente.
Los diagramas de clases de análisis siempre
están asociados a una clase, a una operación
o a un caso de uso en particular, en este caso
están asociados a los casos de uso mostrados
anteriormente.
Ahora procederemos a realizar el diagrama de
clases de análisis del caso de uso “Iniciar Juego”.

La explicación de cómo se pasa de un diagrama

de caso de uso a un diagrama de clases de
análisis se explicarán en los siguientes temas,
la idea de presentarlo a nivel introductorio es
para visualizar cómo las clases de análisis se
utilizan para capturar los principales “grupos
de responsabilidad” del sistema, de acuerdo a
cada uno de los casos de uso, a través de tres
tipos de clases. Ya en esta etapa empiezan a
configurarse las clases de diseño, en su primera
aproximación, aparecen clases asociadas
a interfaz con el usuario, a ejecución de
transacciones y cálculos y a entidades de datos.
 RESUMEN DEL TEMA
El diagrama de clases de análisis es uno de los diagramas principales de análisis y
diseño para un sistema software. En este diagrama se especifican la estructura y las
relaciones de las clases conceptuales del sistema.
Durante el análisis del sistema, el diagrama se desarrolla buscando una solución ideal.
Durante la fase de diseño, se puede modificar el mismo diagrama para satisfacer los
detalles de la implementación del software.
Las clases de análisis especifican los elementos de un modelo conceptual temprano
para objetos del sistema que tienen responsabilidades y comportamiento. Representan
las clases prototípicas del sistema, y son un primer paso de las abstracciones principales
que el sistema debe manejar. Se pueden mantener durante el diseño, si se desea una
visión general de alto nivel y conceptual del sistema.
Las clases de análisis generan las principales abstracciones del diseño del sistema: las
clases de diseño y los subsistemas del sistema.
Las clases de análisis se utilizan para capturar los principales “grupos de responsabilidad”
del sistema, de acuerdo a cada uno de los casos de uso, a través de tres tipos de clases,
que se describirán posteriormente. Ya en esta etapa empiezan a configurarse las clases
de diseño, en su primera aproximación, aparecen clases asociadas a interfaz con el
usuario, a ejecución de transacciones y cálculos y a entidades de datos.

LA IDEA PRINCIPAL
El diagrama de clases de análisis es uno de los diagramas
principales de análisis y diseño orientado a objetos.
UNIDAD 7 - TEMA 3
ELEMENTOS DE LOS DIAGRAMAS
DE CLASES DE ANÁLISIS
Los diagramas de clases de análisis son un
tipo de diagrama de clases UML, donde se
especifican los grupos de responsabilidad a
través de tres tipos de clases.

Clase Interfaz o de Frontera (Boundary).

Estas clases se utilizan para modelar la Como se observa del ejemplo, la clase interfaz
interacción entre el sistema y los actores. se representa con el siguiente estereotipo.
Generalmente, se asocia con la entrada y la
salida.
Modelan las partes del sistema que dependen
de los actores, lo cual implica que clasifican y
reúnen los requisitos en los límites del sistema
Representan a menudo abstracciones de
ventanas, formularios, paneles, interfaces de Clase Control
comunicaciones, etc. Las clases de control manejan una unidad de
Se utilizan para crear la interfaz, por ejemplo, trabajo desde el inicio hasta el final, es decir,
pantallas interactivas o reportes impresos, que estas clases se pueden diseñar para manejar:
el usuario ve y con la cual interactúa cuando se • La creación o actualización de los objetos de
vaya a utiliza el software. entidad (datos).
Las clases interfaz están diseñadas para • La inmediatez de objetos de interfaz
manejar la forma en que los objetos de entidad conforme éstos obtienen información de
se presentan a los usuarios. Por ejemplo, una objetos de entidad.
Interfaz de Usuario y los Reportes de Estado de • La comunicación compleja entre conjuntos
Cuenta de un cliente de un banco. de objetos.
• La validación de datos comunicados entre
Ejemplo Clase Interfaz. los objetos o entre el usuario y la aplicación.
Teniendo el siguiente Caso de Uso Registrar
Compra.

De ese caso de uso se pueden definir, de

acuerdo a su especificación, dos clases interfaz
que permitan la interacción entre el Encargado
de compras con el sistema.
Las clases control representan coordinación, Clase Entidad.
secuenciado, transacciones y control de otrosLas clases de entidad, también llamadas clases
objetos. de modelo o de negocio, se extraen de manera
Una clase control es un modelo de los cálculos
directa del enunciado del problema descrito en
y algoritmos complejos. Por ejemplo, Clase los casos de uso del sistema.
Calcular Monto de Préstamo, Clase Calcular De manera típica, estas clases representan
Cuotas a Pagar. clases que se almacenarán en una base de
datos y que persisten durante la aplicación.
Ejemplo Clase Control. Una clase entidad es un modelo de la
Siguiendo con el ejemplo del Caso de Uso información perdurable. Por ejemplo: la Clase
Registrar Compra, tenemos la siguiente clase Cuenta es una entidad porque la información
de control. sobre las cuentas tiene que permanecer en el
Sistema Bancario.

Como se observa del ejemplo, la clase interfaz

se representa con el siguiente estereotipo.
Ejemplo Clase Entidad.
Completando el ejemplo del Caso de Uso
Registrar Compra, tenemos la siguiente clase
de entidad.
Del ejemplo se observa que la clase entidad se
representa con el siguiente estereotipo.
 RESUMEN DEL TEMA
Las clases de análisis se utilizan para capturar los principales grupos de responsabilidad
del sistema, de acuerdo a cada uno de los casos de uso, a través de tres tipos de
clases. Ya en esta etapa empiezan a configurarse las clases de diseño, en su primera
aproximación, aparecen las clases asociadas a interfaz con el usuario, a ejecución de
transacciones y cálculos y a entidades de datos, a través de tres tipos de clases: Interfaz,
Control y Entidad.
Las clases de análisis especifican los elementos de un modelo conceptual temprano
para objetos del sistema que tienen responsabilidades y comportamiento. Representan
las clases prototípicas del sistema, y son un primer paso de las abstracciones principales
que el sistema debe manejar
Las clases de análisis generan las principales abstracciones del diseño del sistema: las
clases de diseño y los subsistemas del sistema.

LA IDEA PRINCIPAL
Se capturan los principales grupos de responsabilidad del
sistema, con las clases: Interfaz, Control y Entidad.
UNIDAD 7 - TEMA 4
REALIZACIÓN DE LOS CU EN
CLASES DE ANÁLISIS
¿Qué se debe hacer para desarrollar los • Información referida. La clase potencial será
elementos basados en clases de un modelo útil durante el análisis sólo si la información
de análisis? Se deben identificar las clases de acerca de ella debe recordarse para que el
análisis. sistema pueda funcionar.
Identificación de clases de análisis • Servicios requeridos. La clase potencial
Examinar el enunciado del problema, haciendo debe tener un conjunto de operaciones
un “análisis gramatical”, sobre las narrativas identificables que puedan cambiar el valor
desarrolladas para el sistema que se va a de sus atributos de alguna manera.
construir y/o de los Casos de Uso. • Atributos múltiples. Durante el análisis
Las clases se determinan al reconocer cada de requisitos el enfoque debe estar en la
sustantivo. información “importante”; una clase con
Las clases se manifiestan en una de las un solo atributo puede, de hecho, ser útil
siguientes formas: durante el diseño, pero probablemente es
• Entidades externas: como, otros sistemas, mejor representarla como un atributo de
dispositivos, personas, que producen otra clase durante la actividad de análisis.
o consumen información que usará un Una vez identificadas las clases de acuerdo a
sistema. las formas y consideraciones mencionadas
• Cosas: por ejemplo, reportes, despliegues, anteriormente, las tenemos que clasificar
letras, señales, etc., que son parte del según las tres categorías de clases estudiadas
dominio de la información para el problema. anteriormente:
• Sucesos o eventos: como, una transferencia • Clase Interfaz.
de propiedad, que ocurren dentro del • Clase de Control.
contexto de la operación del sistema. • Clase Entidad.
• Roles: por ejemplo, gerente, ingeniero, Un ejemplo de aplicación de la realización de los
personal de ventas, etc., que desempeñan casos de uso en clases de análisis se describe a
personas que interactúan con el sistema. continuación.
• Unidades organizacionales: como, por Sistema de que permita el manejo de los
ejemplo, división, grupo, gerencia, etc., procesos de ventas de productos de una
relevantes para alguna aplicación. empresa.
• Sitios: como, el piso de manufactura o el Actores.
puerto de carga, etc., que establecen el
contexto del problema y la función global
del sistema.
• Estructuras: por ejemplo, sensores,
vehículos de cuatro ruedas, computadoras,
etc., que definen una clase de objetos o
clases de objetos relacionadas.
Para la selección de clases, que se deben
usar, cuando un analista considera cada
clase potencial, para incluirlas en el modelo
de análisis, se deben tener estas principales
consideraciones:
Casos de Usos agrupados en paquetes.

Veamos solo el diagrama de Casos de Usos de

Gestionar Ventas.

Dentro de estos casos de uso, veamos el

Diagrama de Clase de Análisis del Caso de Uso
Verificar Stock.

Para cada Caso de Uso del Sistema, se tienen

que hacer los respectivos diagramas de clases
de análisis.
Ahora bien, según el paquete (subsistema) en
que se encuentre en CU, se podrán identificar
las relaciones donde se puedan compartir, por
ejemplo, la Clases Entidad, como se observa el
en siguiente diagrama de clases de análisis del
Caso de Uso Entregar Productos, que utiliza la
misma clase entidad Productos.
 RESUMEN DEL TEMA
Para desarrollar los elementos basados en clases de un modelo de análisis, se deben
identificar las clases de análisis. Esto se logra al examinar el enunciado del problema,
haciendo un “análisis gramatical”, sobre las narrativas desarrolladas para el sistema
que se va a construir y/o de los Casos de Uso.
Las clases se determinan al reconocer cada sustantivo, manifestándose en una de las
siguientes formas, como: Entidades externas, cosas, sucesos o eventos, roles, unidades
organizacionales, sitios, estructuras, que definen una clase de objetos o clases de
objetos relacionadas.
Para la selección de clases, que se deben usar, cuando un analista considera cada clase
potencial, para incluirlas en el modelo de análisis, se deben tener estas principales
consideraciones: información referida, servicios requeridos y sus atributos múltiples.
Durante el análisis de requisitos el enfoque debe estar en la información “importante”.
Una vez identificadas las clases de acuerdo a las formas y consideraciones mencionadas
anteriormente, las tenemos que clasificar según las tres categorías de clases de análisis
estudiadas: Interfaz, Control o Entidad.

LA IDEA PRINCIPAL
Identificar las clases importantes de acuerdo a los casos de uso y sus
especificaciones, para categorizarla como clase de análisis.
UNIDAD 7 - TEMA 5
ELABORAR DIAGRAMAS DE CLASES DE
ANÁLISIS – CASO DE ESTUDIO
Caso – Financiera
La financiera de crédito “El truco S.A.”, financia en base al monto aprobado y al número de
la adquisición de vehículos (o refacciones) meses concedidos para pagar, recargando los
exclusivamente a sus asociados. El sueño de intereses y comisiones respectivas, efectuando
los directores de la financiera es ser la primera la adquisición del vehículo (o préstamo para
financiera del Perú. Para ello han planteado una la refacción) previa firma de los documentos
serie de Objetivos como tener una atención legales. El objetivo que se tiene es optimizar
personalizada a los socios, optimizar los procesos de créditos. Tienen una
los procesos de la financiera. meta de dar 20% más de crédito
Para ser socio se debe pagar que el año anterior.
una cuota de inscripción y para Los directivos en las entrevistas
solicitar un financiamiento, se describieron los requisitos
debe haber cotizado como que debería tener el nuevo
mínimo 3 meses, la cuota sistema.
de socio (cuota que se paga R1. El sistema ofrecerá a
solicite o no financiamiento los socios la posibilidad de
para vehículo). consultar vía web el estado
La inscripción como socio de cuenta de los créditos
se tiene que presentar los aprobados, saldos a la fecha
documentos personales del para cancelar. Para ello el socio
nuevo socio como DNI y datos ingresara su código de socio.
generales que son recepcionados por el R2. El encargado de recepción registrará
encargado de inscripción. La meta planteada es en el sistema los datos del nuevo socio.
que el proceso de inscripción demore un 10% R3. El encargado de crédito registrará en el
menos del tiempo actual. sistema la solicitud de adquisición.
A partir del 3er.mes, el socio podrá solicitar R4. Nuestro Sistema deberá ser instalado
el financiamiento para adquirir o refaccionar en nuestro servidor Web que manejará la
un vehículo, presentando una solicitud de seguridad de acceso para los socios y los
adquisición con sus datos y los datos del empleados.
vehículo, tales como costo, marca, modelo, R5. El sistema deberá ser desarrollado en PHP
año de fabricación, etc. Esta información es y como gestor de base de datos MySql.
presentada al encargado de crédito. De igual R6. El encargado de crédito ingresará al
modo debe adjuntar los documentos legales sistema el cronograma de pago por cada
de la compra venta del vehículo, dicha solicitud crédito aprobado.
es aprobada o desaprobada en el comité Se deben realizar las siguientes actividades de
directivo. análisis de requisitos:
Si la solicitud fue aprobada, el área de créditos • Determinar requisitos funcionales y
(apoyados por el área legal) elabora los requisitos no funcionales.
documentos del crédito, evacuando entre otros • Diagrama de Casos de Uso
el cronograma de pagos, el cual está elaborado • Diagramas de Clases de Análisis.
Requisitos Funcionales Diagrama de Casos de Usos del Sistema
CUS:
• CUS01: Registrar socio (Pagar de cuota de
inscripción).
• CUS02: Pagar cuota de socio.
• CUS03: Registrar solicitud de financiamiento.
• CRU04: Aprobar crédito (Registrar
cronograma de pagos)
• CUR05: Consultar estado de cuenta.
Actores:
• Socio
• Encargado de recepción
• Encargado de crédito
Requisitos No Funcionales

Diagrama de Clases de Análisis:

Para cada CUS se identifican sus clases Interfaz,
de Control y Entidad.
 RESUMEN DEL TEMA
Se realiza el análisis de requisitos a un caso de estudio particular, paso a paso se
obtienen los artefactos: modelo de requisitos funcionales y no funcionales, diagrama
de casos de uso del sistema y el diagrama de sus clases de análisis.
Se realiza la asignación de las responsabilidades de los Casos de Uso a las Clases de
Análisis, a través de la elaboración de un Diagrama de Clases de Análisis.

LA IDEA PRINCIPAL
Se asignan las responsabilidades de los Casos de Uso a las Clases de Análisis con
un caso de estudio.
 LECTURAS RECOMENDADAS
• Kendall, Kenneth E. y Kendall, Julie E. Análisis y Diseño de Sistemas. Pearson
Educación, México, 2011.
• https://www.revistaespacios.com/a13v34n01/13340108.html

ACTIVIDADES Y EJERCICIOS
1. Explicar cómo obtienen las clases de análisis que realizan los Casos de Usos, a
las cuales se le asignan las responsabilidades de los CUS.
2. Elaborar los diagramas de clases de análisis de los CUS de un caso de estudio:
sistema de ventas de una pollería.
 INTRODUCCIÓN ACTITUDES
Conforme hemos ido avanzando en el • Tiene habilidades para administrar su
desarrollo de nuestro modelo, se han ido tiempo y organizarse.
incorporando elementos importantes bajo el • Tener la capacidad de pensar y trabajar
paradigma de la orientación a objetos. Derivado independientemente.
de los conceptos identificados en los casos • Realiza aprendizaje de valores.
de uso, hemos encontrado los insumos para
desarrollar el modelo conceptual o modelo TEMAS
de dominio, reconociendo, precisamente,
conceptos claves en el entorno del problema al

1
que buscamos dar una solución.
Tales conceptos iniciales evolucionan en su Modelo de Dominio
modelado bajo un análisis más detallado:
TEMA
se comienzan a identificar posibles clases
conceptuales, las colaboraciones entre ellas
vistas como relaciones, la multiplicidad de
cada relación, las especificaciones de clases,
la identificación de jerarquías de herencia,
la definición de atributos y operaciones. Se
2
TEMA
Cómo realizar un Modelo
de Dominio
incorporan nuevos casos de uso en el análisis
de algunas situaciones del modelo y lo
enriquecemos. Marcamos un hito en nuestro
avance: logramos obtener un modelo de clases
conceptuales consistente, que pueda apoyar
3
TEMA
Identificar las Clases
Conceptuales
los casos de uso.

COMPETENCIA
Realiza el diagrama de clases conceptuales para 4
TEMA
Añadir Atributos de Clases y
Relaciones entre Clases
lograr el diseño lógico estructural del modelo
de dominio del sistema.

CAPACIDADES 5
TEMA
Diagrama de clases de
dominio – Caso de estudio
• Realizar el diseño lógico del modelo de
dominio, basado en las clases de dominio
del sistema, con sus atributos.
UNIDAD 8 - TEMA 1
Modelo de Dominio
EL Modelo de Dominio o Modelo de Negocio Según Larman (2002): “Un modelo de dominio es
está en el dominio del problema, por lo tanto, una representación de las clases conceptuales
es independiente de la solución de software. del mundo real, no de componentes software.
Es el modelo resultante del análisis de los No se trata de un conjunto de diagramas que
requisitos, donde los conceptos se llevan a describen clases software, u objetos software
clases, a las que se le añaden sus atributos, con responsabilidades.”
relaciones de asociación con otras clases y la Recordemos que, en general, nos estamos
multiplicidad de dicha relación. enfrentando a un proceso evolutivo de
Un modelo de dominio muestra las clases definición de software. Los modelos que
conceptuales significativas en un dominio del desarrollemos a través de diagramas UML irán
problema, por lo que se basa en el Diagrama entrando en mayor detalle conforme pasan las
de Clases de Dominio o Clases Conceptuales. iteraciones en las fases del RUP.
En UML se utilizan los diagramas de clases para Según la metodología de desarrollo de software
representar los modelos de dominio. RUP, que hemos trabajado en el curso, el
Su utilidad radica en ser una forma de modelo de diseño, basado en clases, se realiza
“inspiración” para el diseño de los objetos de los casos de uso del sistema, usando
software. Adicionalmente, es la entrada para también las clases de análisis, identificadas en
muchos de los artefactos que se construyen el modelo de análisis, con algún otro artefacto,
en un proceso de desarrollo de software. Es el que también hemos trabajado en este libro,
artefacto clave del análisis y diseño orientado a tal como, el diagrama de secuencia. Esto se
objetos. representa en las siguientes dos figuras.
Un Modelo de Dominio es un artefacto de la
disciplina de análisis, construido con las reglas
de UML durante la fase de concepción, en la
tarea construcción del modelo de dominio,
presentado como uno o más diagramas de
clases y que contiene, no conceptos propios
de un sistema de software sino de la propia
realidad física.
El modelo de dominio puede utilizarse para
capturar y expresar el entendimiento ganado
en un área bajo análisis como paso previo al
diseño de un sistema, ya sea de software o
de otro tipo. Similares a los mapas mentales
utilizados en el aprendizaje, el modelo de
dominio es utilizado por el analista como un
medio para comprender el sector de negocios
al cual el sistema va a servir.
El modelo de dominio puede ser tomado
como el punto de partida para el diseño del
sistema. Esto es así ya que cuando se realiza la
programación orientada a objetos, se supone
que el funcionamiento interno del software
va a imitar en alguna medida a la realidad,
por lo que el mapa de conceptos del modelo
de domino constituye una primera versión del
sistema.
Cuando se sigue una aproximación centrada en
casos de uso, como RUP, el modelo de dominio
usa el modelo de análisis de los casos de uso,
en la identificación de las clases conceptuales.
 RESUMEN DEL TEMA
El Modelo de Dominio es el modelo que resulta del análisis de los requisitos, donde
los Conceptos se llevan a Clases, a las cuales se le añaden sus atributos, relaciones de
asociación con otras clases y la multiplicidad de dicha relación.
Un Modelo de Dominio muestra las clases conceptuales significativas en un dominio
del problema, por lo que se basa en el Diagrama de Clases de Dominio o Clases
Conceptuales. En UML se utilizan los diagramas de clases para representar los modelos
de dominio.
El modelo de dominio puede utilizarse para capturar y expresar el entendimiento
ganado en un área bajo análisis como paso previo al diseño de un sistema, ya sea de
software o de otro tipo. Dicho modelo es utilizado por el analista como un medio para
comprender el sector de negocios al cual el sistema va a servir.
El modelo de dominio puede ser tomado como el punto de partida para el diseño del
sistema. Esto es así ya que cuando se realiza la programación orientada a objetos, se
supone que el funcionamiento interno del software va a imitar en alguna medida a
la realidad, por lo que el mapa de conceptos del modelo de domino constituye una
primera versión del sistema.
Cuando se sigue una aproximación centrada en casos de uso, como RUP, el modelo de
dominio usa el modelo de análisis de los casos de uso, en la identificación de las clases
conceptuales.

LA IDEA PRINCIPAL
Un Modelo de Dominio muestra las clases conceptuales
significativas en un dominio del problema.
UNIDAD 8 - TEMA 2
Cómo realizar un Modelo de Dominio
La esencia del análisis orientado a objetos es 3. Con las clases ubicadas en el diagrama de
la descomposición del problema en conceptos clases, se añaden los atributos de las clases,
individuales. Un modelo de dominio contiene necesarios para satisfacer los requisitos de
principalmente los conceptos y sus relaciones información.
que sean significativos en el dominio del
problema.
Un modelo de dominio tiene como:
Entrada:
• Descripción del problema.
• Casos de Uso.
Salida:
• Un conjunto de diagramas de clases.
A continuación, se presenta una guía básica de 4. Por último, se procede a añadir las
cómo hacer un modelo de Dominio, partiendo asociaciones necesarias para registrar las
del modelo de Casos de Uso y de modelo de relaciones que hay entre clases.
Análisis. En este caso al cliente lo colocamos como
1. Primeramente, hay que identificar las una subclase de la superclase persona, que
clases conceptuales (entidades) candidatas, podemos utilizar también para agrupar al
relacionadas con los requisitos actuales staff del restaurant, quedando por ahora,
en estudio (revisando los escenarios un diagrama de clases de dominio, con las
identificados en los casos de uso y/o las siguientes relaciones.
clases de análisis).
Por ejemplo, en un sistema de organización
de un restaurante, podemos considerar
al cliente y al restaurant como conceptos
importantes (clases conceptuales).
2. Luego, representar las clases en un modelo
de dominio, es decir, comenzar a generar
el diagrama de clases conceptuales que
formaran el modelo de dominio, también
conocido como modelo de negocio o
modelo lógico.
Del ejemplo anterior, se representas estas
clases en el diagrama de clases, como se
muestra en la siguiente figura.
El Modelo de Dominio es importante utilizarlo
como artefacto en un proceso de desarrollo de
software. Ahora describiremos una técnica que
se pueden usar para poderlo elaborar, usando
diagramas de actividad de un caso de uso.
Primero, hay que analizar los procesos de Siguiendo con el diagrama de actividades del
negocio y rescatar las entidades que se usan proceso de “Gestionar apertura de cursos”,
durante el proceso. Los procesos de negocio también nos podemos encontrar con la
se pueden modelar a través de diagramas de actividad “Crear grupo”. Analizando esta
actividad, y las actividades necesitan procesar actividad, podemos deducir que al crear un
datos. Los datos requeridos por las actividades grupo se estará asociando al curso registrado
que están estrechamente relacionados serán anteriormente y asignado posteriormente a un
parte de una entidad o concepto. docente.
Por ejemplo, en el diagrama de actividades Entonces, gracias al análisis del proceso de
de un proceso de “Gestionar apertura de negocio podemos ir elaborando parcialmente
cursos”, de un caso de estudio de un sistema el Modelo de Dominio, por ahora se han
que gestiona el dictado de cursos, existiría la descubierto tres entidades las cuales están
actividad “Registrar curso”, de esta actividad relacionadas o asociadas. La siguiente figura
podemos deducir que se necesitan datos como muestra el Modelo de Dominio Parcial de este
el nombre del curso y probablemente una caso de estudio.
descripción y algunos pre requisitos. En los siguientes temas, se explicarán con
Todos estos datos serán parte de la entidad más detalle, como se llevan a cabo cada uno
Curso, por tanto, se ha podido descubrir el de estos pasos para generar un Modelo
concepto Curso que es parte del dominio de de Dominio, como el que se muestra en la
problema. siguiente figura para un Sistema de Préstamos
en una Biblioteca.
 RESUMEN DEL TEMA
La esencia del análisis orientado a objetos es la descomposición del problema en
conceptos individuales. Un Modelo de Dominio contiene principalmente los conceptos
y sus relaciones que sean significativos en el dominio del problema.
Un modelo de dominio tiene como Entrada; la descripción del problema y los Casos de
Uso, y como Salida; Un conjunto de diagramas de clases.
En este tema se presenta guía básica de cómo hacer un modelo de Dominio, partiendo
del Modelo de Casos de Uso y de Modelo de Análisis, que costa principalmente de los
siguientes 4 pasos:
1. Identificar las clases conceptuales (entidades).
2. Representar las clases en un modelo de dominio.
3. Añadir los atributos de las clases.
4. Añadir las asociaciones necesarias para registrar las relaciones que hay entre clases.
El Modelo de Dominio es importante utilizarlo como artefacto en un proceso de
desarrollo de software. Una técnica que se pueden usar para poderlo elaborar, consiste
en usar los diagramas de actividad de los casos de uso.
Primero, hay que analizar los procesos de negocio y rescatar las entidades que se usan
durante el proceso. Los procesos de negocio se pueden modelar a través de diagramas
de actividad, y las actividades necesitan procesar datos. Los datos requeridos por
las actividades que están estrechamente relacionados serán parte de una entidad o
concepto, que se convertirá en clase conceptual, a la que se le añadirá sus atributos
y se relacionará con otras clases conceptuales, para formar el diagrama de clases de
dominio.

LA IDEA PRINCIPAL
Guía básica de cómo hacer un Modelo de Dominio, partiendo del
Modelo de Casos de Uso y del Modelo de Análisis.
UNIDAD 8 - TEMA 3
Identificar las Clases Conceptuales
La esencia del análisis orientado a objetos es Por eso debemos comenzar a realizar esbozos
la descomposición del problema en conceptos de los conceptos alrededor del dominio del
individuales. problema que queremos modelar.
¿Qué es un concepto? Hay que comenzar la construcción de un
Informalmente: es una idea, una cosa u objeto. Modelo de Dominio haciendo una lista de
Formalmente: puede considerarse en términos conceptos candidatos. Existen dos técnicas
de: para ello:
• Símbolo: palabras o imágenes que • Lista de categorías de conceptos.
representan una clase conceptual. • Identificación de sustantivos.
• Definición del Concepto. Lista de categorías de conceptos.
• Extensión: conjunto de objetos que Consiste en repasar la lista de categorías de
pertenecen a la clase. conceptos, buscando los conceptos del dominio
Por ejemplo: Concepto Venta, descrito del problema que apliquen a cada categoría.
formalmente en la siguiente figura. Entre las principales categorías están las
siguientes:
Categoria de clase Ejemplos
Objetos tangibles o físicos Libro,Revista
especificaciones,diseños o especificacion del
descripciones de las cosas producto(copias de un libro)
lugares Biblioteca central, biblioteca de
sede, biblioteca de salud
transacciones Préstamo,devolucion de un
Un Modelo de Dominio contiene principalmente material
los conceptos y sus relaciones, que sean líneas de transaccion cada copia de material prestado
significativos en el dominio del problema: en una transacción de prestamo

El problema y los requerimientos determinan roles de la gente usuario, bibliotecario

qué es significativo. contenedores de otras cosas estante
Es muy común omitir algunos conceptos en cosas en un contenedor libro
esta fase de identificación, que pueden ser otros sistemas informaticos o sistema financiero
dispositivos externos al sistema
descubiertos en una fase o etapa posterior.
organizaciones biblioteca
Al descubrirlos se los agrega al Modelo de
Dominio. hechos prestamo,devolución, mora por
devolución
Es posible encontrar conceptos interesantes
catalogos catalogo de materiales
que no tengan atributos, que tengan un rol de bibliograficos
comportamiento más que de información. registros de finanzas, trabajos, comprobante de prestamo
Cuando comenzamos a tratar de elaborar contratos, cuestiones legales
un modelo de clases, debemos saber que no instrumentos y servicios restricciones al prestamo de
es una tarea fácil. Quizás si se posee mucha financieros libros, adquisición al por mayor
experiencia, poder intuir y definir clases de un libro

se vuelve un proceso muy natural en un manuales, documentos, libros procedimiento de

mantenimiento del material
desarrollador de software, pero no es simple. bibliotecario
Identificación de sustantivos.
Se identifican los sustantivos de una
descripción textual del problema (visión del
problema y/o casos de uso) y se los considera
como conceptos o atributos candidatos.
No es posible realizar esta actividad en formaUna vez identificamos las clases importantes,
totalmente automática, ya que el lenguaje es decir, las clases conceptuales, las debemos
natural es ambiguo y no todo sustantivo refiere
diagramar según el estereotipo UML.
a un concepto significativo. Pero, aun así, es la
La Clase se representa a través de un rectángulo
más usada. dividido en tres partes.
• Parte Superior: Se coloca el nombre de la
Ejemplo de identificación de sustantivos. clase.
… Un cliente llega a un puesto de venta para • Parte Intermedia: Se colocan los atributos
reservar un pasaje de avión… El empleado hace de la clase.
la reserva en el sistema de aerolínea. • Parte Inferior: Se especifican las
Consideramos los sustantivos en negritas como operaciones. No se identifican en el Modelo
los primeros candidatos para ser conceptos de Dominio

Casos de uso e identificación de clases

conceptuales.
Hemos desarrollado hasta este momento, la
especificación de casos de uso del sistema de
préstamo de libros de una biblioteca. Vamos
a recordar la definición breve de uno de los
casos de uso que fueron identificados como
de mayor riesgo, es decir, que es esencial para
el sistema, como el de Registrar Préstamo. En
dicha definición vamos a subrayar algunas
palabras que pueden referirnos, de acuerdo
con la categorización propuesta, a clases
conceptuales.
Ejemplos:

Observe cómo, en primer lugar, aparecen

roles de personas en el sistema: bibliotecario
y usuario. De igual forma podemos notar
cosas como material bibliográfico que es lo
que se registra en una transacción, como es
el préstamo. Otras transacciones como la
morosidad (las cuales son consultadas), que
pudieron ser registradas en otro momento,
intervienen en los conceptos que estamos
identificando para el proceso. De este ejemplo
nos quedarían identificadas las siguientes
clases conceptuales.
 RESUMEN DEL TEMA
Un Modelo de Dominio contiene principalmente los conceptos y sus relaciones, que
sean significativos en el dominio del problema:
El problema y los requerimientos determinan qué es significativo.
Cuando comenzamos a tratar de elaborar un modelo de clases, debemos saber que
no es una tarea fácil. Quizás si se posee mucha experiencia, poder intuir y definir clases
se vuelve un proceso muy natural en un desarrollador de software, pero no es simple.
Por lo anterior, debemos comenzar a realizar esbozos de los conceptos alrededor del
dominio del problema que queremos modelar.
Hay que comenzar la construcción de un Modelo de Dominio haciendo una lista de
conceptos candidatos. Existen dos técnicas para ello:
• Lista de categorías de conceptos.
• Identificación de sustantivos.

LA IDEA PRINCIPAL
Para elaborar el modelo de dominio, se comienza con esbozos de los
conceptos alrededor del dominio del problema que queremos modelar.
UNIDAD 8 - TEMA 4
Añadir Atributos de Clases y Relaciones
entre Clases
Identificación de Atributos
Los atributos forman la parte estática de la
clase, un atributo representa una característica
de la clase, la cual debe dar una idea clara de la
unidad de información que representa.
Los valores del atributo establecen la diferencia
entre los objetos, por lo que, todo objeto debe
tener un atributo identificador irrepetible.
Un atributo debe nombrarse con un sustantivo
Ejemplos de atributos de clase:
claro y preciso, puede formarse por una o varias
palabras, deben ser escritas de forma continua,
utilizar letra minúscula en su redacción, y si
está compuesto por más de una palabra solo
la primera letra de cada palabra a partir de la
segunda debe escribirse en mayúsculas.
Los elementos que definen al atributo son:
Nombre, tipo de dato, valor inicial y
visibilidad
Su sintaxis es la siguiente:
Visibilidad nombre: tipodato = valorInicial Relaciones entre Clases
La visibilidad permite diferentes formas de Una asociación es una relación entre las
acceso a miembros de una clase: clases, que indica una conexión significativa
+ Público e interesante, se deben identificar las frases
# Protegido que relacionen los sustantivos (Clases), estas
- Privado relaciones se deben ir agregando al modelo.
Los atributos deben ser lo más simple posible. La asociación es inherentemente bidireccional y
Los atributos no primitivos deben ser es convencional leer la asociación de izquierda
representados como clases. Un atributo es no a derecha o de arriba hacia abajo.
primitivo si está conformado por secciones La asociación es una relación que indica algún
separadas, o por atributos internos o es una vínculo o conexión significativa entre dos
abstracción de uno o más tipos con las mismas clases, modelan la forma en que se relacionan
características. los objetos de las clases. Se representa a través
Por ejemplo: el atributo Dirección, podría ser de una línea continua entre clases, con un
atributo no primitivo porque puede dividirse en nombre, ver ejemplo siguiente.
Calle, Nro, Mzna, pero depende del significado
del concepto en el contexto en el que se
utilizará.
El atributo Distrito en el siguiente ejemplo,
tambien podría definirse como no primtivo o
compuesto, ya que puede dividerse en nombre
del distrito, código distrito, código postal.
Este último ejemplo se lee: El cliente emite
órdenes de compra.
Las relaciones contienen también una Composición
información de multiplicidad (cardinalidad) que Es una asociación con la semántica “compuesto
precisa el número de instancias que participan por/es componente de”, contiene un atributo
en la relación. Se debe incluir la multiplicidad que siempre será una colección.
entre las distintas asociaciones. La multiplicidad El ciclo de vida de un objeto B que es
indica cuántos atributos de una clase estarán en componente de un Objeto A, si depende de A.
otra, Se representa a través de una numeración Si A desaparece, B ya no tiene sentido de existir.
y se coloca en cada extremo de la asociación.
Veamos el siguiente ejemplo.

Generalización y Especialización
Los diferentes tipos de multiplicidad se
muestran en el siguiente cuadro. Ve La generalización identifica una relación de
herencia entre dos clases, es la relación de tipo
“A es un tipo de B”.

Los tipos de asociación más comunes son:

• Agregación
• Composición
• Generalización o Herencia.

Agregación
Es una asociación con la semántica “formado
por/forma parte de”, que contiene un atributo
que siempre será una colección.
El ciclo de vida de un objeto B que forma
parte de un Objeto A, no depende de A. Si A
desaparece, B puede seguir existiendo.
Una clase es más específica que otra si todas
las instancias que la componen son a su
vez instancias de la otra clase. La clase más
especifica es una subclase de la otra clase.
Esta última, más general, recibe el nombre de
superclase.
La siguiente figura muestra ambas clases
así como la relación de generalización/
especialización que las une.

Ejemplo
El caballo es una especialización del équido,
que a su vez es una especialización del animal.
La zebra es otra especialización del équido.
El resultado es la jerarquía presentada en la
siguiente figura
 RESUMEN DEL TEMA
Los atributos forman la parte estática de la clase, un atributo representa una
característica de la clase, la cual debe dar una idea clara de la unidad de información
que representa.
Los valores del atributo establecen la diferencia entre los objetos, por lo que, todo
objeto debe tener un atributo identificador irrepetible.
Una asociación es una relación entre las clases, que indica una conexión significativa e
interesante, se deben identificar las frases que relacionen los sustantivos (Clases), estas
relaciones se deben ir agregando al modelo.
Tanto los atributos de las clases conceptuales, como las asociaciones entre ellas, se
agregan al diagrama de clases para formar el Modelo de Dominio o Modelo Lógico.

LA IDEA PRINCIPAL
Los atributos de las clases conceptuales y las asociaciones entre ellas, se
agregan al diagrama de clases para formar el Modelo de Dominio.
UNIDAD 8 - TEMA 5
Diagrama de clases de dominio –
Caso de estudio
Caso de estudio: Sistema de Gestión de Logística de una Empresa
Uno de los Casos de Uso típico, de un
sistema como este, es Registrar Compras, ya
desarrollado en su modelo de clases de análisis
en el Tema 3 de la Unidad de Aprendizaje
anterior.
A este Caso de Uso se le deben agregar otros
Casos de Uso, para Registrar Proveedores
y Registrar Productos, que en conjunto
Luego, identificamos los atributos de las clases
generarían un diagrama de Clases de Análisis
Entidad, como se muestra a continuación.
como el que se muestra a continuación.

Para, por último, identificar las relaciones entre

las clases Entidad, asignándoles nombres a
las relaciones de asociación y su multiplicidad,
logrando así, el Modelo de Clases Conceptuales
Se procede a identificar las clases Entidad del
o Modelo Lógico, tal como se muestra en la
Dominio, para ello nos guiamos con el diagrama
siguiente figura.
de clases de análisis de la figura anterior.

Ahora se muestran estas clases entidad en un

diagrama de dominio de clases conceptuales,
sin relaciones, como se muestra a continuación.
 RESUMEN DEL TEMA
Siguiendo los pasos explicados previamente como la guía para generar el Modelo
de Dominio, se generó dicho modelo para algunos Casos de Usos de un Sistema de
Logística de una Empresa cualquiera.
Uno de los Casos de Uso típico, de un sistema como este, es Registrar Compras,
ya desarrollado en su modelo de clases de análisis en el Tema 3 de la Unidad de
Aprendizaje anterior.
A este Caso de Uso se le deben agregar otros Casos de Uso, para Registrar Proveedores
y Registrar Productos, que en conjunto generarían un diagrama de Clases de Análisis.
Luego se procede a identificar las clases Entidad del Dominio, para ello nos guiamos
con el diagrama de clases de análisis.
Ahora se muestran estas clases entidad en un diagrama de dominio de clases
conceptuales, sin relaciones.
Luego, identificamos los atributos de las clases Entidad.
Para, por último, identificar las relaciones entre las clases Entidad, asignándoles
nombres a las relaciones de asociación y su multiplicidad, logrando así, el Modelo de
Clases Conceptuales o Modelo Lógico.

LA IDEA PRINCIPAL
Se realiza el Modelo de Dominio, una vez identificadas las
clases conceptuales, sus atributos y relaciones.
 LECTURAS RECOMENDADAS
• Kendall, Kenneth E. y Kendall, Julie E. Análisis y Diseño de Sistemas. Pearson
Educación, México, 2011
• Paul Kimmel Manual de UML, Guía de Aprendizaje
• https://www.ediciones-eni.com/open/mediabook.
aspx?idR=704eaebf396f2da980a440d503309722

ACTIVIDADES Y EJERCICIOS
1. Identificar, a partir de los casos de uso, conceptos claves para la identificación y
desarrollo de clases conceptuales.
2. Indicar cómo se relacionan las clases entre ellas, identificando un nombre para
la relación y su multiplicidad.
3. Realizar el modelo conceptual de clases, a partir del análisis de un caso de
estudio: sistema de ventas de una pollería.
 INTRODUCCIÓN CAPACIDADES
El objetivo del Modelo de Diseño Dinámico • Realizar el diseño del sistema a través
es presentar o describir el comportamiento del modelo dinámico que describe el
del sistema a través del tiempo. Dentro de los comportamiento del sistema.
elementos principales del modelo Dinámico • Realizar diagramas de secuencia y
está la Vista de Interacción, que la conforman comunicación.
los Diagramas de Secuencia y los Diagramas
de Comunicación (antes Colaboración), que TEMAS
estaremos describiendo en esta Unidad de
Aprendizaje.
1 diseño dinámico del Sistema
– Vista de Interacción
COMPETENCIA TEMA

Realiza los diagramas de secuencia y de

comunicación, como componentes de la vista 2
TEMA
Diagramas de secuencia
de interacción, para lograr el diseño dinámico
del comportamiento del sistema.
3 Diagramas de secuencia –
Casos de estudio
ACTITUDES TEMA

•
•
Trabaja con metas bien definidas.
Tiene habilidades para administrar su
4
TEMA
Diagramas de comunicación

tiempo y organizarse.
• Tiene una perspectiva positiva hacia el
aprendizaje. 5
TEMA
Diagramas de comunicación
– Casos de estudio
UNIDAD 9 - TEMA 1
Diseño dinámico del Sistema –
Vista de Interacción
El objetivo del modelo dinámico es presentar Vista de Interacción
o describir el comportamiento del sistema a El objetivo de esta vista es describir el
través del tiempo. comportamiento dinámico del sistema
Los elementos principales del modelo Dinámico mediante el paso de mensajes entre los objetos
son: del mismo. Además, representa un medio para
verificar la coherencia del sistema mediante la
Vista de Interacción validación con el modelo de clases.
• Diagramas de Secuencia. Un diagrama de interacción describe en detalle
• Diagramas de Comunicación (antes un determinado escenario de un caso de uso.
Colaboración). En él se muestra la interacción entre el conjunto
de objetos que cooperan en la realización
de dicho escenario. Suele ser conveniente
Modelo de Máquina de Estados. especificar en la parte izquierda del diagrama
• Diagrama de Estados. el caso de uso que se está́ representando para
que resulte más sencilla su validación.
Vista de Actividades Los elementos que componen los diagramas
• Diagrama de Actividades. de interacción son los objetos y los mensajes:
La vista de Interacción la estaremos tratando Un objeto es una entidad que tiene un estado,
en esta Unidad de Aprendizaje y El Modelo un comportamiento e identidad. La estructura
de Máquina de Estado lo trataremos en la y el comportamiento común de diferentes
siguiente Unidad de Aprendizaje. objetos se recoge en una clase. En un diagrama
de interacción, los objetos serán al final
instancias de una determinada clase o de un
actor.
Un mensaje es una comunicación entre dos
objetos. El envío de un mensaje por parte de
un objeto (emisor) a otro (receptor), puede
provocar que se ejecute una operación, se
produzca un evento o se cree o destruya un
objeto.
Las interacciones entre las instancias de los
objetos en tiempo de ejecución.
Interacción: es la unidad de comportamiento
que se centra en el intercambio de información
observable entre elementos que pueden
conectarse.
En los diagramas de interacción los objetos
interactúan para realizar colectivamente
los servicios ofrecidos por las aplicaciones,
mostrando cómo se comunican los objetos en
una interacción.
Existen dos tipos de diagramas de interacción:
El Diagrama de Secuencia y el Diagrama de Comunicación

• El Diagrama de Secuencia es más • El Diagrama de Comunicación ofrece una

adecuados para observar la perspectiva mejor visión espacial mostrando los enlaces
cronológica de las interacciones. de comunicación entre objetos.
Los diagramas de secuencia se usan para Esta vista describe las interacciones entre
mostrar la interacción entre los usuarios, clases/objetos que componen el sistema,
las pantallas y las instancias de los objetos modeladas como intercambios de mensajes,
en el sistema. Proveen un mapa secuencial para cumplir algún comportamiento
del paso de los mensajes entre los objetos deseado. Estos mensajes se intercambian a
a lo largo del tiempo. Frecuentemente, través de enlaces.
estos diagramas se ubican bajo los casos de Un mensaje se define como una
uso o los componentes en el modelo para comunicación unidireccional entre
ilustrar un escenario, un conjunto de pasos objetos, adicionalmente puede contener
comunes que se siguen en respuesta a un parámetros.
evento externo y que genera un resultado. Una comunicación se define como una
El modelo incluye qué inicia la actividad en colección de objetos que interactúan entre
el sistema, qué procesamiento y cambios ellos para representar un comportamiento
ocurren internamente y qué salidas se en un determinado contexto.
generan
 RESUMEN DEL TEMA
El objetivo del modelo Dinámico es presentar o describir el comportamiento del
sistema a través del tiempo. Lo conforman varios elementos, pero en esta Unidad de
Aprendizaje nos focalizaremos en la Vista de Interacción.
En los diagramas de interacción los objetos interactúan para realizar colectivamente
los servicios o funciones ofrecidas por las aplicaciones, descritos en los Casos de Uso,
mostrando cómo se comunican los objetos en una interacción.
Existen dos tipos de diagramas de interacción: el Diagrama de Secuencia y el Diagrama
de Comunicación
El Diagrama de Secuencia es más adecuados para observar la perspectiva cronológica
de las interacciones.
El Diagrama de Comunicación ofrece una mejor visión espacial mostrando los enlaces
de comunicación entre objetos.

LA IDEA PRINCIPAL
Los objetos interactúan para realizar colectivamente las
funciones ofrecidas por las aplicaciones.
UNIDAD 9 - TEMA 2
DIAGRAMAS DE SECUENCIA
Los diagramas de secuencia muestran la Cuando el objeto/actor se encuentra activo
interacción entre los objetos centrándose en la se representa un rectángulo sobre la línea de
secuencia de mensajes que envían y reciben tiempo, tan grande como tiempo se encuentre
Un diagrama de secuencia se representa con activo.
un gráfico en dos dimensiones, el elemento Los cuadros de activación representan el
fundamental es una línea vertical que tiempo que un objeto necesita para completar
representa el eje del tiempo. En la dimensión una tarea.
horizontal se presentan los distintos roles de
actor u objetos presentes, cada uno de estos
tiene una línea que representa su línea de vida
representada por una línea punteada.
El diagrama de secuencia describe la interacción
de objetos que requiere la funcionalidad de los
distintos escenarios de un Caso de Uso.
Los objetos son representados con su ciclo de
vida dentro de una serie temporal.

Las líneas de vida son verticales y en línea de

puntos, ellas indican la presencia del objeto
durante el tiempo.

Cada posible escenario de un Caso de Uso

puede representarse con un diagrama de
secuencia.
Veamos a continuación los elementos normas
que se deben seguir para construir un diagrama
de secuencia.

Elementos y normas para generar un

diagrama de secuencia
El tiempo se representa para un actor u objeto
mediante un eje vertical.

El paso de mensajes se indica con una línea

horizontal entre los objetos, además de la
descripción del mensaje.
Los mensajes pueden ser: Destrucción de Objetos: Los objetos pueden
• Síncronos. El emisor del mensaje espera ser eliminados tempranamente usando una
respuesta. flecha etiquetada “<>” que apunta a una X.
• Asíncronos. El emisor del mensaje no espera
respuesta.
• Automensaje. El emisor se manda un
mensaje a sí mismo.
Los mensajes se representan mediante una
flecha continua, mientras que los mensajes de
retorno, la flecha es discontinua.
Se puede indicar un número que identifique el
orden de ejecución del mensaje.
El mensaje puede ser escrito en lenguaje
humano o a nivel técnico.

Loops: Una repetición o loop en un diagrama

de secuencias, es representado como un
rectángulo. La condición para abandonar
el loop se coloca en la parte inferior entre
corchetes [ ].
 RESUMEN DEL TEMA
El diagrama de secuencia es uno de los dos diagramas que permiten modelar de
manera dinámica el diseño del sistema.
Los diagramas de secuencia muestran la interacción entre los objetos centrándose en
la secuencia de mensajes que envían y reciben
Un diagrama de secuencia se representa con un gráfico en dos dimensiones, el
elemento fundamental es una línea vertical que representa el eje del tiempo. En la
dimensión horizontal se presentan los distintos roles de actor u objetos presentes,
cada uno de estos tiene una línea que representa su línea de vida representada por
una línea punteada.
El diagrama de secuencia describe la interacción de objetos que requiere la funcionalidad
de los distintos escenarios de un Caso de Uso. Los objetos son representados con su
ciclo de vida dentro de una serie temporal.
Los elementos y las normas que se deben seguir para construir un diagrama de
secuencia se explican en este tema.

LA IDEA PRINCIPAL
El diagrama de secuencia permite modelar de manera
dinámica el diseño del sistema.
UNIDAD 9 - TEMA 3
DIAGRAMAS DE SECUENCIA –
CASOS DE ESTUDIO
Ya en la Unidad de Aprendizaje 6 tratamos También se observa como el mensaje
el tema de los diagramas de secuencia en getEspecificación (id) que se convierte en
etapa de análisis de requisitos con los Casos el método getEspecificacion de la clase
de Uso del Sistema, es bueno aclarar que en CatalogoDeProductos en el modelo de clases
esta etapa de diseño, que estamos tratando, de diseño.
ya con las clases conceptuales identificadas, La asignación de estas responsibilidades en
donde pueden surgir nuevas clases, se vuelven sus respectivas clases se puede hacer por
a realizar los diagramas de secuencia de las experiencia o usando patrones de diseño para
clases de diseño, tal como se muestra en la la asignación de responsabilidades.
siguiente figura.

Ejemplos de aplicación
Un administrador de recursos usa el sistema
para asignar una habilidad a un recurso, y
Diagramas de secuencia en el modelo de cómo las clases del sistema trabajan juntos
diseño para proveer esta funcionalidad:
Un aspecto importante de utilizar diagramas 1. Los objetos al tope de la figura representan
de secuencia en la etapa de diseño, una vez se roles de clases; ellas se denominan así
ha obtenido el modelo de clases de dominio, es porque representan los objetos que
que, a través de los mensajes de los diagramas participan en la interacción
de secuencia, realizados en esta etapa de 2. Las líneas punteadas que se extienden
diseño, se pueden definir los métodos de las desde cada objeto representan líneas de
clases, asignandole así su comportamiento, vida, y los rectángulos ubicados sobre las
y por lo tanto, conviertiendolas en clase líneas de vida representan activaciones
de diseño. En otras palabras, las clases 3. Las flechas horizontales entre líneas de vida
descubiertas durante las realizaciones de los indican los mensajes intercambiados entre
casos de uso se pueden agrupar en el diagrama objetos, y son rotulados con el mensaje que
de clases de diseño, con sus responsabilidades es enviado entre los roles de clases.
o comportamientos (métodos). 4. Un mensaje dispara una operación en el
Lo anterior se puede observar en la figura objeto receptor.
mostrada anteriormente, donde, por ejemplo, 5. Un administrador de recursos usará la
el mensaje de creación del objeto Venta ventana del administrador de recursos,
enviado o llamado desde el objeto Registro, la cual es una interfaz para encontrar un
define el método crearNuevaVenta en la clase recurso, encontrar una habilidad y asignar
de diseño Registro. la habilidad al recurso
6. Dicha ventana encontrará un recurso que Ejemplo del diagrama de secuencia de una
usa un objeto de la clase Recurso, y una llamada telefónica
habilidad que usa un objeto de la clase
Habilidad
7. La ventana asignará una habilidad a un
recurso si la habilidad no está ya asignada
al recurso
8. Esta condición se representa entre
corchetes sobre el mensaje que origina
desde la línea de vida de la ventana al rol de
la clase Recurso-Habilidad
Con las especificaciones anteriores se elabora
el caso de uso Asignar Habilidad a Recurso.

A continuación, se muestra el diagrama de

secuencia sobre el proceso de completar un
pedido y pagar.
 RESUMEN DEL TEMA
Los diagramas de secuencia se utilizan en la etapa de análisis de requisitos con los
Casos de Uso del Sistema, es bueno aclarar que, en esta etapa de diseño, que estamos
tratando en esta Unidad de Aprendizaje, ya con las clases conceptuales identificadas,
donde pueden surgir nuevas clases, se vuelven a realizar los diagramas de secuencia
de las clases de diseño.

LA IDEA PRINCIPAL
Los diagramas de secuencia se usan tanto en la etapa de análisis
de requisitos con en la etapa de diseño.
UNIDAD 9 - TEMA 4
DIAGRAMAS DE COMUNICACIÓN
Los diagramas de comunicación se centran En los diagramas de comunicación, los objetos
en las interacciones y en los enlaces entre los se muestran con conectores de asociación
objetos que colaboran. entre ellos. Los mensajes se agregan a las
Sólo se representa el rectángulo de la línea asociaciones y se muestran como flechas
de vida y los mensajes se colocan cerca de los cortas apuntando en la dirección del flujo del
enlaces. Se representan con una flecha y una mensaje. La secuencia de los mensajes se
etiqueta que contiene el nombre del mensaje y muestra a través de un esquema enumerado.
otra información adicional. Los siguientes diagramas muestran un
Un diagrama de comunicación es una forma de diagrama de comunicación y el diagrama de
representar interacción entre objetos, alterna secuencia que muestran la misma información.
al diagrama de secuencia, se centra en una A pesar de que es posible derivar la secuencia
representación espacial de los objetos. de mensajes en el diagrama de comunicación
Los objetos intervienen en el diagrama de la desde el esquema enumerado, no es
misma forma que lo hacían en el diagrama de inmediatamente visible.
secuencia. Este está unido gráficamente a los Lo que el diagrama de comunicación realiza es
objetos con los que interactúa. mostrar claramente el conjunto completo de
El marco en el que aparece el objeto se mensajes pasados entre objetos adyacentes.
denomina también línea de vida, como en el
diagrama de secuencia.
Los envíos de mensajes se sitúan a lo largo de
los vínculos entre objetos. Los mensajes deben
numerarse obligatoriamente, tal como se
muestra en la siguiente figura.

También es posible transmitir información

(parámetros y devolver mensajes) durante el
envío de la misma manera que en los diagramas
de secuencia.
Un diagrama de comunicación, inicialmente
llamado un diagrama de colaboración, es
un diagrama de interacción que muestra
información similar a los diagramas de
secuencia, pero su foco principal es en la
relación de objetos.
 RESUMEN DEL TEMA
Los diagramas de comunicación se centran en las interacciones y en los enlaces entre
los objetos que colaboran.
Sólo se representa el rectángulo de la línea de vida y los mensajes se colocan cerca de
los enlaces. Se representan con una flecha y una etiqueta que contiene el nombre del
mensaje y otra información adicional.
Un diagrama de comunicación es una forma de representar interacción entre objetos,
alterna al diagrama de secuencia, se centra en una representación espacial de los
objetos.
Los objetos intervienen en el diagrama de la misma forma que lo hacían en el diagrama
de secuencia. Este está unido gráficamente a los objetos con los que interactúa.
El marco en el que aparece el objeto se denomina también línea de vida, como en el
diagrama de secuencia.
Los envíos de mensajes se sitúan a lo largo de los vínculos entre objetos. Los mensajes
deben numerarse obligatoriamente.
En los diagramas de comunicación, los objetos se muestran con conectores de
asociación entre ellos.
Los mensajes se agregan a las asociaciones y se muestran como flechas cortas
apuntando en la dirección del flujo del mensaje.
La secuencia de los mensajes se muestra a través de un esquema enumerado.

LA IDEA PRINCIPAL
En un diagrama de comunicación el foco principal es la
relación de objetos.
UNIDAD 9 - TEMA 5
DIAGRAMAS DE COMUNICACIÓN –
CASOS DE ESTUDIO
Sistema de Ventas

Los diagramas de comunicación se pueden Ejemplo del Caso de Uso Sacar Dinero de un
realizar sobre las clases de análisis, por cajero automático.
ejemplo, en este caso de gestión de facturas en
un sistema de ventas.

Del mismo sistema se puede generar el

diagrama de comunicación de flujo básico del
Actor Vendedor para Consultar Stock.
 RESUMEN DEL TEMA
Se muestran varios ejemplos de aplicación de los diagramas de comunicación dentro
del modelado de interacciones entre objetos, herramienta muy útil dentro del diseño
del comportamiento dinámico de un sistema.

LA IDEA PRINCIPAL
Un diagrama de comunicación es una forma de representar
interacción entre objetos, centrado en su representación
espacial.
 LECTURAS RECOMENDADAS
• http://www.omg.org/technology/uml/
• http://www.omg.org/technology/documents/formal

ACTIVIDADES Y EJERCICIOS
• Realizar el diagrama de secuencia de clases/objetos de un caso de estudio.
• Realizar el diagrama de comunicación de clases/objetos de un caso de estudio:
sistema de ventas de una pollería.
 INTRODUCCIÓN ACTITUDES
Un diagrama de estado (también llamado • Ser un líder nato
diagrama de transición de estados o diagrama • Solucionadores de problemas.
de máquina de estados) muestra los estados • Realiza el aprendizaje de valores.
por los que pasa una máquina de estados • Ser un jugador en equipo
finitos, es decir, un modelo de comportamiento
que consiste en acciones y estados o
transiciones a otros estados. TEMAS
El diagrama proporciona un estado inicial y uno

1
final, así como al menos un estado intermedio
para cada objeto. diagrama de máquina de
Los diagramas de estados muestran el conjunto TEMA estado
de estados por los que pasa un objeto durante
su ciclo de vida, cuando se presentan diversos
eventos.

COMPETENCIA
2
TEMA
Elementos de diagramas de
máquina de estado
Realiza el modelo de máquina de estado
para conformar el diseño dinámico del
comportamiento del sistema.

CAPACIDADES
3
TEMA
Utilidad de los diagramas
de máquina de estado
• Identificar, a partir de los casos de uso,

•
elementos necesarios para hacer modelado
de estado de objetos.
Realizar e interpretar diagramas de máquina
4
TEMA
Diagramas de máquina de
estado – Casos de estudio
de estado en la etapa de diseño.
UNIDAD 10 - TEMA 1
diagrama de máquina de estado
Un diagrama de estado muestra los estados por paquete, el adeudo, el semáforo o el préstamo.
los que pasa una máquina de estados finitos, Es decir, se desarrolla un diagrama de estados
es decir, un modelo de comportamiento que por cada objeto a analizar. Claro que no todos
consiste en acciones y estados o transiciones a los objetos que identificamos merecen ser
otros estados. analizados tan a fondo como para crearles
El diagrama proporciona un estado inicial y uno uno de estos diagramas. Recuerda que no
final, así como al menos un estado intermedio queremos tener proyectos llenos de artefactos
para cada objeto. El diagrama de estado que no aportan valor, así que hay que ser muy
permite, de este modo, representar selectivos.
el ciclo de vida completo de No porque el objeto pueda
cualquier sistema, subsistema tener ocho posibles estados
o componentes o clases del significa que puede pasar
mismo, como podrían ser a cualquiera de ellos en
un lector de códigos, una cualquier momento.
factura de una venta o un Uno de los valores que
componente tecnológico ofrece este diagrama
de un avión. es precisamente que
No todos los proyectos establece las reglas para
requieren utilizar todos que el objeto, estando en
los artefactos de UML. un estado determinado,
Uno de los artefactos pueda pasar a otro. Por
que no veremos en todos ejemplo, si el semáforo está
los proyectos, es el diagrama en verde no debe de poder pasar
de estados. Sin embargo, esto no a rojo, sino únicamente a amarillo.
le resta importancia. En proyectos donde el Estos cambios y restricciones se muestran
comportamiento del sistema depende en con una flecha, que es el símbolo para las
gran medida del estado en que se encuentran transiciones entre estados.
los objetos de negocio, los diagramas de Si queremos indicar la causa por la cual se
estado son indispensables. Los diagramas de puede dar una transición de un estado a
estado permiten visualizar los estados de un otro, lo podemos indicar con un evento, con
objeto —ya sea éste un documento, producto una condición o con ambos. Un evento es
o persona—, los eventos ante los cuales algo que ocurre en el ambiente que afecta
reacciona y los efectos o acciones que realiza el comportamiento del objeto analizado
al cambiar de estado o mientras se encuentra ocasionando que cambie a un nuevo estado.
en un estado. Si una computadora está apagada y se oprime
Lo que convierte a estos diagramas en algo el botón de “Encendido”, la computadora pasa
especial y que lo liga con el paradigma de a un estado de “Arrancando”. Pulsar el botón
orientación a objetos, es que, en lugar de de encendido es el evento que ocasionó este
centrarse en un proceso completo, mostrando cambio. La mayoría de las veces vamos a
los diversos objetos que colaboran, este encontrar a estos elementos como verbos,
diagrama se centra únicamente en lo que pues es algo que ocurre y que afecta el
afecta a un objeto específico; por ejemplo, el comportamiento del objeto.
Un evento es una posible causa de que un La puerta puede estar en uno de los siguientes
objeto pase de un estado a otro, pero otra tres estados: “Opened”(Abierta), “Closed”
posible causa se debe al cumplimiento de (Cerrada) o “Locked”(Cerrada con llave), luego
una condición que afecta al objeto analizado. de su estado inicial.
Puede ser el hecho de que los atributos del Puede responder a cinco eventos: Crear
objeto analizado tomen cierto valor, o que (Create), Abrir (Open), Cerrar (Close), Cerrar con
haya pasado un lapso de tiempo. Ejemplo, si el llave (Lock) y No Cerrar con llave (Unlcak).
monto acumulado en la máquina dispensadora Tener en cuenta que no todos los eventos son
es igual al precio del producto deseado, válidos en todos los estados: por ejemplo, si
entonces pasa a un nuevo estado donde una puerta está abierta, no lo puede bloquear
permite seleccionar el producto a despachar. hasta que lo cierre.
La comparación del monto acumulado en un También tener en cuenta de que como una
momento en la máquina, contra el precio del transición de estado puede tener una condición
producto deseado puede considerarse como de guarda adjunta. Si la puerta está abierta,
una condición de guardia. Estas condiciones se esta solo puede responder al Evento cerrar si
muestran entre corchetes como expresiones la condición doorWay->isEmpty está completa.
booleanas junto a las transiciones. La sintaxis y las conexiones usadas en los
Hay causas, pero también consecuencias de los diagramas de máquina de estados se discutirán
cambios de estado, así como hay situaciones por completo en el siguiente tema.
que provocan el cambio de estado de un objeto,
también hay situaciones que se dan como
resultado de un cambio de estado. A estos
efectos se les llama acciones. Aunque tanto las
acciones como los eventos se muestran como
verbos, las acciones son consecuencia del
cambio y los eventos son causas del cambio.
En cualquier momento, un objeto se encuentra
en un estado particular, la luz está encendida o
apagada, el auto en movimiento o detenido, la
persona leyendo o cantando, etc. El diagrama
de máquina de estados UML captura esa
pequeña realidad.
Un diagrama de máquina de estado modela
el comportamiento de un solo objeto,
especificando la secuencia de eventos que un
objeto atraviesa durante su tiempo de vida en
respuesta a los eventos
Como ejemplo, el siguiente diagrama de
máquina de estado muestra los estados que
una puerta atraviesa durante su ciclo de vida.
 RESUMEN DEL TEMA
Un modelo de comportamiento que consiste en acciones y estados o transiciones a
otros estados.
El diagrama proporciona un estado inicial y uno final, así como al menos un estado
intermedio para cada objeto. El diagrama de estado permite, de este modo, representar
el ciclo de vida completo de cualquier sistema, subsistema o componentes o clases del
mismo.
No todos los proyectos requieren utilizar todos los artefactos de UML. Uno de los
artefactos que no veremos en todos los proyectos, es el diagrama de estados. Sin
embargo, esto no le resta importancia. En proyectos donde el comportamiento
del sistema depende en gran medida del estado en que se encuentran los objetos
de negocio, los diagramas de estado son indispensables. Los diagramas de estado
permiten visualizar los estados de un objeto —ya sea éste un documento, producto o
persona—, los eventos ante los cuales reacciona y los efectos o acciones que realiza al
cambiar de estado o mientras se encuentra en un estado.
Lo que convierte a estos diagramas en algo especial y que lo liga con el paradigma
de orientación a objetos, es que, en lugar de centrarse en un proceso completo,
mostrando los diversos objetos que colaboran, este diagrama se centra únicamente
en lo que afecta a un objeto específico; por ejemplo, el paquete, el adeudo, el semáforo
o el préstamo.
Es decir, se desarrolla un diagrama de estados por cada objeto a analizar. Claro que
no todos los objetos que identificamos merecen ser analizados tan a fondo como para
crearles uno de estos diagramas. Recuerda que no queremos tener proyectos llenos de
artefactos que no aportan valor, así que hay que ser muy selectivos.

LA IDEA PRINCIPAL
Un diagrama de estado muestra los estados por los que pasa una máquina de estados
finito.
UNIDAD 10 - TEMA 2
Elementos de diagramas
de máquina de estado
Estados “Trigger” (Disparador) es la causa de la
Un estado se denota por un rectángulo con transición, la cual podría ser una señal, un
las esquinas redondeadas y con el nombre del evento, un cambio en alguna condición, o el
estado escrito dentro del mismo. pasaje de tiempo.
“Guard” (guarda) es una condición que debe
ser verdadera para que el disparador cause la
transición.
“Effect” (efecto) es una acción que se llamará
directamente en el objeto que tiene la máquina
de estado como resultado de la transición.

Estados Inicial y Final Acciones de Estado

El estado inicial se denota con un círculo negro En el ejemplo de transición, un efecto se asoció
y se le puede proporcionar un nombre. con la transición. Si el estado de destino tenía
El estado final se denota con un círculo con un muchas transiciones llegando al mismo, y cada
punto negro en el medio y también se lo puede transición tenía el mismo efecto asociado con
nombrar. este, sería mejor asociar el efecto con el estado
de destino en lugar de con las transiciones. Esto
se puede realizar para definir una acción de
entrada para el estado. El siguiente diagrama
muestra un estado con una acción de entrada
y una acción de salida.

Transiciones También es posible definir las acciones que

Las transiciones desde un estado al siguiente se ocurren en los eventos, o acciones que siempre
denotan por líneas con flechas. Una transición ocurren. Es posible definir cualquier número de
puede tener un disparador, una guarda y un acciones de cada tipo.
efecto, como a continuación.
 Transiciones recursivas Punto de Entrada
Un estado puede tener una transición que Algunas veces no deseará ingresar una sub
retorna a sí misma, como en el siguiente máquina en un Estado Inicial normal. Por
diagrama. Esto es más útil cuando un efecto se ejemplo, en la siguiente sub máquina sería
asocia con la transición. normal comenzar en el estado inicial, pero si
por alguna razón no fuera necesario realizar
la inicialización, sería posible comenzar en
el estado Ready realizando una transición al
punto de entrada nombrado.

Estados Compuestos
Un diagrama de máquina de estado puede
incluir diagramas de sub maquinas, como en el
siguiente ejemplo.

El siguiente diagrama muestra la máquina de

estado un nivel hacia arriba:

La forma alternativa de mostrar la misma

información es como el siguiente ejemplo.

Punto de Salida
Similar al Punto de Entada, es posible nombrar
Puntos de Salida. El siguiente diagrama provee
un ejemplo donde el estado ejecutado después
del estado de procesos principal depende de
que ruta se use para realizar la transición del
estado.

La notación en la versión anterior indica que

los detalles de la sub máquina Check Pin se
muestran en un diagrama separado.
 Pseudo estado “Choice” (Elección) Estado “History” (Historial)
Un pseudo estado se muestra como un Un estado historial se usa para recordar el
diamante con una transición llegando y dos estado anterior de una máquina de estado
o más transiciones saliendo. El siguiente cuando fue interrumpida. El siguiente diagrama
diagrama muestra que cualquier estado al que ilustra el uso de estados del historial. El ejemplo
se llega después del pseudo estado elección es una máquina de estado que pertenece a un
depende del formato del mensaje seleccionado lavarropas.
durante la ejecución del estado anterior.

En esta máquina de estado, cuando un

Pseudo estado “Junction” (unión) lavarropas comience, su proceso será desde
Los pseudo estados unión se usan para unir el lavado y enjuague hasta el secado. Si hay
transiciones múltiples. Una sola unión puede un corte de luz, el lavarropas se detendrá por
tener una o más transiciones de entradas y una lo que pasará al estado Power off (apagado).
o más de salida, y se puede aplicar una guarda Luego, cuando la energía retorne, el estado
a cada transición. Las uniones son libres de Running (ejecutar) ingresa al símbolo de estado
semántica; una unión que divide una transición Historial, lo que significa que debería seguir
de entrada en transiciones de salida múltiples con el proceso donde quedó cuando se cortó
realiza una rama condicional estática, opuesto la energía.
a un pseudo estado elección que realiza una
rama condicional dinámica.
Regiones concurrentes
Un estado se puede dividir en regiones
conteniendo sub estados que existen y se
ejecutan concurrentemente. El siguiente
ejemplo muestra que dentro del estado
“Applying Brakes” (Aplicar frenos), los frenos
de adelante y atrás estarán operando
simultáneamente e independientemente.
Tener en cuenta el uso de los pseudo estados
en lugar de los pseudo estados elección y
combinación. Estos símbolos se usan para
sincronizar los hilos concurrentes.
Pseudo estado “Terminate” (terminar)
Ingresar un pseudo terminar indica que la línea
de vida de la máquina de estado ha terminado.
Un pseudo estado terminar se denota como
una cruz.
 RESUMEN DEL TEMA
Se explican tanto la sintaxis como las conexiones a ser usadas para realizar los
diagramas de máquina de estados, de tal manera que se pueda especificar la secuencia
de eventos que atraviesa un objeto durante su tiempo de vida, en respuesta a los
eventos.

LA IDEA PRINCIPAL
Sintaxis y conexiones necesarias para diagramar la secuencia de estados de un
objeto durante su ciclo de vida.
UNIDAD 10 - TEMA 3
Utilidad de los diagramas de máquina
de estado
Al desarrollar un producto software, los
diagramas de estado pueden ayudar a visualizar
el ciclo de vida de cada objeto de forma clara
y comprensible. Aunque este diagrama solo
consta de unos pocos elementos, si se utiliza
correctamente, puede contribuir notablemente
al resultado final.
Un diagrama de estado UML (también llamado
diagrama de estado, diagrama de transición de
estados o diagrama de máquina de estados)
muestra los estados por los que pasa una
máquina de estados finitos, es decir, un modelo
de comportamiento que consiste en acciones y
estados o transiciones a otros estados.
El diagrama proporciona un estado inicial y uno
final, así como al menos un estado intermedio
para cada objeto.
El diagrama de estado permite, de este modo,
representar el ciclo de vida completo de
cualquier sistema, subsistema o componentes ¿Para qué sirve el diagrama de estado?
o clases del mismo, como podrían ser una Como ya hemos mencionado, el objetivo
máquina de café, un lector de libros electrónicos de los diagramas de estado es describir
o un componente tecnológico de un vehículo. el comportamiento de un sistema con la
máxima precisión. Entre otras cosas, esta
representación gráfica de los procesos debería
dar respuesta a las siguientes preguntas:
• ¿Qué sucede cuando el objeto está en un
estado concreto?
• ¿En qué estado debe estar el objeto para
cambiar de comportamiento?
• ¿Cuáles son los desencadenantes?
• ¿Qué propiedades debe tener el objeto para
poder cambiar de estado?
Por lo tanto, los diagramas de estado se utilizan
para optimizar cualquier proceso de desarrollo
donde sea útil visualizar los estados del objeto
y las condiciones para que se produzca la
transición de un estado a otro.
Suelen emplearse, por ejemplo, en el diseño
de sistemas embebidos (en inglés, embedded
systems), donde las señales automatizadas
y los procesos en segundo plano deben estar
perfectamente coordinados.
En este caso, el diagrama de estado ayuda a los En varios sectores de la industria, como
desarrolladores a visualizar todas las funciones el transporte o la tecnología sanitaria, los
de control y regulación más importantes en un diagramas de estado se utilizan para explicar
solo esquema. procesos complejos. También se emplean en
La función de interrupción de la toma de la ingeniería de requisitos y en la gestión de
agua que tienen casi todas las lavadoras productos y proyectos.
puede servirnos de ejemplo para imaginar un En la siguiente figura tenemos un diagrama de
diagrama de estado UML. En este contexto, estado para un ascensor, donde se combinan
esta función se representaría como un sistema los estados con las transiciones simples.
independiente. En este caso, el esquema
mostraría en qué estado y bajo qué condiciones
se activa la función.
 RESUMEN DEL TEMA
Un diagrama de estado UML (también llamado diagrama de estado, diagrama de
transición de estados o diagrama de máquina de estados) muestra los estados por los
que pasa una máquina de estados finitos, es decir, un modelo de comportamiento que
consiste en acciones y estados o transiciones a otros estados.
Los diagramas de estado UML se utilizan para optimizar cualquier proceso de desarrollo
donde sea útil visualizar los estados del objeto y las condiciones para que se produzca
la transición de un estado a otro.
Suelen emplearse, por ejemplo, en el diseño de sistemas embebidos (en inglés,
embedded systems), donde las señales automatizadas y los procesos en segundo
plano deben estar perfectamente coordinados.

LA IDEA PRINCIPAL
En los diagramas de estado se visualizan los estados del objeto y las
condiciones para que se produzca la transición de un estado a otro.
UNIDAD 10 - TEMA 4
DIAGRAMAS DE MÁQUINA DE ESTADO –
CASOS DE ESTUDIO
Los diagramas de estado pueden aplicarse a Diagrama de estados de disponibilidad en
objetos de todo tipo. En el siguiente ejemplo, te calendario.
mostramos cómo incluir cada elemento en el Este ejemplo de diagrama de máquina de
diagrama de estado de una factura. Estos son estados muestra el proceso por medio del cual
los elementos más importantes de un diagrama una persona define una cita en su calendario.
de estado UML:

Si combinamos los elementos para nuestro

ejemplo, un diagrama de máquina de estado
sencillo podría ser el siguiente:

• En el punto de partida, la factura se

encuentra en el pseudoestado “escrita”
(written).
• En el mejor de los casos, se producirá la
transición hacia el estado “pagada” (paid). • En el estado compuesto “Revisar
Esta transición podría describirse con más fecha” (Check date), el sistema revisa el
detalle indicando el evento “enviar”. calendario (Calendar checked) en busca
• Antes de llegar al estado de “pagada” (paid), de disponibilidad en algunos subestados
puede ser necesario enviar un “recordatorio” diferentes.
(reminder). Si no se paga la factura, se • Si no hay disponibilidad de tiempo en el
enviarán hasta tres recordatorios. calendario, va al estado “Calendario no
• Una vez que se ha pagado, la factura se disponible” (Calendar not available).
encuentra en el estado “pagada”. En este • Sin embargo, si el calendario muestra
caso, como la factura no cambiará más de disponibilidad (Calendar available), se
estado, aunque se ocasione una actividad, agregará la cita al calendario (Appoinment
se trata de una transición interna. added).
Diagrama de estados de universidad. Diagrama de estados de registro en
• El siguiente diagrama de estados muestra aeropuerto.
el proceso de inscripción y clases en una El siguiente ejemplo simplifica los pasos
universidad. necesarios para registrarse en un aeropuerto.
• El estado compuesto “Inscripción” se En el caso de las aerolíneas, un diagrama de
compone de diversos subestados que guían estados puede ayudar a agilizar procesos y
a los estudiantes a través del proceso de eliminar pasos innecesarios.
inscripción.
• Una vez que los estudiantes se han inscrito,
pasan al estado “Siendo instruidos” y
finalmente a “Exámenes finales”.
 RESUMEN DEL TEMA
En este tema se describen y diagraman varios ejemplos de aplicación de los diagramas
de máquinas de estado, que son de gran ayuda en el modelado del comportamiento
de las clases/objetos dentro de diversos procesos de negocio.

LA IDEA PRINCIPAL
Aplicación de la máquina de estado en el modelado del
comportamiento de las clases/objetos, dentro de diversos procesos
de negocio.
 LECTURAS RECOMENDADAS
• https://sg.com.mx/content/view/365
• http://www.sparxsystems.com.ar/resources/tutorial/uml2_statediagram.php

ACTIVIDADES Y EJERCICIOS
1. Identificar, a partir de los casos de uso, elementos necesarios para hacer
modelado de estado de objetos.
2. Realizar diagramas de máquina de estados de clases/objetos de un caso de
estudio: sistema de ventas de una pollería.