Resumen Analisis Sistema

Análisis de Sistemas
INSTITUCIONALES ........................................................................................................................................................... 1
¿Cómo está organizado este texto? ...................................................................................................................... 5
Introducción.......................................................................................................................................................................... 6
REFERENCIAS 1 ............................................................................................................................................................. 7
Esquema ................................................................................................................................................................................. 8
Situación profesional 1: Conceptos Generales (cadena de ventas) .................................................. 9

SP1 / H1: Modelado ....................................................................................................................................................... 10
REFERENCIAS 2 ................................................................................................................................................... 14
SP1 / Autoevaluación 1 ........................................................................................................................................ 15
SP1 / H2: Metodología .................................................................................................................................................. 18
REFERENCIAS 3 ................................................................................................................................................... 28
SP1 / H3: UML ................................................................................................................................................................ 35
REFERENCIAS 4 ................................................................................................................................................... 44
SP1 / H4: El Proceso Unificado de Desarrollo de Software ................................................................................. 49
SP1 / Ejercicio resuelto ................................................................................................................................................. 59
SP1 / Ejercicio por resolver .......................................................................................................................................... 60
SP1 / Evaluación de paso ............................................................................................................................................ 61
Situación Profesional 2: Requisitos.................................................................................................................... 65

SP2 / H1: Captura de requisitos.................................................................................................................................. 66
REFERENCIAS 5 ................................................................................................................................................... 70
SP2 / H2: El Modelo de Casos de Uso...................................................................................................................... 75
REFERENCIAS 6 ................................................................................................................................................... 89
SP2 / H3: Captura de requisitos como Casos de Uso ........................................................................................ 104
REFERENCIAS 7 ................................................................................................................................................ 109
SP2 / Autoevaluación 3 ..................................................................................................................................... 113
SP2 / H4: Prototipos de Interfaz............................................................................................................................... 116
REFERENCIAS 8 ................................................................................................................................................ 130
SP2 / Ejercicio resuelto .............................................................................................................................................. 136
REFERENCIAS 9 ................................................................................................................................................ 146
SP2 / Ejercicio por resolver ....................................................................................................................................... 147
REFERENCIAS 10 ............................................................................................................................................. 150
SP2 / Evaluación de paso ......................................................................................................................................... 151
Situación Profesional 3: Análisis ....................................................................................................................... 154

SP3 / H1: El Proceso de Análisis ............................................................................................................................. 155
SP3 / H2: El Diagrama de Clases............................................................................................................................ 162
REFERENCIAS 11 ............................................................................................................................................. 173
SP3 / H3: Caso de Uso - Análisis ............................................................................................................................ 186
REFERENCIAS 12 ............................................................................................................................................. 195
REFERENCIAS 13 ............................................................................................................................................. 206
REFERENCIAS 14 ............................................................................................................................................. 218
Situación Profesional 4: Diseño ......................................................................................................................... 223

SP4 / H1: El Modelo de Diseño ................................................................................................................................ 224
REFERENCIAS 15 ............................................................................................................................................. 228
SP4 / H2: Interacciones ............................................................................................................................................. 232
REFERENCIAS 16 ............................................................................................................................................. 239
SP4 / H3: Estados y Actividades ............................................................................................................................. 245
REFERENCIAS 17 ............................................................................................................................................. 253
REFERENCIAS 18 ............................................................................................................................................. 264
Análisis de Sistemas
REFERENCIAS 19 ............................................................................................................................................. 281
Situación Profesional 5: Implementación..................................................................................................... 302

SP5 / H1: El Modelo de Implementación ............................................................................................................... 303
REFERENCIAS 20 ............................................................................................................................................. 306
SP5 / H2: El Diagrama de Componentes .............................................................................................................. 310
REFERENCIAS 21 ............................................................................................................................................. 315
SP5 / H3: El Diagrama de Despliegue ................................................................................................................... 319
Situación profesional 6: Prueba ......................................................................................................................... 332

SP6 / H1: El Modelo de Prueba ............................................................................................................................... 333
REFERENCIAS 22 ............................................................................................................................................. 339
Cierre ................................................................................................................................................................................... 350
Bibliografía ...................................................................................................................................................................... 351
Anexos ............................................................................................................................................................................... 352

Microsoft Visio 2010.................................................................................................................................................... 353
Instalación ............................................................................................................................................................. 354
Configuración de Entorno y Características ................................................................................................. 355
Construcción de los modelos ........................................................................................................................... 356
REFERENCIAS 23 .............................................................................................................................................................. 361
Ejercicios ....................................................................................................................................................................... 362

Situación profesional 1: Conceptos Generales:
Cadena de Ventas
Una cadena internacional de supermercados tiene pensado poner en marcha en el país, a través de Internet,
un canal de comunicación eficaz y exclusivo con sus clientes, para la gestión del ciclo de venta que abarca
desde la captura del pedido hasta la cobranza y entrega de la mercadería.
El objetivo de este servicio on-line es llegar a más personas, brindándole mayores beneficios y servicios.
Además, la empresa piensa que este servicio le permitirá reducir sus costos administrativos y financieros.
Para la ejecución de los aspectos informáticos de este servicio, la firma lo eligió a usted con el objeto de que
proponga una metodología para desarrollar una aplicación de e-business, empleando las últimas tecnologías.
SP1 / H1: Modelado
Modelos
Es importante comprender el concepto de modelado. Para ello, recurriremos a un ejemplo que sintetiza lo
que queremos transmitir. Suponga que usted desea construir una casa. Es más que seguro que no va a
comprar una cantidad indiscriminada de materiales de construcción, o de aberturas sin saber previamente
que es realmente lo que necesita.
Por otro lado, consultará o se asesorará con profesionales o expertos en el tema de la construcción para
que realicen los estudios de viabilidad, de costos, de estructuras, etc. Estos estudios se verán resumidos
o su información podrá ser vista de manera gráfica a través de planos, planillas de cálculo, documentos.
Es decir, usted no construye directamente sino que lo que se va a construir se presenta a través de
distintas herramientas ("modelos") que permitirán visualizar lo que será su casa en el futuro (figura 1-1-
1).
Figura 1-1-1: Un ejemplo de Modelo
Ahora bien, si comparamos el ejemplo anterior con las actividades que nos demanda nuestra profesión,
nos damos cuenta de que la construcción de un buen sistema no comienza escribiendo directamente el
código de los programas, sino que debemos modelar lo que se quiere del sistema.
Por tal motivo, decidimos comenzar este texto hablando del concepto de modelado y de cómo se
aplica a nuestra actividad profesional.
¿Qué es un modelo
Un modelo es una representación de algo real en cierto medio. Esta representación capta los aspectos
importantes de lo que se esta modelando, desde un punto de vista, y simplifica u omite otros aspectos que
no son considerados de interés por el momento.
Un modelo tiene semántica * 2.1 y notación * 2.2 , y puede adoptar varios formatos que incluyen
texto y gráficos.
En nuestra profesión, ¿para qué sirven los modelos?
a) Para captar y enumerar exhaustivamente los requisitos y el dominio de conocimiento, de forma que todos
los implicados puedan entenderlos y estar de acuerdo con ellos. Los diversos modelos de un sistema de
software pueden capturar requisitos sobre su dominio de aplicación, las formas en que los usuarios los
utilizarán, su división en módulos, los patrones comunes usados en su construcción, etcétera.
b) Para pensar en el diseño de un sistema. Ayuda a los desarrolladores a explorar varias arquitecturas y
soluciones de diseño fácilmente, antes de escribir el código. Un buen lenguaje de modelado permite que
el diseñador consiga la arquitectura correcta antes de que comience el diseño detallado.
c) Para capturar decisiones del diseño en una forma mutable a partir de los requisitos. Puede captar el
comportamiento externo de un sistema y la información del dominio del mundo real representado por
el sistema. Otro modelo muestra las clases y las operaciones internas, que implementan el
comportamiento externo. Hay muchas maneras de implementar el comportamiento; el modelo final de
diseño muestra un acercamiento que el diseñador cree correcto.
d) Para generar productos aprovechables para el trabajo. Se puede utilizar para generar las
declaraciones de clase, los cuerpos de procedimiento, las interfaces de usuario, las bases de datos,
los escenarios de uso válidos o los guiones de configuración.
e) Para organizar, encontrar, filtrar, recuperar, examinar, y corregir la información en grandes sistemas.
Organiza la información en varias vistas: estructura estática, máquinas de estado, interacciones,
requisitos, etcétera. Cada vista es una proyección del modelo completo para un propósito determinado.
Mantener un modelo, de cualquier tamaño, es imposible sin tener una herramienta de edición, que
maneje el modelo. Un editor gráfico e interactivo del modelo, puede presentar la información en diversos
formatos, ocultar información que es innecesaria para un propósito dado, y mostrarla otra vez más
adelante, agrupar operaciones relacionadas, realizar cambios en los elementos individuales, así como
cambiar grupos de elementos con un comando, etc.
f) Para explorar económicamente múltiples soluciones. Los modelos de un sistema de software grande
permiten que se propongan y comparen varios diseños. Los modelos no se construyen al detalle, por
supuesto, pero incluso un modelo rudimentario puede exponer muchas cuestiones que el diseño final
debe tener en cuenta. Modelar permite considerar varios diseños, con un coste pequeño al implementar
cualquiera de ellos.
g) Para comprender los sistemas complejos. Un modelo de un sistema software grande permite ocuparse
de la complejidad que es demasiado difícil de tratar directamente. Un modelo se puede abstraer a un
nivel que sea comprensible a los seres humanos sin perderse en detalles. Un computador puede realizar
complicados análisis en un modelo, en un esfuerzo para encontrar problemas tales como errores de
sincronización o desbordamiento en los recursos. Un modelo puede determinar el impacto potencial de
un cambio antes de que se haga, explorando dependencias en el sistema. Un modelo puede también
mostrar cómo reestructurar un sistema para reducir tales efectos.
¿Qué hay en un modelo?
Semántica y presentación. El aspecto semántico toma el significado de una aplicación como una
red de construcciones lógicas, por ejemplo clases, asociaciones, estados, casos de uso, y
mensajes. Los elementos semánticos del modelo llevan el significado del modelo, es decir,
transportan la semántica. Los elementos semánticos del modelo se utilizan para la generación del
código, la comprobación de la validez, las métricas de complejidad, etcétera. La presentación
visual muestra la información semántica de modo que pueda ser considerada y corregida por los
seres humanos. No agregan significado, sino que organizan la presentación, para acentuar la
organización del modelo de una manera útil. Por lo tanto, dirigen la comprensión humana del
modelo.
Contexto. Los modelos son herramientas en un sistema informático, y se utilizan dentro de un
contexto más grande que les dé significado completo. Este contexto incluye la organización
interna del modelo, anotaciones sobre el uso de cada modelo en el proceso total del desarrollo,
un sistema de valores por defecto y de suposiciones para la creación y la manipulación del
elemento, y una relación al entorno en el cual se utilizan.
Clasificación de Modelos
Particularmente en la aplicación de modelos en proyectos de desarrollo de sistemas informáticos, éstos

adquieren diversas formas para diferentes propósitos, y aparecen en diversos niveles de abstracción que
tienen una relación directamente proporcional con el nivel de detalle que especifican.
De acuerdo a estos niveles, podemos clasificar los modelos en:
a. Modelos Conceptuales. Constituyen una guía al proceso de pensamiento. Los modelos de alto nivel construidos al principio
de un proyecto, sirven para enfocar el proceso del pensamiento de los participantes y destacar determinadas opciones.
Capturan requisitos y representan un punto de partida hacia un diseño del sistema. Los primeros modelos ayudan a los autores
a explorar las opciones posibles antes de converger en un concepto de sistema. Según progresa el diseño, los primeros
modelos son sustituidos por otros modelos más exactos.
b. Modelos Lógicos o Abstractos. Especifican de forma abstracta la estructura esencial de un sistema. Los modelos en el
análisis o las etapas preliminares del diseño se centran en los conceptos y mecanismos claves del probable sistema. Se
corresponden de cierta manera con el sistema final, pero faltan los detalles, que se deben agregar explícitamente durante el
proceso de diseño. El propósito de los modelos abstractos o lógicos es conseguir que los aspectos de alto nivel estén
correctos, antes de abordar los detalles más localizados.
c. Modelos Físicos. Contienen las especificaciones completas de un sistema final. Un modelo de implementación incluye
suficiente información para construir el sistema. Debe incluir, no solamente la semántica lógica del sistema y los algoritmos, las
estructuras de datos y los mecanismos que aseguran funcionamiento apropiado, sino también las decisiones de organización
sobre las herramientas del sistema que son necesarios, permitiendo así el trabajo cooperativo de las personas y el
procesamiento por parte de las herramientas.
Esta clasificación es la que, también, le da el nombre de metodología descendente * 2.3 a las técnicas de
análisis y modelado que estudiaremos en esta materia.
Los modelos utilizados para el análisis y el diseño de sistemas informáticos, son muy variados y responden
a una metodología determinada. De acuerdo a ella, por ejemplo, podemos tener modelos que permiten
diseñar estructuras, otros que se utilizan específicamente para datos o también los que permiten modelar
diferentes comportamientos de los componentes de un sistema.
Profundizaremos sobre este punto en la herramienta siguiente, donde aprenderemos nuevos conceptos que
nos ayudarán a elegir de forma más precisa la metodología de modelado a aplicar en el escenario planteado
por la situación profesional.
2.1 : Semántica
Especificación formal del significado y del comportamiento de algo.
2.2 : Notación
Codificación o símbolo que se establece para un elemento perteneciente a un modelo.
2.3 : Metodología Descendente
Se denomina así a cualquier proceso de desarrollo de conocimiento (en nuestro caso modelos, objetos,
componentes de software, etcétera) que parte de un nivel general o "superior", y mediante la aplicación de métodos
formales busca arribar a definiciones detalladas que se correspondan casi completamente con el producto final.
Respuestas de la Autoevaluación
1. Indique la opción correcta

Dentro la clasificación de los modelos, ¿en cuál se ubicaría el Modelo de Entidad Relación (DER)
que especifica la estructura detallada de una base de datos?
○ El DER no es un modelo.

Un modelo es una representación asbtracta de la realidad, simplificada para su análisis y estudio en
un contexto específico.
X Verdadero
○ Falso
En un modelo hay Semántica, Notación y
Contexto. X Verdadero
6. Ordene relaciones
Relacione los conceptos de la columna izquierda con sus características correspondientes en la
columna derecha:
Semántica Significado y Comportamiento

Notación Simbología y Presentación Visual
Contexto Descripción de elementos del Entorno
Modelo Representación abstracta y simplificada
P1 / H2: Metodología
En el ámbito del análisis y el diseño de software, se pueden construir muchos tipos de modelos. Estos tipos de
modelos en la mayoría de los casos son estructurales, y permiten visualizar y especificar las diferentes partes de
los sistemas y la forma en que se relacionan entre sí; pero siempre responden a un método determinado.
Metodología Orientada a Objetos por tres sencillas razones:

Por ser la más completa, evolucionada, estandarizada, documentada y utilizada; proporcionando
todos los elementos necesarios para analizar y modelar estructuras, comportamientos,
relaciones e interacciones de todos los componentes de un sistema.
Porque el lenguaje de modelado que utilizaremos en nuestra materia, el UML, está basado en
esta metodología.
Porque es soportada por la mayoría de las herramientas IDE * 3.2 (en sus lenguajes de
programación) y las herramientas CASE * 3.1 (que usan UML como lenguaje de modelado) de
uso actual.
Características de los Modelos Orientados a Objetos
Cuando analizamos sistemas, creamos modelos del área de aplicación que nos interesa, modelamos para
representar ciertos aspectos de la realidad y poder comprenderla, y por eso los modelos son muchos mas
sencillos que la realidad, y eso los hace manejables, característica fundamental que nos permitirá idear sistemas,
soluciones, identificar problemas o rediseñar procesos.
En nuestra profesión, este proceso de estudio y comprensión de la realidad a través de modelos tendrá
como principal objetivo la generación de programas, es decir el código fuente escrito en un determinado
lenguaje de programación. Este código, durante su ejecución (ya sea compilado o interpretado), será el
motor de nuestro sistema informático y por lo tanto de la automatización de la empresa
Esta transformación de modelos en software, nos permite comprender la existencia de una relación directa
entre las diferentes metodologías de modelado y los lenguajes de programación
Metodologías Estructuradas vs. Metodologías Orientadas a Objetos
Las dos metodologías más utilizadas en la ingeniería de software han sido principalmente las Estructuradas
y las Orientadas a Objetos. Ambas, cumplen con la misión de brindar elementos para modelar el diseño de
un sistema informático, pero parten de paradigmas diferentes:
Las primeras proponen modelos con un nivel de abstracción menor, basados principalmente en la
identificación de componentes sistémicos representados de una manera mas cercana al software
que a la realidad
Las segundas, las Metodologías OO, parten de conceptos totalmente abstractos (como lo son
las clases, los objetos, las colaboraciones, los actores, etcétera), que no solo modelan
aspectos del software, sino aspectos del ambiente, de los usuarios y de los procesos de
negocio.
Metodologías Estructuradas
Para soportar el análisis y el diseño del software, y permitir elaborar modelos de un sistema existente o de un
sistema que tiene que ser construido. Con el desarrollo de los años, evolucionaron para soportar los primeros
conceptos de orientación a objetos, con los que finalmente se unificaron.
Los métodos estructurados fueron aplicados con éxito por largo tiempo en muchos proyectos, y sobre todo
los de gran envergadura que requerían altos niveles de calidad y documentación. Sin embargo, presentaban
una serie de inconvenientes que fueron claves para su evolución:
No proporcionan un soporte efectivo para la comprensión o el modelado de requerimientos
no funcionales (es decir requerimientos que no forman parte del alcance del software).
Su implementación a menudo genera demasiada documentación
No brindan flexibilidad, lo que dificulta el análisis para el uso de los modelos en escenarios
o entornos diferentes.
La documentación no está orientada al usuario, sino a los especialistas técnicos
Los modelos producidos son tan detallados y técnicos, que los usuarios a menudo los encuentran
difíciles de entender.
Los lenguajes de programación contemporáneos a estas metodologías y que permitían codificar este tipo de
modelos eran los homónimos lenguajes estructurados, como el COBOL, el BASIC, el PASCAL, entre otros.
Estos lenguajes contaban con las sentencias necesarias para la creación de estructuras de control,
estructuras lógicas y de procesamiento. Algunos de ellos, como el COBOL, todavía son muy utilizados,
principalmente para dar soporte a sistemas generalmente corporativos, de gran dimensión, alta criticidad en
el negocio y con gran demanda de procesamiento. Estos aspectos hacen que sea muy difícil y poco viable la
decisión de una reingeniería o un reemplazo, por el impacto en los procesos de negocio y por el alto costo
económico que implica.Algunos ejemplos de modelos utilizados en las metodologías estructuradas, son los
Diagramas de Entidad Relación (los Diagramas de Procesos o los Diagramas de Flujo de Datos
Metodologías Orientadas a Objetos

Las Metodologías Orientadas a Objetos, se basan en que un sistema está compuesto por objetos que
interactúan. El proceso de diseño orientado a objetos comprende el diseño de clases de objetos y las
relaciones entre estas clases. Las clases, definen los objetos del sistema y sus interacciones. Cuando
este diseño se implementa como un programa de computación, los objetos requeridos se crean
dinámicamente utilizando las definiciones de las clases. En la figura 1-2-3 se presenta un Diagrama de
Clases de UML, modelo muy utilizado en la metodología.
Como medio para la generación de programas, tiene varias ventajas. Fomenta una metodología basada en
componentes para el desarrollo de software, que luego se amplía agregándole funcionalidad a estos o
nuevos componentes, permitiendo la reutilización los objetos creados lo cual reduce sustancialmente el
tiempo de desarrollo de un sistema.
El análisis y diseño orientado a objetos comprende el desarrollo de modelos OO del dominio de la
aplicación, que identifican objetos que reflejan las entidades y operaciones que se asocian con el problema
a resolver. Estos modelos deben ser refinados y transformados por el diseñador hasta convertirse
definiciones sistémicas estructurales y dinámicas, implementables en un lenguaje de programación
orientado a objetos. Estos lenguajes, como JAVA, C++, C#, Python, entre otros; proveen los recursos
necesarios para definir clases y un sistema ara crear los objetos correspondientes a las clases.
La orientación a objetos es muy importante para el diseño de software actual. Está regulada y
estandarizada por el
Elementos de la Programación Orientada a Objetos

La orientación a objetos es un paradigma que se basa en ciertos elementos y principios fundamentales, los
cuales describiremos a continuación:
a) Objetos
Los objetos nos rodean, conforman nuestro mundo. Pueden ser reales o abstractos. El software, simula
una parte de nuestra realidad y los programas imitan a los objetos que forman parte de esta realidad.
El concepto mas conocido, es que un objeto es la instancia de una clase (o categoría). Por ejemplo, los
alumnos y los profesores, son instancias de la clase Persona. Un objeto cuenta con una estructura (o
también denominada "características" o "rasgos"), conformada por atributos y acciones. Los atributos
describen las propiedades de un objeto, mientras que las acciones son todas las actividades que el objeto
es capaz de realizar. Siguiendo con el ejemplo, un objeto cualquiera de la clase Persona cuenta con los
siguientes atributos: nombre, altura, peso, fecha de nacimiento, etcétera, y puede realizar las siguientes
acciones: comer, dormir, caminar y hablar, entre otros.
En el ámbito de los sistemas, los objetos pueden ser una factura, una organización, una pantalla con la que
interactúa un usuario, una reservación aérea, una figura en un programa de dibujo, etcétera. La
representación en un software OO de un objeto es una colección de tipos de datos y métodos. Como
definición, podemos establecer que: "Un objeto es cualquier cosa, real o abstracta, acerca de la cual
almacenamos datos y los métodos que controlan dichos datos."
b) Clases
Una clase, puede entenderse como un tipo o categoría de objeto. Por ello, se considera a un objeto como una
instancia de una determinada clase. Una clase es la descripción de un conjunto de objetos que tienen la misma
estructura, comportamiento, y relaciones. Todos los atributos y operaciones están unidos a clases o a otros
clasificadores. Las clases son los nodos alrededor de los cuales se organizan los sistemas orientados a objetos.
Mientras que un objeto es una entidad discreta con identidad, estado y un comportamiento que puede
ser invocado, las clases son los conceptos individuales, a través de las cuales se entiende y se describe
la multiplicidad de objetos individuales. Una clase define un conjunto de objetos que tienen estado y
comportamiento iguales. Se describe el estado de una clase a través de sus atributos y asociaciones.
Los atributos se utilizan generalmente para los valores puros de los datos sin identidad, tales como
números y cadenas (como por ejemplo número telefónicos, nombres, apellidos, etcétera), y las
asociaciones se utilizan para las conexiones entre objetos con identidad. Las piezas individuales de
comportamiento invocable se describen mediante operaciones; un método es la implementación de una
operación. Sin embargo, no podemos dejar de mencionar que tanto los atributos como los métodos en las
clases, están condicionados por el contexto de nuestro análisis. Por ejemplo: los atributos y métodos de la
clase Empleado, a la hora de abstraerla como entidad, no son los mismos para un sistema de Sueldos, que
para un sistema de Control de Accesos.
Definimos entonces que: "Una clase es una entidad que representa a un conjunto de objetos que
comparten los mismos atributos, métodos y relaciones, dentro de un determinado contexto de análisis".
La notación general para una clase es un rectángulo con compartimentos, el compartimento superior se
dispone el nombre de la clase (preferentemente en negrita y centrado), en el compartimento intermedio se
detallan los atributos (especificando su nombre y seguido de dos puntos el tipo de dato para ese atributo), y
en el último compartimento se detallan las operaciones, como se muestra en la Figura 1-2-
Representación de una Clase (Figura 1-2-4)
c) Encapsulamiento
Un objetos es utilizado por otros objetos o por los usuarios. A través de esta interacción se pueden obtener
sus atributos o ejecutar algunas de sus operaciones, pero esto no implica conocer como están estructurados
sus datos o cuál es la lógica que siguen sus métodos.
Al igual que podemos ver la televisión sin que sea necesario cual es el mecanismo mediante el cual las
imágenes llegan a la pantalla, el encapsulamiento es la característica de los objetos que permite a los
mismos "ocultar" o resguardar sus datos y funcionalidad interna. El objeto esconde sus datos de los
demás objetos, y permite el acceso a los mismos mediante sus propios métodos.
En los sistemas informáticos, el encapsulamiento evita la corrupción de los datos de un objeto. Si todos los
pogramas pudieran tener acceso a los datos en cualquier forma que quisieran los usuarios, los datos se
podrían utilizar de mala manera. El encapsulamiento protege los datos del uso no pretendido. También
permite reducir el potencial de errores que pudieran ocurrir. En un sistema que consta de objetos, éstos
dependen unos de otros de diversas formas. Si uno de éstos falla y los especialistas del software deben
modificarlo de alguna manera, el ocultar sus operaciones de otros objetos significa que seguramente no
será necesario modificar a ninguno de los demás.
Podemos definir entonces el encapsulado en encapsulamiento como "el resultado (o acto) de ocultar los
detalles de implantación de un objeto, respecto de su usuario".
d) Herencia
Como ya se mencionó anteriormente, una clase es una categoría de objetos, pero en el mundo del software
esta también un plantilla que sirve para crear otros objetos. Un objeto es una instancia de una clase. Esta
idea tiene una consecuencia importante: como instancia de una clase, un objeto tiene todas las
características de la clase de donde proviene. A esto se lo conoce como herencia.
Un objeto no sólo hereda de una clase, sino que una clase también puede heredar de otra. Por ejemplo sin
nos remitimos a la figura 1-2-3 * 3.4 , podemos observar que Alumno y Profesor (como podrían haber sido
Empleado, Cliente o Postulante en otro contexto de análisis), son clases y forman parte de una clase más
genérica llamada Persona.Una Persona cuenta con los atributos de Nombre, Apellido y Fecha de
Nacimiento, y la operación Edad. En cada una de las clases Persona heredará los mismos atributos y
métodos; por ello, si se conoce que un objeto es una persona, queda explícito que cuenta con todas las
características de la clase Persona.
Otra forma de explicarlo es que un alumno o un profesor son subclases de la clase Persona. Podemos decir
que Persona es una superclase de todas las demás.
Y la herencia puede continuar desarrollándose hacia arriba (superclases) o hacia abajo (subclases) si fuera
necesario. Por ejemplo pueden ser subclases de Alumno, "Alumno Recibido" y "Alumno Regular",
presentando nuevos atributos y métodos propios.
e) Polimorfismo
Uno de los objetivos principales de las técnicas OO es utilizar otra vez el código. Sin embargo, algunas de
las operaciones requieren adaptación para resolver necesidades particulares. Por ejemplo, en la Figura 1-
2-5, la clase Empleado define una operación Calcular Indemnización.
Polimorfismo (Figura 1-2-5)
En las implementaciones orientadas a objetos todas las subclases Empleado heredan esta operación en
forma automática. Sin embargo, una organización puede tener distintos métodos para calcular la antigüedad
de un ejecutivo y a un empleado. En este caso, el método para el cálculo de la indemnización de un
ejecutivo está por encima del método para el retiro de los empleados en general. Aún así, aunque los
métodos sean distintos, llevan a cabo el mismo propósito operativo. Este fenómeno se conoce como
polimorfismo. La palabra polimorfismo se aplica a una operación que adopta varias formas de
funcionamiento, dependiendo el tipo de objeto del que se trate, pero denominándose de una sola forma.
Una de las ventajas del polimorfismo es que se puede hacer una solicitud de una operación sin conocer
el método que debe ser llamado. Los detalles internos de funcionamiento del método quedan ocultos
para el usuario, la responsabilidad reside en el mecanismo de implementación OO.
f) Ligamiento Dinámico
es una característica fundamental de la metodología orientada a objetos que está totalmente relacionada
con los conceptos de herencia y polimorfismo.
Sintéticamente, ligadura dinámica (en inglés dynamic binding) es un mecanismo que pospone hasta el
momento de ejecutar una llamada, la elección del método u operación a ejecutar. Esto es muy importante,
ya que se aplica siempre sobre operaciones polimórficas.
Veamos un ejemplo sencillo: tomando como base el ejemplo de la figura 1-2-5
" Polimorfismo (Figura 1-2-5)"
, un objeto puede ser instanciado como Empleado, y cambiar durante la ejecución del programa a la clase
Ejecutivo. Si fuera necesario calcular la indemnización mediante el método correspondiente, ¿como lo
resolvería el lenguaje, si el objeto fue instanciado en una clase y ahora pertenece a una subclase?. La
respuesta es la ligadura dinámica: ella se encargará de ligar o relacionar la llamada a un método con el
cuerpo del método que se ejecuta finalmente. Este mecanismo resuelve el conflicto entre un método de una
superclase y un método de la subclase, donde el comportamiento correcto es que el método de la subclase
sobrescriba al de la superclase.
Esta capacidad de las operaciones para adaptarse automáticamente a los objetos a los cuales se aplican
es una de las propiedades más importantes de la orientación a objetos.
En programación orientada a objetos, existen dos tipos de ligamientos o ligaduras: estática (por defecto
cuando se crea un objeto) y dinámica. La primera se ejecuta en tiempo de compilación, mientras que la
segunda se resuelve en tiempo de ejecución, y debe ser explícitamente declarada. La forma de implementar
ligadura dinámica puede variar de un lenguaje a otro, pero básicamente presentan características comunes.
g) Relaciones
En la Metodología Orientada a Objetos, la forma en que dos elementos se conectan entre sí, se modela
como Relaciones. Todas las relaciones existentes entre los objetos que deben ser consideradas en el
modelo para entender su comportamiento.
Existen básicamente tres tipos de relaciones:
Las dependencias, que son relaciones de uso. Por ejemplo, un componente de software que valida el login de
un usuario al sistema, depende de otro componente que "encripta" la clave para poder ser validada. Entre ellos
existe una relación de dependencia.
Las generalizaciones, que conectan clases generales con otras más especializadas en lo que se conoce como
relaciones subclase/superclase o hijo/padre. Por ejemplo, y usando ejemplos ya vistos, Persona es una
generalización de Alumno, de Profesor, de Empleado, de Cliente, etcétera; mientras que éstos son
especializaciones de Persona.
Las asociaciones, que son relaciones estructurales entre clases y sus instancias
h) Jerarquía de Clases
El concepto de jerarquía de clases integra a otros ya vistos en características anteriores como son la
generalización, la especificación, las superclases y las subclases, las relaciones y la herencia.
La jerarquía de clases es establecida por las relaciones de generalización establecidas entre
superclases y subclases, donde las segundas heredan atributos y métodos de las segundas. En un
diagrama de clases, la jerarquía de clases tiene forma de árbol, donde las subclases son ubicadas debajo
de las superclases, como se muestra en la figura 1-2-6.
Jerarquía de Clases (Figura 1-2-6)
Una Clase puede tener ninguno, uno o más padres. Una clase sin padres y uno o más hijos se denomina Clase
Raíz o Clase Base. Una clase sin hijos se llama Clase Hoja. Una clase con un único padre se dice que utiliza
herencia simple, mientras que una clase con más de un padre se dice que utiliza herencia múltiple.
REFERENCIAS 3
3.1 : Herramienta CASE: son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo
de software. Existen herramientas CASE que permiten desarrollar software orientado a objetos, que están basadas
principalmente en UML como lenguaje de modelado: Rational Rose, Enterprise Architect, StarUML, entre otras.
3.2 : Herramientas IDE: consiste en un editor de código, un compilador, un depurador y un constructor de interfaz gráfica
(GUI).
1. Indique las opciones
Cada metodología tiene lenguajes de programación que las soportan. Seleccione los lenguajes orientado
a objetos.
X JAVA
○ COBOL
○ PASCAL
X C++
X PHYTON ○
BASIC
Cada metodología tiene lenguajes de programación que las soportan. Seleccione los
lenguajes estructurado.
○ JAVA
X COBOL
X PASCAL
○ C++
○ PHYTON X
BASIC
Las Metodologías Orientadas a Objetos son una evolución de las Metodologías Estructuradas.
X Verdadero

Una de las características de las Metodologías OO es permitir la reutilización de los objetos creados, la
cual reduce sustancialmente el tiempo de desarrollo de un sistema.
X Verdadero
Relacione las características de las metodologías OO con el concepto adecuado
Objeto--------------------Instanciade una clase
Clase------ ------------------Categoría de objetos
Generalización---------------- Lo opuesto Especificación
Polimorfismo ------------Comportamiento diferente de un método de acuerdo al tipo de objeto
Encapsulamiento ------ Resguardo de datos y funcionalidad de un objeto
Jerarquía de Clases -------Árbol de relaciones entre clases padres e hijos
SP1 / H3: UML

Conceptos elementales
Como bien lo menciona la Situación profesional, hemos sido contratados para recomendar una metodología
de desarrollo de software para un proyecto e-business. Esto tiene ciertas particularidades, teniendo en
cuenta la tecnología a utilizar, las herramientas de desarrollo actuales, y las características de Internet, y de
los medios de comunicación existentes en este momento. Comencemos para ello, hablando un poco sobre
qué deberíamos tener en cuenta en este sentido, y en relación a la metodología a utilizar.
En primer lugar deberíamos conocer "que es" el UML y como surge de otras metodologías
desarrolladas previamente. Para ello analicemos la definición según los autores de la metodología:
"Es un lenguaje completo para capturar el conocimiento sobre una problemática de un negocio y
expresar este conocimiento con el propósito de comunicación. Se aplica al modelado de sistemas de
cualquier característica y envergadura".
Cabe destacar que UML no es un lenguaje de programación. Porque su objetivo no es el de permitir la
escritura de código fuente y la compilación, sino por el contrario, el objetivo primordial es el de comunicar
con mecanismos, sintaxis y semántica cuestiones relacionadas al desarrollo de sistemas informáticos.
Aunque ofrece un conjunto de herramientas que permiten generar un código para una gran variedad de
lenguajes de programación, así como construir modelos por ingeniería inversa a partir de programas
existentes. UML, no es un lenguaje altamente formal pensado para probar teoremas: es un lenguaje de
modelado de propósito general.
En este punto deberíamos tener en cuenta una de las premisas fundamentales del desarrollo de sistemas, esto
es que "debe haber una comunicación muy estrecha con los usuarios" para llegar a buen puerto, es decir para
que el proyecto de software sea exitoso. Para ello el Proceso de Unificado de Desarrollo
"Proceso unificado de desarrollo (Figura 1-4-2)"
y UML nos proveen de una serie de herramientas y de modelos en beneficio de este punto.
Una de las más importantes es la del Modelado del Negocio, debido a que nos permite entender a fondo
las características de la organización y como funcionan internamente los procesos. Una vez conocido esto,
será mucho más fácil encarar el modelado del sistema de software de soporte. Aclarado esto, sigamos con
algunas características importantes de UML, para conocer un poco el contexto estas herramientas.
Pero debemos destacar que UML no garantiza el éxito de un proyecto pero permite a los
ingenieros/Analistas/Programadores focalizarse en la entrega de un producto utilizando un lenguaje de
modelación Standard que además de ser consistente es soportado directamente por las mejores
herramientas de software.
Entre los sistemas posibles de desarrollar con UML, hoy en día casi no hay límite con la evolución de las
versiones, pero de todas formas podemos mencionar una gran cantidad de sistemas desarrollados bajo
este lenguaje, entre las categorías de sistemas podemos mencionar:
Sistemas de Información de propósito general
Sistemas de Gestión empresarial
Sistemas de Tiempo Real
Sistemas Embebidos en Hardware
Sistemas Distribuidos
Sistemas de Negocios
Aplicaciones e-business
Aplicaciones e-commerce
Historia
El UML es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema
software orientado a objetos. Como decíamos anteriormente se ha convertido en el estándar de facto de la
industria, debido a que ha sido concebido por los autores de los tres métodos más usados de orientación a
objetos. Estos autores fueron contratados por la empresa Rational Software Corporation. para crear una
notación unificada en la que basar la construcción de sus herramientas CASE En el proceso de creación
de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, HP,
ORACLE o IBM, así como grupos de analistas y desarrolladores.
Esta notación ha sido ampliamente aceptada debido al prestigio de sus creadores y debido a que incorpora
las principales ventajas de cada uno de los métodos particulares en los que se basa: Booch, OMT y OOSE.
UML ha puesto fin a las llamadas "guerras de métodos" que se han mantenido a lo largo de los 90, en las
que los principales métodos sacaban nuevas versiones que incorporaban las técnicas de los demás. Con
UML se fusiona la notación de estas técnicas para formar una herramienta compartida entre todos los
trabajadores de software que trabajan en el desarrollo orientado a objetos.
Historia y Evolución del UML (Figura 1-3-1)
Con estos conceptos podemos decir que con UML podemos construir un software tal como se nos solicita
en nuestra Situación profesional, y dadas las características tecnológicas de este sistema, con las
permitidas por UML, podemos considerar que este lenguaje de modelado se adaptaría correctamente para
este tipo de desarrollo.
Vemos entonces que UML es un lenguaje de modelado visual que se usa para especificar, visualizar,
construir y documentar herramientas de un sistema de software. Captura decisiones y conocimiento sobre
los sistemas que se deben construir. Se usa para entender, diseñar, configurar, mantener, y controlar la
información sobre tales sistemas.
UML incluye conceptos semánticos, notación, y principios generales. Tiene partes estáticas, dinámicas, de
entorno y organizativas. Está pensado para ser utilizado en herramientas interactivas de modelado visual
que tengan generadores de código así como generadores de informes.
El modelar un sistema desde varios puntos de vista, separados pero relacionados, permite entenderlo para
diferentes propósitos. UML también contiene construcciones organizativas para agrupar los modelos en
paquetes, lo que permite a los equipos de software dividir grandes sistemas en piezas de trabajo, para
entender y controlar las dependencias entre paquetes, y para gestionar las versiones de las unidades odelo,
en un entorno de desarrollo complejo
Estructura estática
Cualquier modelo preciso debe primero definir el universo del discurso, esto es, los conceptos clave de la
aplicación, sus propiedades internas, y las relaciones entre cada una. Los conceptos de la aplicación son
modelados como clases, cada una de las cuales describe un conjunto de objetos discretos que almacenan
información y se comunican para implementar un comportamiento. La información que almacenan es
modelada como atributos; el comportamiento que realizan es modelado como operaciones. Varias clases
pueden compartir una estructura común usando generalización.
Comportamiento dinámico
La visión de un objeto aislado es una máquina de estados (una vista de un objeto que muestra la forma en
que responde a los eventos en función de su estado actual, realiza acciones como parte de su respuesta y
transiciones a un nuevo estado). Las máquinas de estados se representan en un diagrama de estados.
La visión de la interacción de los objetos de un sistema es una colaboración: una vista, dependiente de
contexto, de los objetos y los enlaces entre ellos, junto con el flujo de mensajes entre los objetos mediante
los enlaces de datos. Este punto de vista unifica la estructura de los datos, el control de flujo y el flujo de
datos en una sola vista. Las colaboraciones e interacciones se muestran mediante los diagramas de
secuencia y los diagramas de colaboración. Guiando todas las vistas de comportamiento se encuentra un
conjunto de casos de uso. Cada uno es una descripción de una porción de la funcionalidad del sistema
como la percibe un actor, un usuario externo del sistema.
Construcciones de implementación
Los modelos de UML tienen significado para el análisis lógico y para la implementación física. Ciertos
constructores representan elementos de implementación. Un componente es una parte física reemplazable
de un sistema y es capaz de responder a las peticiones descritas por un conjunto de interfaces. Se
pretende que sea fácilmente sustituible por otro componente que cumpla la misma especificación. Un nodo
es un recurso computacional que define una localización durante la ejecución del sistema.
Pueden contener componentes y objetos. La vista de despliegue describe la configuración de los nodos
de un sistema en ejecución y la organización de los componentes y objetos en él, incluyendo posibles
migraciones de contenido entre nodos.
Organización del modelo

Los ordenadores pueden manejar grandes modelos "planos", pero los humanos, no. En un sistema grande,
la información del modelo debe ser dividida en piezas coherentes, para que los equipos puedan trabajar en
las diferentes partes de forma concurrente. Incluso en un sistema más pequeño, el conocimiento humano
requiere que se organice el contenido del modelo en paquetes de tamaño modesto. Los paquetes son
unidades organizativas, jerárquicas, y de propósito general de los modelos de UML.
Pueden usarse para almacenamiento, control de acceso, gestión de la configuración, y construcción de

bibliotecas que contengan fragmentos de código reutilizable. Una dependencia entre paquetes resume las
dependencias entre los contenidos del paquete. Una dependencia entre paquetes puede ser impuesta por la
arquitectura global del sistema. Por lo tanto, los contenidos de los paquetes deben adaptarse a las
dependencias del paquete y a las impuestas por la arquitectura del sistema.
Los Diagramas de UML
El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas.
Debido a que UML es un lenguaje, contiene reglas para combinar estos elementos.
La finalidad de los diagramas es presentar diversas perspectivas de un sistema a las cuales se las conoce
como modelos. El modelo de UML de un sistema es similar a un plano de un arquitecto de un edificio, sólo
desde del punto de vista de qué hará y cómo lo hará, pero sin especificar cómo se desarrollará. Veamos
ahora cuales son los diferentes diagramas:
Diagrama de Casos de Uso:

Aceptado por la comunidad usuaria de Objetos y por muchos metodologistas.
De empleo en la etapa de relevamiento para captar los requerimientos de los usuarios.
De fácil comprensión por parte de los usuarios de los sistemas.
Herramienta que precisa otras complementarias para ser utilizada en procesos de modelación OO.
Diagrama de Clases:
Proviene de los diagramas de entidad-relación. Fueron extendidos con conceptos de Análisis Orientado a Objetos.
Incorporados por los autores orientados a las características de los objetos. Permiten modelar la estructura estática de los
sistemas. Utilizados en el UML para la construcción de los modelos de datos
Diagrama de Secuencia:
Es uno de los dos diagramas de interacción que propone el UML.
Describe la forma en la que colaboran entre sí los objetos para llevar a cabo sus respectivas responsabilidades.
Cada diagrama representa la funcionalidad de un único caso de uso.
Permite ver cómo se suceden cronológicamente los mensajes entre los objetos.Fueron utilizados por los tres autores del UML
en sus respectivos métodos previos.
Diagrama de Colaboración:
Es otro de los diagramas de interacción que se incluye en el UML.
No permite observar gráficamente la cronología de los mensajes.
Facilita la organización de los objetos en paquetes.
Destaca la conexión estática entre los objetos.
Diagrama de Estados:
Describe los estados posibles en la vida de los objetos de una clase.
Permite observar cómo cambian de estado los objetos a medida que ocurren los eventos.
Cada diagrama se utiliza para representar el ciclo de vida de los objetos de una única clase.
Diagrama de Actividades:
No posee antecedentes claros entre las herramientas de los autores del UML en sus propios métodos.
Proviene de varias técnicas, como diagramas de eventos de Odell y redes de Petri.
Permite destacar y sincronizar las operaciones concurrentes y establecer caminos alternativos.
Muestra el comportamiento combinado de varias clases, aunque éstas no se identifican si no se lo hace explícitamente.
Al igual que los diagramas de estado, se emplea para describir comportamientos complejos.
Son usualmente utilizados para modelar la lógica de operaciones y métodos de clase.
Diagrama de Componentes:
Este diagrama, junto al de despliegue, corresponde al grupo de herramientas de implementación del UML.
Representa módulos físicos de código.
Es importante que cada componente sea equivalente a un paquete.
De esta manera, las dependencias entre componentes con las mismas que las existentes entre los paquetes
Diagrama de Despliegue:
Es la segunda herramienta de implementación del UML.
Muestra las relaciones entre los componentes de hardware y software del sistema.
Permite observar dónde se encuentran físicamente los paquetes en el sistema.
Otras herramientas complementarias al modelado en UML

Complementan a los diagramas de UML y permiten revisar aspectos funcionales y de diseño que quedan
fuera del alcance de los mismos. Son muy utilizadas en los equipos de análisis y desarrollo de sistemas en
donde UML se utiliza principamente como una herramienta de documentación y control, y el diseño no tiene
objetivos de ingeniería.
Interactiva "Herramientas complementarias al modelado UML"
Lista de Requerimientos:
Es un detalle de las funcionalidades que abarcará el sistema.
Suele hacerse antes que cualquier modelo o diagrama.
Debe ser lo más descriptiva posible, ya que sirve de base para confeccionar los primeros modelos del análisis.
Detalla aspectos funcionales que condicionan directamente el diseño, pero también permite documentar aquellos aspectos que
deben ser tenidos en cuenta en otras etapas del desarrollo.
Ficha de Caso de Uso:
Detalla paso a paso el funcionamiento de un caso de uso, centrado en la interacción con el usuario.
Facilita la comprensión del resto de los modelos.
Establece los cursos normales, alternativos y las excepciones en el desarrollo funcional del caso de uso.
Se documenta en una plantilla estandarizada. Existen varios modelos.
Permite registrar muchos datos necesarios en las normas de calidad (versionamiento, fechas, autores, dependencias, etcétera).
Prototipo de Interfaz:
Es un modelo simplificado de una interfaz del sistema (pantallas, informes, listados, displays especiales).
Se utiliza principalmente en fase de diseño, aunque es muy útil su elaboración en fase de análisis para interactuar con el usuario.
Permite inferir el funcionamiento del sistema, aunque no es un modelo dinámico.
Es de mucha utilidad para identificar objetos, métodos y atributos.
Casos de Prueba:
Son documentos estandarizados que se utilizan principalmente en la etapa de Prueba o Testing del sistema.
Detallan el tipo de prueba a realizar, y los aspectos a controlar.
También se utiliza para documentar el resultado de las pruebas, así como otros datos necesarios en normas de calidad.
Es un feedback muy importante para las etapas de análisis, diseño y construcción.
Al igual que la Ficha de Caso de Uso, es una planilla estandarizada y existen varios modelos.
Es importante recalcar que en un modelo UML no es necesario que aparezcan todos los diagramas. De
hecho, la mayoría de los modelos UML contienen un subconjunto de los diagramas indicados.
La gran diversidad de diagramas propuestos por el lenguaje tiene como principal objetivo satisfacer las
diferentes perspectivas que le dan las personas implicadas en el proyecto, es decir, las diferentes vistas
Las Vistas de UML
La visualización, especificación, construcción y documentación de un sistema con gran cantidad de software

requiere que el sistema sea visto desde varias perspectivas. Diferentes usuarios (finales, analistas,
desarrolladores, integradores de sistemas, encargados de pruebas, encargados de documentación y
jefes de proyectos) siguen diferentes agendas en relación al proyecto, y cada uno mira a ese sistema de
formas diferentes en diversos momentos a lo largo de la vida del proyecto.
Estas perspectivas se denominan vistas, y son representadas por un conjunto determinado de modelos que
representan el alcance y el objetivo de las mismas. Podemos decir que una vista es una proyección de un
modelo, que se ve desde una perspectiva o un punto de vista dado, y que omite entidades (o elementos del
modelo) que no son relevantes desde esa perspectiva. Las vistas pueden ser establecidas con varios
criterios, y justamente esa es su razón de ser, pero existen vistas ya establecidas en UML que son de uso
general y se encuentran suficientemente documentadas. Estas son la vista Estática, la vista Dinámica y la
vista de Arquitectura.
Vista Estática
La vista estática nos muestra aspectos que tienen que ver con la estructura del sistema, y por eso se conoce
también como vista estructural. Los diagramas de esta vista son los que nos permiten enfocarnos en los
elementos que forman parte de nuestro sistema. Un ejemplo ajeno a UML, pero análogo a esta estructura
sería el DER, en el modelado de bases de datos relacionales. Pertenecen a esta vista en UML los siguientes
diagramas:
Diagrama de Clases
Diagrama de Componentes
Diagrama de Despliegue
Vista Dinámica
Es la perspectiva representada por los modelos que nos permiten entender al sistema desde un punto de vista
de su comportamiento, es decir de ejecución. También es conocida como vista de comportamiento. Como otro
ejemplo análogo, fuera de UML, podríamos citar un Diagrama de Flujo o un Cursograma, donde se presentan los
elementos pero enfocándose en su interacciones. Los diagramas UML de la vista dinámica son:
Diagrama de Casos de Uso
Diagrama de Secuencia
Diagrama de Colaboración
Diagrama de Estados
Diagrama de Actividades
Vistas de Arquitectura
La arquitectura de un sistema es quizás la referencia más importante que puede emplearse para manejar
estos diferentes puntos de vista y controlar el desarrollo iterativo e incremental de un sistema a lo largo de
su ciclo de vida. No tiene que ver solamente con la estructura y el comportamiento, sino también con el uso,
la funcionalidad, el rendimiento, la capacidad de adaptación, la reutilización, la capacidad de ser
comprendido, las restricciones económicas y de tecnología y los aspectos técnicos.
Como muestra la Figura 1-3-2 * 4.3 , la arquitectura de un sistema con gran cantidad de software puede
describirse mejor a través de cinco vistas interrelacionadas. Cada vista es una proyección de la
organización y estructura del sistema, centrada en un aspecto particular del mismo, y puede estar
representada por varios diagramas de UML.
• Vista de Casos de Uso: esta vista comprende los casos de uso que describen el comportamiento del sistema tal y como es
percibido por los usuarios finales, analistas y encargados de pruebas. Esta vista no especifica realmente la organización de un
sistema, más bien, existe para especificar las fuerzas que configuran la arquitectura del mismo. Con UML, los
aspectos estáticos de esta vista se capturan en los diagramas de Casos de Uso; los aspectos dinámicos de esta
vista se capturan con los diagramas de Interacción, Estados y Actividades.
• Vista de Diseño: abarca las clases, interfaces y colaboraciones que forman el vocabulario del problema y su solución. Esta vista
soporta principalmente los requisitos funcionales del sistema, entendiendo por ello los servicios que el sistema debería
proporcionar a los usuarios finales. Con UML, los aspectos estáticos de esta vista se capturan en los diagramas
de Clases, y los aspectos dinámicos en los diagramas de Estados, Interacción y Actividades.
• Vista de Procesos: comprende los hilos y procesos que forman los mecanismos de sincronización y concurrencia del sistema.
Esta vista cubre principalmente el funcionamiento, capacidad de crecimiento y rendimiento del sistema. Con UML sus aspectos
estáticos y dinámicos de esta vista se capturan en el mismo tipo de diagramas que la vista de diseño, pero con énfasis en las
clases activas que representan estos procesos.
• Vista de Implementación: incluye los componentes y archivos que se utilizan para ensamblar y hacer disponible el sistema físico.
Esta vista se preocupa principalmente de la gestión de configuraciones de las distintas versiones de un sistema, a partir de
componentes y archivos un tanto independientes y que pueden ensamblarse de varias formas para producir un sistema en ejecución.
Con UML, los aspectos estáticos de esta vista se capturan en los diagramas de Componentes, mientras que los
aspectos dinámicos en los diagramas de Interacción, Estados y Actividades.
• Vista de despliegue: contiene los nodos que forman la topología hardware sobre la que se ejecuta el sistema. Esta vista se
preocupa principalmente de la distribución, entrega e instalación de las partes que constituyen el sistema físico. Con UML, los
aspectos estáticos de esta vista se capturan en los diagramas de Despliegue, y los aspectos dinámicos en los diagramas de
Interacción, Estados y Actividades.
Cada una de estas cinco vistas puede existir por sí misma, de forma que diferentes usuarios puedan centrarse en
las cuestiones de la arquitectura del sistema que más les interesen. También, las vistas pueden interactuar entre
sí, por ejemplo: los nodos de la vista de despliegue contiene componentes de la vista de implementación, que, a
su vez, representa la realización física de las clases, interfaces, colaboraciones y clases activas de las vistas de
diseño y procesos. UML permite modelar cada una de estas cinco vistas y sus interacciones.
Vista : Es una proyección de un modelo, que se ve desde una perspectiva o un punto de vista dado, y que omite entidades
(o elementos del modelo) que no son relevantes desde esa perspectiva.
El diagrama de UML secuencia pertenece a la vista:
X Dinámica
○ Estática
El diagrama de UML colaboración pertenece a la vista:
X Dinámica
○ Estática
El diagrama de UML clases pertenece a la vista:
○ Dinámica
X Estática
El diagrama de UML actividades pertenece a la vista:
X Dinámica
○ Estática
El diagrama de UML casos de uso pertenece a la vista:
X Dinámica
○ Estática
El diagrama de UML componentes pertenece a la vista:
○ Dinámica
X Estática
El diagrama de UML despliegue pertenece a la vista:
X Estática
El diagrama de UML estados pertenece a la vista
X Dinámica
○ Estática
La primera versión de UML fué creada en 1996 mediante la unificación de las tres metodologías OO
más utilizadas.
X Verdadero
○ Falso
La Ficha de Caso de uso no es un modelo de UML, pero se documenta en una plantilla
estandarizada. X Verdadero
○ Falso
SP1 / H4: El Proceso Unificado de Desarrollo de Software
En la ingeniería de software el objetivo es construir un producto de software o mejorar uno existente.
Un proceso efectivo nos proporciona las normas para que este desarrollo sea eficiente, captura y
presenta las mejores prácticas que la tecnología permite, y en consecuencia reduce el riesgo y hace
los proyectos más predecibles.
El proceso de desarrollo para que sea útil, tiene que servir de guía para todos los participantes del
proyecto, entiéndase como participantes a los usuarios, clientes, programadores, etc.
Un proceso de desarrollo de software debería ser capaz de evolucionar durante muchos años
Proceso de Desarrollo de Software (Figura 1-4-1)
Proceso Unificado de Desarrollo de Software

El proceso que estudiaremos es el definido por Booch, Jacobson y Rumbaugh, comocido como Proceso
Unificado de Desarrollo de Software o por su sigla en idioma inglés RUP (Rational Unified Process). Para
empezar, tenemos que decir que este proceso está formado por un conjunto de actividades necesarias
para transformar los Requerimientos del Usuario en un sistema de información que sea de utilidad para
éstos.
Sin embargo este proceso además aporta un marco de trabajo genérico que nos permite trabajar con una
gran variedad de sistemas de software, diferentes áreas de aplicación, diferentes tamaños de proyectos y
diferentes niveles de aptitud de los mismos.
El Proceso Unificado de Desarrollo: Fases y Flujos de Trabajo (Figura 1-4-2)

Algunas características de Proceso Unificado de Desarrollo:
Usa los modelos de UML, los cuales proporcionan representaciones ricas desde el punto de
vista semántico.
Es un proceso iterativo e incremental.
La documentación se puede mantener y controlar electrónicamente con el uso de
herramientas CASE.
Minimiza la sobrecarga asociada con la generación y mantenimiento de la documentación.
Está centrado en la arquitectura.
Las actividades de desarrollo están dirigidas por los Casos de Uso.
Soporta técnicas orientadas a objetos.
Es un proceso configurable.
Impulsa un control de calidad del software.
A nivel de las actividades, existen premisas fundamentales para este proceso que definen al mismo
como único, estas son:
Dirigido por Casos de Uso: un sistema de software nace para dar servicio a los usuarios, caso
contrario no se justifica su existencia. Por lo tanto debemos construir software que soporte lo que
los usuarios necesitan y esperan, tanto en el presente como en el futuro. Los casos de uso
representan la interacción entre los usuarios y el sistema, teniendo en cuenta que los usuarios no
solo pueden ser humanos sino máquinas u otros componentes de software, y que los casos de uso
son un fragmento de funcionalidad del sistema que representa algunos requisitos del usuario, por lo
tanto todos los casos de uso juntos representan la funcionalidad total del sistema. Pero no solo
sirven para representar los requisitos, sino también guían el diseño, la implementación y las
pruebas, con lo cual podemos decir que guían el proceso de desarrollo del software.
Centrado en la Arquitectura: un sistema que tiene una buena arquitectura, es aquel que tiene
integridad conceptual, entendida esta como la buena estructura de objetos y clases, que permita
al software extenderse, reorganizarse, que sea mantenible y pueda probarse. Para que el
sistema tenga estas características deberá tener:
Capas de abstracción bien definidas.
Clara separación de intereses entre la interfaz y la implantación.
Arquitectura simple.
Mantener un equilibrio entre las decisiones estratégicas y tácticas.
Iterativo: se conoce como desarrollo iterativo el acto de revisar un resultado previo para ser
luego modificado. Desarrollo iterativo apoya rehacer porciones del sistema. La idea detrás del
desarrollo iterativo es revisar parte del sistema de forma controlada para remover errores o
hacer mejoras basadas en la retroalimentación del usuario. Después de cada iteración, se
evalúa el resultado y se planea, en la iteración siguiente, mejorar el sistema y la calidad del
diseño.
Incremental: se conoce como desarrollo incremental el acto de incrementar o añadir desarrollo.
Desarrollo incremental apoya dividir los sistemas para desarrollarse en diferentes momentos con
el objeto de obtener progreso en pequeños pasos.
Visión general del Proceso, sus áreas conceptuales, sus fases y

sus flujos de trabajo
¿cómo hacemos para llegar a construir código ejecutable?

La respuesta son los modelos que tenemos que construir en todo el proceso de desarrollo.
¿Cuáles son estos modelos y donde encajan en cada etapa de desarrollo?.
Fases, flujos de trabajo e iteraciones
En el Flujo de Trabajo (ver la Figura 1-4-2

"Proceso unificado de desarrollo (Figura 1-4-2)"
), se presenta el conjunto de etapas que formarán parte del ciclo de vida del desarrollo del software.
Estas etapas, bastante unificadas en los procesos de desarrollo, representan todas las actividades que se
pueden hacer para producir un conjunto particular de modelos dentro del análisis y diseño. En este proceso,
contamos con cinco flujos de trabajo principales: Requerimientos, Análisis, Diseño, Implementación y
Pruebas. Para cada una de ellas, UML propone diagramas específicos que permiten modelar el sistema.
Una Fase es el intervalo de tiempo entre dos hitos importantes del proceso durante el cual se cumplen
un conjunto bien definido de objetivos, se completan artefactos y se toman las decisiones sobre si
pasar a la siguiente fase. las fases son las siguientes:
Interactiva "Fases del proceso unificado de desarrollo"

Iniciación
Es aquella en que la idea inicial para el desarrollo se lleva al punto de estar suficientemente bien fundamentada para comenzar
el trabajo de desarrollo del software. En esta etapa se establece la planificación de tareas del proyecto y se delimitan los
alcances del mismo. Se establecen los criterios de éxito y se estiman los recursos de desarrollo y el costo del proyecto.
También se deberán estimarlos riesgos del proyecto y al menos una arquitectura básica propuesta.
Elaboración
En la elaboración se definen la visión del producto y su arquitectura, a través del análisis del dominio del problema. En esta fase
se expresan con claridad los requisitos del sistema que pueden variar desde enunciados de carácter general hasta criterios
precisos de evaluación, especificando cada uno un comportamiento funcional o no y proporcionando una referencia para las
pruebas.
Construcción: cuando el software se lleva desde una base arquitectónica sustentable a un conjunto de programas ejecutables
disponibles para la comunidad de usuarios. Aquí también los requisitos del sistema y especialmente sus criterios de evaluación
son constantemente reexaminados frente a las necesidades del proyecto.
Transición la transición: es la fase en la cual el software es puesto en las manos de la comunidad de usuarios. El proceso del
software raramente termina aquí, porque incluso durante esta fase el sistema es mejorado continuamente, se erradican errores
de programación, y se añaden características que no se incluían en una versión anterior.
Iteración Una Iteración representa un ciclo de desarrollo completo, desde la captura de requisitos en el análisis hasta la
implementación y pruebas, que produce como resultado la entrega al cliente de un proyecto ejecutable. Cada iteración pasa
por varios flujos de trabajo del proceso, con un énfasis diferente en cada uno de ellos.
Cabe destacar que las fases interactúan permanentemente con los flujos de trabajo, a diferencia de otras
metodologías de modelado, en donde se consideraba que debía terminarse una fase para comenzar con la
otra.
En primera medida, tendremos el modelo de casos de uso, que nos sirve fundamentalmente como contrato
con el cliente ya que transforma los requerimientos de usuario en modelos, y permite entrar a la fase de
análisis. En esta etapa modelaremos las estructuras y los comportamientos básicos del sistema, ya más
concentrados en la parte técnica, es decir el desarrollo propiamente dicho. Luego, en el modelo de diseño,
refinaremos lo realizado en el análisis, transformando los modelos lógicos en físicos, integrando y orientando
el modelado al entorno de implementación.
El modelo implementación, diseña y describe los componentes del software y cómo se insertarán
en el equipamiento que tengamos disponible, a través de los diagramas de componentes y
despliegue.
Por último, el modelo de las pruebas nos permitirá verificar la consistencia, funcionalidad y desempeño del
sistema, basado en los casos de uso, ya que una de las caracterísitas de este proceso era "Dirigido por
casos de Uso"
¿Cuál de estas NO es considerada una FASE dentro del RUP?:
○ Iniciación
XIteración
○ Construcción
○ Elaboración
○ Transición
Una de las ventajas fundamentales del RUP es revisar el sistema (o parte de él) de forma controlada
para remover errores o hacer mejoras basadas en la retroalimentación del usuario. ¿A qué característica
responde?:
X Ser iterativo.
○ Ser dirigido por casos de uso.
○ Ser incremental.
○ Ser centrado en la arquitectura.
○ Ser unificado.
5. Ordenamiento
Ordene siguiendo el Flujo de Trabajo propuesto por el RUP, las siguientes etapas:
Requerimientos
Análisis Diseño
Implementación
Pruebas
ResueltoSP1
Como metodología de desarrollo de software (aplicaciones), y sobre todo tratándose del desarrollo de un
sistema nuevo, tendríamos que proponer la Orientada a Objetos, y utilizar como lenguaje de modelado a
UML, porque es apropiado para modelar sistemas de información de empresas basadas en la web, e
incluso para sistemas en tiempo real muy exigentes.
Es un lenguaje muy expresivo, que cubre todas las vistas necesarias para desarrollar sistemas. Para aplicar
UML de modo eficaz se tendría que recomendar la utilización de las herramientas de modelado para cada
fase en los distintos flujos de trabajo (en la resolución del presente ejercicio no se recomiendan
herramientas de modelado para cada flujo de trabajo por no estar completamente definida la complejidad del
sistema, sí se verá en las próximas situaciones profesionales).
En relación al RUP (Proceso Unificado de Desarrollo) tenemos que decir que los flujos de trabajo, y las
fases son importantes cuando se trata de sistemas de misión crítica, o sistemas complejos ya que nos
ayudan a realizar una mejor gestión del proyecto en todas sus etapas, y nos permiten trabajar de una
manera organizada y bajo el mismo paradigma a todos los integrantes del equipo de desarrollo.
Además, al ser un sistema web, será mas apropiado el modelado orientado a objetos para trabajar con
un lenguaje de programación de páginas también orientado a objetos. Actualmente estos lenguajes,
como Java, Python o Asp .Net, brindan muchos recursos gráficos y tecnológicos para desarrollar
sistemas de última generación
Una de estas no es una Vista de Arquitectura. ¿Cuál es?
○ Casos de Uso X
Dinámica
○ Implementación
○ Despliegue
○ Procesos
En el Proceso Unificado de Desarrollo existen fases, flujos de trabajo e iteraciones. Indique en la lista
siguiente cuál es una fase.
○ Requerimientos
○ Análisis
○ Diseño
X Elaboración ○
Pruebas
Un objeto es cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los métodos
que controlan dichos datos.
○ Verdadero
Falso
Situación profesional 2: Requisitos
Ventel le ha solicitado a la empresa en la que usted trabaja el desarrollo del software que le dé soporte a
sus actividades comerciales. Usted como integrante del equipo de análisis y desarrollo estará a cargo del
relevamiento inicial. Ventel es una empresa que se dedica a la venta telefónica de entradas para
espectáculos tales como obras de teatro, conciertos, musicales, etcétera
Los clientes son atendidos exclusivamente por operadores que se encargan de brindar la información
referente a los espectáculos disponibles.
Los clientes pueden realizar reservas o compras de entradas. Las ventas se realizan únicamente con
tarjeta de crédito y hasta 4 horas de iniciarse la función, en toda operación se debe pedir la autorización a
la Administradora de Tarjetas de Crédito. Una vez obtenida la autorización, se registra la venta y se genera
un cupón que será enviado junto a las entradas del cliente por medio de una empresa de reparto privada.
La rendición del cobro de las entradas a los organizadores se realiza cada 10 días, por intermedio de
Bancos autorizados. Ventel obtiene como ganancia un 12% de las ventas realizadas, la cual se descuenta al
momento de la rendición del cobro. En caso de existir clientes en situación de morosidad, Ventel se encarga
de la Gestión de Cobranzas, a través de su Departamento de Legales.
SP2 / H1: Captura de requisitos
Toda tarea de análisis y diseño de sistemas comienza por las entrevistas iniciales que se mantienen con el
cliente. A partir de ellas usted deberá establecer una metodología de relevamiento y técnicas * 5.1 que
utilizará para ello.
A partir de esas técnicas usted podrá ir adquiriendo mayores conocimientos acerca del sistema de
información de la empresa o de la situación de negocio que se desea analizar. A los efectos de que el
avance en el conocimiento de los requerimientos del sistema sean documentados y puedan ser expuestos al
cliente para su aprobación es que nos introduciremos en los diagramas que proporciona el Proceso
Unificado de Desarrollo de Software.
El Proceso Unificado de Desarrollo de Software (Figura 2-1-1) presenta flujos de trabajo que aparentan
suponer una secuencia de pasos continuos que no tienen retorno aunque esto, en realidad, no sea así.
Ya se mencionó en la situación anterior que cada uno de los flujos de trabajo posee iteraciones que nos
permiten depurar y perfeccionar cada uno de los diagramas.
La captura de requisitos (Requerimientos) dentro del Proceso Unificado de Desarrollo (Figura 2-1-1)
Objetivos de la captura de requisitos
En realidad la captura de requisitos o requerimientos del sistema no es otra cosa que una tarea de
descubrimiento, esta tarea no es fácil, generalmente el ambiente o las circunstancias en las que se realiza
son difíciles. Podemos decir que es tan difícil que la mayoría de las personas que trabajan en un proyecto
comienzan a escribir código de programas, sin saber exactamente qué es lo que debe hacer el programa.
¿Qué posibilidades hay de que en una empresa en la que usted ha sido designado para efectuar el relevamiento
encuentre una persona con un conocimiento global y a la vez detallado para cada una de las funciones que se
deben realizar? La respuesta es obvia, no existe la posibilidad o es mínima. El problema es que las personas que
desarrollan software no lo desarrollan para ellos mismos, lo desarrollan para otras personas: los usuarios. En
general los usuarios se presenta como una fuente imperfecta de información. Los motivos son varios, pero el
principal que podemos mencionar, es que todo sistema tiene múltiples usuarios con diferentes requerimientos,
cada uno de ellos tiene una visión más o menos acabada de lo que debe realizar pero no poseen una visión
global, otro punto a detallar es el que es posible que ellos no sepan que en diversos puntos de la empresa se
realizan las mismas tareas, otro punto es que los usuarios no saben qué parte de sus actividades se pueden o
deben informatizar o cómo se pueden automatizar determinados procesos, también puede ocurrir que existan
usuarios que conocen perfectamente lo que hacen pero no saben de qué manera lo que hacen impacta en las
actividades de otros usuarios u otras áreas de la empresa.
Para solucionar estos inconvenientes aparece en escena el Analista de Sistemas, quien en el afán de
satisfacer al cliente comienza a desarrollar el sistema sin tener una visión íntegra y acabada del sistema y
al presentar los avances a los usuarios; es en ese momento donde los usuarios encuentran o ponen de
manifiesto los defectos del relevamiento deficiente. ¿Cuál es el inconveniente que se suscita en este punto?
El inconveniente es que a veces la cantidad de cambios que se deben realizar al programa que se está
evaluando son tantos que se debe iniciar de nuevo el desarrollo de esa pieza.
Lo que propone esta metodología es tomarnos un tiempo prudencial en el inicio y efectuar un trabajo
minucioso de relevamiento de los requerimientos del sistema de información de la empresa y de las
funciones de negocio que se desarrollan en cada una de las áreas involucradas en el relevamiento.
Aún así, la captura de los requisitos sigue siendo una de las tareas más difíciles por lo que se trata de
aportar un buen proceso que sea sistemático para llegar a un buen final.
El papel de los requisitos en el ciclo de vida software

El propósito del flujo de trabajo dentro del ciclo de vida del software es guiar al desarrollador hacia la
construcción de un sistema correcto. La única forma de lograr esto es a través de una descripción acabada
de los requisitos del sistema, las condiciones en las que operará, las capacidades que se le requerirán con
el objeto de poder determinar claramente qué debe hacer el sistema y qué no debe hacer el sistema.
La única manera que poseemos para lograrlo es que el usuario (que asumimos que es un especialista en
las funciones que estamos relevando, pero que no es un informático) debe ser capaz de interpretar o
entender los resultados de la captura de requisitos. Esto nos obliga a tener que utilizar el lenguaje del
cliente al describir esos resultados con ellos.
Debe asumirse desde un comienzo que cada proyecto de software es diferente. Esta diferencia se
manifiesta
en los tipos de sistemas que se solicitan, en las diferencias propias que existen entre los clientes, en las
diferencias organizativas y en la tecnología a aplicar en cada caso.
El modelo de contexto del sistema mediante un modelo de dominio

El objetivo del modelado de dominio es el de comprender y describir las clases más relevantes o
importantes, que generalmente pueden estar entre 10 y 50, dependiendo de la magnitud del sistema. El
resto de las clases candidatas se almacenan como definiciones en un glosario de términos si no el modelo
de dominio se haría demasiado grande y difícil de comprender.
Por esta razón al Diagrama de Clases de UML se lo conoce también como Modelo de Dominio.
Las clases del modelo de dominio y las que están en el glosario se utiliza para la confección de los casos de uso
y el diseño de los prototipos de interfaz, temas que profundisaremos mas adelante en esta SP. Existe una forma
más sistemática para identificar los casos de uso y encontrar las clases, esta forma es desarrollar un modelo de
negocio. El modelado del negocio describe procesos con el objetivo de comprenderlos, es decir, especifica qué
procesos de negocio soportará el sistema y establece las competencias requeridas en cada proceso: sus
trabajadores, sus responsabilidades y las operaciones que llevan a cabo.
El modelado del dominio describe los conceptos importantes del contexto como objetos del dominio y
enlaza estos objetos con otros objetos; luego estos objetos del dominio nos ayudarán en la identificación
de algunas clases a medida que se analiza y diseña el sistema. Estos objetos pueden obtenerse a partir de
las especificaciones de los requisitos, estos objetos aparecerán de tres formas típicas:
Como objetos del negocio que representan cosas que se manipulan en el negocio, como
por ejemplo, facturas, remitos, pedidos, cuentas, etcétera.
Como objetos del mundo real y conceptos de los que el sistema debe hacer un seguimiento,
como por ejemplo, los recorridos de las líneas de colectivo.
Como sucesos que ocurrirán o han ocurrido, como por ejemplo, la grilla horaria de partidas o
arribos de aviones a un aeropuerto.
La comprensión del contexto del sistema mediante un modelo de negocio

El modo de comenzar con la captura de requerimientos puede ser a través de un modelo de negocio
(negocio que ya está en marcha) o simplemente partir de la idea de negocio de un cliente, quien sólo tiene
una noción de lo que deberá hacer el sistema. Entre estos dos extremos nos moveremos siempre para la
captura de los requerimientos. A pesar de esta diferencia en los puntos de inicio, ciertos elementos son
comunes y nos permiten definir un flujo de actividad. Este flujo de actividad cuenta con una serie de puntos
que no se llevan a cabo separadamente:
Interactiva "Captura de requerimientos"

Enumerar los requisitos candidatos
A lo largo de la vida del sistema, los usuarios, los clientes, los analistas involucrados y los desarrolladores proporcionarán
buenas ideas que podrían convertirse en verdaderos requisitos, se deberá mantener una lista de ellos considerados como
candidatos a implementar en una versión posterior. Esta lista de características crece y decrece a lo largo del tiempo,
crece cuando se incorporan nuevos elementos y decrece cuando algunas de estas características se transforman en
requerimientos.
Comprender el contexto del sistema

Para capturar los requisitos correctos es imprescindible el conocimiento del contexto en el que se emplazará el sistema. Este
conocimiento se lleva a cabo a través del modelado del dominio y del modelado del negocio.
Capturar requisitos funcionales
La técnica siguiente se basa en los casos de uso. Estos casos de uso capturan tanto requisitos funcionales como
no funcionales que son específicos para cada caso de uso. Para el usuario un caso de uso es un modo de utilizar
el sistema, describiendo todos los casos de uso se puede saber que es lo que el sistema debe hacer. Esta captura
de información para poder describir los casos de uso se realizará mediante la entrevista a los usuarios ,
discusiones, generación de propuestas, etcétera. También pueden hacerse especificaciones sobre como se verán
las interfaces de usuario construyendo prototipos. Más adelante, dedicaremos unas líneas a los conceptos a tener
en cuenta con relación a la construcción de prototipos de interfaz. Capturar requerimientos no funcionales
Estos especifican propiedades del sistema o requerimientos que no afectan ni condicionan directamente el análisis, como por
ejemplo restricciones de entorno o de implementación, dependencias de plataforma, facilidad de mantenimiento, uso de
periféricos especiales. Es muy importante detallarlos ya que deben ser contemplados en fases de integración e implementación.
¿Cual de estos Diagramas de UML representa el dominio del sistema analizado?:
○ Diagrama de Casos de
Uso X Diagrama de Clases
○ Diagrama de Colaboración
○ Diagrama de Estados
○ Todos ellos representan el dominio
Uno de estos pasos no forma parte del proceso de captura de requisitos:
○ Enumerar los requisitos candidatos
○ Comprender el contexto del sistema
○ Capturar requisitos funcionales
○ Capturar requerimientos no funcionales

La captura de requisitos en una tarea ardua y difícil de competencia del Analista de Sistemas, y es
clave para capturar las definiciones fundamentales del sistema.
X Verdadero
○ Falso
○
El Modelado del Negocio tiene como principal objetivo la identificación de Casos de
Uso.
X Verdadero

El requisito: “El resultado de una transacción debe demorar menos de 5 segundos” es:
○ Funcional

El requisito: “El sistema deberá permitir cancelar una transacción a pedido del usuario”
es: X Funcional
○ No Funcional
El requisito: “La interfaz deberá permitir implementar lectora de código de barra” es:
○ Funcional

El requisito: “Una vez confirmada la transacción, el sistema deberá emitir un comprobante
impreso automáticamente” es:
X Funcional
○ No Funcional
El requisito: “La pantalla deberá permitir buscar los datos por código y por descripción”
es: X Funcional
○ No Funcional
SP2 / H2: El Modelo de Casos de Uso
El objetivo de realizar los casos de uso utilizando la lista de requerimientos es la construcción de un modelo
del sistema que se va a confeccionar; ésto se lleva a cabo a través de los requisitos funcionales que se
estructuran de manera natural en casos de uso. A través de la utilización de los casos de uso, los analistas
se ven obligados a pensar en quiénes son los usuarios y que necesidades de la empresa deben cumplir.
El modelado de los casos de uso permite a quienes se encargan del desarrollo del software y a los
clientes acordar los requisitos (condiciones y posibilidades) que debe cumplir el sistema y proporciona
una visión acordada para el inicio del análisis, diseño y prueba. Puede decirse que es el diagrama más
utilizado en forma conjunta con el cliente ya que permite que tanto el analista como él lleguen a un
entendimiento sobre lo que debe hacer el sistema.
El Diagrama de Casos de Uso

La vista de los casos de uso debe capturar el comportamiento de un sistema o de un subsistema, o más en
detalle aún, el comportamiento de una clase, tal como se la debe mostrar a un usuario. Describe la
funcionalidad del sistema en transacciones significativas para los actores (usuarios de un sistema). Podemos
decir también que los casos de uso son una técnica para especificar el comportamiento de un sistema.
Todo sistema de software desarrollado ofrece a sus usuarios una serie de servicios para registrar o
resolver diferentes situaciones de negocio.
Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando
decimos "alguien o algo" hacemos referencia a que los sistemas son usados no sólo por personas, sino
también por otros sistemas de hardware y software.
Si tuviéramos que definirlos, diríamos que: "Un caso de uso es una secuencia de interacciones entre
un sistema y alguien o algo que usa alguno de sus servicios, representado como una unidad
funcional y sistémica."
Los casos de uso hacen foco en su análisis en situaciones de negocio bien definidas y pequeñas, por lo que es
importante conocer bien a fondo las partes en que se desglosa cada una de las funcionalidades interactivas.
Las partes en que se desglosa la funcionalidad interactiva se llaman casos de uso. Por lo tanto un caso de
uso describe una interacción del sistema con los actores como secuencia de mensajes entre el sistema y
uno o más actores. El término actor que utilizamos incluye a los seres humanos, así como a otros sistemas
informáticos y procesos y se utiliza no para determinar "quién" sino para definir el rol que está desarrollando
quien se encuentra operando el sistema en esas funciones.
Cada vez que un actor usa el sistema para una determinada acción, está haciendo uso de un caso de uso y
este especifica el comportamiento de "cosas" dinámicas (objetos).
La siguiente figura (tomada de "El Lenguaje Unificado de Modelado" de Booch, Jacobson y Rumbaugh)
muestra un diagrama de casos de uso simplificado, para una aplicación de compra telefónica, similar a la de
la SP planteada.
Diagrama de Casos de Uso (Figura 2-2-1)
Actor
Un actor es la representación en forma ideal de una persona externa, de un proceso, o de cualquier cosa que
interactúa con un sistema, un subsistema, o una clase. Un actor es una agrupación uniforme de personas,
sistemas o máquinas que interactúan con el sistema que estamos construyendo de la misma forma. El actor
representa las interacciones que los usuarios pueden tener con el sistema. Diferentes usuarios pueden estar
identificados al mismo actor y por lo tanto pueden representar casos múltiples de la misma definición de actor.
Por ejemplo, para la empresa de ventas telefónicas, todos los operadores que reciban pedidos y los
ingresen en un sistema de ventas, si pueden hacer las mismas cosas con el sistema, deben ser
considerados como un único actor: Empleado de Ventas.
Cada actor puede participar en uno oás casos de uso. El actor interactúa con el caso de uso (y por lo
tantocon el sistema o la clase que posee el caso de uso), intercambiando mensajes. Los actores pueden ser
definidos también en jerarquías de generalización, en las cuales una descripción abstracta del actor es
compartida y aumentada por una o más descripciones específicas del actor.
Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamos
empezando a delimitar el sistema, y a definir su alcance. Definir el alcance del sistema debe ser el primer
objetivo de todo analista, ya que un proyecto sin alcance definido nunca alcanzará sus objetivos.
Es importante destacar la diferencia que existe entre usuario y actor. Un actor es una clase de rol, mientras
que un usuario es la persona que hace uso el sistema, y por lo tanto asume un rol. De este modo, un
usuario puede acceder al sistema como distintos actores, ejecutando diferentes casos de uso. La forma más
simple de entender esto es pensar en perfiles de usuario de un sistema operativo. Una misma persona
puede acceder al sistema con distintos perfiles, que le permiten hacer cosas distintas.
En el caso de que otro sistema sea el que interactúa con el que estamos construyendo, ese sistema
también es un actor. Por ejemplo, si en nuestro sistema de la situación profesional, el sistema de
autorización de tarjetas de crédito será una actor, que usa los servicios de nuestro sistema.
Como se ve en la Figura 2-2-2, un actor se representa como una persona pequeña con trazos lineales
y el nombre del rol que desarrolla debajo de él.
En el caso de actores que no sean roles de usuarios, por ejemplo otros sistemas o procesos,
pueden representarse con otro icono diferente que nos permita comprender de que se trata.
Ejemplos de Actores (Figura 2-2-2)
Identificar a los actores es el primer paso para usar la técnica de casos de uso. Por ejemplo, en el sistema de
ventas de entradas, conociendo prácticamente pocos detalles sobre cómo funcionará, podemos decir que:
El grupo de usuarios que ingrese las reservas y ventas al sistema será un actor.
El grupo de usuarios que desarrolle otras operaciones, como por ejemplo crear
nuevos espectáculos, asignar nuevas funciones, etcétera, será un actor.
Todo grupo de usuarios que reciba informes o reportes del sistema, como por ejemplo
estadísticas de las ventas, será un actor.
Todos los actores participan de los casos de uso y también es lógico que existan intersecciones entre lo
que hacen los distintos actores. Tomemos por ejemplo el caso en que una operación deba ser autorizada
por un supervisor, pero también el supervisor puede realizar dicha operación.
Caso de uso
Un caso de uso es una unidad coherente de funcionalidad, externamente visible, proporcionada por una
unidad del sistema y expresada por secuencias de mensajes intercambiados por la unidad del sistema y uno
o más actores.
El propósito de un caso de uso es definir un bloque de comportamiento coherente, sin definir la estructura
interna del sistema. La definición de un caso de uso debe incluir todo el comportamiento que implica: las
líneas principales, las variaciones que pudiera haber sobre el comportamiento normal, y todas las
condiciones excepcionales que pueden ocurrir con tal comportamiento, junto con la respuesta deseada.
En el modelo, la ejecución de cada caso de uso es independiente de las demás, aunque, como
normalmente ocurre, una implementación de casos de uso puede crear dependencias implícitas entre ellas,
debido a que los objetos involucrados son compartidos. Cada caso de uso representa una pieza de la
funcionalidad del sistema, cuya ejecución se puede mezclar con la ejecución de otros casos de uso.
Veremos más adelante que cuando se implementa un caso de uso, estos son realizados mediante la
colaboración entre clases del sistema. Una clase puede participar en múltiples colaboraciones y, por lo
tanto, en múltiples casos de uso.
Un caso de uso es como una operación de sistema, una operación que es llamada o invocada por un
usuario exterior. Sin embargo, a diferencia de una operación, un caso de uso puede continuar recibiendo la
entrada de sus actores durante su ejecución. Los casos de uso también se pueden aplicar internamente a
unidades más pequeñas de un sistema, tales como subsistemas y clases individuales.
Un caso de uso es una descripción lógica de una parte de funcionalidad del sistema. El comportamiento
del caso de uso se corresponde con las transiciones y operaciones de las clases. Ya que una clase
puede desempeñar roles múltiples en la implementación de un sistema, puede por lo tanto realizar
porciones de múltiples casos de uso. Una parte de la tarea del diseño es encontrar las clases de
implementación que combinen claramente los roles apropiados para implementar todos los casos de uso,
sin introducir complicaciones innecesarias. La implementación de un caso de uso se puede modelar
como un conjunto de una o más colaboraciones. Una colaboración es una realización de un caso de uso.
Un caso de uso es iniciado por un actor. A partir de ese momento, ese actor, junto con otros
actores, intercambian datos o control con el sistema, participando de ese caso de uso.
El nombre de un caso de uso se expresa con un verbo en gerundio o infinitivo (lo importante es que su nombre
sea explícito y represente una acción concreta), seguido generalmente por el principal objeto o entidad del sistema
que es afectado por el caso. Gráficamente, los casos de uso se representan con un óvalo, con el
nombre del caso en su interior, como se observa en las Figuras 2-2-1
"Diagrama de Casos de Uso (Figura 2-2-1)" y 2-2-2Ejemplos de Actores (Figura 2-2-2)"
.
Tenga siempre presenta que el nombre del caso siempre está expresado teniendo en cuenta el punto de
vista del actor y nunca desde el punto de vista del sistema.
Los casos de uso tienen las siguientes características:
Están expresados desde el punto de vista del actor.
Se documentan con texto informal.
Describen tanto lo que hace el actor como lo que hace el sistema cuando se interactúa con
él, aunque el énfasis está puesto en la interacción.
Son iniciados por un único actor.
Están acotados al uso de una determinada funcionalidad, claramente diferenciada, del sistema.
Relaciones entre Casos de Uso

Como ya vimos, en un sistema analizado con mediante un proceso "guiado por casos de uso", existirán muchos
de ellos, cuya cantidad dependerá de la complejidad del sistema, del alcance del mismo y del nivel de
análisis y diseño desarrollados. Estos casos de uso identificados pueden necesitar interactuar entre sí,
siendo necesario en este caso establecer dependencias o asociaciones funcinales. Por ejemplo: en un caso
de uso que permite registrar productos en el sistema (CU1), podremos necesitar opcionalmente consultar
proveedores (CU2), con el fin de especificar el proveedor correspondiente a ese producto. En nuestro
análisis, esta situación requerirá establecer una relación entre los casos de uso CU1 y CU2.
También, al momento de diseñar un caso de uso determinado, nos veremos en la necesidad de "dividirlo" en
unidades funcionales mas simples, cuyo uso facilitará posteriormente el análisis del sistema y la construcción
del software. Estas unidades funcionales (que también por definición son casos de uso), se integrarán al caso
de uso principal (o caso de uso base) mediante relaciones. Usemos el mismo ejemplo anterior: el caso de uso
registrar productos (CU1), demandará para su funcionamiento de ciertos servicios (validaciones, obtención de
datos externos, impresiones, ejecución de transacciones, etc.), como por ejemplo obtener la fecha del sistema
(CU2), registrar datos en la base de datos (CU3) o limpiar pantalla (CU4).
Los casos de uso deben poder organizarse a través de una especificación para evitar los problemas de
redundancia, es decir, no duplicar de manera innecesaria la información, las estructuras y los
comportamientos; y por otro lado para hacer que su comprensión sea sencilla. Esto se logra a través de la
identificación de los tipos de relaciones que se establecerán entre los casos de uso. Estas relaciones pueden
ser relaciones de extensión o relaciones de uso o inclusión.
Relaciones de Extensión
Puede ocurrir que algunas veces, la funcionalidad de un caso de uso incluye un conjunto de pasos que
ocurren sólo en algunas oportunidades.
Supongamos que estamos especificando para nuestro sistema de venta de entradas, en el cual los clientes
deben proporcionar la identificación de su tarjeta de crédito, y que dentro de la funcionalidad de ventas, el
empleado puede mostrarle un plan de promociones que están asociadas a un determinado plan de esa
tarjeta de crédito.
En este caso, tenemos una excepción dentro del caso de uso Vendiendo Entradas. La excepción consiste en
interrumpir el caso de uso y pasar a ejecutar el caso de uso Mostrando Promociones de Tarjetas. En este
caso decimos que el caso de uso Mostrando Promociones de Tarjetas extiende el caso de uso Vendiendo
Entradas y se representa por una línea de trazos desde el caso que ‘extiende a’ al caso que es ‘extendido’.
Tal como se muestra en la siguiente figura.
Relación de extensión entre Casos de Uso (Figura 2-2-
Las extensiones tienen las siguientes características:

Representan una parte de la funcionalidad del caso que no siempre ocurre.
Son un caso de uso en sí mismas.
No necesariamente provienen de un error o excepción.
En la práctica siempre aparecen dudas con respecto a la correcta consideración de las alternativas o las
extensiones, sobre todo porque no queda claro si algo puede ser visto como un caso de uso en sí mismo o
no. La respuesta puede derivarse de las características de cada uno:
Si una funcionalidad es opcional, generalemte debe ser expresado con más de un paso,
entonces seguramente es una extensión y no una alternativa.
Una extensión es un caso de uso en sí mismo, mientras que una alternativa no.
Una alternativa es un error o excepción, mientras que una extensión puede no serlo.
Relaciones de Uso o Inclusión

Puede ocurrir y de hecho es muy común que la misma funcionalidad del sistema deba ser accedida desde
varios casos de uso. Por ejemplo, la funcionalidad de buscar un espectáculo puede ser accedida desde la
venta de entradas, las reservas de entradas, desde las consultas de espectáculos, o desde los reportes de
espectáculos. ¿Cómo hacemos para no repetir el texto de esta funcionalidad en todos los casos de uso que
requieren de ella?
La respuesta es muy simple: se debe sacar esta funcionalidad a un nuevo caso de uso, que es usado (o
incluido) por los casos de los cuales fue sacada. Este tipo de relaciones se llama relaciones de uso o include
y se representa por una línea punteada desde el caso que "usa a" al caso que es "usado"
Decimos, por ejemplo, que el caso de uso Obteniendo reporte de ventas por espectáculo usa al caso de
uso Buscando espectáculo.
Relación de inclusión entre Casos de Uso (Figura 2-2-4)
Este concepto no debe ser novedoso para usted, es simplemente el concepto de la subrutina o
subprograma usado en un nivel más alto de abstracción.
Las características de las relaciones de uso o inclusión son:
Aparecen como funcionalidad común, luego de haber especificado varios casos de uso.
Los casos usados son casos de uso en sí mismos.
El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca la diferencia con
las extensiones, que son opcionales.
La bibliografía no es muy clara en relación a estas relaciones por lo que creemos conveniente que este tipo
de situaciones se especifiquen como extensiones, puesto que de esta forma se podrá remarcar
gráficamente la opcionalidad de la relación.
Diagrama de Asociaciones o Relaciones

A los efectos de representar las relaciones de caso de uso dentro de un alcance acotado y específico, por
ejemplo en el análisis de de un caso de uso determinado, son muy utilizados los Diagramas de Asociaciones o
Relaciones. Este diagrama es una variante del diagrama de caso de uso * 6.1 , en el cual el modelado se
enfoca solamente en las relaciones, sin presentar actores ni límites del sistema. Como podemos ver en la figura
2-2-5, se presenta el caso de uso base (preferentemente destacado del resto), y todos los casos de uso
extendidos e incluidos asociados a él, especificando en cada caso el tipo de relación.
El objetivo de este diagrama no es otro que simplificar la gráfica del modelo, permitiendo "aislar" un caso
de uso y sus asociados directos. Viendo la Figura 2-2-5, imagínense la complejidad gráfica (y por lo tanto
de comprensión) que tendría un diagrama convencional de casos de uso, si tuviera que presentar todas
las relaciones entre todos los casos de uso.
En relación a la Situación profesional planteada, veamos el Diagrama de Asociaciones del caso de

uso "Vendiendo Entradas":
Diagrama de Asociaciones del caso de uso "Vendiendo Entradas" (Figura 2-2-5
Ficha de Caso de Uso

Los casos de uso se documentan con texto informal. Para ello y en general, se usa una lista numerada de
los pasos que sigue el actor para interactuar con el sistema, y la respuesta de este. Esta es una versión
detallada a nivel de caso de uso de la ya estudiada en SP2 / H1: Captura de requisitos, y se suele
documentar en una planilla conocida como Ficha de Caso de Uso o Especificación de Caso de Uso.
Existen varios modelos de plantillas, algunas de ellas estandarizadas bajo normas de calidad para su
uso específico de las áreas de análisis funcional en las empresas. Presentamos aquí dos de los
modelos más utilizados, de las cuales usaremos el primero de ellos en nuestra materia:
parte simplificada de la Ficha del caso de uso "Vendiendo Entradas".
Ficha de especificación simplificada del caso de uso "Vendiendo Entradas" (Figura 2-2-6)
Al describir los casos de uso aparece una de sus principales limitaciones. Debido a que los casos de uso
no describen la funcionalidad interna del sistema, por ejemplo, si tuviésemos una interacción con un
usuario en donde se proporcionan una serie de valores y con ellos se desarrollan complejas operaciones
matemáticas, éstas no se representan en el caso de uso. Para especificar este comportamiento se utiliza
otra notación, que en UML se denomina "Diagrama de Actividad".
Otra de las limitaciones que presentan los casos de uso es que no poseen una sintaxis clara para indicar, dentro
de la descripción del caso, las decisiones e iteraciones. Por ello es común que en las descripciones de los casos
se recurra a frases como "Se repite el paso X hasta que ocurre Z", o "Si ocurre Z se pasa al paso X".
En estas casos lo importante no es la forma en la que se expresan las condiciones e iteraciones, sino
hacerlo de una forma consistente. Si la descripción del caso fuera muy compleja, es conveniente usar
notaciones gráficas, por ejemplo los diagramas de actividad.
Alternativas
Durante la ejecución normal de un caso de uso, pueden aparecer errores o excepciones. Por ejemplo,
mientras se ingresa una venta, el cliente puede solicitar un espectáculo que ya no está disponible. El
sistema deberá en este caso informar esta situación al empleado que se encuentra operando la venta.
Esas desviaciones del curso normal del caso de uso se llaman alternativas. Las alternativas tienen las
siguientes características:
Representan un error o excepción en el curso normal del caso de uso.
No tienen sentido por sí mismas, fuera del contexto del caso de uso en el que ocurren
En toda la bibliografía referida a los casos de uso se expresa que las alternativas se documentan al final del
caso de uso, pero la experiencia ha demostrado lo útil que resulta documentar los casos en las Fichas de
Casos de Uso, mostrando el curso principal en la primera columna, y las alternativas en una segunda
columna, como lo muestra el siguiente ejemplo:
Ficha del caso de uso "Vendiendo Entradas", presentando alternativas (Figura 2-2-7)
De esta manera, es mucho más simple ver en qué momentos del caso de uso ocurrirán las excepciones,
y se mantiene la ventaja de poder leer de corrido el curso normal.
La identificación de los cursos de acción normales y alternativos, especifican y retroalimentan el modelo de
casos de uso, ya que nos permiten identificar nuevas funcionalidades e identificar claramente las relaciones
de inclusión (curso normal) o extensión (generalmente curso alternativo), ya estudiadas.
Tipos de Casos de Uso

A partir de la aplicación de los casos de uso en la práctica, aparecen distintas clasificaciones, que son
útiles según el tipo de sistema o el modelo de ciclo de vida utilizado.
Esenciales o de Trazo Grueso
En el ciclo de vida de desarrollo de sistemas, uno de los modelos que más popularidad posee en la
actualidad es el denominado "modelo incremental", este modelo consiste en sucesivas entregas de
versiones parciales del sistema, que implementan una parte de su funcionalidad.
La recomendación en este caso pasa siempre por identificar todos los requerimientos que uno pueda,
definir sus prioridades, y seleccionar cuáles se irán implementado en cada versión. Sin embargo, no se
pueden especificar en detalle todos los requerimientos: deberemos tener apenas el nivel de detalle
suficiente para poder definir sus prioridades y comprenderlos en términos generales.
Para aplicar los casos de uso a desarrollos incrementales, debemos empezar por identificar todos los casos
de uso del sistema, sólo al nivel de su nombre. Una vez que los identificamos, los expresamos en "trazo
grueso", esto quiere decir que:
Se Ignoran los detalles sobre la forma de la interacción entre el actor y el sistema.
Sólo se incluyen las alternativas más relevantes, ignorando la mayoría de los errores que
aparecen en el uso del sistema.
No entramos en detalle sobre las acciones que realiza el sistema cuando el usuario interactúa
con él. Por ejemplo, si la empresa estableciera una política de descuentos para sus clientes, no
se debe especificar cómo es esa política: basta con saber que existe una y que debe ser tenida
en cuenta.
De este modo, culminamos con una descripción "gruesa" de todos los casos de uso. Esto permite tomar mejor las
decisiones, junto con los usuarios, sobre qué casos de uso se implementarán en cada fase. Además, permite
realizar un análisis sobre los principales aspectos de todos los casos que afectan al diseño.
De Implementación o "Trazo Fino"

Los casos de uso de trazo fino serán aquellos que se especifican una vez que se ha tomado la decisión de
implementarlos. En este momento se deberán completar todos los detalles que dejamos pasar:
A medida que vamos haciendo prototipos de las interfaces con los usuarios, incluimos detalles
sobre la forma de la interfaz en la descripción del caso. Por ejemplo, podemos incluir detalles
como: "el operador puede en cualquier momento pasar de la ventana de datos del cliente a la
ventana de datos del espectáculo". Si bien esto implica anticiparse al diseño, esto no es negativo,
ya que es prácticamente imposible (y perjudicial en ciertos aspectos) hablar con los usuarios
siempre en términos de un sistema abstracto.
Inclusión de otras alternativas. En particular se especifican todos los errores o excepciones que se
detallaron en la lista de requerimientos de los usuarios. Recordemos que para esto debemos tener en
cuenta que un sistema tiene dos tipos de errores o excepciones: las que provienen de las
definiciones del negocio y las que provienen del procesamiento interno del sistema. Por ejemplo,
pensemos en un requerimiento del tipo: "si un cliente hace una compra de entradas y la tarjeta no
está autorizada, se debe rechazar el pedido". Esta excepción es claramente un requerimiento, y debe
ser incluida en las alternativas de los casos de uso. Por el contrario, una excepción del tipo: "Si el
usuario ingresa una letra en el lugar del código de la tarjeta se le informa que el código de la tarjeta
debe ser numérico" no debe ser incluida en esta etapa del análisis.
Se especifica con más detalle el comportamiento interno del sistema. En nuestro ejemplo de las
promociones de las tarjetas, deberíamos especificar cómo es esa política, en un nivel de detalle
suficiente para luego poder diseñar una forma de implementarla dentro del sistema.
Casos de Uso Temporales

Los casos de uso tienen un actor que los inicia, y uno o más actores que participan de él. Pero ocurre que
muchas veces el inicio de una determinada funcionalidad del sistema es provocado exclusivamente por el
paso del tiempo.
Supongamos que nuestro sistema de ventas de entradas debe generar en forma automática un conjunto de
estadísticas para ser entregadas al directorio de la empresa el último día hábil de cada mes. En este caso,
es el paso del tiempo el que inicia el caso de uso, y el directorio es el actor del sistema.
Sin embargo, como se debe expresar taxativamente que es el paso del tiempo el que inicia el caso de
uso, podemos usar una línea punteada en el borde del óvalo del caso.
Ejemplo de caso de uso Temporal (Figura 2-2-8
Es importante que cuando se especifican los casos de uso de trazo fino, se exprese claramente cuál es el
momento del tiempo en el que se inicia el caso. Es común que se indiquen cosas como "una vez al mes" o
"mensualmente" cuando se habla de casos iniciados por el paso del tiempo. Se debe especificar en qué
momento del mes se realizan (el primer día hábil, el primer día calendario, el último día hábil, etc.). De lo
contrario, estamos dejando en los diseñadores la decisión sobre cuándo generar esta salida, y esto no es
correcto, ya que la oportunidad de las salidas del sistema debe ser definida por los usuarios.
Caso de Uso Ambiental

El primer diagrama de caso de uso que se construye cuando se inicia el modelado de requerimientos de
un sistema, es el Diagrama de Caso de Uso Ambiental. Como su nombre lo indica, este diagrama nos
brinda una visión conceptual y contextual del primer caso de uso que tenemos identificado, que es el
objeto de nuestro proceso de análisis: el sistema.
Podemos decir que un sistema en su primer concepto es un caso de uso, ya que cumple con la definición
establecida: "Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de
sus servicios, representado como una unidad funcional y sistémica", aunque es necesario aclarar que a este nivel la
especificación del mismo es muy pobre o de trazo muy "grueso". Sin embargo, la confección de un Diagrama de Caso
de Uso Ambiental en el inicio de la especificación de requerimientos, presenta las siguientes ventajas:
Es el primer nivel de detalle de los diagrama de casos de uso. Es como una "vista aérea" del
sistema, que no presenta el límite del sistema ya que el mismo está dado por el alcance del caso
de uso.
Permite centrarse en la identificación de los actores (usuarios, procesos y sistemas).
No es necesario especificarlo con una Ficha de Caso de Uso, pero sí es muy útil acompañar este
diagrama con la descripción de las interacciones establecidas entre los actores y el sistema, que
serán una guía importante para la identificación de los primeros casos de uso de negocio.
A continuación, la Figura 2-2-9 presenta un posible Diagrama de Caso de Uso Ambiental aplicable a nuestra
Situación profesiona
Ejemplo de Diagrama de Caso de Uso Ambiental (Figura 2-2-9
Una aplicación externa al sistema analizado, cuya función es la de tomar en forma periódica una serie de
datos para ser mostrados en la página web de la empresa, ¿como se modelaría?
X Un actor.
○ Un objeto de control.
○ Un caso de uso con relación de extensión.
○ Un caso de uso con relación de inclusión.
○ Ninguna de las anteriores es correcta.
Si en la especificación de un caso de uso utilizando la Ficha de Casos de Uso se identifican cursos de
acción alternativos que no son producidos por excepciones ni por errores, éstos deberán considerarse
en el diagrama como:
○ No deben ser considerados en el diagrama, para eso está la ficha.

○ Casos de uso incluidos.
○ Casos de uso temporales.
○
Seleccione cuáles de estas afirmaciones sobre los Casos de Uso son falsas:
○ Están expresados desde el punto de vista del actor.
○ Se documentan con texto informal.
○ Están acotados al uso de una determinada funcionalidad del sistema claramente diferenciada.
○
Seleccione cuáles de estas afirmaciones sobre la Relación de Extensión son verdaderas:
X No siempre ocurren durante el curso normal del caso de uso.

X Las funcionalidades extendidas son un caso de uso en sí mismas.
○ Siempre provienen de un error o excepción.
○ Se las denomina también relaciones de “uso”.

De acuerdo al diagrama, identifique el “Límite del Sistema”
X1

De acuerdo al diagrama, identifique la “Relación de inclusión”.
X6

De acuerdo al diagrama, identifique el “Caso de Uso Incluido”.
X5
De acuerdo al diagrama, identifique el “Actor”.
X3
De acuerdo al diagrama , identifique el “Caso de Uso”.
X4

De acuerdo al diagrama, identifique el “Caso de Uso Temporal”.
○ 1X2
SP2 / H3: Captura de requisitos como Casos de Uso
Identificación de los Casos de Uso
Tomando como punto de partida la Lista de Requerimientos ya establecida, describiremos aquí la técnica de
análisis de requerimientos con casos de uso. Esta técnica consiste básicamente en tres pasos: identificar los
Actores, identificar los principales Casos de Uso de cada Actor e identificar nuevos Casos de Uso a partir de
los existentes.
Identificar los Actores

La primera pregunta que un analista debe hacer a sus usuarios es: ¿para qué es este sistema?, y la segunda
es claramente ¿para quiénes es este sistema? Identificar a todos los actores es crítico para un buen análisis
de requerimientos. Por lo tanto, antes de avanzar con los casos de uso, se debe tratar de identificar todos los
tipos de usuario diferentes que tiene el sistema.
Si el sistema funcionará en una empresa, debo preguntar cuáles de las áreas afectadas usarán o
actualizarán su información, tratando de no confundir puestos de trabajo con actores. Recordemos que los
actores son roles que asumirán los usuarios para interactuar con el sistema.
Para realizar la identificación de actores y plantear un modelo inicial, resulta muy conveniente la realización
de un Diagrama de Caso de Uso Ambiental, como el representado en la Figura 2-2-9 * 7.1 .
A pesar de hacer una identificación inicial de los actores, también se debe repetir a medida que se
empiezan a describir los casos de uso, ya que al conocer con más detalle el sistema pueden aparecer
nuevos tipos de usuarios.
Identificar los Principales Casos de uso de Cada Actor

El paso siguiente es enunciar los nombres de los principales casos de uso de cada uno de los actores que
se identificaron en el paso anterior. No es necesario especificar cuáles son las acciones dentro del caso de
uso. Tampoco debemos preocuparnos si no aparecen muchos casos, ya que existen técnicas para
encontrar nuevos casos de uso a partir de los existentes.
Para hacer esta identificación, una forma muy útil es tomar la Lista de Requerimientos planteada, y
organizarlos por Actor. También en este paso es útil el Diagrama de Caso de Uso Ambiental, ya que
las principales interacciones Actor / Sistema están descriptas.
Identificar Nuevos Casos a Partir de los Existentes

Uno de los principales errores que se pueden cometer al identificar requerimientos es: ¡olvidarse de algún
requerimiento! Como los requerimientos están en la cabeza de los usuarios, el éxito de esta tarea depende
de la habilidad del analista para recopilarlos. Para ayudarnos a identificar nuevos casos de uso a partir de
los casos existentes, podemos aplicar la técnica que se basa en el análisis de cuatro situaciones posibles a
partir de los requerimientos ya identificados:
Variaciones Significativas de Casos de Uso Existentes
Es muy común que existan variaciones en los casos de uso dependiendo del actor que los ejecuta, o del
tipo de objeto sobre el que se apliquen. Por ejemplo, en el caso del sistema de ventas de
entradas, podemos hacernos las siguientes preguntas:
¿Existen distintos tipos de cliente que compren entradas?
¿Existen distintos tipos de venta, que lleven a acciones distintas por parte del sistema?
Si la respuesta a la primera pregunta es Sí, lo próximo que debemos preguntarnos es si el sistema
ejecuta acciones distintas en función del tipo de cliente. Tal vez la respuesta sea que existen clientes
normales y clientes premium, y que en estos dos casos el procesamiento es totalmente diferente, ya
que las ventas a clientes premium registran una acumulación de millas en un sistema de vuelos. Tal
vez estemos frente a un nuevo caso de uso, "Vendiendo Entradas Premium", que es distinto del caso
de uso "Vendiendo Entradas". Tal vez tengamos dudas sobre si estos son dos casos de uso o uno
solo, porque el proceso puede tener puntos en común y puntos que los distinguen. Ante esta situación
se debe utilizar el sentido común y tal vez aplicando la modularización de los casos de uso a través de
las relaciones de uso, se pueda determinar la funcionalidad común y expresar claramente, incluso
gráficamente, la funcionalidad que los distingue.
Obviamente que si la respuesta a la primera pregunta es no, estaremos en el caso en que no
vamos a encontrar un nuevo caso de uso a partir de este análisis.
Aceptemos ahora que la respuesta a la segunda pregunta es Sí. En este caso, nuevamente podremos
encontrar un nuevo caso de uso. Podemos encontrar que hay muchas diferencias entre la venta y la
reserva de entradas. En este caso, debemos decidir si la funcionalidad diferenciada es lo
suficientemente relevante como para especificar un nuevo caso. Para hacer este análisis, debemos
tener en cuenta lo siguiente:
1) Si especificamos dos casos de uso similares como un único caso de uso, en el texto del caso
tendremos muchos frases como "Si pasa Z, hago X, si no, hago W". Esta situación hace un poco
más difícil de seguir la especificación.
2) Si especificamos dos casos de uso con funcionalidad en común como dos casos de uso
distintos, la relación de uso nos puede ayudar a evitar la redundancia.
Casos de Uso "Opuestos"
Existen dos caminos para la búsqueda de casos de uso opuestos. El primero de ellos es buscar la
función opuesta a la que se describe en el caso. Por ejemplo, en el caso de uso realizar una reserva,
podremos pensar que la función opuesta es cancelar esa misma reserva. Si cancelar reservas es una
función que nuestro sistema debe realizar, y que no se había identificado anteriormente, acabamos de
evitar un error que podría haber sido muy costoso de corregir más adelante.
La otra forma de buscar casos de uso opuestos es pensando en la negación de la acción principal
del caso de uso. Supongamos que tenemos un caso de uso "Autorizando Tarjeta", que es realizado
por el actor Sistema de Autorizaciones. El caso "No Autorizando Tarjeta", puede de nuevo ser
significativo. Si el sistema de autorizaciones no autoriza la tarjeta, nuestro sistema debe hacer algo,
y podemos estar frente a un nuevo caso de uso.
Casos de Uso que Preceden a Casos Existentes
Una buena pregunta para hacerse frente a un caso de uso es: ¿Qué es lo que tiene que ocurrir antes
de este caso de uso?
En el caso de la venta de entradas, son muchas las cosas que pueden ocurrir antes de ese caso:
1) La venta se realiza con tarjetas de crédito. En esta situación tal vez tenga un nuevo caso de
uso "Ingresando Tarjetas", que puede o no ser un caso de mi sistema.
2) El sistema debe poder mostrar cuáles son los espectáculos existentes. Probablemente este sea un
caso de uso que ya haya sido identificado. Sin embargo, usando esta técnica muchas veces se
descubren nuevos requerimientos.
Casos de Uso que Suceden a Casos Existentes
Esto es similar al punto anterior. La pregunta que debo hacerme es: ¿Qué ocurre después de este caso de
uso? En nuestro ejemplo de las reservas de entradas, es evidente que la mayoría de la funcionalidad de
nuestro sistema recién empieza cuando el cliente hace una reserva. Por lo tanto, analizar "cómo sigue la
historia" es una buena forma de asegurarme que no estoy dejando requerimientos sin identificar.
Documentación de los Casos de Uso
Descripciones de Casos de Uso de Trazo Grueso

Una vez que se han identificado todos los casos de uso, empezaremos a documentar sus pasos. Esta tarea
no debe realizarse de manera estrictamente secuencial a la anterior: puede ocurrir y de hecho es común
que, mientras empezamos a documentar los casos, sigamos buscando otros nuevos. La documentación de
los casos de uso identificados debe hacerse del tipo "trazo grueso", salvo que sea un caso de uso que deba
implementarse sí o sí en la primera iteración.
Definir Prioridades y Seleccionar Casos de la Primera Iteración
Una vez documentados los casos de trazo grueso, es conveniente definir las prioridades de los
distintos requerimientos, expresados como casos de uso. Se recomienda para ello que utilice una de
estas tres categorías: imprescindible, importante y deseable.
Los requerimientos imprescindibles son aquellos que, si no se implementan, hacen que el
sistema no tenga sentido.
Los importantes son aquellos que harían que el usuario se sienta decepcionado si no
se implementan.
Los deseables son aquellos que el usuario querría tener, si hubiese tiempo disponible.
Al evaluar un requerimiento se debe también analizar su costo o complejidad. Una vez que está hecha la
categorización de los requerimientos, podemos tomar como estrategia general el incluir los imprescindibles,
discutir los importantes y descartar los deseables cuyo costo no sea bajo. Pero esta regla también cumple
con la regla de ser relativa puesto que debemos analizar su costo, complejidad, y una cantidad de otros
factores antes de decidir su inclusión.
Escribir los Casos de Trazo Fino y Crear Prototipos de Interfaces

Una vez que se han seleccionado los casos de uso que se implementarán en la primera iteración,
empezamos a profundizar sus definiciones. Es una muy buena idea si al mismo tiempo, se crear un
prototipo visual de la implementación de los casos de uso lo que nos puede evitar muchos problemas.
Cuando creamos prototipos de la implementación de los casos de uso, debemos tener en cuenta que:
1) Estos son prototipos para descartar: si incluimos algo de código en el prototipo, debe ser
descartado o revisado con mucho cuidado si se lo piensa mantener.
2) Estamos intentando validar el estilo de la interacción, no toda la interacción: no debemos dejarnos llevar por el
entusiasmo. Si tenemos varios casos de uso que realizan funciones similares, o con una interfaz similar,
puede alcanzar con crear un prototipo de sólo una de ellas. Queremos que el usuario se dé una idea
sobre cómo se verá el sistema, no que nos apruebe todas sus pantallas y listados.
Organización de la Especificación
Trataremos ahora cuál es la mejor forma de organizar una especificación de requerimientos en la que se
aplicó la técnica de casos de uso. Para ello definiremos los gráficos a utilizar y cómo implementar las
secciones de especificación.
Dependiendo del tamaño del sistema, es probable que un único gráfico con todos los casos de uso no sea
adecuado, pues nos quedará chico. Recuerde que los modelos gráficos que utilizamos son para aclarar el
texto, y no para confundir. Por ello tendremos en cuenta lo siguiente:
1) Un gráfico de casos de uso no debe mostrar más de 15 casos.
2) Si se debe particionar un gráfico, debo hacerlo por actor. La primera partición debe ser separar los
casos centrales de los casos auxiliares, ya que probablemente les interesen a personas distintas.
3) Si las relaciones de uso y las extensiones entran en el diagrama principal, sin dejar de cumplir con la regla
1), debo dejarlas ahí. Lo mismo se aplica a los actores abstractos.
4) Si las relaciones de uso no entran en el diagrama principal, debo mostrarlas en Diagramas de
Relación, teniendo en cuenta que siempre debo mostrar todos los casos de uso que usan a otro en un
mismo diagrama.
5) Si tengo un caso de uso que es usado por gran parte de los otros casos, como por ejemplo el caso de
uso Identificándose ante el sistema, debo evitar mostrarlo en el gráfico principal, ya que las flechas serán
imposibles de organizar. Es probable que no haga falta mostrar esta relación de uso en un gráfico.
Sugerimos utilizar el siguiente esquema de secciones para una especificación de requerimientos de
sistema utilizando casos de uso:
1) Objetivos, Límites y Alcance del Sistema. En esta breve descripción se plantean las metas que el sistema
deberá cumplir, las funcionalidades abarcadas por el alcance, y las que quedan fuera del sistema.
2) Lista de Requerimientos General.
3) Diagrama de Caso de Uso Ambiental * 7.1 .
4) Descrpición de Requerimientos por actor.
5) Diagrama de cada Caso de Uso, presentando sus relacione * 7.2 .
6) Ficha de Caso de Uso, describiendo cada uno de los casos de uso con sus alternativas. * 7.3 .
7) Prototipos de interfaz * 7.4 .
Esta no es obviamente una especificación de requerimientos completa: estamos incluyendo solo la

parte referida a los casos de uso.
Revisión de los Casos de Uso
El trabajo de revisión se divide en dos sub-actividades: la revisión del modelo y la revisión de los casos de
uso individuales.
La revisión del modelo de casos de uso significa comprobar que los actores y los casos de uso correctos se
identifican y que el modelo se estructura de una manera sensata. La revisión también involucra lograr el
acuerdo sobre las descripciones breves de todos los casos de uso y actores en el documento de descripción.
La revisión de un caso de uso individual ocurre cuando la persona responsable se siente satisfecha
con su descripción. El número de personas que revisará un cierto caso de uso debe seleccionarse,
dependiendo de la naturaleza de ambos: el negocio y el caso de uso. Deben existir por lo menos
representantes de los siguientes grupos:
Del equipo de requerimientos.
Personal que será utilizado como recurso para realizar los procesos correspondientes, por
lo tanto estarán directamente afectados por como opera el curso de elementos en el caso
de uso.
Aquellos responsables por otros casos de uso que dependen de como opera el curso de
eventos en el caso de uso.
Los desarrolladores de los programas vinculados al caso de uso.
Las descripciones del caso de uso deben distribuirse a tiempo para que todos los revisores tengan
tiempo suficiente para leer y prepararse adecuadamente para la reunión de revisión. Un número de
puntos que deben considerarse antes de la revisión son los que se indican a continuación:
¿Es la comunicación desde o hacia el actor correcta?
¿Se describe el curso de eventos a un nivel adecuado de detalle?
¿Es el curso de eventos correcto y completo?
¿Es posible simplificar y acelerar el curso de eventos?
¿Se describen todos los cursos de eventos alternativos?

En el caso que en un Diagrama de Caso de Uso entren todas las asociaciones, debo mostrarlas en
Diagramas de Relación, teniendo en cuenta que siempre debo mostrar todos los casos de uso que
usan a otro en un mismo diagrama.
X Verdadero
○ Falso
Si un Caso de Uso es utilizado por más de un Actor, es un indicio de que el caso de uso puede
ser dividido para identificar nuevos Casos de Uso específicos.
X Verdadero
○ Falso
Los Casos de Uso Precedentes se conocen también como Casos de Uso Opuestos.
○ Verdadero
X Falso
La revisión de los casos de uso sirve para comprobar el grado de satisfacción del modelo y acordar
las definiciones, e involucra solamente al analista de sistemas y al desarrollador.
○ Verdadero
X Falso
5. Ordenamiento
Ordene cronológicamente los pasos que debe seguir el analista de sistemas a la hora de
capturar requisitos como casos de uso:
Identificar Actores
Identificar Casos de Uso por Actor
Identificar Nuevos Casos de Uso desde los Existentes
Describir Casos de Uso identificados en “Trazo
Grueso” Priorizar Casos de Uso a analizar
Especificar los Casos de Uso prioritarios en “Trazo Fino” Revisar
la documentación generada con los actores involucrados
SP2 / H4: Prototipos de Interfaz
Los Prototipos de Interfaz están íntimamente ligados al Modelo de Requerimientos, pero también lo están al
Diagrama de Clases del Modelo de Análisis (que veremos en la próxima situación profesional) y es por ello
que nos extenderemos un poco en el análisis de ellos.
Analizaremos ahora los conceptos necesarios que se deben tener en cuenta durante el proceso de creación de
prototipos. Durante mucho tiempo se manejó el concepto de "codifique algo rápido y vea que los usuarios lo
acepten", este ha sido uno de los grandes errores en las metodologías pasadas, es preciso desterrar este
concepto. Pensamos que un prototipo puede y debe ser utilizado si está bien construido. Trataremos además, los
pro y contra en la construcción de modelos de prototipos tempranos. Posteriormente nos abocaremos a ver de
que forma pueden usarse los modelos de análisis para confeccionar la interfaz del sistema.
Prototipos
Generalmente se entiende por prototipo a un modelo a escala de lo real pero con sus funciones disminuidas
en relación al producto final.
Por otro lado, se entiende como interfaz a cualquier objeto que permita interactuar al usuario con el sistema,
y biceversa. Como su nombre lo expresa, significa "entre caras", refiriéndose a que es un elemento que se
encuentra entre otros dos para cumplir una función de comunicación. Son interfaces * 8.1 en un sistema las
pantallas, los reportes (informes y listados), los periféricos de entrada y salida (como un teclado, un joystick,
un monitor o un molinete de acceso), entre otros. Por supuesto que, en nuestra misión como analistas de
sistemas, nos enfocaremos principalmente en las pantallas y los reportes del sistema, cuyo diseño es
nuestro objetivo.
Los prototipos de interfaz son maquetas que pueden tener diferentes grados de complejidad, desde tan
simple como un conjunto de pantallas ilustradas en papel a algo tan sofisticado como un programa de
software animado que permita la interacción.
Ejemplo de Prototipo de Interfaz realizado con MS Visio 2010 (Figura 2-4-1)

Los prototipos son útiles en diversas fases del proceso de análisis y diseño, como por ejemplo, durante la fase
de análisis un prototipo será útil para obtener un detalle acabado de los requerimientos de un usuario o en la
fase de diseño puede ayudar en la evaluación de muchos aspectos de la implementación seleccionada.
Prototipado "Temprano" de Interfaces

La generación de los prototipos en fase temprana debe enfocarse en la manera de crear disposiciones de
ventanas utilizando los modelos de contexto, de eventos y de información (es decir, la lista de
requerimientos, los casos de uso y el diagrama de clases). Téngase en cuenta que durante la fase de
análisis, el objetivo principal del prototipo es derivar y validar los requerimientos esenciales, manteniendo
abiertas las opciones de implementación.
El esfuerzo en la fase de análisis, debe concentrarse hacia el contenido de información de la ventana y los
eventos de negocio (lista de requerimientos). Es decir, todo lo referente a la disposición, formas de navegación,
determinación de la unidad de trabajo necesaria para el usuario y la disposición de los botones y controles GUI
* 8.2 deben posponerse. La idea es comenzar a formar opiniones y recolectar información acerca del
diseño definitivo del producto. En este proceso deben tomarse notas de los comentarios de los usuarios,
siempre tratando de mantener la dirección o atención sobre el contenido y los eventos de negocio.
Pero como el prototipado de interfaces es competencia principalmente de la etapa de diseño, ya que las
interfaces está íntimamente vinculado a sus comportamientos, su implementación temprana en el proceso
de modelado de los requerimientos presenta tanto ventajas como desventajas, que debemos conocer:
Ventajas
Gracias a esta construcción temprana, el sistema tiene una cara visible, sobre la cual los usuarios
efectuarán comentarios o mencionarán algún evento no presente en la misma. También podrán
mencionarse conceptos que no se relevaron en las entrevistas y también se podrán eliminar algunos
datos que sean irrelevantes. Algunos autores consideran que mientras no se hayan realizado los
prototipos es imposible terminar el modelo de información.
La creación de prototipos ayudará a que salgan a la luz los asuntos de procesos de negocios. En otras
palabras, nos permitirá determinar si otras personas realizan las mismas tares pero de forma diferente, o
determinar si existe una captura de datos redundantes en otras aplicaciones o utilitarios. Por otro lado,
también podrá poner en evidencia algunos puntos técnicos, como por ejemplo la necesidad de los
usuarios de mostrar mucha información en una sola ventana.
Es importante que los usuarios estén familiarizados con las tecnologías vigentes a los efectos de que ellos
puedan aportar ideas sobre la interfaz de su función de negocio. Este análisis nos permitirá evaluar si
realmente es aconsejable una interfaz gráfica, si se pueden utilizar dispositivos portátiles, lectores de códigos
de barras, montar el desarrollo en un página web o simplemente en una pantalla de modo caracter.
Desventajas
Como se mencionó anteriormente, el prototipo puede utilizarse para lograr un acabado

conocimiento del sistema de información. Esto será válido si el analista se mantiene siempre en
la directiva de derivar y validar los requerimientos. Es conveniente dejar el diseño detallado de
la interfaz para cuando se comience a evaluar el modelado arquitectónico y la base de datos
cuando se finalicen los modelos de análisis.
Quizás el peligro mayor de la construcción temprana de prototipos es que el conductor del
proyecto deje liberados a los programadores de la fase de análisis y se comience a codificar
sin haber terminado el mismo en forma detallada y completa. Tenga presente que es mucho
más costoso modificar un desarrollo que una especificación de diseño bien realizada.
Nivel de detalle de los Prototipos
Existen dos tendencias al respecto. Una promueve la construcción de prototipos de alta tecnología que
derivará rápidamente en un sistema terminado. El sistema se codifica de manera progresiva agregando
más y más detalles para dar mayor vida al sistema.
La otra, promueve los prototipos de tecnología básica, hechos en un procesador de textos, una herramienta de
dibujo, un papel o una herramienta CASE. La razón argumentada por ellos es que es más rápida en el logro de los
objetivos y el bajo costo permite hacer la cantidad de cambios que sea necesario. Este último punto de vista es
válido teniendo en cuenta que el objetivo de la creación de prototipos en la fase de análisis es recopilar
y validar requerimientos.
Debe tenerse en cuenta que si anteriormente los futuros usuarios no han trabajado nunca con una interfaz
GUI, se deberá construir al menos algunas interfaces y ser tratadas como un laboratorio de prueba a los
fines de que los usuarios se familiarice con el nuevo ambiente.
Los Usuarios
Un diseño correcto de la interfaz de usuario es parte fundamental del proceso general del software, ya que
si un sistema alcanza su potencial máximo cuando su interfaz de usuario está diseñada para ajustarse a
las habilidades, experiencias y expectativas de sus usuarios previstos.
A la hora de construir los prototipos de interfaz, es muy importante considerar la forma en que se
establecerá el diálogo entre el usuario y la interfaz. No deben asumirse habilidades especiales por parte de
los usuarios o en cuyo caso deberá preverse una tarea de capacitación. Es importante tener en cuenta que
los modelos de análisis no pueden ser transformados de manera mecánica en un prototipo de interfaz sin
una actividad intelectual.
Prototipos de Interfaz conocidos que respetan el nivel de habilidad del usuario (Figura 2-4-2)
Cuando se toman decisiones en el diseño de las interfaces de usuario, deben tenerse en cuenta las
capacidades físicas y mentales de las personas que utilizarán el software. Por ejemplo, algunos factores
importantes a considerar son:
Las personas tienen una memoria limitada a corto plazo: podemos recordar instantáneamente
lrededor de siete elementos de información (estudio hecho por Miller en 1957). Por lo tanto, si a
los usuarios se les presenta demasiada información al mismo tiempo, es posible que no puedan
asimilarla.
Todos cometemos errores, especialmente cuando tenemos que manejar demasiada información
o estamos estresados. Cuando los sistemas fallan y emiten mensajes de aviso y alarmas, a
menudo aumentan el estrés de los usuarios, incrementando así la posibilidad de que cometan
errores.
Poseemos un amplio rango de capacidades físicas. Algunos ven y escuchan mejor que otros,
otros son más hábiles en manipulaciones físicas; por eso no debe diseñarse para las propias
capacidades y suponer que todos los usuarios serán capaces de adaptarse.
Tenemos diferentes preferencias de interacción. A algunas personas les gusta trabajar con
imágenes (manipulación directa), a otras con texto (emitir comandos e instrucciones al
sistema).
Esto significa que a la hora de diseñar interfaces, debemos conocer muy bien a los usuarios y su contexto,
ya que gran parte del éxito de la implementación de un software radica en la usabilidad y aceptación del
mismo por parte de los usuarios. Para ello nos basaremos en 6 principios simples:
Familiaridad: La interfaz debe utilizar términos y conceptos obtenidos de la experiencia de
las personas que más utilizan el sistema.
Uniformidad: Siempre que sea posible, la interfaz debe ser uniforme en el sentido que las
operaciones comparables se activen de la misma forma. Por ejemplo, la ubicación de los botones
de comando "Aceptar" y "Cancelar".
Mínima sorpresa: El comportamiento del sistema no debe provocar sorpresa a los usuarios.
Recuperabilidad: La interfaz debe incluir mecanismos para permitir a los usuarios recuperarse de
los errores.
Guía: Cuando ocurran errores, la interfaz debe proporcionar retroalimentación significativa
y características de ayuda sensible al contexto.
Diversidad: La interfaz debe proporcionar características de interacción apropiadas para
los diferentes tipos de usuario del sistema.
En la figura 2-4-2 * 8.3 , presentamos dos ejemplos de diseño de interfaces donde hubo un adecuado análisis
de estos aspectos.
En el primer caso, vemos la pantalla de un cajero automático. Esta interfaz se ha diseñado descomponiendo
los eventos de negocio que intervienen en un diálogo a un extremo lógico, solicitando un dato a la vez
seguido de una actividad de edición y de una respuesta del sistema que pide el siguiente dato. Cada
fragmento de este diálogo es un evento. Sin embargo este diseño asume que el usuario sabe desempeñarse
frente a un teclado, borrar datos erróneos, desplazarse entre los campos de la pantalla y sabe cómo anular
una transacción no deseada. Es una interfaz pensada para un conjunto de usuarios muy heterogéneos en
sus capacidades y conocimientos, pero se orienta a que la transacción se resuelta en pocos pasos, de forma
intuitiva y segura, priorizando los apectos funcionales a los gráficos (estéticos).
En el segundo caso, la pantalla de operación de un teléfono inteligente sigue principios parecidos, aunque
lo funcional y lo estético exigen altos niveles de diseño. Nadie va a comprar un cajero automático, ni elige a
qué cajero ir por su interfaz, sólo es una herramienta con un fin muy específico que responde a una
necesidad momentánea y puntual; en cambio, el smartphone debe satisfacer necesidades de mercado,
estéticas, debe permitir su operación a usuarios de diversas habilidades, pero que "exigen" prestaciones y
condiciones de operación: operar con dos dedos o con uno, rotar la pantalla, operar caminando o sentado,
en la oscuridad o a plena luz, con música, radio, sonido y vibración, entre otras. Con la gran oferta de
modelos, precios y prestaciones que hay en el mercado de los smartphones (como en el de los sistemas
informáticos), sólo sobreviven y marcan tendencia los que son aprobados por los usuarios.
Técnicas de análisis para el prototipado
No debemos olvidar que los prototipos de interfaz son una actividad de diseño. Debe tenerse en mente
siempre la directiva principal del prototipo del análisis para derivar y validar los requerimientos esenciales.
Pero hay también una cantidad de consideraciones a tener en cuenta en una interfaz bien elaborada y que
pueden ser postergadas hasta la etapa del diseño detallado, como por ejemplo determinar la unidad de
trabajo adecuada para el usuario, el tipo de ventana, la modalidad de navegación, los estilos de
interacción * 8.4 y los puntos en los cuales se deben registrar datos en la base de datos.
A este extremo de la comunicación entre los usuarios y la interfaz se le pueden agregar otros esquemas
de elaboración, que permiten agrupar pantallas, eventos y objetos de acuerdo a varios criterios de
acuerdo a la necesidad.
Agrupación de eventos por tema

Los eventos de un sistema pueden usarse en diversas formas para guiar el prototipo. Una lista de eventos
puede ordenarse o agruparse por transportador * 8.5 o por sujeto. Esta técnica permite recolectar todos
los eventos de los que es responsable un grupo de usuarios particular. Analicemos por ejemplo lo que
ocurre en un subconjunto de los eventos iniciados por un doctor en una clínica de medicina familiar:
El doctor solicita historial del paciente.
El doctor registra diagnóstico del paciente.
El doctor solicita dosis de receta.
El doctor solicita búsqueda de síntomas.
El doctor solicita el reporte de ventas mensual.
El doctor revisa el calendario de citas.
El doctor reserva tiempo libre.
Tradicionalmente, muchos sistemas han sido diseñados siguiendo la estructura organizacional tradicional
de una compañía. Dada la lista de eventos iniciados por el doctor cabe preguntarse ¿en cuántos
"módulos" debe introducirse el doctor?:
Nombre del eventoMódulos del sistema tradicional
1) El doctor solicita historial del paciente Información del Paciente
2) El doctor registra diagnóstico del paciente Información del Paciente
3) El doctor solicita dosis de receta Información Médica
4) El doctor solicita búsqueda de síntomas Información Médica
5) El doctor solicita reporte de ingresos mensual Contabilidad
6) El doctor revisa el calendario de citas Reservaciones
Los sistemas que han sido estructurados en forma organizacional suponen que las descripciones de trabajo
de las personas están bien divididas a lo largo de las fronteras políticas de la empresa (Figura 2-4-3). Por
ello, la interfaz se estructura de acuerdo a ello. Cada ventana se encuentra, por lo general, en un lugar de la
aplicación, por ejemplo, el calendario de reservaciones diarias sólo puede encontrase bajo el icono de
reservaciones en el menú principal. La aplicación de reservaciones también incluye toda la funcionalidad
requerida para la creación, modificación y cancelación de reservaciones.
Aplicación estructurada en forma organizacional (Figura 2-4-3)
Agrupación de eventos por transportador

Una estrategia para controlar el acceso de usuarios en una aplicación estructurada organizacionalmente es
proporcionar la misma aplicación a todos pero variar su acceso dependiendo de su autoridad para iniciar
diversos eventos. Esta es la implementación más común en el ambiente cliente/servidor. La desventaja es
que un solo usuario, tal como el doctor, tiene que familiarizarse con varios subsistemas principales para
encontrar las ventanas que necesita.
Se presentan problemas en las aplicaciones estructuradas organizacionalmente cuando la actividad del
trabajo actual del usuario cae fuera de las fronteras políticas tradicionales. Esto ha llegado a ser cada vez
más común en las empresas actuales que dan "mayores facultades" a sus empleados. Una alternativa a la
estructura organizacional es el empacar en las aplicaciones a las ventanas que están relacionadas con
iniciadores de eventos específicos (Figura 2-4-4).
La ventaja principal de este método es que, el tamaño de la aplicación es físicamente más pequeño y el
usuario no necesita aprender la manera de navegar en las partes no usadas de la aplicación. La desventaja
es que el control de versiones de las mejoras de software tendrá que administrar la construcción y
distribución de ejecutables a diferentes sitios clientes.
Una aplicación organizada por transportador (Figura 2-4-4)

Agrupación de eventos por objeto
Una de las formas más poderosas para utilizar un modelo de eventos es agrupar los eventos por objeto. El
objeto representa a la cosa del mundo real sobre la que se realiza el evento. Ilustremos a través del evento
el cliente coloca un pedido. El objeto pedido puede estar representado en el modelo de datos por varias
entidades. En el Diagrama de Clases (que estudiaremos en detalle la próxima SP) que presenta la Figura 2-
4-5 puede verse una estructura de datos preliminar para un caso de uso que permite Realizar Pedidos de
Productos, donde un cliente puede solicitar pedidos de varios productos a un vendedor, pedidos que serán
posteriormente facturados y enviados. En esta versión del diagrama no se presentan los atributos ni los
métodos de las clases.
El contexto asociado a la palabra objeto se refiere al nombre de evento que representa la abstracción
del negocio para el cual pueden ser representados datos relevantes con una o más entidades en el
modelo de información * 8.6 .
Diagrama de Clases preliminar del caso de uso "Realizar Nuevo Pedido" (Figura 2-4-5)
El agrupamiento y examen del modelo de eventos junto con el modelo de información es el primer paso
para descubrir y catalogar las clases del negocio en un diseño orientado a objetos.
El agrupamiento de eventos por objetos nos lleva al paradigma objeto-acción, éste es un cambio en el diseño
general de las interfaces de usuario que ha estado ocurriendo durante muchos años. Las primeras
investigaciones sobre la facilidad de uso de diferentes diseños de pantalla revelaron que es más intuitivo y
eficiente cuando los usuarios adquieren primero un objeto en la pantalla y luego le dicen a la computadora la
acción que hay que aplicar. Los lenguajes de programación en línea frecuentemente motivaban ha hacer
exactamente lo contrario. La Figura 2-4-6 muestra el menú principal para una implementación acción-objeto.
Menú principal acción-objeto (Figura 2-4-6)

El menú principal de una aplicación acción-objeto típica necesitaría que el usuario declarara el tipo de acción
que pretende realizar. Por ejemplo puede teclear AP para "Actualizar Pedidos" y oprimir Entrar. El programa
podría llamar a una pantalla de actualización de pedidos en blanco, como se presenta en la Figura 2-4-7
Pantalla para actualización de pedidos (Figura 2-4-7)
Luego el usuario podría identificar el pedido que quisiera actualizar tecleando una clave tal como el número
de pedido, en la parte superior de la pantalla y volviendo a oprimir Entrar. Luego la pantalla recuperaría el
pedido y se podría empezar a trabajar. Este tipo de diseño soportó un ambiente, en donde las tareas del
usuario eran extremadamente repetitivas. Podría permanecer en la misma pantalla y teclear pedidos todos
el día, tecleando datos de montones de hojas de entrada. Hoy reconocemos que la mayoría de los trabajos
de los usuarios son más complejos.
Al automatizar hasta las líneas frontales de la organización, el movimiento repetitivo de las áreas de captura
de datos antiguos ha dado paso a las fuerzas más aleatorias del mundo real. Por ejemplo, el personal de
ventas recibe llamadas de clientes haciendo nuevos pedidos, cambios al trabajo que se está realizando y
cancelación de pedidos existentes. El paradigma objeto-acción establece que los usuarios deben ser
capaces de seleccionar una lista de objetos de la base de datos, seleccionar uno o más de ellos y luego
especificar la acción que quieren aplicar.
La Figura 2-4-8 muestra una ventana que soporta el paradigma objeto-acción. El usuario puede teclear
varios criterios de selección opcionales en la parte superior de la ventana, los que le permiten recuperar
una lista de pedidos cuando selecciona un Cliente en "Facturar a". La lista de los elementos del pedido se
despliega en la parte inferior de la ventana.
La ventana de Pedidos (Figura 2-4-8)

Se puede seleccionar el objeto que se desee haciendo clic en los renglones del conjunto resultante.
de usuario también soporta una extensión importante al paradigma objeto-acción. Cuando el usuario ha
seleccionado al objeto, la interfaz es lo suficientemente inteligente para informarle cuáles acciones
son legales en cualquier momento con base en la autoridad del usuario y el estado actual del objeto. Los
botones de comando y conceptos de menú son rutinariamente desactivados (puestos en gris) en la interfaz
cuando la acción es ilegal para el objeto seleccionado. Ésta puede ser una tarea difícil para un programa y
virtualmente imposible de probar a menos que se tenga un diagrama de estado-transición.
La siguiente tabla muestra una lista de eventos que han sido agrupados por objeto. El objeto del evento
puede determinarse, por lo general, mediante una inspección simple. Frecuentemente los eventos afectarán
a más de un objeto. Un enfoque mucho más riguroso es producir una matriz evento/entidad para determinar
cuáles entidades son afectadas por cada evento, sin embargo, no siempre se requiere este nivel de detalle.
Un buen método para crear un prototipo para estos eventos es examinar primero al transportador del evento
y luego examinar el objeto.
Por medio del paradigma objeto-acción podemos dar al representante de ventas una ventana donde pueda
adquirir una lista de objetos de la base de datos e iniciar estos eventos para los elementos seleccionados.
Uso del Modelo de Información para acomodar el contenido de la Ventana

El modelo de información es una guía crítica para la disposición de ventanas. El marco organizacional de los
datos es dictado por la cardinalidad de las relaciones entre las entidades de datos. Si un pedido puede tener
varios ítems, uno para cada producto pedido, entonces se podría esperar una relación encabezado-detalle
clásica en la ventana de toma de pedidos, como se presenta en las Figuras 2-4-5 * 8.7 y 2-4-8 * 8.8 .
Tenga en cuenta las siguientes consideraciones a la hora de prototipar:
Si hay espacio para desplegar las entidades en la misma ventana, los datos del pedido deben
ser acomodados en la parte superior, y debajo en una sección tipo cuadrícula o grilla, puede
desplegar cada instancia de ítem de pedido en la parte inferior de la ventana. Si hay
demasiados atributos para que quepan en forma agradable en una ventana, se deberán
emplear varias ventanas para desplegar la información.
Tenga en cuenta todo lo aprendido sobre GUI * 8.2 para la elección de los controles: cajas de
texto, grillas, listas desplegables, frames, botones de opción, etc. Cada uno de ellos tiene
objetivos y comportamientos específicos que lo diferencia de los demás, y deben ser tenidos en
cuenta ya que la interfaz debe ser cómoda, intiuitiva y segura para el usuario. Por ejemplo en la
figura 2-4-8, se eligió una lista desplegable para seleccionar el Vendedor, ya que este dato es
muy variable y siempre debe seleccionarse solamente uno (como muestra la cardinalidad). Se
debe evitar emplear controles rígidos para grupos de datos variables.
Para campos actualizables evite a toda costa las barras de desplazamiento para ver los campos
que han quedado ocultos a la derecha o en la parte inferior de la ventana. Los usuarios
frecuentemente rechazan las ventanas desplazables que tienen campos actualizables ocultos.
Trate que visualmente todo esté en la interfaz en la medida de lo posible.
Las barras de desplazamiento horizontal también deben reservarse para las listas no
actualizables cuando la cantidad de columnas regresadas excede la anchura del desplegado.
Cuando se usan
listas de desplazamiento horizontal es un buen hábito usar ventanas estilo cuadrícula que
permiten que los usuarios reacomoden las columnas a sus especificaciones.
Las interfaces gráficas de usuario permiten una gran variedad de diseños de arreglos de
navegación, por lo que es necesario mantener abiertas las opciones mientras todavía se están
recopilando y validando los requerimientos. Si se enfrenta a un grupo de usuarios que están
obsesionados en la navegación, la demostración de varias rutas de navegación para su disposición
de ventanas, frecuentemente eliminará sus preocupaciones. También aclarará consideraciones de
diseño importantes que pueden usarse posteriormente, y ayudará a que los usuarios regresen al
tema.
En conclusión, debe existir una coherencia entre el prototipo de interfaz y el modelo de información, ya
que este último proporciona un mapa de la cardinalidad entre grupos de datos. Además de la estructura
de los datos, el diseñador de interfaz también necesita comprender las estadísticas del mundo real que
están tras la cardinalidad para evitar la creación de interfaces que fuerzan a los usuarios a seguir las raras
rutas de excepción, en vez de la normal
Evaluación de la Interfaz
La evaluación de la interfaz es el proceso de evaluar la forma en que se utiliza una interfaz y verificar
que cumple los requerimientos del usuario.
De forma ideal, estas evaluaciones deben llevarse a cabo contra una especificación de la usabilidad
(facilidad de uso), basada en atributos de usabilidad:
Aprendizaje: ¿Cuánto tiempo tarda un usuario nuevo en ser productivo con el sistema?
Velocidad de funcionamiento: ¿Cómo responde el sistema a las operaciones de trabajo del usuario?
Robustez: ¿Qué tolerancia tiene el sistema a los errores del usuario?
Recuperación: ¿Como se recupera el sistema a los errores del usuario?
Adaptación: ¿Está muy atado el sistema a un único modelo de trabajo?
Los prototipos pueden ser muy instructivos durante su construcción, pero su valor real se obtiene
cuando éstos son revisados con los usuarios finales. Hay que informar a los usuarios el objetivo de
aprendizaje específico antes de presentarles el prototipo. Lo mejor es revisar el prototipo en persona
para observar las reacciones de los usuarios.
Es una buena práctica invitar a los usuarios a simular la captura de datos. Conforme llenan los campos,
el analista puede indicar cuáles elementos de datos serán de captura en formato libre, en listas
desplegables o seleccionados en menús desplegables. La mayoría de los usuarios será capaz de validar
el contenido de la ventana y de asegurar que los eventos sean capturados adecuadamente con este
método de creación de prototipos de tecnología básica.
Los beneficios de utilizar prototipos de tecnología básica es que la mayoría del análisis y gran parte de la
información de diseño puede ser recopilada sin incurrir en el costo de construir un producto funcional. Los
prototipos de tecnología básica son baratos de construir y fáciles de modificar. Cuando un producto sufre
varias iteraciones de prototipos en papel antes de su construcción inicial es mucho más probable que la
versión beta de ese producto sea más cercana a lo que se pretende.
La principal desventaja de la construcción temprana de prototipos es el costo que tendría reprogramar
las interfaces por haber sido codificadas sin el suficiente análisis. X Verdadero
El uso del Modelo de Información para el desarrollo de prototipos es determinante porque establece la
cardinalidad entre grupos de datos, y esto afecta la disposición y la elección de los controles en la
interfaz. X Verdadero
SP2 / Ejercicio resuelto

La resolución de este ejercicio nos lleva, en primer lugar, a tener que enumerar o enunciar la Lista de
Requerimientos del sistema VenTel:
Requerimientos Funcionales:
El sistema debe registrar y administrar los espectáculos.
Registra y administrar las locaciones.
Registrar y administrar los organizadores.
Registrar y administrar las tarjetas.
Registrar los datos de los clientes para realizar las entregas de las entradas.
Registrar y administrar los operadores del sistema.
Permitir la asignación de funciones para los espectáculos, detallando la locación, el
horario, el sector y el precio de la entrada y la cantidad de butacas habilitadas al sector.
Permitir la registración de reservas para una función en un espectáculo.
Registrar la venta de entradas con tarjetas de crédito luego de la autorización correspondiente.
Efectuar reportes de ventas por espectáculo, ventas por operador, ventas por tarjeta, etc.
Administrar las comunicaciones con el Centro de Validación de Tarjetas.
Administrar las transacciones que realizan cada uno de los usuarios.
Validar los accesos al sistema por parte de los operadores o administradores del mismo.
Realizar la rendición de cobro a los organizadores.
Registrar las rendiciones efectuadas en los bancos habilitados.
Remitir al subsistema de cobranzas la información sobre los organizadores que se
encuentran bajo la situación de morosos.
Requerimientos No Funcionales
Realizar las comunicaciones con el centro de autorizaciones
Notará que la lista presentada todavía está escueta, poco detallada e incompleta. Esto fue realizado a
propósito, con el solo fin de hacerle ver que quien solicita un desarrollo y confecciona su descripción no
podrá abarcar todos los detalles. Es aquí en donde usted deberá utilizar todas las Técnicas de
relevamiento * 9.1 que le sea posible con el objeto de conocer a fondo la problemática. Un recurso muy útil
es identificar las Clases Candidatas * 9.2 , como las que están remarcadas en negrita en la lista de
requerimientos (espectáculos, funciones, entradas, tarjetas, locaciones, entre otras).
Es conveniente aclarar que la Situación profesional se resolverá teniendo en cuenta que todo funciona por
las vías normales, es decir, no se tendrá en cuenta que sucederá si cuando un cliente que solicita una
entrada, el sistema de autorizaciones le rechaza la operación. Es decir, no nos ocuparemos por ahora de
las causas del rechazo ni de la registración del hecho.
Bien, con nuestra lista de requerimientos comenzaremos a realizar los diagramas de los casos de uso
de la situación planteada y acompañando a éste presentaremos los diagramas de asociación de casos
de uso, los prototipos de interfaz y las fichas de caso de uso correspondientes para ver como se
analizan pequeñas operaciones de negocio de manera completa.
Diagrama de Casos de Uso: Módulos del Sistema de Venta Telefónica de Entradas
A través de este diagrama se están representando las siguientes asociaciones: un Cliente puede realizar reservas
o compra de entradas, el Empleado de Ventas es quien se encarga de las tareas de atención del cliente, y el
Gerente de Administración puede realizar operaciones sobre las ventas y/o reservas y además es quien se
encarga de toda la administración de los datos (tablas o clases) que serán manejadas en el sistema de ventas.
Ampliaremos ahora los casos de uso, analizando sus correspondientes relaciones de inclusión o extensión
en el caso de que hubiera.
El Módulo de Gestión de Datos posee una serie de clases asociadas en las que no se puede realizar
asociaciones debido a que su implementación responde a una única clase, este es el caso de la
administración de empleados de ventas, organizadores, espectáculos, locaciones y tarjetas. Pero existen
otro tipo de operaciones de administración que hacen uso de más de una clase, es decir, para generar una
instancia de una clase deben operar o asociarse con otras clases, como por ejemplo los casos de uso
"Estableciendo Funciones" para un espectáculo, y "Generando Entradas" para cada una de las funciones,
teniendo en cuenta la posibilidad de que para un mismo espectáculo se puedan establecer sectorizaciones
diferentes para las diferentes funciones.
Diagrama de Casos de Uso: Casos de uso del Módulo de Gestión de Datos

A continuación presentaremos, tal como lo explicamos anteriormente, los diagramas de relación de casos
de uso, los prototipos de interfaz y las Fichas de Caso de Uso correspondientes a cada uno de ellos.
Diagrama de Relación de Caso de Uso: Caso de Uso "Estableciendo Funciones"
Prototipo de Interfaz: Caso de Uso "Estableciendo Funciones"
Por ejemplo, viendo ambos modelos: el Diagrama de Relación y el Prototipo de Interfaz,

analicemos la coherencia entre los mismos.
El caso de uso que se analiza es la generación de las funciones para un espectáculo. Esta actividad
presupone que alguien, en otra u otras funciones de negocio o casos de uso realizó los casos de uso que
permiten administrar los tipos de espectáculo, los espectáculos, las locaciones y los operadores; es decir
que estos datos están previamente "cargados" en el sistema.
Observemos en primer lugar que el Diagrama de Relaciones presenta identificadas funcionalidades básicas
que deberá tener el sistema para dar soporte a la interfaz presentada. Seguramente, cuando avancemos
con el análisis en las sucesivas situaciones profesionales, veremos que muchas de estas funcionalidades
serán candidatas a ser métodos de clase. Las inclusiones denominadas "Obteniendo...", no son más que
procedimientos que recuperan datos del sistema para presentarlos en las listas desplegables; o viéndolo de
forma inversa, cada lista desplegable en el prototipo está soportada por un caso de uso incluido (es decir,
que se ejecuta siempre durante el curso normal del caso de uso base).
Vemos además, que también están representadas en las realaciones, las operaciones de la interfaz que
cumplen con el objetivo del caso de uso, que es como su nombre lo dice "Estableciendo Funciones", es
decir las transacciones de "Registración", "Eliminación" y "Modificación". Las dos últimas se muestran en
esta versión del diagrama como extensiones, ya que no son caminos alternativos al caso de uso.
Si vamos al Prototipo de Interfaz, podemos notar que en la cabecera del formulario se encuentran tres
combos para la selección del espectáculo al que se le asignarán funciones. Se debe seleccionar el tipo de
espectáculo (cine, teatro, concierto, musical, etcétera); esta selección debería permitir el filtrado de los
espectáculos de ese tipo para la selección del espectáculo en su combo. Luego se debe seleccionar la
locación donde se realizará la función.
Con estos datos seleccionados, debemos iniciar la carga de las funciones, estás pueden ser una o varias
y además esta diagramación nos permite armar diferentes funciones del espectáculo en diferentes
locaciones. Note que en el bloque de creación de funciones se encuentran dos fechas, éstas se utilizarán
para definir el rango de fechas entre las que se crearán las funciones para el día de la semana que se
encuentra la lado, solo se debe fijar la fecha y pulsar en agregar. Este proceso debería agregar tantas
funciones como días de la semana seleccionado se encuentren en el rango de fecha.
Al generarse estas funciones se muestran en la grilla inferior, otorgando la posibilidad de eliminar alguna
de ellas o modificarla.
Como ya estudiamos, existe una relación directa entre los grupos de datos presentados en el prototipo
de interfaz y el modelo de información (que para nosotros será el Diagrama de Clases), y por esta
importante razón debemos analizar las cardinalidades que se plantean en la asociación de las clases
candidatas de este caso de uso.
A continuación presentamos la Ficha del Caso de Uso "Estableciendo Funciones"
Ficha de Caso de Uso: Caso de Uso "Estableciendo Funciones"

Podemos observar que esta ficha se encuentra en un detalle de tipo "trazo intermedio", ya que
especifica cursos normales y alternativos, y además todas las tareas que el actor (usuario) realizará
sobre el sistema; aunque no especifica cómo el sistema resolverá cada una de esas interacciones.
Están obviados, con el objetivo de sintetizar, el detalle de las acciones de "eliminación" y "modificación"
de funciones, presentados en la ficha en los pasos 9.1 y 9.2 del curso alternativo.
Veamos ahora el caso de uso "Generando Entradas", este es el caso de uso que creará las entradas
con sus características (precio por sector en el caso que se sectoricen las funciones).
Diagrama de Relación de Caso de Uso: Caso de Uso "Generando Entradas"
Note que, al definir en el caso de uso las funcionalidades, no estamos hablando de manera directa sobre
los atributos que se deben capturar, este suele ser un error muy común de cometer. Recuerde que el
objetivo de este diagrama es capturar la funcionalidad de esa tarea, para a partir de ellas determinar que
estructuras de datos le darán soporte y no al revés.
Veamos el Prototipo de Interfaz asociado a este diagrama
Prototipo de Interfaz: Caso de Uso "Generando Espectáculos"
Tal como se plantea en el caso de uso, se debe identificar el espectáculo al cual se le crearán las entradas,
de la misma manera que se realizó en el caso de uso anterior se han puesto los combos que nos permitirán
identificar el espectáculo deseado.
A partir de allí, hemos incorporado un frame que nos permite elegir dos opciones, una de ellas es la que
permite asignar a todas las entradas de todas las funciones diferentes sectores y precios (la selección de
esta opción deshabilita la grilla y por lo tanto no se pueden seleccionar las funciones).
La otra opción que permite establecer sectorización y precios diferentes para cada función habilita la grilla
en un modo de multiselección para crear a esas funciones seleccionadas los precios y cantidades de
entradas disponibles.
Veamos ahora la Ficha del Caso de Uso analizado:
Ficha de Caso de Uso: Caso de Uso "Generando Entradas"
Bien, hemos finalizado parcialmente la resolución de la situación profesional, enfocándonos en el Módulo

de Gestión de Datos. Para que comprenda claramente la aplicación de todas estas herramientas, quedará
a su cargo la resolución del Módulo de Venta de Entradas, solicitado en el Ejercicio por resolver de esta
situación profesional.
¿Cuál de estos pasos no corresponde a la captura de requisitos?:
○ Enumerar Requisitos Candidatos.
○ Capturar Requisitos No Funcionales.
○ Identificar Requisitos Funcionales.
○ Comprender el Contexto del Sistema.
○
¿Que es un Modelo de Dominio?:
○ Un diagrama ambiental del dominio del negocio.
○ Un modelo que captura casos de uso.
○ Un diagrama de todos los objetos y sus interacciones.

Una aplicación externa al sistema analizado, cuya función es la de tomar en forma periódica una serie
de datos para ser mostrados en la página web de la empresa, se representaría en el Diagrama de
Casos de Uso como… :
X Un actor.
○ Un objeto de control.
○ Un caso de uso con relación de extensión.
○ Un caso de uso con relación de inclusión
Dentro de las herramientas del análisis guiado por Casos de Uso, ¿que elemento es el que nos permitirá
interactuar mejor con el usuario a la hora de validar si nuestra solución propuesta es acertada?:
○ Diagrama de Asociaciones.
○ Diagrama de Casos de Uso.
○ Diagrama de Clases
○
¿Cual de estos métodos de análisis NO sirve como guía para la construcción de Prototipos de Interfaz?
○ Agrupamiento de eventos por tema.
○ Agrupamiento de eventos por transportador.
○ Uso del modelo de información.
○ Agrupamiento de eventos por objetos.
X Todos sirven como herramientas de prototipado.
Situación profesional 3: Análisis
Antes que nada, aclararemos que el caso práctico a desarrollar en esta Situación Profesional será el mismo
planteado en la SP2. La razón de esto es muy sencilla: estamos estudiando un Proceso de Desarrollo,
incremental, iterativo, descendente, complejo e integrado, con modelos y diagramas que deben presentar
coherencia estática y dinámica. A medida que avanzamos en la materia, las herramientas que abordamos
aportan a las anteriores un nuevo grado de refinamiento en el análisis y el diseño del los diferentes modelos.
Como ya pudo comprobar en la etapa de Requisitos, el proceso del Analista de Sistemas para obtener
modelos sistémicos es exhaustivo y empírico. Por esta razón, consideramos más simple y claro para
comprender estas metodologías, el uso de todos los modelos y documentación ya generados, los cuales
serán la base para la aplicación de las nuevas herramientas.
espectáculos tales como obras de teatro, conciertos, musicales, etcétera.
La rendición del cobro de las entradas a los organizadores se realiza cada 10 días, por intermedio de
Bancos autorizados. Ventel obtiene como ganancia un 12% de las ventas realizadas, la cual se descuenta al
Para ver la documentación generada en la etapa de Requisitos, acceda al Ejercicio resuelto de la
Situación profesional 2.
SP3 / H1: El Proceso de Análisis
El objeto del Análisis
En la Situación profesional anterior habíamos llegado a confeccionar el Modelo de Requerimientos; ahora

entraremos de lleno en el Modelo de Análisis. Este modelo nos muestra los requisitos capturados en la
etapa anterior, refinándolos y estructurándolos a los fines de tener un conocimiento más acabado y preciso.
En la etapa anterior se utilizó el lenguaje del cliente por lo que es muy posible que hayan quedado algunos
aspectos sin resolver.
En esta etapa debemos centrarnos más en los aspectos internos del sistema, analizando la posible
existencia de alguna interferencia entre los casos de uso relevados. Además, deben estructurarse los
requisitos de manera que se facilite su comprensión, su separación, su modificación y su mantenimiento.
Sin embargo, el Modelo de Análisis todavía hace algunas abstracciones y deja sin resolver algunas
cuestiones físicas que se posponen para las etapas de Diseño e Implementación.
El propósito de esta etapa de Análisis puede resumirse en tres puntos fundamentales:
Transformar los requerimientos en un sistema ejecutable.
Evolucionar a una arquitectura más robusta y que soporte los futuros requerimientos.
Adaptar el diseño a un entorno de implementación que le permita al sistema tener el
óptimo desempeño.
Además podemos decir que:
Un modelo de análisis ofrece una especificación más detallada de los requisitos
capturados y presentados como casos de uso.
Se describe utilizando el lenguaje de los desarrolladores, introduciendo un mayor
formalismo que permite razonar sobre los funcionamientos internos del sistema.
Estructura los requisitos de manera tal que permiten su comprensión, preparación,
modificación y mantenimiento.
Puede considerarse como una primera aproximación al modelo de diseño.
Podemos resumir estas cuestiones en el cuadro comparativo presentado en la Figura 3-1-1.
Modelo de Requerimientos vs. Modelo de Análisis (Figura 3-1-1
El papel del análisis en el ciclo de vida del software

Las iteraciones iniciales de la elaboración se centran en el análisis (ver Figura 3-1-2). Eso contribuye a
obtener una arquitectura estable y sólida y facilita una comprensión en profundidad de los requisitos. Más
adelante, al término de la fase de elaboración y durante la construcción, cuando la arquitectura es estable y
se comprenden los requisitos, el énfasis pasa en cambio al diseño y a la implementación.
El Análisis dentro del Proceso Unificado de Desarrollo (Figura 3-1-2)
El propósito y objetivo del análisis, ya mencionados, deben alcanzarse de algún modo en todo
proyecto. Pero la manera exacta de ver y de emplear el análisis puede diferir de un proyecto a otro. Se
pueden distinguir tres variantes básicas:
El proyecto utiliza el modelo de análisis para describir los resultados del análisis, y
mantiene la consistencia de este modelo a lo largo de todo el ciclo de vida del
software.
El proyecto utiliza el modelo de análisis para describir los resultados del análisis pero
considera a este modelo como un herramienta transitoria e intermedia, una especie de
puente entre los requerimientos y el diseño final. Más adelante, cuando el diseño e
implementación estén en marcha durante las fases de construcción, los modelos de
análisis se dejan de actualizar.
El proyecto no utiliza en absoluto el modelo de análisis. En su lugar analiza los
requisitos como parte integrada en la captura de requisitos o directamente en el
diseño. Esto es justificable principalmente en los casos en que los requisitos son muy
simples y son bien conocidos
Para elegir cualquiera de estas variantes, se deben poner en la balanza las ventajas y desventajas
de cada
una de ellas, evaluando por ejemplo el contexto en el que se desarrollará el proyecto, el nivel de
experiencia de los recursos humanos, el nivel de documentación exigido y su costo de
mantenimiento, la cantidad de iteraciones del ciclo y la documentación de cada una de ellas, etc.
Una vez ubicados dentro del Proceso de Desarrollo veremos como nos permiten las herramientas de
UML llegar a obtener la arquitectura de un sistema ejecutable, según las especificaciones obtenidas
de los usuarios a través del modelo de requerimientos.
Los propósitos del modelo de análisis son fundamentalmente transformar los requerimientos en
un sistema ejecutable, evolucionar a una arquitectura mas robusta y adaptar el diseño a un
entorno de implementación.
X Verdadero
○ Falso
En el caso de que los requisitos están muy bien modelados, son muy simples y son bien conocidos por
los analistas y desarrolladores, la etapa de análisis puede obviarse, pasando directamente al diseño.
X Verdadero
○ Falso
El flujo de Análisis tiene su punto de mayor desarrollo en la fase de
elaboración.
X Verdadero
SP3 / H2: El Diagrama de Clases
La Vista Estática de UML
Una vez que se posee un acabado conocimiento de la instancia de negocio que queremos analizar, que se
han identificado todos los actores y sus responsabilidades generando los correspondientes casos de uso, y
también se han generado los prototipos de interfaces que se utilizarán, los que ya deberían haber sido
expuestos a la consideración de los usuarios, estamos en condiciones de realizar el Diagrama de Clases y
analizar la correspondencia entre éste y los otros diagramas mencionados anteriormente.
Cuando se construye una casa, se comienza con un vocabulario que incluye bloques de construcción
básicos, tales como paredes, suelos, ventanas, puertas, techos y vigas. Estos elementos son principalmente
estructurales (las paredes tienen una altura, un largo y un ancho), pero también tienen algo de
comportamiento (diferentes tipos de paredes pueden soportar diferentes cargas, las puertas se abren y
cierran, etcétera). Los diseños que se crean para visualizar la casa y especificar sus detalles a la empresa
constructora son representaciones gráficas de estos elementos y sus relaciones.
La construcción de software coincide en muchas de estas características con la construcción de una
casa, excepto que, dada la fluidez del software, es posible definir los bloques de construcción básicos
desde cero. Con UML, los diagramas de clases se emplean para visualizar el aspecto estático de estos
bloques y sus relaciones para especificar los detalles para construirlos.
El Diagrama de Clases es el más representativo de la Vista Estática (ver en UML, "Las Vistas de
UML") del sistema y es la base de UML.
Los elementos de la vista estática de un modelo son los conceptos significativos en una aplicación,
incluyendo conceptos del mundo real, conceptos abstractos, conceptos de implementación, conceptos de
computación y todo tipo de conceptos encontrados en los sistemas. Por ejemplo, en nuestra situació
profesional, el sistema de venta telefónica de entradas para Ventel tiene conceptos tales como clientes,
espectáculos, tarjetas, comunicaciones con el centro de autorización, registro de ventas y administración de
los datos de las transacciones, etcétera.
La vista estática captura la estructura de la clase. Un sistema orientado a objetos unifica la estructura de datos y
características del comportamiento en una sola estructura de clase. La vista estática incluye todo lo que
concierne a las estructuras de datos tradicionales, como así también la organización de las operaciones sobre
los datos. Los datos y las operaciones son cuantificadas en clases. En la perspectiva orientada a objetos, los
datos y el comportamiento se relacionan estrechamente. Por ejemplo, un objeto de venta de entrada lleva datos,
como su monto, fecha de la operación, número de tarjeta y código de tarjeta, así como operaciones sobre él,
como verificar saldo disponible o actualizar el saldo de la tarjeta después de autorizarla.
La vista estática describe entidades de comportamiento como elementos de modelado, pero no contiene
los detalles de su comportamiento dinámico. Su ejecución dinámica es descripta por otros diagramas que
muestran los detalles internos de su dinámica. Estas otras vistas incluyen los diagramas de colaboración,
los diagramas de interacción y los diagramas de estados.
Obviamente, las vistas dinámicas requieren de la vista estática para describir las cosas que interactúan
dinámicamente; no se puede decir cómo interactúa algo sin decir primero qué está interactuando. En
síntesis, la vista estática es la base sobre la que se construyen las otras vistas.
Los Clasificadores
Los elementos que constituyen las vistas de UML son los clasificadores y sus relaciones. Un clasificador
es un mecanismo que describe características estructurales y de comportamiento. Es un concepto
discreto * 11.1 en el modelo, que tiene identidad, estado, comportamiento, y relaciones.
El tipo más importante de clasificador en UML es la clase, y su forma gráfica es la que mostraba la Figura 1-2-4
* 11.2 . Como ya estudiamos en la Situación profesional 1, una clase es una descripción de un conjunto de
objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Sin embargo, las clases no
son el único tipo de clasificador. UML proporciona otros tipos de clasificadores para ayudar a modelar
"Tipos de clasificadores para modelar"

Interfaz: es una colección de operaciones que especifican un servicio de una clase o componente. La interfaz es la descripción
del comportamiento de los objetos sin dar a conocer su implementación o estado; contiene operaciones pero no atributos. Una
o más clases o componentes pueden realizar una interfaz, y cada clase implementa las operaciones de la interfaz.
Tipo de datos: Un tipo cuyos valores no tienen identidad, incluyendo los tipos primitivos predefinidos (como números y cadenas),
así como los tipos enumerados como los booleanos.
Señal: La especificación de un estímulo asíncrono enviado desde instancias. Se utiliza principalmente en las vistas de
comportamiento dinámico.
Componente: Una parte física y reemplazable de un sistema que conforma y proporciona la realización de un conjunto de
interfaces.
Nodo: Un elemento físico que existe en tiempo de ejecución y representa y recurso computacional, generalmente con alguna
memoria y a menudo capacidad de procesamiento.
Caso de uso: Descripción de una secuencia de acciones, incluyendo variantes, que ejecuta un sistema y produce un resultado
observable para un actor particular.
Paquete: Es un subsistema, una agrupación de elementos, algunos de los cuales constituyen una especificación del
comportamiento de los otros elementos contenidos.
Las Relaciones
Por otro lado, una relación es una conexión entre elementos. En el modelado orientado a objetos, los cuatro
tipos más importantes de relaciones son las dependencias, las generalizaciones, las asociaciones y las
realizaciones. Gráficamente, una relación se dibuja como una línea que une dos clasificadores, con
diferentes tipos de trazo y de extremos para distinguir los diferentes tipos. También otros tipos de relaciones
utilizadas en UML son las relaciones de uso (utilizadas en el diagrama de casos de uso) y de flujo (utilizadas
en los diagramas de estados y actividades).
Ya hemos visto algunas de ellas cuando estudiamos el Diagrama de Casos de Uso (Relaciones de inclusión
y extensión * 11.3 ), o los elementos de las metodologías orientadas a objetos (Generalización * 11.4 ).
Tanto la forma gráfica como la utilización de los clasificadores y las relaciones, se irán desarrollando
mientras avancemos en los distintos diagramas.
Objetivos del Diagrama de Clases
Como ya mencionamos, el Diagrama de Clases se utiliza para modelar la vista de diseño estática de un sistema.
Esta vista soporta principalmente los requisistos funcionales de un sistema, los servicios que el sistema debe
proporcionar a sus usuarios finales. Cuando se modela esta vista, normalmente se utiliza este diagrama para:
Modelar el vocabulario de un sistema: El modelado del vocabulario de un sistema implica tomar
decisiones sobre qué abstracciones son parte del sistema en consideración y cuáles caen fuera
de sus límites. Los diagramas de clases especifican estas abstracciones y sus
responsabilidades.
Modelar colaboraciones simples: Una colaboración es una sociedad de clases, interfaces y otros
elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma
de todos los elementos. Por ejemplo cuando se modela la semántica de una transacción en un
sistema distribuido, no se puede observar simplemente una clase aislada para comprender qué
ocurre. Más bien, esta semántica se lleva a cabo por un conjunto de clases que colaboran entre
sí. Los diagramas de clases se emplean para visualizar y especificar este conjunto de clases y
sus relaciones.
Modelar un esquema lógico de base de datos: Se puede pensar en un esquema como en un
plano para el diseño conceptual de una base de datos. En muchos dominios se necesitará
almacenar información persistente en una base de datos relacional o en una base de datos
orientada a objetos. Se pueden modelar esquemas para estas bases de datos mediante el
diagrama de clases. Esta última aplicación del diagrama de clases, es la que más utilizaremos en
el estudio de nuestra materia y en la resolución de los casos, aunque es necesario aclarar las
siguientes cuestiones:
El diseño lógico de bases de datos no forma parte del alcance de nuestra materia. Los
conceptos de abstracción, normalización, multiplicidad, entre otros; ya fueron estudiados por
usted en la materia Estructuras de Datos.
El diagrama de clases no es el Der. El diagrama de clases es un modelo de propósito bastante
más amplio y rico en cuanto a los aspectos estáticos del sistema que describe, y además
ambos tienen objetivos diferentes. Por este motivo no hablaremos de tablas, sino de clases;
de registros o filas, sino de objetos; de campos, sino de atributos.
Veamos un ejemplo de un Diagrama de Clases concreto, relacionado con nuestra Situación profesional.
En la Figura 3-2-1 observamos una versión segmentada del diagrama de clases del Sistema de Venta
Telefónica de Entradas. Podemos observar los clasificadores utilizados y las relaciones entre ellos (de
asociación binaria y generalización).
Observe también que está planteada la multiplicidad (o cardinalidad) de las relaciones en forma de pares.
Los tipos de dato de los atributos pueden ser omitidos temporalmente durante las primeras etapas del
análisis, ya que es una característica de poca relevancia cuando se plantean las primeras estructuras. De
todas maneras su identificación temprana ayuda a adelantar tareas específicas del flujo de diseño.
Diagrama de Clases parcial del Sistema de Venta Telefónica de Entradas (Figura 3-2-1)
Análisis de las relaciones

Asociaciones
Una asociación describe conexiones discretas entre objetos u otras instancias de un sistema. Una
asociación relaciona una lista ordenada de dos o más clasificadores, con las repeticiones permitidas. Las
asociaciones tienen las siguientes características:
Enlaces: Así como un objeto es una instancia de una clase, una instancia de una asociación es
un enlace. Un enlace es una lista ordenada de referencias a objetos, cada uno de los cuales
debe ser una instancia de la clase correspondiente en la asociación o una instancia de un
descendiente de la clase. Los enlaces en un sistema constituyen parte del estado del sistema.
Los enlaces no existen independientemente de los objetos; toman su identidad de los objetos
que se relacionan (en
términos de bases de datos, la lista de objetos es la clave para el enlace).

Bidireccionalidad: Los diferentes extremos de una asociación son distinguibles, incluso si dos de
ellos implican la misma clase. Esto quiere decir que diversos objetos de la misma clase pueden
ser relacionados. Debido a que los extremos son distinguibles, una asociación no es simétrica
por lo tanto los extremos no pueden ser intercambiados. Una relación bidireccional significa que
las relaciones lógicas trabajan en ambos sentidos. Es frecuente que esta asociación se
entienda mal, esto no quiere significar que una clase "conozca" a la otra clase o que durante la
ejecución de una aplicación sea posible tener acceso a cada clase desde la otra.
En los diagramas las asociaciones se pueden indicar con direcciones de navegación, para asignar la
posibilidad de atravesar una asociación en una dirección pero no en la otra, pero ésto corresponde a una
decisión del diseño.
La forma más común de asociación es una asociación binaria, que ocurre entre un par de clasificadores.
Como ya definimos, una instancia de una asociación es un enlace, y éste abarca una lista ordenada de
objetos, cada uno dibujado a partir de su clase correspondiente. Todo enlace binario abarca un par de
objetos como se muestra en la Figura 3-2-2.
Las asociaciones serán las encargadas de llevar la información sobre las relaciones entre los objetos
participantes de un sistema. Cuando un sistema se encuentra en ejecución se crean los enlaces entre los
objetos y luego se destruyen. Como ejemplo de esto podemos citar lo siguiente para el caso del cajero
automático: Durante la instancia de negocio de extracción de dinero se generarán los enlaces entre la
tarjeta del cliente, la cuenta del cliente y el banco en el que está esa cuenta; estos enlaces permanecerán
vivos hasta tanto la transacción no se haya finalizado.
Las asociaciones son las relaciones que mantiene unido un sistema. Si no existieran estas asociaciones,
solo tendríamos clases separadas que no trabajan juntas.
Asociaciones Binarias y Autoasociaciones. Notaciones (Figura 3-2-2)
Puede darse el caso que un solo objeto se asocie a sí mismo si la misma clase aparece más de una vez en
una asociación. Por lo tanto, si la misma clase aparece dos veces en una asociación, las dos instancias no
tienen que ser el mismo objeto, y no lo son generalmente. Esta situación se denomina Autoasociación, y está
presentada en la figura 3-2-2. Es muy utilizada para expresar relaciones jerárquicas entre objetos que
representan datos persistentes.
Las conexiones de una asociación a una clase se llaman extremo de la asociación. La mayoría de la
información sobre una asociación se une a uno de sus extremos. Los extremos de la asociación pueden tener
nombres, llamados nombres de rol y visibilidad. La propiedad más importante que tienen es la multiplicidad, es
decir, cuantas instancias de una clase se pueden relacionar con una instancia de otra clase.
Para una asociación binaria, la notación que utilizamos es una línea que conecta las clases que participan en
esa asociación. El nombre de asociación debe ponerse a lo largo y sobre de la línea, con el nombre de rol y
la multiplicidad en cada extremo de la línea como se muestra también en la figura 3-2-2.
En algunos casos, puede ocurrir que una asociación tenga atributos por sí misma, en cuyo caso es una
asociación y una clase, es decir, una clase asociación (Figura 3-2-3). Este tipo de asociaciones se utiliza para
evitar la creación de una nueva clase ante asociaciones con multiplicidad *..*.
Ejemplo de una Clase Asociación (Figura 3-2-3)
Si un atributo de la asociación es único dentro de un conjunto de objetos relacionados, entonces es un

calificador (figura 3-2-4). Un calificador es un valor que permite seleccionar un objeto único del conjunto de
objetos que se relacionan a través de una asociación. Los calificadores son importantes para modelar los
nombres y los códigos de identificación (claves). Los calificadores también se utilizan para analizar índices
en un modelo de diseño. Se representan con un pequeño rectángulo ubicado en el extremo de la
asociación que califican, y pueden detallar los atributos calificadores.
Podemos observar también en la figura 3-2-4, construida con MS Visio 2010, que esta herramienta (así como
otros diagramadores que soportan UML) nos permite mostrar y ocultar partes gráficas de los clasificadores (no
confundir con calificadores), a través de la configuración de las propiedades de presentación. En este caso
hemos ocultado el cuadro de atributos y el cuadro de métodos, para resaltar gráficamente los calificadores.
Asociación Calificada (Figura 3-2-4)

Durante el análisis, las asociaciones representan relaciones lógicas entre objetos. No hay gran
necesidad de imponer la dirección, o de tratar sobre cómo implementarla. Para definir estas
especificaciones, tendremos otros tipos de relaciones.
Agregación y Composición
Una agregación es una asociación que representa una relación todo-parte. Se muestra en los diagramas
como un diamante hueco en el extremo de la trayectoria unida a la clase agregada.
Una composición es una forma más fuerte de asociación, donde el compuesto es el responsable
único de gestionar sus partes, por ejemplo una camisa está compuesta por puño, mangas, botones,
etc., pero si eliminamos la camisa y el cuello será inútil por si solo. Se muestra con un diamante
relleno el extremo compuesto.
Existe una asociación separada entre cada clase que representa una parte y la clase que representa el todo,
pero por conveniencia, las trayectorias dirigidas al todo pueden unirse para dibujar el sistema entero de
asociaciones como un árbol. La figura 3-2-5 muestra ejemplos de un agregado y un compuesto.
Agregación y Composición (Figura 3-2-5)
Generalización y Especialización
La relación de generalización es una relación taxonómica (de clasificación) entre una descripción más
general y una descripción más específica, que se construye sobre ella y obviamente la extiende. La
descripción más específica es completamente consistente con la más general (tiene todas sus
propiedades, miembros y relaciones), y puede contener información adicional.
En las relaciones de generalización la descripción más general se llama padre. La descripción más
específica se llama hijo. Para las clases, los términos superclase y subclase se utilizan para el padre y el
hijo respectivamente. La forma de graficar una generalización es con una flecha desde hijo al padre, con un
triángulo hueco en el extremo conectado con el padre (figura 3-2-6). Varias relaciones de generalización se
pueden dibujar opcionalmente como un árbol con una punta de flecha que se ramifica en varias líneas a los
hijos, como se mostraba en la Figura 1-2-6 * 11.5 .
Generalización y Especialización (Figura 3-2-6)
Se dice que una superclase generaliza a sus subclases, mientras que una subclase especializa a su superclase.
De ahí que el nombre de este tipo de relación entre clases se llame de Generalización y Especialización.
Las operaciones polimórficas son permitidas en la generalización. El polimorfismo funciona porque una
clase padre puede tener muchos hijos, cada uno de los hijos implementa su propia variación de una
operación, que se define a través de todo el conjunto de clases. Por ejemplo, el cálculo de intereses
funcionaría de forma diferente en una hipoteca y en un préstamo para un automóvil, pero cada uno de
ellos es una variación del cálculo de interés de la clase padre Préstamo.
Cuando se declara una variable de la clase padre, cualquier objeto de clases hijas puede ser asociado a
ella, lógicamente cada uno de ellos con sus propias operaciones según la clase a la que pertenezca. Esto
es particularmente útil porque se pueden agregar nuevas clases más adelante, sin necesidad de modificar
las llamadas polimórficas existentes. Por ejemplo, se podría agregar más adelante una nueva clase
préstamo, y el código existente que utiliza la operación del cálculo de interés todavía funcionaría.
La generalización permite también la descripción de un elemento que comparte las descripciones de sus
antecesores. Esto se llama herencia (ver SP1 / H2: Metodología). La herencia es el mecanismo por el cual la
descripción de los objetos de una clase se articula a partir de los fragmentos de declaración de la clase y de
sus antecesores. La herencia permite que las partes compartidas de la descripción se declaren una vez y
sean compartidas por muchas clases, en lugar de que se repitan en cada clase que las utiliza. Al compartir,
el tamaño del modelo se reduce y por consiguiente se reduce el número de los cambios que se deben
realizar al actualizar el modelo.
Un hijo hereda todas las propiedades heredables de todos sus antecesores. Su conjunto completo de
propiedades está compuesto por el conjunto de propiedades heredadas junto con las propiedades que él
declara directamente. Debe tenerse en cuenta que un atributo declarado en un antecesor no puede
estar declarado nuevamente en un descendiente.
En una clase concreta, cada operación heredada o declarada debe tener un método definido, en forma
directa o por herencia de un antecesor.
REFERENCIAS 11
11.2 : Representación de una Clase (Figura 1-2-4)
11.3 : Diagrama de Asociaciones del caso de uso "Vendiendo Entradas" (Figura 2-2-5
11.4 : Diagrama de Clases de UML (Figura 1-2-3)

11.5 : Jerarquía de Clases (Figura 1-2-6)
Marque a qué concepto corresponde el grafo siguiente:
X Calificador

X Multiplicidad
Agregación

X Generalización

X Composición

○ Calificador
○ Composición
○ Agregación
○ Generalización
○ Multiplicidad

Un enlace es:
X Una instancia de una asociación.

Vea la imagen y marque las afirmaciones correctas sobre la figura:
○ Empleado es una subclase de Ejecutivo.

○ Empleado hereda el atributo “Autoriza Gastos”.
○ Ejecutivo es una superclase de Empleado.

Cuando una asociación binaria entre dos clases tiene multiplicidad de tipo *..*, ¿Como se
puede resolver?.
X Estableciendo una clase asociación.

○ Eliminando la asociación.
X Creando una nueva clase intermedia que rompa la multiplicidad.
○ No es necesario resolver la situación.
Identifique en la lista al elemento que NO es considerado un clasificador en UML:
○ Interfaz.
○ Tipo de dato.
○ Paquete.
○ Caso de Uso.
X Todos son clasificadores.
SP3 / H3: Caso de Uso - Análisis
Clase de Análisis
Para comenzar con el desarrollo del análisis y aplicarlo en nuestra situación profesional, empezaremos
estudiando uno de los conceptos más importantes para esta etapa, que es la Clase de Análisis y
analizaremos su aplicación para poder empezar a estructurar nuestro sistema.
Las clases de análisis representan un modelo conceptual primario de las cosas o términos en el sistema
que tienen responsabilidades y comportamiento. Eventualmente se transforman en clases y/o subsistemas
dentro del sistema principal.
Obviamente, partimos de los casos de uso generados en la etapa anterior y nos centramos en el análisis de
los requisitos funcionales, dejando para la etapa de diseño e implementación los requisitos no funcionales.
Esto hace que una clase de análisis sea más evidente en el contexto del dominio del problema.
Las clases de análisis siempre encajan en uno de los tres estereotipos * 12.1 básicos del análisis: interfaz,
control o entidad, y en ellas se analizan las responsabilidades, los atributos y las relaciones que tiene con
sus pares del modelo.
Clases de Interfaz
Las clases de interfaz se utilizan para modelar la interacción que existe entre el sistema y sus actores,
teniendo en cuenta que esta interacción implica recibir información, presentar información; y efectuar
peticiones de los usuarios o sistemas externos. Estas clases usualmente son representadas por interfaces
definidas en algún lenguaje de programación, como por ejemplo, Java o Visual Basic.
Una de las características fundamentales de las clases de interfaz es la de hacer fácil el entendimiento
del sistema porque precisamente clarifican la frontera entre el sistema y el exterior.
Pero no sólo serán interfaces visuales, también podríamos tener como una interfaz a un protocolo
de comunicación, a un equipo de comunicaciones o cualquier otro componente informático.
Finalmente recordemos tres conceptos para encontrar rapidamente nuestras clases de interfaz en el modelo:
Interfaz de usuario: son las que representan la interacción Sistema-Actor, y generalmente son
ventanas. Ej.: ventana de ingreso de clientes.
Interfaz de sistemas: son interfaces entre el sistema y otros sistemas. Ej.: la comunicación
con una tarjeta de crédito.
Interfaz con dispositivos: proveen comunicación con dispositivos de hardware. Ej.:
la comunicación con un módem o un software de FTP.
Clases de Control
Las clases de control representan la coordinación, secuencia y transacciones que se utilizan para
encapsular el comportamiento de un caso de uso. También pueden ser utilizadas para representar
derivaciones y cálculos complejos (es decir, aspectos dinámicos del sistema) hacia otros objetos (de
entidad y de interfaz). Cabe destacar que en muchos casos de uso simples, no es necesario el uso de
clases de control, generalmente se utilizan para modelar comportamiento complejo de casos de uso que
tienen gran cantidad de cálculos y procesamiento de datos.
Cabe destacar que la clase de control no maneja todo dentro de un caso de uso, sino más bien es la
encargada de coordinar a otros objetos que implementan la funcionalidad requerida. Es decir que le delegan
trabajo a otros objetos que realizan las tareas y luego le retornan los resultados.
Recordemos algunos pasos para encontrar de manera sencilla nuestras clases de control:
Determinar cuándo una clase de control es necesaria: será necesario principalmente cuando el
comportamiento no pueda ser manejado por ninguna de las otras clases; ésto sucederá
cuando el comportamiento sea complejo, y estas generalmente podrán ser rehusadas desde
otras partes del sistema.
Encapsular el flujo normal de eventos y el alternativo en diferentes clases de control: esto se hace
generalmente para simplificar los cambios, esto hará al sistema más mantenible y fácil
de extender al sistema en el futuro.
Dividir en dos clases de control cuando dos actores compartan esta misma clase: es necesario dividir
las clases de control cuando estas son utilizadas por varios actores, esto debe venir ya
pensado desde el modelo de requerimientos, ya que en esta etapa es bastante complicado
introducir cambios.
Clases de Entidad
Las clases de entidad se utilizan para modelar la información persistente del sistema y su comportamiento
asociado. Por otro lado, generalmente los objetos instanciados a partir de estas clases son utilizados para
mantener información de eventos, personas, y objetos que tengan implicancia en el sistema, ya que estos
usualmente son persistentes, tienen atributos y relaciones que perduran por largos períodos.
Estas son las más sencillas ya que estamos acostumbrados a manipular este tipo de clases, principalmente
en el diseño de tablas, en una base de datos. Los objetos creados de estas clases son usualmente pasivos y
persistentes, y solo tienen la responsabilidad de almacenar y administrar la información en el sistema.
Generalmente estas clases ya fueron encontradas en el modelo de objetos del problema, en la etapa
de Requerimientos, con lo cual no necesitaremos mucho esfuerzo para encontrarlas, salvo una
revisión y un refinamiento.
Su representación gráfica, al igual que la de la de los otros dos estereotipos que estudiaremos, está
estandarizada en UML y sus símbolos básicos provienen de las primeras metodologías orientadas a
objetos. Actualmente, y debido al uso de distintos diagramadores y herramientas CASE para modelar
UML, pueden utilizarse básicamente las alternativas que se presentan en la Figura 3-3-1:
Símbolos estandarizados de los estereotipos o clases de análisis (Figura 3-3-1)
Nosotros utilizaremos en los diagramas la Alternativa 1, ya que nuestra herramienta de modelado será Microsoft
Visio. Es posible, como en el caso de la Figura 3-3-1, que sea necesario definir nuevas etiquetas en idioma
español para los estereotipos. Por ejemplo, por defecto las etiquetas que trae la Visio se denoninan
<<Interface>>, <<Utility>> y <<Struct>> respectivamente. En definitiva, son todas clases.
Realizaciones de Casos de Uso – Análisis
Una vez aclaradas las diferencias entre estos estereotipos de clases, veremos cómo se produce la realización
de un caso de uso - análisis. Esta realización describe cómo se lleva a cabo y se ejecuta un caso de uso
determinado, utilizando para ello sus objetos de análisis (las tres clases definidas en el párrafo anterior).
Identificados los diferentes tipos de clases que intervienen en el caso de uso que se analiza, las mismas
deben relacionarse para representar la parte funcional del sistema en un diagrama de clases (no confunda
este diagrama de clases con el diagrama de clase de la vista estática).
Este proceso de relacionar los diferentes tipos de clases identificados se denomina realización de caso de
uso - análisis. La realización de caso de uso posee una descripción textual del flujo de sucesos, diagramas
de clases que muestran el escenario particular del caso de uso en términos de interacciones de objetos del
análisis (diagramas de colaboración y secuencia).
Veamos un ejempo de las relaciones que se manifiestan entre los diferentes tipos de clases en la realización
de un caso de uso de nuestra situación profesional. El caso de uso que tomaremos será "Estableciendo
Funciones", y para plantear la realización, tomaremos como base los modelos y documentación generados
en el Modelo de Requerimientos: Prototipo de Interfaz * 12.2 , Diagrama de Asociaciones * 12.3 y la Ficha
de Caso de Uso * 12.4 .
En este caso, cabe destacar que estamos trabajando con clases y por lo tanto no existirán los mensajes
entre las clases, ya que éstos son atributo de los "objetos". Este modelo es una versión particular de un
Diagrama de Clases, donde los atributos y operaciones de cada clase están ocultos; donde se muestra en
cada caso el estereotipo de análisis; y donde las relaciones entre las clases son "vínculos" de colaboración.
Realización del caso de uso - análisis "Estableciendo Funciones" (Figura 3-3-2)
Como se ve en la Figura 3-3-2, el diagrama de clases que se ha presentado carece de la identificación de

los requisitos y responsabilidades que tendrán los objetos cuando un actor envía algún mensaje al
sistema, por lo tanto es necesario refinar este diagrama y transformarlo en un diagrama de colaboración en
el que se detallen ellas, creando enlaces entre ellos y añadiendo mensajes en los vínculos.
Para poder construir este diagrama de colaboración es necesario contar con la descripción del flujo de
sucesos-análisis de manera textual. Presentemos ahora esta descripción:
1) El Gerente de Administración a través de la interfaz * 12.5 "IU Estableciendo Funciones"
gestiona la generación de nuevas funciones para un espectáculo.
2) La interfaz utiliza el Gestor de Datos para mostrar obtener los datos para mostrar en las listas de
valores (ver Prototipo de Interfaz).
3) La interfaz solicitará al actor los datos necesarios para la creación de nuevas funciones (fecha
desde, fecha hasta, dia, hora, etcétera).
4) Una vez que se llenaron los datos y se confirmaron los mismos, el Gestor de Funciones registra los
datos de las nuevas funciones, y luego muestra los nuevos datos en la interfaz.
Las acciones de "Eliminación" y "Modificación" de funciones no están planteadas en el flujo de sucesos.
Un diagrama de realización, al igual que cualquiera de los diagramas de interacción, no tiene que
abarcar necesariamente toda la funcionalidad del caso de uso, ni incluir todas sus clases u operaciones.
Podemos tener más de un diagrama de estos tipos por caso de uso que especifiquen el comportamiento
de distintos cursos de uso.
Ahora estamos en condiciones de realizar el diagrama de colaboración, mediante la utilización de la

descripción textual de los flujos de acción y el diagrama de clases presentado anteriormente. Antes de
empezar con el diagrama es conveniente que desarrollemos algunos conceptos sobre esta herramienta.
Diagramas de colaboración
Como mencionábamos anteriormente, diagrama de colaboración se utiliza para ejecutar la realización de un
caso de uso, es decir como interactúan los objetos instanciados de las clases definidas anteriormente
(Entidad, Control, Interfaz) para llevar adelante el objetivo del caso de uso. Este diagrama forma parte de un
meta diagrama denominado de interacción, y es acompañado por el de secuencia, que veremos en la
próxima situación profesional, es decir que uno se utiliza en el análisis y el otro en el diseño.
Como vimos, un diagrama de colaboración destaca la organización de los objetos que participan en una
interacción. Un diagrama de colaboración se construye colocando en primer lugar los objetos que participan
en la colaboración como nodos del grafo. A continuación se representan los enlaces que conectan esos
objetos como arcos del grafo. Por último, en estos enlaces se colocan los mensajes que envían y reciben los
objetos. Esto da al lector una señal visual clara del flujo de control en el contexto de la organización
estructural de los objetos que colaboran.
Los diagramas de colaboración tienen dos características que los distinguen de los diagramas de secuencia:
En primer lugar, el camino. Para indicar cómo se enlaza un objeto a otro, se puede asociar un
camino al extremo más lejano de un enlace (como «local», que indica que el objeto
designado es local al emisor).
En segundo lugar, está el número de secuencia. Para indicar la ordenación temporal de un
mensaje, se precede de un número (comenzando con el mensaje número 1), que se incrementa
secuencialmente por cada nuevo mensaje en el flujo de control (2, 3, etc.). Para representar el
anidamiento, se utiliza la numeración (1 es el primer mensaje; 1.1 es el primer mensaje dentro del
mensaje 1 ; 1.2 es el segundo mensaje dentro del mensaje 1 ; etcétera). El anidamiento se puede
representar a cualquier nivel de profundidad. Cabe acotar que también a través del mismo
enlace, se pueden mostrar varios mensajes (posiblemente enviados desde distintas direcciones),
y cada uno tendrá un número de secuencia único.
Los diagramas de secuencia y de colaboración son semánticamente equivalentes, ya que ambos derivan
de la misma información del meta-modelo de UML. Como consecuencia de esto, se puede partir de un
diagrama en una forma y convertirlo a la otra sin pérdida de información. Sin embargo, ésto no significa que
ambos diagramas visualicen explícitamente la misma información.
Análogamente, el diagrama de secuencia muestra el retorno de mensajes (por ejemplo el valor de retorno
éxito ), pero el correspondiente diagrama de colaboración no lo hace. En ambos casos, los dos diagramas
comparten el mismo modelo, pero cada uno puede representar cosas que el otro no representa.
Cuando se modelan los aspectos dinámicos de un sistema, normalmente se utilizan los
diagramas de interacción de dos formas:
Para modelar flujos de control por ordenación temporal: Para ello se utilizan los diagramas de
secuencia. El modelado de un flujo de control por ordenación temporal destaca el paso de mensajes
tal y como se desarrolla a lo largo del tiempo, lo que es una forma útil de visualizar el
comportamiento dinámico en el contexto de un escenario de un caso de uso. Los diagramas de
secuencia hacen un papel mejor que los diagramas de colaboración para mostrar las
iteraciones y las bifurcaciones sencillas.
Para modelar flujos de control por organización: Para ello se utilizan los diagramas de
colaboración. El modelado de un flujo de control por organización destaca las relaciones
estructurales entre las instancias de la interacción, a través de las cuales pasan los mensajes.
Los diagramas de colaboración son mejores que los diagramas de secuencia para visualizar las
iteraciones y las bifurcaciones complejas.
Ahora estamos en condiciones de confeccionar una realización de un caso de uso - análisis a través
de un diagrama de colaboración, tal como se ve en la siguiente figura 3-3-3:
Diagrama de colaboración de una realización del caso de uso "Estableciendo Funciones" (Figura 3-3-3)
Observamos en el diagrama de colaboración las siguientes características:

Las clases se transformaron en objetos. Podemos observarlo en la notación, que el nombre de
la clase está precedido por un símbolo de dos puntos ":" y subrayado.
Los vínculos, son ahora roles de asociación o "colaboraciones", donde se especifican
los mensajes de comunicación entre un objeto y su asociado.
Los mensajes ejecutan a los métodos de las clases. Este diagrama es una excelente
oportunidad para analizar nuevos métodos de clase no identificados.
La dirección del mensaje está representada por una flecha que va desde el objeto
que "demanda" hacia el objeto que realiza la operación o devuelve una respuesta.
Se puede ver el orden secuencial de las interacciones.
Estos diagramas de realización y diagramas de colaboración deberán confeccionarse para cada uno de los casos
de uso que usted haya identificado en la etapa de relevamiento, generalmente, y una vez experimentado
no será necesario confeccionar ambos, solo con el de colaboración será suficiente.

La forma de confeccionar estos diagramas está explicada en la sección "Anexos, en Microsoft Visio 2010".
Paquete del análisis
Antes de avanzar con este concepto, definamos qué es un Paquete. En UML, un paquete es un mecanismo de
propósito general para organizar elementos en grupos. Un paquete puede contener otros elementos, incluyendo
clases, interfaces, componentes, nodos, colaboraciones, casos de uso, diagramas e incluso otros paquetes.
Esta "contención" genera una relación de posesión que implica que cada elemento se declara en el paquete, y
por lo tanto que éste pertenece al paquete. Si el paquete se destruye, el elemento es destruido.
Los paquetes pueden ser utilizados durante las etapas de requerimientos, de análisis, diseño e implementación.
Permiten organizar los modelos según diversos criterios, como la arquitectura del sistema, las vistas de UML, los
subsistemas o "módulos" que tendrá el sistema, etc. Un paquete es también una clase, por lo tanto tiene todas las
caracterísitcas de esta. Los paquetes pueden estar relacionados entre sí mediante asociaciones,
generalizaciones, dependencias, composición, etc., como podemos observar en el ejemplo de la Figura 3-3-4.
Ejemplo de Paquetes (Figura 3-3-4)
Los paquetes del análisis proporcionan un medio para organizar los elementos del modelo de análisis en piezas
manejables. Un paquete de análisis puede constar de clases de análisis, de realizaciones de casos de uso, y de
otros paquetes del análisis (recursivamente). Los paquetes del análisis tienen las siguientes características:
Deberían ser cohesivos, es decir que sus contenidos deberían estar fuertemente relacionados; y
deberían ser débilmente acoplados, es decir que sus interdependencias deberían minimizarse.
Pueden representar una separación de intereses de análisis. Por ejemplo, en un sistema grande
algunos paquetes del análisis pueden analizarse de manera separada, y posiblemente en forma
conjunta por diferentes desarrolladores con diferente conocimiento del dominio.
Deberían crearse en base a los requisitos funcionales y dentro del dominio del problema (es decir, la
aplicación o el negocio), y deberían ser reconocibles por las personas con conocimiento del dominio. Los
paquetes del análisis no deberían basarse en requisitos no funcionales o en el dominio de la solución.
Probablemente se convertirán en subsistemas en el modelo de diseño, o probablemente se distribuirán
entre ellos. En algunos casos, un paquete del análisis podría incluso reflejar una capa completa de primer
nivel en el modelo de diseño.
Paquetes de servicio y paquetes de negocio
Aparte de proporcionar casos de uso a sus actores, todo sistema también proporciona un conjunto de
servicios a sus clientes. Un cliente adquiere una combinación adecuada de servicios para ofrecer a sus
usuarios los casos de uso necesarios para llevar a cabo su negocio.
Un caso de uso, especifica una secuencia de acciones: un actor inicia una transacción, seguida de interacciones
entre el actor y el sistema, que termina tras haber devuelto un valor al actor. Normalmente los casos de uso no
existen aisladamente. Por ejemplo el caso de uso "Generando Entradas" presupone que otro caso de uso ha
creado las Funciones ("Estableciendo Funciones") y que están disponibles estos datos para su utilización.
Por otro lado, un servicio representa un conjunto coherente de acciones relacionadas funcionalmente que
se utiliza en varios casos de uso. Un cliente de un sistema normalmente compra una combinación de
servicios para ofrecer a sus usuarios los casos de uso necesarios. Un servicio es indivisible en el sentido
de que el sistema necesita ofrecerlo o todo entero o nada en absoluto.
Podemos decir entonces que los casos de uso son para los usuarios, y los servicios son para los clientes. Los
casos de uso atraviesan a los servicios, es decir, un caso de uso requiere acciones de varios servicios.
Los paquetes del análisis pueden identificarse entonces como paquetes del negocio y paquetes de servicio
(figura 3-3-5). Los primeros estarán estructurados en función a los casos de uso, mientras que los segundos
agruparán los elementos de soporte funcional del sistema.
Diagrama de Paquetes (Figura 3-3-5)

En la figura observamos un Diagrama de Paquetes correspondiente al Sistema de Venta Telefónica de
Entradas (Ventel) de nuestra situación profesional. Vemos un paquete superior correspondiente al sistema,
compuesto por los paquetes de negocio que agruparán los casos de uso. A su vez, el paquete de servicio
"Datos", del cual dependenden (usan) los módulos de negocio, agrupa al componente "Gestor de Datos"
(entre otros). La funcionalidad de este componente, que ya la conocimos en la realización del caso de uso -
análisis "Estableciendo Funciones", es retornar listas de valores.
A continuación, en el Ejercicio resuelto procederemos a desarrollar el análisis restante en el caso de
uso "Generando Entradas" de nuestra situación profesional.
REFERENCIAS
12.1 : Estereotipo
Extensión del vocabulario de UML que permite crear nuevos bloques de construcción derivados a partir de los existentes,
pero específicos a un problema concreto. Por ejemplo: un actor es un estereotipo de una clase, es decir, es una clase
utilizada en un determinado contexto, con propiedades y comportamientos específicos.
12.2 : Prototipo de Interfaz: Caso de Uso "Estableciendo Funciones"
12.3 : Diagrama de Relación de Caso de Uso: Caso de Uso "Estableciendo Funciones"

12.4 : Ficha de Caso de Uso: Caso de Uso "Estableciendo Funcion
Definición de IU:
IU: Abreviatura que se utiliza para indicar que se trata de una Interfaz de Usuario.
El modelo que representa una Realización de Caso de Uso - Análisis, pertenece a la vista estática ya
que es un diagrama de clases.
X Verdadero
Una clase de análisis representa un modelo conceptual primario de las cosas o términos en el
sistema que tienen responsabilidades y comportamiento.
X Verdadero

Continuando con el desarrollo del análisis de nuestra situación profesional, desarrollaremos los Diagramas
de Clases correspondientes, las realizaciones de Casos de Uso - Análisis y los diagramas de colaboración
faltantes. Nos enfocaremos en los casos de uso "Especificando Funciones" y "Generando Entradas".
Hagamos una breve recopilación de la documentación ya generada:
Sistema de Venta Telefónica de Entradas (Caso de Uso * 13.1 )
Módulo de Gestión de Datos (Caso de Uso * 13.2 )
Caso de Uso "Estableciendo Funciones":
Prototipo de Interfaz: * 13.3
Diagrama de Asociaciones: * 13.4
Ficha de Caso de Uso: * 13.5
Realización de Caso de Uso - Análisis: * 13.6
Diagrama de Colaboración: * 13.7
Caso de Uso "Generando Entradas":
Prototipo de Interfaz: * 13.8
Diagrama de Asociaciones: * 13.9
Ficha de Caso de Uso: * 13.10
Quedan pendientes de resolver entonces: el Diagrama de Clases del módulo, y los diagramas de Realización y
Colaboración para el caso de uso "Generando Entradas" para analizar el comportamiento del mismo.
Como primer paso, procederemos a desarrollar los Diagramas de Clases de cada uno de estos casos de
uso. Aplicando las herramientas ya aprendidas, y basándonos en la documentación del Modelo de
Requerimientos, plantearemos una versión preliminar de este diagrama, enfocándonos en primera
instancia en la identificación de las clases, sus relaciones y la multiplicidad de las mismas:
* 13.11 Imágenes
Imágenes "Diagrama de clases. Ej. resuelto SP3"
Como se podrá apreciar, hemos ocultado (gráficamente a través de una propiedad de MS Visio) los
bloques de atributos y métodos para facilitar la lectura del diagrama.
Al confrontar estos diagramas y realizar el análisis conjunto vemos que existe una coherencia total entre las
restricciones que impone el diagrama de clases en lo referente a las cardinalidades, los atributos y las
estructuras con lo diagramado en el prototipo de interfaz y con la lista de requerimientos que nos
permitieron determinar los casos de uso y sus funcionalidades.
Ahora lo que haremos es integrar ambos diagramas para obtener un diagrama general. Recuerde que el
Diagrama de Clases es la vista estática no solo de un caso de uso, sino que puede alcanzar a un
subsistema o al sistema mismo. De hecho, el Diagrama de Clases se va "alimentando" del resto de los
modelos, incorporando nuevas entidades, métodos, relaciones, atributos, restricciones, etc..
Incorporaremos también en este diagrama integrado los atributos de las clases, especificando sus tipos
de dato, y enfocándonos principalmente en los atributos identificados en las interfaces y en los
requerimientos. También podemos incorporar otros atributos que consideremos que forman parte del
dominio del sistema y que podrán ser utilizados por otros casos de uso del sistema.
Aclaramos que algunas clases fueron reubicadas para mejorar la distribución gráfica del diagrama.
Diagrama de Clases integrado
Ya contando con el Diagrama de Clases, procederemos a modelar la Realización de Caso de Uso -

Análisis "Generando Entradas":
Caso de Uso "Generando Entradas": Realización de Caso de Uso - Análisis
Fíjese que en el diagrama, las entidades están alineadas en columnas de acuerdo a su estereotipo,
es decir las clases de análisis <<Interfaz>>, <<Control>> y <<Entidad>>. Esta organización del
modelo fue realizada ex profeso para que visualmente queden claramente sectorizadas las tres
capas principales de una aplicación: Interfaz, Negocio y Datos respectivamente. Por supuesto, esta
organización no es de ninguna manera "obligatoria"; es más, es muy difícil de mantener en
diagramas complejos donde se hace muy necesario reubicar elementos permanentemente.
A continuación, basados en la Realización, construimos el Diagrama de Colaboración. Incorporamos
nuevos mensajes y reutilizamos otros que ya fueron creados para el caso de uso anterior. Recuerde que
los mensajes llaman a operaciones (métodos), y que deben ser incorporadas como tales en las clases
correspondientes.
Caso de Uso "Generando Entradas": Diagrama de Colaboración

Para finalizar con el objetivo de nuestro ejercicio, presentamos el Diagrama de Clases
terminado para el Módulo de Gestión de Datos de nuestro sistema Ventel. Como ya
establecimos en la herramienta donde estudiamos este diagrama, solamente plantearemos
clases de tipo "entidad", es decir que servirán para almacenar datos.
Módulo de Gestión de Datos: Diagrama de Clases
REFERENCIAS 13
13.1 : Diagrama de Casos de Uso: Módulos del Sistema de Venta Telefónica de Entradas
13.2 : Diagrama de Casos de Uso: Casos de uso del Módulo de Gestión de Datos

13.5 : Ficha de Caso de Uso: Caso de Uso "Estableciendo Funciones"

13.6 : Realización del caso de uso - análisis "Estableciendo Funciones" (Figura 3-3-2)
13.7 : Diagrama de colaboración de una realización del caso de uso "Estableciendo Funciones" (Figura 3-
3-3)
13.8 : Prototipo de Interfaz: Caso de Uso "Generando Espectáculos"
13.9 : Diagrama de Relación de Caso de Uso: Caso de Uso "Generando Entradas"

13.10 : Ficha de Caso de Uso: Caso de Uso "Generando Entradas"
13.11 Imágenes: Diagrama de clases. Ej. resuelto SP3
SP3 / Ejercicio por resolver
A usted le tocará continuar con el Módulo de Venta de Entradas del Sistema Ventel. Ya hemos estudiado
las herramientas necesarias, como el Diagrama de Clases, la Realización de un Caso de Uso - Análisis y
el Diagrama de Colaboración.
Con el objetivo de ayudarlo en esta tarea, hemos presentado el Diagrama de Clases del sistema ya
completo y resuelto, con sus clases, atributos y métodos. También lo hemos presentado terminado para
que todos los alumnos partan de la misma base al resolver este ejercicio, minimizando las diferencias de
"criterio de análisis" que puedan presentarse en el desarrollo de los diagramas.
Sistema Ventel: Diagrama de Clases completo
Note que, en este diagrama, a las Entradas las hemos tratado como una superclase que posee dos
subclases: Reservadas y Vendidas. Pudo haberse optado por no desarrollar una superclase y resolver el
registro de las entradas vendidas y reservadas de otra manera (trabajar con clases independientes o
incorporando un atributo de Estado).
Puede darse el caso de que surja algún método nuevo durante la resolución. Si así fuera, éste debe
ser incorporado al Diagrama de Clases.
Actividad: Casos de Uso - Análisis.
Desarrolle los diagramas de Realización de Caso de Uso - Análisis y Colaboración, para cada de uno de
los tres casos de uso del Módulo de Venta de Entradas * 14.1 . No olvide que son 6 diagramas en total.

Identifique las afirmaciones correctas:
○ El Módulo de Venta de Entradas se modelaría como un Paquete de Servicio.

X En el Diagrama de Colaboración, las clases se representan como objetos.
X La Realización de Caso de Uso - Análisis se utiliza para llegar al Diagrama de Colaboración, y
puede ser obviada.
○ El Diagrama de Colaboración destaca la ordenación, mientras que el de Secuencia la
organización de los objetos.
X En las colaboraciones, los mensajes ejecutan a los métodos de las clases.
Indique la afirmación incorrecta sobre el proceso de análisis:
X Puede tener redundancias e inconsistencias. Éstas se resuelven en el diseño.

○ Es estructurado en clases y paquetes.
○ Es una vista interna del sistema.
○ Esboza cómo funciona el sistema por dentro.
○ Se encuentra descripto en el lenguaje del desarrollador.
¿Cuál de estos objetivos del Diagrama de Clases no es correcto?
○ Modelar la vista de diseño estática de un sistema.

○ Modelar el vocabulario de un sistema.
○ Modelar colaboraciones simples.
○ Visualizar y especificar el este conjunto de clases dominio y sus relaciones.

¿Cuáles son los elementos que conforman un diagrama de colaboración?
○ Clases, Colaboraciones y Mensajes.

X Objetos, Colaboraciones y Mensajes.
○ Objetos, Vínculos y Colaboraciones.
○ Clases, Vínculos y Colaboraciones.
○ Objetos, Colaboraciones y Métodos.
Relacione los conceptos análogos entre el Diagrama de Clases y el Diagrama de Entidad Relación (DER):
Clase Tabla
Asociación Binaria Relación
Multiplicidad Cardinalidad
Calificador Atributo Clave
Método No presenta
Objeto Fila
Situación profesional 4: Diseño
Por las mismas razones expuestas en la Situación profesional anterior, continuamos con el desarrolo del
caso práctico que venimos estudiando desde la etapa de Requerimientos.
En esta situación profesional aplicaremos las herramientas del Diseño de UML en nuestro Proceso
Unificado de Software, con el objetivo de comprender y generar todos aquellos modelos que permiten
especificar el comportamiento dinámico y más "fino" del sistema. Utilizaremos para ello todos los modelos
generados durante el Análisis.
Recién en la próxima Situación profesional (Implementación), donde estudiaremos el modelado los
detalles físicos de un sistema, abordaremos un nuevo ejercicio con una problemática diferente.
espectáculos tales como obras de teatro, conciertos, musicales, etcétera.
La rendición del cobro de las entradas a los organizadores se realiza cada 10 días, por intermedio de Bancos
autorizados. Ventel obtiene como ganancia un 12% de las ventas realizadas, la cual se descuenta al
Para ver la documentación generada en la etapa de Análisis, acceda al Ejercicio resuelto de la
situación profesional 3.
SP4 / H1: El Modelo de Diseño
El papel del diseño en el Ciclo de Vida del Software
Creemos que es necesario efectuar una síntesis general para repasar las actividades desarrolladas
hasta el momento en anteriores situaciones profesionales para ubicarnos en la descripción del Flujo de
Trabajo del Diseño.
Hemos comenzado nuestro estudio capturando los requerimientos del sistema en la etapa de Requisitos,
posteriormente en la etapa de análisis especificamos el modelo de sistema en forma lógica, es decir que
nuestra tarea se centró en la visión de lo que se necesita hacer en el modelo de sistema,
independientemente de la forma de hacerlo. Para ello hemos empleado herramientas tales como: listas de
requerimientos, casos de usos, diagramas de clase, etcétera; ésto significa que en nuestro estudio no
consideramos los requerimientos físicos de hardware. En cambio, durante el diseño se toman decisiones
acerca de la forma en que se resolverá el problema que se ha analizado en la etapa anterior, teniendo en
cuenta ahora sí los componentes físicos de hardware que se utilizarán en la etapa de implementación.
El proceso de diseño se realiza generalmente en dos partes durante su desarrollo: en la primera, más
cercana al análisis, sirve para llevar el modelo lógico desarrollado hasta el momento a un modelo físico, sin
introducirse demasiado en los componentes físicos del software y del hardware; mientras que en la segunda
parte el diseño se aproxima a la implementación, por lo tanto se utilizan herramientas de modelado con
niveles de detalle físicos más fuertes.
En la etapa del Diseño se modela el sistema de manera que pueda soportar todos los requerimientos incluyendo
la arquitectura, los requerimientos no funcionales y otras restricciones. El modelo de análisis que se generó
anteriormente nos proporcionará la totalidad de los requerimientos relevados del sistema en cuestión. Además el
modelo de análisis le ha impuesto al sistema una cierta estructura que se deberá respetar.
Para llevar a cabo este planteo se deben cumplir los propósitos que nos plantea la metodología para el
modelo de diseño:
Se debe adquirir un conocimiento acabado de todo lo vinculado con los requerimientos no
funcionales y las restricciones que se encuentren relacionadas al lenguaje de programación, que
componentes será provistos desde un repositorio (reutilización de código), los sistemas
operativos, tecnologías y metodologías de distribución, gestión de las transacciones, etcétera.
Proporcionar un modelo de entrada para las actividades de implementación: determinar
cuáles serán los subsistemas, las interfaces y clases.
Proporcionar las herramientas que permitan descomponer las tareas de implementación en partes
manejables. Para ello se capturan las interfaces entre los subsistemas, lo que nos ayudará en los
casos de interfaces que deban funcionar de manera sincronizada entre diferentes equipos de
desarrollo. También se visualiza y se reflexiona sobre el diseño utilizando una notación común y
por último se crea una abstracción de la implementación del sistema como un refinamiento del
diseño.
El diseño debe ser considerado como el nodo en donde finaliza la fase de elaboración y donde comienzan los
ciclos de iteración de construcción, como se muestra en la Figura 4-1-1. Este detalle es el que contribuye a que la
arquitectura sea sólida y estable y proporcionar una estructura que definirá el modelo de implementación.
De todos modos es difícil separar el modelo de diseño del modelo de implementación puesto que el
primero puede ser utilizado para visualizar la implementación.
El Diseño dentro del Proceso Unificado de Desarrollo (Figura 4-1-1)
Tal como lo expresáramos anteriormente, todos los modelos que se construyen se encuentran
entrelazados y dependen directamente unos de otros. Partimos para obtener el modelo de Diseño del
Modelo de Análisis y entre ellos podemos mencionar ciertas diferencias que nos permitirán determinar las
forma en que deberemos trabajar en las diferentes etapas.
Mientras que en el Modelo de Análisis se construyó un modelo conceptual dado que es una abstracción
de lo que se pretende que realice el sistema, en el Modelo de Diseño estaremos realizando un físico
porque estaremos indicando explícitamente como deberá realizarse la implementación.
En el Modelo de Análisis el tema del diseño fue tomado en forma genérica, en cambio en el modelado
del diseño se realizan especificaciones de la implementación. Esto permite diferenciar estos dos modelos
en otros aspectos como los que presenta la siguiente tabla:
Modelo de Análisis vs. Modelo de Diseño (Figura 4-1-2)

Elementos del Diseño
El modelo de diseño es un modelo de objetos que describe la realización física de los casos de uso y se
centra en cómo los requisitos funcionales * 15.1 y no funcionales * 15.2 , junto con las restricciones del
entorno de implementación, afectan al sistema en consideración.
El modelo de diseño es una jerarquía de subsistemas de diseño que contienen clases del diseño,
realizaciones de caso de uso-diseño e interfaces.
Como notará, todos estos conceptos le resultarán familiares, ya que han sidos vistos en herramientas
anteriores, con la diferencia fundamental de que en esta etapa, todas sus características se profundizan
internamente, se define concretamente el dinamismo secuencial de los casos de uso y del sistema en
general y se especifican los componentes ya con una orientación concreta a los aspectos conceptuales y
físicos del sistema.
Interactiva "Modelo de diseño"
Subsistema de diseño: es un paquete que proporciona los medios para organizar las herramientas del modelado de diseño
en piezas manejables. Un subsistema del diseño puede consistir en clases del diseño, realización de casos de uso-diseño,
interfaces y otros subsistemas del diseño utilizados de manera recursiva. Los paquetes en la etapa de diseño se
constituyen en subsistemas, que al igual que en el análisis, se pueden estructurar en subsistemas de negocio y de servicio.
Clases del diseño: representan una abstracción de una clase o construcción similar en la implementación de un sistema, esto se
debe a que el lenguaje utilizado en una clase de diseño es similar al lenguaje de programación, es decir que las operaciones,
parámetros, atributos, tipos y demás especificaciones utilizan la misma sintaxis del lenguaje de programación elegido.
Caso de uso - diseño: es una descripción textual que explica y complementa los diagramas que definen la realización del
caso de uso. Además recopila requisitos, como los requisitos no funcionales, de una realización de caso de uso. Se trata de
requisitos que se especifican en el análisis, pero que se manejan mejor en el diseño y la implementación.
Interfaces: como ya se ha visto son una colección de operaciones que son utilizadas para especificar un servicio de una
clase o de los subsistemas del diseño.
En las siguientes herramientas, comenzaremos a explicar y a utilizar herramientas de modelado de

diseño que nos permite mostrar el comportamiento dinámico de un sistema.
REFERENCIAS
15.1 : Requisito Funcional
Especifica una acción que debe ser capaz de realizar el sistema, sin considerar restricciones físicas. Este requisito
especifica comportamiento de entrada/salida de un sistema.
15.2 : Requisito No Funcional
Especifica propiedades del sistema, como restricciones del entorno o de implementación, rendimiento,
dependencias de la plataforma, mantenimiento y fiabilidad. Estos requisitos especifican restricciones físicas sobre
un requisito funcional.
RRespuestas de la Autoevaluación
El Proceso de Diseño se realiza generalmente dos partes durante su desarrollo, una mas cercana
al análisis para llevar el modelo lógico al físico, y otra que se aproxima a la implementación, con
modelos de mayor de detalle de componentes físicos.
X Verdadero
○ Falso
Las estructuras generadas durante en el Modelo de Análisis son respetadas en el Modelo de Diseño.
X Verdadero
○ Falso
SP4 / H2: Interacciones
Diagramas de Interacción
La vista de Interacción se utiliza para describir secuencias de intercambios de mensajes entre los roles
que implementan el comportamiento de un sistema.
Los Diagramas de Secuencia y los Diagramas de Colaboración (ambos llamados diagramas de interacción) son
dos de los cinco tipos de diagramas de UML que se utilizan para modelar los aspectos dinámicos de los sistemas.
Un Diagrama de Interacción muestra de manera específica una interacción, que consiste en un
conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar entre ellos.
Un Diagrama de Secuencia es un Diagrama de Interacción que destaca la ordenación temporal de los mensajes;
es más adecuado para observar la perspectiva cronológica de las interacciones, muestra la secuencia explícita
de mensajes y son mejores para especificaciones de tiempo real y para escenarios complejos.
Un Diagrama de Colaboración es un diagrama de interacción que destaca la organización estructural de
los objetos que envían y reciben mensajes, ofrece una mejor visión espacial mostrando los enlaces de
comunicación entre objetos, muestra las relaciones entre objetos y son mejores para comprender todos
los efectos que tiene un objeto y para el diseño de procedimientos.
Esta visión proporciona una vista integral del comportamiento del sistema, es decir, muestra el flujo de
control a través de muchos objetos. La vista de interacción se manifiesta en estos dos diagramas centrados
en distintos aspectos pero complementarios: el primero de ellos centrado en los objetos individuales y el
segundo centrados en objetos cooperantes.
En el sistema, los objetos interactúan para realizar colectivamente los servicios ofrecidos por las
aplicaciones. Los diagramas de interacción muestran cómo se comunican los objetos en una interacción, es
por ello que los diagramas de interacción pueden ser utilizados para visualizar, especificar, construir y
documentar la dinámica de un conjunto particular de objetos, o se pueden utilizar para modelar un flujo de
control particular de un caso de uso.
Definiciones
Antes de describir cada uno de los elementos que componen estos diagramas, creemos conveniente
realizar algunas explicaciones referentes a los alcances de las definiciones de los siguiente términos: Flujo
de Control, Colaboración, Interacción y Patrón, utilizados en esta herramienta.
Flujo de Control: los aspectos dinámicos se visualizan, se especifican, se construyen y se documentan como
flujos de control, que
pueden incluir simples secuencias de interacciones a través del sistema, así como flujos más complejos que
impliquen
bifurcaciones, iteraciones, recursión y concurrencia.
Colaboración: una colaboración es una descripción de una colección de objetos que interactúan para
implementar un cierto comportamiento dentro de un contexto. Describe una sociedad de objetos cooperantes
unidos para realizar un cierto propósito. Una colaboración tiene un aspecto estructural y un aspecto de
comportamiento. El aspecto estructural es similar a una vista estática: contiene un conjunto de roles y
relaciones que definen el contexto para su comportamiento. El comportamiento es el conjunto de mensajes
intercambiados por los objetos ligados a los roles. Tal conjunto de mensajes en una colaboración se llama
Interacción. Una colaboración puede incluir una o más interacciones.
Interacción: es el conjunto de mensajes intercambiados por los roles de clasificador a través de los roles de
asociación. Un mensaje es una comunicación unidireccional entre dos objetos, un flujo de objeto con la
información de un remitente a un receptor. Un mensaje puede tener parámetros que transporten valores
entre objetos. Un mensaje puede ser una señal (comunicación explícita entre objetos, con nombre y
asíncrona) o una llamada (la invocación de una operación con un mecanismo para el control, que retorna
posteriormente al remitente). Un patrón de intercambios de mensajes que se realizan para lograr un
propósito específico es lo que se denomina una interacción.
Patrón: un patrón es una colaboración parametrizada, junto con las pautas sobre cuándo debe ser utilizado.
Un parámetro se puede sustituir por diversos valores, para producir distintas colaboraciones. Los parámetros
señalan generalmente las ranuras para las clases.
Diagramas de Secuencia
Un diagrama de secuencia destaca la ordenación temporal de los mensajes. Como se muestra en la
Figura 4-2-1, un Diagrama de Secuencia se forma colocando en primer lugar los objetos que participan
en la interacción en la parte superior del diagrama, a lo largo del eje X. Normalmente, se coloca a la
izquierda el objeto que inicia la interacción, y los objetos subordinados a la derecha. A continuación, se
colocan los mensajes que estos objetos envían y reciben a lo largo del eje Y, en orden de sucesión en
el tiempo, desde arriba hasta abajo.
Esto ofrece al lector una señal visual clara del flujo de control a lo largo del tiempo.
Diagrama de Secuencia de Caso de Uso "Estableciendo Funciones" (Figura 4-2-1)
Este diagrama fue realizado tomando como base el Diagrama de Colaboración del Caso de Uso
"Estableciendo Funciones" * 16.1 , desarrollado en la Situación profesional anterior.
Los Diagramas de Secuencia, conocidos también como Diagramas de Traza de eventos o de interacción de
objetos, se utilizan con frecuencia para validar los casos de uso. Documentan el proceso de diseño desde el
punto de vista de los casos de uso. Observando qué mensajes se envían a los objetos, componentes o
casos de uso y viendo de modo estimativo cuanto tiempo consume el método invocado.
Los Diagramas de Secuencia tienen características que los distinguen de los Diagramas de Colaboración.
Interactiva "Diagramas de secuencia: características"
Línea de vida: la línea de vida da de un objeto es la línea discontinua vertical que representa la existencia de
un objeto a lo largo
de un período de tiempo. La mayoría de los objetos que aparecen en un diagrama de interacción existirán
mientras dure la
interacción, así que los objetos se colocan en la parte superior del diagrama, con sus líneas de vida
dibujadas desde arriba hasta abajo. Pueden crearse objetos durante la interacción. Sus líneas de vida
comienzan con la recepción del mensaje como «create».
Los objetos pueden destruirse durante la interacción. Sus líneas de vida acaban con la recepción del
mensaje como «destroy» (además se muestra la señal visual de una gran X que marca el final de sus vidas).
Ver figura 4-2-2.
Activación o Foco de control: el foco de control es un rectángulo delgado y estrecho que representa el
período de tiempo durante el cual un objeto ejecuta una acción, bien sea directamente o a través de un
procedimiento subordinado. La parte superior del rectángulo se alinea con el comienzo de la acción; la
inferior se alinea con su terminación (y puede marcarse con un mensaje de retorno). También puede
mostrarse el anidamiento de un foco de control (que puede estar causado por recursión, una llamada a una
operación propia, o una llamada desde otro objeto) colocando otro foco de control ligeramente a la derecha
de su foco padre (esto se puede hacer a cualquier nivel de profundidad). Si se quiere ser especialmente
preciso acerca de dónde se encuentra el foco de control, también se puede sombrear la región del
rectángulo durante la cual el método del objeto está ejecutándose (y el control no ha pasado a otro objeto).
Devoluciones: o también llamados retornos, devuelven un valor al invocador. Recordemos que siempre los
enlaces entre objetos son bidireccionales, y en particular las colaboraciones, lo que significa que ante una
ejecución o llamada, es conveniente manejar valores de retorno para poder validar el resultado de la
transacción y poder dar feedback al objeto correspondiente. Esto es muy útil para evaluar cursos alternativos
de acción y para dar mensajes a los usuarios a través de la interfaz.
Marcadores de destrucción de objetos: puede mostrarse en la gráfica qué objetos son destruidos durante la
ejecución del flujo de
control, agregando una equis (X) en la línea de vida del objeto. Generalmente son objetos que se destruyen
explícitamente aquellos que no tienen persistencia en el sistema, como por ejemplo algunos gestores u
objetos de procesamiento, que son invocados y utilizados durante un ciclo específico y con un objetivo
determinado, debiendo liberar recursos computacionales una vez finalizada su tarea.
Normalmente, los diagramas de interacción contienen como elementos básicos a los Objetos, los Enlaces y
los Mensajes. A continuación, la Figura 4-2-2 presenta otro ejemplo de un Diagrama de Secuencia de una
transacción simple de acutalización, donde se puede apreciar que en la etapa de diseño, los Diagramas de
Interacción incorporan detalles específicos del producto final, como los nombres definitivos de los métodos,
los parámetros, el dominio de objetos, las instancias de creación y destrucción de los mismos, entre otros.
Ejemplo de Diagrama de Secuencia (Figura 4-2-2)
Diagramas de Colaboración
Un Diagrama de Colaboración es una forma alternativa al diagrama de secuencia de mostrar un escenario.
Este tipo de diagrama muestra las interacciones entre objetos organizadas entorno a los objetos y los
enlaces entre ellos. Ya hemos tenido oportunidad de estudiar este tipo de diagramas en la Situación
profesional anterior, como resultantes de la especificación de las Realizaciones de Casos de Uso - Análisis.
Los Diagramas de Secuencia proporcionan una forma de ver el escenario en un orden temporal (qué pasa
primero, qué pasa después). Los clientes entienden fácilmente este tipo de diagramas, por lo que resultan
útiles en las primeras fases de análisis. Por el contrario, los diagramas de colaboración proporcionan la
representación principal de un escenario, ya que las colaboraciones se organizan entorno a los enlaces de
unos objetos con otros. Este tipo de diagramas se utilizan más frecuentemente en la fase de diseño, es decir,
cuando estamos diseñando la implementación de las relaciones.
Como se muestra en la figura 4-2-3 (Diagrama de Colaboración correspondiente al mismo caso de la figura 4-2-
2), se construye colocando en primer lugar los objetos que participan en la colaboración como nodos del grafo. A
continuación se representan los enlaces que conectan esos objetos como arcos del grafo. Por último, en estos
enlaces se colocan los mensajes que envían y reciben los objetos. Esto da al lector una señal visual clara del
flujo de control en el contexto de la organización estructural de los objetos que colaboran.
Ejemplo de Diagrama de Colaboración (Figura 4-2-3)
Los Diagramas de Colaboración tienen dos características que los distinguen de los diagramas de secuencia. En
primer lugar, el camino. Para indicar cómo se enlaza un objeto a otro, se puede asociar un camino al extremo más
lejano de un enlace (como «local», que indica que el objeto designado es local al emisor).
En segundo lugar, está el número de secuencia. Para indicar la ordenación temporal de un mensaje, se
precede de un número (comenzando con el mensaje número 1), que se incrementa de manera secuencial
por cada nuevo mensaje en el flujo de control (2, 3, etc.). Para representar el anidamiento, se utiliza la
numeración (1 es el primer mensaje; 1.1 es el primer mensaje dentro del mensaje 1 ; 1.2 es el segundo
mensaje dentro del mensaje 1 ; etc.). El anidamiento se puede representar a cualquier nivel de profundidad.
Cabe acotar que también a través del mismo enlace, se pueden mostrar varios mensajes (posiblemente
enviados desde distintas direcciones), y cada uno tendrá un número de secuencia único.
A continuación se enumeran los elementos fundamentales de un Diagrama de Colaboración:
Interactiva "Elementos fundamentales de un diagrama de colaboración"

Objeto: se representa con un rectángulo que contiene el nombre y la clase del objeto en un formato
nombreObjeto :
nombreClase.
Enlaces: un enlace es una instancia de una asociación en un diagrama de clases. Se representa como una
línea continua que une a dos objetos, acompañada por un número que indica el orden dentro de la
interacción. Pueden darse varios niveles de subíndices para indicar anidamiento de operaciones. Se pueden
utilizar estereotipos para indicar si el objeto que recibe el mensaje es un atributo, un parámetro de un
mensaje anterior, si es un objeto local o global.
Flujo de mensajes: expresa el envío de un mensaje. Se representa mediante una flecha dirigida cerca de un
enlace.
Marcadores de creación y destrucción de objetos: puede mostrarse en la gráfica qué objetos son creados y
destruidos, agregando una restricción con la palabra "new" o "delete" respectivamente.
Objeto compuesto: es una representación alternativa de un objeto y sus atributos. En esta representación se
muestran los objetos contenidos dentro del rectángulo que representa al objeto que los contiene.
Los Diagramas de Secuencia y de Colaboración son semánticamente equivalentes, ya que ambos fueron
creados a partir de la misma información del meta-modelo de UML. Como consecuencia de esto, se puede
partir de un diagrama en una forma y convertirlo a la otra sin pérdida de información, como se muestra en
las dos figuras 4-2-2 y 4-2-3, que son semánticamente equivalentes. De hecho, la mayoría de las
herramientas CASE * 16.2 que soportan UML, cuentan con una función de conversión automática.
Sin embargo, esto no significa que ambos diagramas visualicen explícitamente la misma información. Por
ejemplo, en las figuras anteriores, el Diagrama de Colaboración muestra cómo se enlazan los objetos («local» y
«global»), mientras que el correspondiente Diagrama de Secuencia no lo muestra. Análogamente, el Diagrama
de Secuencia muestra el retorno de mensajes (por ejemplo el valor de retorno éxito ), pero el correspondiente
Diagrama de Colaboración no lo hace. En ambos casos, los dos diagramas comparten el mismo modelo, pero
cada uno puede representar cosas que el otro no representa, es decir que son complementarios.
Cuando se modelan los aspectos dinámicos de un sistema, normalmente se utilizan los diagramas
de interacción de dos formas:
Para modelar flujos de control por ordenación temporal: Para ello se utilizan los Diagramas de
Secuencia. El modelado de un flujo de control por ordenación temporal destaca el paso de
mensajes tal y como se desarrolla a lo largo del tiempo, lo que es una forma útil de visualizar el
comportamiento dinámico en el contexto de un escenario de un caso de uso. Los diagramas de
secuencia hacen un papel mejor que los diagramas de colaboración para mostrar las
iteraciones y las bifurcaciones sencillas.
Para modelar flujos de control por organización: Para ello se utilizan los Diagramas de
Colaboración. El modelado de un flujo de control por organización destaca las relaciones
estructurales entre las instancias de la interacción, a través de las cuales pasan los mensajes.
Los diagramas de colaboración son mejores que los diagramas de secuencia para visualizar las
iteraciones y las bifurcaciones complejas.
REFERENCIAS
16.1 : Diagrama de colaboración de una realización del caso de uso "Estableciendo Funciones" (Figura 3-3-3)
16.2 : Herramienta CASE

Las herramientas CASE (Computer Aided Software Engineering o Ingeniería de Software Asistida por Computadora) son
diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software. Existen herramientas
CASE que permiten desarrollar software orientado a objetos, que están basadas principalmente en UML como lenguaje de
modelado: Rational Rose, Enterprise Architect, StarUML, entre otras.
El elemento Línea de vida corresponde al diagrama de interacción:
○ Colaboración
X Secuencia
○ Ambos
El elemento Organización temporal corresponde al diagrama de interacción:
○ Colaboración
X Secuencia
○ Ambos
El elemento Enlace corresponde al diagrama de interacción:
X Colaboración
○ Secuencia
○ Ambos
El elemento Devolución corresponde al diagrama de interacción:
○ Colaboración
X Secuencia
○ Ambos
El elemento Número de secuencia corresponde al diagrama de interacción:
X Colaboración
○ Secuencia
○ Ambos
El elemento Activación corresponde al diagrama de interacción:
○ Colaboración
X Secuencia
○ Ambos
El elemento Objetos corresponde al diagrama de interacción:
○ Colaboración
○ Secuencia
X Ambos
El elemento Mensajes corresponde al diagrama de interacción:

○ Colaboración
○ Secuencia
X Ambos
El Diagrama de Secuencia y el Diagrama de Colaboración son en cierta forma complementarios,
pero ¿Qué los diferencia fundamentalmente?:
○ Nada, pueden utilizarse indistintamente cualquiera de los

dos.
○ El Diagrama de Colaboración muestra las interfaces.
○ El Diagrama de Secuencia muestra las interacciones entre objetos.
○ Uno le sirve al programador de aplicaciones y otro al analista de sistemas.
X Uno se centra en la organización de los objetos y el otro en el orden de las interacciones.

Una interacción es...
○ Un conjunto de colaboraciones entre clasificadores.
X Un conjunto de mensajes intercambiados a través de roles de asociación.
○ Una colaboración parametrizada.
○ Una sociedad de objetos cooperantes.

Un flujo de control es...
○ Un conjunto de mensajes intercambiados por clasificadores.
○ Un conjunto de colaboraciones.
○ Una secuencia de mensajes entre objetos.
SP4 / H3: Estados y Actividades
Diagramas de Estado
El Diagrama de Estados muestra el flujo de control entre estados, pero la mayoría de las veces, esto
supone el modelado del comportamiento de objetos reactivos.
Un objeto reactivo es aquel para el que la mejor forma de caracterizar su comportamiento es señalar
cuál es su respuesta a los eventos lanzados desde fuera de su contexto. Un objeto reactivo tiene un
ciclo de vida bien definido, cuyo comportamiento se ve afectado por su pasado. Los diagramas de
estados pueden asociarse a las clases, los casos de uso, o a sistemas completos para visualizar,
especificar, construir y documentar la dinámica de un objeto individual.
Cuando se modelan sistemas con gran cantidad de software, se encuentra que la forma más natural
de visualizar, especificar, construir y documentar el comportamiento de ciertos tipos de objetos es
centrarse en el flujo de control entre estados.
Un estado es una condición durante la vida de un objeto, de forma que cuando dicha condición se
satisface se lleva a cabo alguna acción o se espera por un evento. El estado de un objeto se puede
caracterizar por el valor de uno o varios de los atributos de su clase, además, el estado de un objeto
también se puede caracterizar por la existencia de un enlace con otro objeto.
El Diagrama de Estados engloba todos los mensajes que un objeto puede enviar o recibir. En un
Diagrama de Estados, un escenario representa un camino dentro del diagrama. Dado que
generalmente el intervalo entre dos envíos de mensajes representa un estado, se pueden utilizar
los diagramas de secuencia para buscar los diferentes estados de un objeto.
En todo Diagrama de Estados existen por lo menos dos estados especiales: Inicial (start) y Final
(stop). Cada diagrama debe tener uno y sólo un estado inicial para que el objeto se encuentre en
estado consistente. Por el contrario, podemos tener que un diagrama puede tener varios estados
finales.
Gráficamente, un Diagrama de Estados es una colección de nodos y arcos, como se muestra a
continuación en la figura 4-3-1. Los estados se representan mediante rectángulos con las esquinas
redondeadas, y las transiciones mediante flechas que indican el sentido de la misma.
Ejemplo de Diagrama de Estados de la Clase "Entradas" (Figura 4-3-1)

Hemos tomado para ejemplificar el Diagrama de Estados una situación ya conocida: nuestro Sistema
de Venta Telefónica de Entradas "Ventel", donde elegimos realizar el ciclo vida de un objeto de la
clase "Entradas". Para servir a nuestro fin, modificamos la estructura de la clase, incorporando un
nuevo atributo "Estado", que almacenará los valores D (disponible), R (reservada), A (anulada), V
(vendida) y U (utilizada). Además, se incorporaron nuevos métodos que serán llamados por los
eventos de transición.
Una transición entre estados representa un cambio de un estado origen a un estado sucesor destino
que podría ser el mismo que el estado origen, dicho cambio de estado puede ir acompañado de
alguna acción. Las acciones se asocian a las transiciones y se considera que ocurren de forma rápida
y sin interrupción. Por el contrario, tenemos que las actividades se asocian a los estados pudiendo
consumir más tiempo, dicha actividad puede verse interrumpida por la ocurrencia de algún evento.
Una transición en un diagrama de estados puede tener asociada una acción y/o una guarda,
además, una transición puede disparar un evento.
La acción será el comportamiento que se obtiene cuando ocurre la transición.
El evento será el mensaje que se envía a otro objeto del sistema. Un evento es la
especificación de un acontecimiento significativo que ocupa un lugar en el tiempo y en el
espacio.
La guarda es una expresión booleana sobre los valores de los atributos que hace que la
transición sólo se produzca si la condición evalúa a True (verdadero). Tanto las acciones
como las guardas son comportamientos del objeto y generalmente se traducen en
operaciones de alguna clase.
Existen dos formas de transicionar en un Diagrama de Estados: automáticamente y no
automáticamente. Se produce una transición automática cuando se acaba la actividad del estado
origen (no hay un evento asociado con la transición). Se produce una transición no automática
cuando existe un evento que puede pertenecer a otro objeto o incluso estar fuera del sistema.
Los Diagramas de Estados muestran el comportamiento de los objetos, es decir, el conjunto de
estados por los cuales pasa un objeto durante su vida, junto con los cambios que permiten pasar de
un estado a otro.
Aspectos importantes a considerar

Normalmente, los Diagramas de Estados contienen:
Estados simples y compuestos.
Transiciones, incluyendo eventos y acciones.
Un Diagrama de Estados bien estructurado:
Se ocupa de modelar un aspecto de la dinámica de un sistema.
Sólo contiene aquellos elementos esenciales para simplificar la comprensión.
Cuando se dibuje un Diagrama de Estados:
Hay que darle un nombre que comunique su propósito.
Hay que comenzar modelando los estados estables del objeto, y a continuación
modelar las transiciones entre estados.
Deben considerarse las bifurcaciones, la concurrencia y el flujo de objetos
como algo secundario, quizás en diagramas separados.
Hay que organizar los elementos para que se minimicen los cruces de líneas.
Diagrama de Actividades
El Diagrama de Actividades es el quinto y último tipo de diagrama de UML que se utiliza para el
modelado de los aspectos dinámicos de los sistemas, junto a los diagramas de Casos de Uso,
Colaboración, Secuencia y Estados. Un Diagrama de Actividades es fundamentalmente un diagrama
de flujo que muestra el flujo de control entre actividades, a diferencia de los Diagramas de Interacción,
donde se presentaba el flujo de control entre objetos.
Una actividad es una ejecución no atómica en curso dentro de una máquina de estados * 17.1 .
Cuando hablamos de ejecuciones no atómicas nos referimos a que las actividades pueden
descomponerse aún más, pudiendo ser representadas por otros diagramas de actividades. Las
actividades producen finalmente alguna acción, que está compuesta de computaciones atómicas
ejecutables que producen un cambio en el estado del sistema o la devolución de un valor.
Las acciones, al igual que en el caso del Diagrama de Estados, incluyen llamadas a operaciones,
creación o destrucción de objetos, o simples cálculos como una operación matemática o la evaluación de
una expresión.
Cuando se modelan los aspectos dinámicos de un sistema, normalmente se utilizan los Diagramas de
Actividades de dos formas:
Para modelar un flujo de trabajo: para ello se hace hincapié en las actividades, tal y como
son vistas por los actores que colaboran con el sistema. A menudo, en el entorno de los
sistemas con gran cantidad de software, existen flujos de trabajo y se utilizan para
visualizar, especificar, construir y documentar procesos de negocio que implican al sistema
que se está desarrollando. En este uso delos diagramas de actividades, es particularmente
importante el modelado de los flujos de objetos. Por ejemplo, en la figura 4-3-2, hemos
presentado el flujo de trabajo del Caso de Uso "Reservando Entradas".
Diagrama de Actividades - Flujo de trabajo de Caso de Uso "Reservando Entradas" (Figura 4-3-2)
Para modelar el flujo de control de una operación: Para ello se utilizan los diagramas de
actividades como diagramas de flujo, para modelar los detalles de una computación En este uso
de los diagramas de actividades es particularmente importante el modelado de la bifurcación, la
división y la unión. El contexto de un diagrama de actividades utilizado con esta finalidad incluye
los parámetros de la operación, así como sus objetos locales. Para ejemplificar, hemos
presentado el flujo de control del método "ObtenerTipoEspectáculos()" en la Figura 4-3-3.
Diagrama de Actividades - Modelado del método "ObtenerTipoEspectáculos" de la clase "TipoEspectáculos" (Figura 4-3-3)
Elementos y Conceptos
Tomando como base los diagramas de actividades presentados en las figuras anteriores,
definiremos brevemente cada uno de sus elementos y la forma en que se utilizan dentro del modelo.
Estados inicial y final: al igual que en el Diagrama de Estados, el Diagrama de Actividades
debe presentar los pseudoestados inicial y final, para marcar el comienzo y el fin de un flujo de
control de operaciones o de trabajo. Cada diagrama debe tener uno y sólo un estado inicial
para evitar inconsistencias, y por el contrario puede tener que un diagrama puede tener varios
estados finales. Su representación gráfica es la misma que para el Diagrama de Estados.
Estado de acción: es un estado que representa la ejecución de una acción atómica, normalmente la
invocación de una operación. Los estados de acción no se pueden descomponer, llevan un tiempo
insignificante en su ejecución y son atómicos, es decir que no se interrumpe su ejecución ante la
ocurrencia de eventos. Se utiliza frecuentemente en computaciones como asignaciones de valor,
operaciones matemáticas, lógicas o acciones sobre objetos. Un estado de acción se representa
gráficamente como una píldora (no es un rectángulo con bordes redondeados como en el caso de
los Estados). Ver figura 4-3-3.
Estado de actividad: en contraposición a los estados de acción, los estados de actividad pueden
descomponerse. Pueden ser representados internamente con otros diagramas de actividades. No
son atómicos, es decir que pueden ser interrumpidos durante su ejecución y, en general, se
considera que requieren de cierto tiempo en completarse. Un estado de acción sería un caso
especial del estado de actividad. Son importantes para dividir funcionalidades complejas en
partes, y son semánticamente equivalentes a un expansión del diagrama de actividades (como si
fueran diagramas anidados). Su representación gráfica no tiene diferencias con el estado de
acción, como se muestra en la figura 4-3-2.
Transiciones: cuando se completa la acción o actividad de un estado, el flujo de control pasa
inmediatamente al siguiente estado de acción o actividad. Este flujo se especifica con
transiciones que muestran el camino de un estado de actividad o acción al siguiente. En UML,
como se ve en ambas figuras, se representa con una línea dirigida. Son transiciones de
terminación, es decir que no requieren de disparadores (eventos o métodos), ya que se el
control pasa de un estado finalizado al siguiente de forma automática.
Bifurcación: al igual que en los diagramas de flujo, se pueden incluir bifurcaciones, que especifican
caminos alternativos, elegidos según el valor de alguna expresión booleana. Como se muestra en la
figura 4-3-3, se representa con un rombo. Puede tener una transición de entrada y dos o más de
salida, debiendo especificar para cada una de éstas últimas una expresión de evaluación que no
deben solaparse para evitar un flujo de control ambiguo. Utilizando una variable de control, se
puede lograr el efecto de iteración, mediante un estado de acción que establezca su valor, otro que
incremente su valor, y una bifurcación que evalúe la salida del bucle. UML no impone ningún
lenguaje para éstas expresiones, pudiendo utilizarse texto estructurado, pseudocódigo o la sintaxis y
la semántica de un lenguaje de programación específico (preferentemente orientado a objetos). En
el caso de la figura 4-3-3 se utilizó PHP.
División y Unión: las transiciones secuenciales y las bifurcaciones son los caminos más utilizados en
los diagramas de actividades. Sin embargo, también es posible encontrar flujos concurrentes,
especialmente cuando se modelan flujos de trabajo de procesos de negocios, como el que se
presenta en la figura 4-3-2. En UML se utiliza una barra de sincronización para especificar la
división y unión de estos flujos de control paralelos, que se representa como una línea ancha
horizontal (o vertical, dependiendo la dirección del diagrama). En el caso de la división, puede tener
una transición de entrada y dos o más de salida, que representan caminos que continúan en
paralelo. La unión por el contrario, tiene dos o más transiciones de entrada y solamente una de
salida. En la unión los flujos de control se sincronizan, es decir que el flujo de salida espera hasta
que finalizan todos los flujos de entrada.
Calles: Las calles se utilizan para dividir los estados de actividad de un diagrama en grupos. Cada
calle tiene un nombre único dentro del diagrama y representa, por ejemplo, un parte de la
organización responsable de esas actividades. Semánticamente no tienen mucho peso dentro
deldiagrama, a excepción de que pueden representar alguna entidad del mundo real. En un
diagrama organizado por calles, cada actividad pertenece a una única calle, pero las transiciones
pueden cruzar las calles. Como se ve en la figura 4-3-2, se han representados como calles al
Cliente y al área de Ventas, que son las partes activas en para el flujo de trabajo del Caso de Uso
"Reservando Entradas".
Flujo de Objetos: en el flujo de control de un diagrama de actividades pueden verse involucrados
objetos. Por ejemplo, en el caso de la figura 4-3-2, en el flujo de trabajo del procesamiento de una
reserva de entradas incluiría clases como Entradas y Clientes. Ciertas actividades producirán
instancias de estas dos clases o podrán modificar estos objetos, como en el caso de Confirmar
Datos, que modificará el estado de las entradas reservadas y creará un nuevo objeto de la clase
Clientes. Como se ve en la figura, se pueden especificar los objetos implicados en el diagrama de
actividades, colocándolos conectados mediante una dependencia a la actividad que los crea,
destruye o modifica. Este uso de las relaciones de dependencia y objetos se denomina flujo de
objetos, porque representa la participación de un objeto en un flujo de control. Se representan
gráficamente mediante una línea cortada dirigida. Dentro del objeto se puede mostrar también como
cambian los valores de sus atributos, su estado y sus roles.
Ingeniería directa e inversa

Una de las características más interesantes y más útiles de los Diagramas de Actividades, es que con
ellos se puede hacer ingeniería directa (creación de código a partir de un modelo), especialmente si el
contexto del diagrama es una operación. Por ejemplo, con el Diagrama de Actividades de la figura 4-3-
3, una herramienta CASE * 17.2 podría generar el código PHP que muestra la figura 4-3-4 para el
método "ObtenerTipoEspectáculos()".
Si la herramienta de ingeniería directa cuenta también con el modelo estático de clases, el código
resultante completo sería el siguiente:
La ingeniería inversa (creación de un modelo a partir de código) también es posible con los
Diagramas de Actividades utilizando herramientas CASE, especialmente si el contexto del código
es del cuerpo de una operación.
Tanto la ingeniería directa como la ingeniería inversa a través de herramientas CASE, representan un
conjunto de valiosas posibilidades a disposición de los analistas e ingenieros en sistemas, entre las que
podemos mencionar las siguientes como más importantes:
Permitir la construcción de software partiendo de modelos gráficos UML (ingeniería directa).
Casi utópicamente, un sistema podría desarrollarse de forma completa e independiente de un
lenguaje de programación, prácticamente sin recursos destinados a la fase de construcción.
Por supuesto, estos recursos de programación serán inversamente proporcionales al nivel de
detalle y esfuerzo requerido en el análisis y diseño de los modelos. De todas formas, la
ingeniería directa debería utilizarse racionalmente para minimizar el esfuerzo destinado a la
programación y generar software de altos niveles de calidad y de documentación.
Permitir el modelado y la documentación de sistemas orientados a objetos ya construidos
(ingenieria inversa). Durante nuestra vida profesional podemos enfrentarnos a este tipo de
situaciones, principalmente si integramos áreas de calidad o equipos en proyectos de
reingeniería. No es para nada fuera de lo habitual tener que generar la documentación de un
software productivo (modelos de clases, casos de uso, procesos, modelos de datos,
etcétera), por ejemplo para un proyecto de certificación de normas de calidad de una
organización.
Utilizando las herramientas adecuadas, la ingeniería directa e inversa nos permiten realizar
animaciones y simulaciones de los modelos durante la ejecución del sistema desarrollado.
Por ejemplo, una herramienta podría animar los estados de acción de un diagrama de
actividades mientra se van sucediendo en un sistema en ejecución, o mejor aún, utilizar esta
herramienta como un depurador que nos permita medir la performance, velocidad de
ejecución, examinar valores de los atributos de los objetos o detener las acciones en distintos
puntos de interés.
REFERENCIAS
Máquina de Estados
Comportamiento que especifica la secuencia de estados por los que pasa un objeto a lo largo de su vida en respuesta a
eventos, junto con la respuesta a esos eventos.
Herramienta CASE
Las herramientas CASE (Computer Aided Software Engineering o Ingeniería de Software Asistida por Computadora) son
diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software. Existen
herramientas CASE que permiten desarrollar software orientado a objetos, que están basadas principalmente en UML
como lenguaje de modelado: Rational Rose, Enterprise Architect, StarUML, entre otras.

Un estado es una condición durante la vida de un objeto que cuando se cumple se lleva a cabo
alguna acción o se espera por un evento, y se puede caracterizar por el valor de uno o varios de los
atributos de su clase.
X Verdadero
○ Falso
Las transiciones en el Diagrama de Estados se producen solamente cuando se ejecuta un evento
que puede pertenecer a otro objeto o incluso estar fuera del sistema.
○ Verdadero
X Falso
Indentifique las afirmaciones incorrectas sobre un Diagrama de
Estados: ○ Puede presentar estados simples y compuestos.
X Los estados se representan gráficamente en forma de píldora.

○ Hay que comenzar modelando los estados del objeto, y a continuación las transiciones entre
estados. X Puede tener solamente un estado inicial y un estado final.
○ Los diagramas de estados modelan aspectos dinámicos del sistema.
Relacione los siguientes conceptos de un Diagrama de Actividades:
Estado de acción Operación computacional.

Estado de actividad Estado no atómico.
Transición Cambio automático de actividad.
Bifurcación Camino alternativo.
Calle División en grupos de actividades.
Actividades que se inician en
División
paralelo.
Flujo de Objetos Actividad que afecta a un objeto.

¿En cuáles de las siguientes situaciones es aplicable el Diagrama de Actividades?:
X Modelar un flujo de trabajo en un caso de uso.

X Construir modelos que permintan generar código orientado a objetos mediante ingeniería directa.
○ Representar las interacciones entre clases y objetos.
○ Durante la fase de análisis, en lugar de la Ficha de Caso de Uso.
X Especificar el comportamiento de un método de clase.
Continuando avanzando ahora con el desarrollo del Diseño en nuestra situación profesional, para lo
cual previamente haremos un repaso de los modelos generados en las etapas de Requerimientos y
Análisis, así como también en las herramientas estudiadas del Diseño:
Sistema de Venta Telefónica de Entradas (Diagrama de Caso de Uso * 18.1 , Diagrama de Clases * 18.2 * 18.3 )
Clase Entradas (Diagrama de Estados: * 18.4 )
Clase TipoEspectáculos (Diagrama de Actividades del Método "ObtenerTipoEspectaculos()": * 18.5 )
Módulo de Gestión de Datos (Diagrama de Caso de Uso: * 18.6 )
Caso de Uso "Estableciendo Funciones":
Prototipo de Interfaz * 18.7
Diagrama de Asociaciones * 18.8
Ficha de Caso de Uso * 18.9
Realización de Caso de Uso - Análisis * 18.10
Diagrama de Colaboración * 18.11
Diagrama de Secuencia * 18.12
Caso de Uso "Generando Entradas":
Diagrama de Asociaciones * 18.14
Ficha de Caso de Uso * 18.15
Realización de Caso de Uso - Análisis * 18.16
Diagrama de Colaboración * 18.17
Módulo de Venta de Entradas (Diagrama de Caso de Uso * 18.18 )
Caso de Uso "Reservando Entradas":
Diagrama de Actividades * 18.19
Caso de Uso "Vendiendo Entradas":
En primer lugar, y para especificar los modelos del análisis en esta fase de diseño, realizaremos el
Diagrama de Secuencia del Caso de Uso "Generando Entradas". Para ello tomaremos como base el
Diagrama de Colaboración que modelamos durante el análisis. Como ya se explicó en las herramientas,
ambos diagramas son complementarios y coherentes entre sí.
Diagrama de Secuencia: Caso de Uso "Generando Entradas"
Podemos observar en el diagrama la presencia de los mensajes de devolución, que no estaban presentes
en el Diagrama de Colaboración. Los gestores de Datos y Funciones son instanciados y destruidos durante
la ejecución del caso de uso. Con este modelo, completamos todos los diagramas de interacción del
Módulo de Gestión de Datos.
Avanzando con el Diseño de nuestro módulo, procederemos a especificar más la vista dinámica del
sistema, a través del modelado de los diagramas de Estados y Actividades.
Ya sabemos que estos diagramas, por ser los más detallados del sistema, pueden ser realizados a muchos
niveles y con alcances diferentes. Completar todos los diagramas de actividades y estados posibles es una
ardua y minuciosa tarea que debe ser realizada por el Analista de Sistemas criteriosamente, pero nuestro
objetivo no es completar el modelado de todo el sistema, sino presentar la aplicación concreta de todos los
modelos estudiados en la resolución de una situación profesional compleja.
Es por eso que solamente desarrollaremos los diagramas en sus tres usos más comunes y descriptivos:
Diagrama de Estados de una Clase: Tomaremos de nuestro diagrama la clase "Funciones".
Diagrama de Actividades de un flujo de trabajo: Modelaremos las actividades del Caso de
Uso "Estableciendo Funciones".
Diagrama de Actividades de una operación: Desarrollaremos el método
"ObtenerEspectáculos()" de la clase "Espectáculos".
Para el Diagrama de Estados de la clase "Funciones", deberemos en primer lugar, incorporar un atributo
"Estado" a la clase. Los estados de las funciones no fueron especificados dentro de los requerimientos, lo
cual implicaría en la realidad la solicitud de dicha definición a nuestro cliente.
A los efectos de la resolución de la situación, asumiremos un escenario en donde los estados de una función
pueden ser tres: G (Generada), cuando la función es creada desde el caso de uso "Estableciendo
Funciones"; A ("Anulada"), que es cuando una función es cancelada por razones externas como un pedido
expreso de los Organizadores o problemas climáticos; y por último C ("Completa") cuando todas las
entradas para esa función fueron vendidas. Los tres pueden ser estados finales, ya que una función, pasada
la fecha de la misma, puede quedar en cualquiera de las tres situaciones. Una función "Anulada" no puede
ser habilitada nuevamente, debido al costo operativo que tendría para los Organizadores.
Diagrama de Estados: Clase "Funciones"
Está presentada también en la figura la clase "Funciones" con los nuevos atributos y métodos incorporados.
A continuación, presentaremos el Diagrama de Actividades para el flujo de trabajo del Caso
de Uso "Estableciendo Funciones".
Diagrama de Actividades 1: Caso de Uso "Establecer Funciones"

Algunas observaciones:
Hemos utilizado el recurso gráfico de modelar en un segundo diagrama el estado de
actividades "Establecer Parámetros de Generación ()", para ejemplificar el uso de esta
técnica.
Utilizamos el método "RegistrarFunciones()" para validar la generación, ya que el mismo
devuelve 0 (cero) cuando ésta es posible, o un código de error que se traduce en un
mensaje informando el motivo de la falla en la transacción.
No fue necesario el uso de calles en el diagrama, ya que esta transacción es realizada por un
sólo actor de una sola área de la organización.
Note el uso de flujo de objetos para especificar la instancia y el cambio de estado del objeto de
la clase "Funciones", en total coherencia con el Diagrama de Estados anterior.
Se incorporó el uso de notas en el diagrama. Estos elementos no tienen valor semántico en el
diagrama, pero si de comunicación, ya que son muy útiles para aclarar aspectos específicos en
los modelos. Las notas son símbolos gráficos de UML que permiten representar restricciones o
comentarios asociados a un elemento o a una colección de elementos.

Se incorporó el uso de contenedores en el diagrama. Un contenedor es un objeto que existe
para contener a otros objetos y que proporciona operaciones para acceder o iterar sobre los
otros elementos que contiene. En la figura está representado por el marco que contiene el
Diagrama de Actividades de "Establecer Parámetros de Generación ()". Tambien puede
usarse "anidado", es decir, directamente reemplazar dentro del primer diagrama al estado de
actividades "Establecer Parámetros de Generación ()".
Por último, nos queda pendiente modelar el Diagrama de Actividades para el método
"ObtenerEspectáculos()" de la clase "Espectáculos".
Realizaremos el diagrama de forma similiar al método "ObtenerTipoEspectáculos()" de la clase homónima,
pero con una variante: incorporaremos la posibilidad de que el método reciba un parámetro numérico. En
este parámetro se podrá especificar el valor 0 (cero), y en tal caso el método deberá retornar una lista de
todos los espectáculos; o el IDTipoEspectáculo, que condicionará al método para que solamente retorne los
espectáculos del tipo especificado.
Diagrama de Actividades: Método ObtenerEspectáculos().

En el diagrama presentamos los estados de acción escritos en PHP, y a continuación el código
generado mediante ingeniería directa a través de una herramienta CASE. También mostramos en el
diagrama la clase "Espectáculos", donde se puede apreciar la incorporación del parámetro de entrada
"te" en el método, que luego se utiliza dentro del código.
PHP: Código PHP generado a partir del Diagrama de Actividades mediante ingeniería directa
Lo elimine porque no servia para nada el código php
De la misma forma en que hemos estado trabajando hasta ahora, quedarán a su cargo el modelado de
los diagramas solicitados en el Ejercicio por resolver de esta situación profesional.
REFERENCIAS
18.1 : Diagrama de Casos de Uso: Módulos del Sistema de Venta Telefónica de Entradas
18.2 : Sistema Ventel: Diagrama de Clases completo
18.3 : Diagrama de Clases del Sistema

Tenga en cuenta que a raíz de la incorporación de la Máquina de Estados en la clase "Entradas", se incorporaron nuevos
métodos y un nuevo atributo "Estado".
18.4 : Ejemplo de Diagrama de Estados de la Clase "Entradas" (Figura 4-3-1)
18.5 : Diagrama de Actividades - Modelado del método "ObtenerTipoEspectáculos" de
la clase "TipoEspectáculos" (Figura 4-3-3
18.6 : Diagrama de Casos de Uso: Casos de uso del Módulo de Gestión de Datos

18.9 : Ficha de Caso de Uso: Caso de Uso "Estableciendo Funciones"
18.10 : Realización del caso de uso - análisis "Estableciendo Funciones" (Figura 3-3-2)
18.11 : Diagrama de colaboración de una realización del caso de uso "Estableciendo Funciones" (Figura 3-3-3)
18.12 : Diagrama de Secuencia de Caso de Uso "Estableciendo Funciones" (Figura 4-2-1)
18.13 : Prototipo de Interfaz: Caso de Uso "Generando Espectáculos"

18.14 : Diagrama de Relación de Caso de Uso: Caso de Uso "Generando Entradas"
18.15 : Ficha de Caso de Uso: Caso de Uso "Generando Entradas"

18.16 : Caso de Uso "Generando Entradas": Realización de Caso de Uso - Análisis
18.17 : Caso de Uso "Generando Entradas": Diagrama de Colaboración

18.18 : Diagrama de Casos de Uso: Módulo de Venta de Entradas
18.19 : Diagrama de Actividades - Flujo de trabajo de Caso de Uso "Reservando Entradas" (Figura 4-
3-2)
18.20 : Prototipo de Interfaz: Casos de Uso "Vendiendo Entradas" y "Registrando Entradas"
Actividad 1: Casos de Uso-Diseño
Basado en los diagramas de Colaboración que desarrolló en el Ejecicio por resolver de la Situación
profesional anterior (previamente corregidos por su profesor), construya en MS Visio los diagramas de
Secuencia para cada de uno de los tres casos de uso del Módulo de Venta de Entradas * 19.1 .
Actividad 2: Diagrama de Estados
Desarrolle el Diagrama de Estados para la clase "Locaciones". Los estados que puede asumir un objeto de
esta clase son: L (Libre), cuando una locación se registra por primera vez o cuando no tiene funciones
asignadas; O (Ocupada), cuando la locación tiene más de cinco funciones asignadas; y B (Baja), cuando la
locación ha sido eliminada del sistema, siendo este el único estado final.
Tenga en cuenta que deberá incorporar nuevos atributos y métodos en el Modelo de Clases del sistema.
Presente las clases modificadas junto al Diagrama de Estados.
Actividad 3: Diagramas de Actividades
Realice un Diagrama de Actividades del flujo de control del método de clase de su elección (tomado
obviamente del Diagrama de Clases del Sistema Ventel). Los estados de acción del mismo pueden estar
escritos en pseudocódigo o en el lenguaje de programación que prefiera, siempre y cuando éste sea
orientado a objetos. Presente el código correspondiente junto al diagrama.
El foco de control en un Diagrama de Secuencia...
○ Muestra el orden de las interacciones.

○ Representa la existencia de un objeto a lo largo de un período de tiempo.
○ Maneja los valores de retorno para poder validar el resultado de la transacción.

Elija el diagrama que utilizaría para modelar la dinámica de funcionamiento de un método de clase:
○ Diagrama de Estados.
○ Diagrama de Colaboración.
○ Diagrama de Secuencia.
Uno de éstos elementos NO corresponde a los Diagramas de Interacciones:
○ Enlace.
○ Marcador de destrucción.
○ Línea de vida.
○ Devolución o retorno.

Identifique la afirmación incorrecta sobre el Diagrama de Estados
○ Una transición entre estados representa un cambio de un estado origen a un estado sucesor
destino. X Un estado destino nunca puede ser el mismo que el estado origen.
○ Un estado es una situación de un objeto a lo largo de su ciclo de vida.
○ Las transiciones entre estados pueden darse de forma automática o no automática.
○ Todas las afirmaciones son correctas.
De acuerdo al diagrama de actividades, identifique la “División concurrente”
○ X
3
De acuerdo al diagrama de actividades, identifique la “Bifurcación”
○1
○2
○3
○4
○ 5
6
○7
○8
○9
De acuerdo al diagrama de actividades, identifique el “Estado de actividad o acción”
○ 1
2
○3
○4
○5
○6
○7
○8
○9
De acuerdo al diagrama de actividades, identifique el “Objeto”
○1
○2
○3
○4
○5
○6
○7
○ 8
9
De acuerdo al diagrama de actividades, identifique el “Estado final”
○1
○2
○3
○4
○5
○ 6
X
7
○8
○9
De acuerdo al diagrama de actividades, identifique la “Calle”

De acuerdo al diagrama de actividades, identifique el “Flujo de objetos”
○1
○2
○3
○ 4
5
○6
○7
○8
○9
De acuerdo al diagrama de actividades, identifique el “Estado inicial”
○1
○2
○3
○4
○5
○6
○ 7
8
○9
De acuerdo al diagrama de actividades, identifique la “Unión concurrente
○1
○2
○ 3
X4
○5
Situación profesional 5: Implementación
Se le ha encomendado a usted que realice el análisis de la arquitectura del sistema que dará soporte a
las necesidades operativas de la Cooperativa.
El área operativa de la Cooperativa requiere el desarrollo de un sistema de seguridad que monitoree todas
las operaciones de sus unidades (colectivo).
La empresa trabaja con varias subsidiarias, con lo cual cada empresa subsidiaria tiene su propio servidor
concentrador de información, que una vez al día le informa al servidor central de la cooperativa todas las
transacciones realizadas para que se proceda a la liquidación posterior. Por otro lado la empresa trabaja
con POS (puntos de venta) que son los que permiten recargar las tarjetas para el uso del transporte, esto
también es realizado a través de una terminal con un dispositivo lector de tarjetas y un software de control.
Nuestra tarea será la de definir la arquitectura para el nuevo sistema de seguridad propuesto, teniendo en
cuenta todos los equipos ya instalados que pertenecen a otras empresas. Por otro lado deberemos tener en
cuenta que la comunicación entre los lectores instalados en las unidades de transporte solo se conecta una
vez al día al servidor de la empresa y a través de un enlace de microondas descarga la información a los
concentradores para que éstos puedan informarla a la cooperativa.
SP5 / H1: El Modelo de Implementación
El papel de la Implementación en el ciclo de vida del software
La implementación tiene su principal desarrollo en la fase de construcción, aunque también se define los
ejecutables de la arquitectura en la fase de elaboración. En la fase de transición se trabaja sobre los
defectos detectados, creándose de este modo versiones beta * 20.1 del sistema.
En la Figura 5-1-1 se presenta el gráfico que muestra el desarrollo del flujo de trabajo de implementación
en las diversas fases.
El flujo de trabajo de Implementación dentro del Proceso Unificado de Desarrollo (Figura 5-1-1)
Para modelar el flujo de trabajo de implementación utilizamos el modelo de implementación. El modelo de

implementación describe cómo se implementan los elementos del modelo de diseño, por ejemplo, las clases
de diseño en términos de componentes como archivo de código fuentes y ejecutables.
En esta Situación profesional abordaremos lo que hemos denominado la segunda parte del diseño, que se la
suele conocer como diseño avanzado, ya que preparamos nuestro diseño para la posterior implementación. En
la situación profesional anterior habíamos desarrollado la primera parte del diseño, la parte que tenemos que
modelar nuestro sistema.
En esta situación profesional nos centraremos en el "cómo", es decir la manera de implementar

nuestras aplicaciones en un entorno de arquitectura ya conocido o previamente definido.
En esta etapa del diseño tenemos que utilizar conceptos ya utilizados en otras materias de la carrera, es
decir conceptos de nodos, capas, componentes físicos de hardware tales como redes, sistemas de
comunicaciones, y sistemas operativos; es decir que en este momento a través de técnicas de modelado
vamos a preparar los componentes físicos del sistema para implementarlo en la próxima etapa que será
tratado en la siguiente situación profesional.
Subsistemas de implementación
Los subsistemas de implementación proporcionan una forma de organizar los elementos del modelo
de implementación en trozos más manejables.
Un subsistema puede estar formado por componentes, interfaces y otros subsistemas (recursivamente).
Además, un subsistema puede implementar las interfaces que representan la funcionalidad que exportan
en forma de operaciones.
Es importante entender que un subsistema de implementación se manifiesta a través de un "mecanismo
de empaquetamiento" concreto en un entorno de implementación determinado tales como:
Un paquete en Java.
Un proyecto en Visual Basic.
Un directorio de ficheros en un proyecto de C++.
Un paquete o subsistema en cualquier herramienta de modelado visual.
Los subsistemas de implementación están muy relacionados con los subsistemas de diseño en el modelo
de diseño. De hecho, los subsistemas de implementación deberían tener trazabilidad directa de sus
subsistemas de diseño. Un subsistema de implementación debería definir qué componentes o,
recursivamente, qué otros subsistemas de implementación dentro del mismo, deberían proporcionar las
interfaces del sistema. Las interfaces del sistema son las mismas establecidas en el modelo de diseño.
Además, estos componentes (que representan piezas de software, como veremos en la siguiente herramienta),
deberían tener también una trazabilidad directa de las clases de diseño, correspondientes al subsistema de
diseño que implementan. La Figura 5-1-2 aclara la relación entre los subsistemas de diseño e implementación.
Implementación de subsistemas de diseño (Figura 5-1-2
Los subsistemas de implementación, encapsularán también componentes ejecutables que proporcionan

los servicios del sistema, ya que los subsistemas de negocio y servicio del modelo de diseño podrán ser
implementados.
REFERENCIAS 20
20.1 : Versión Beta
Una versión beta o lanzamiento beta representa generalmente la primera versión completa del programa informático o
de otro producto. Es posible que sea inestable, pero útil para que las demostraciones internas y las inspecciones previas
seleccionen a clientes potenciales, y éstos realicen un testing masivo y de bajo costo económico.
La implementación tiene su principal desarrollo en la fase de construcción, aunque también se define
los ejecutables de la arquitectura en la fase de elaboración.
X Verdadero
○ Falso
Los lanzamientos beta del sistema se crean en la fase de elaboración de la implementación.
○ Verdadero
X Falso
El modelo de implementación describe cómo se implementan los elementos del modelo de diseño
en términos de componentes como archivo de código fuentes y ejecutables.
X Verdadero
○ Falso
En la transición de un subsistema de diseño a un subsistema de implementación, las interfaces
se redefinen.
○ Verdadero
X Falso
Un proyecto de Visual Basic.Net puede considerarse como la implementación empaquetada de
un subsistema de diseño.
X Verdadero
○ Falso
Los subsistemas de implementación pueden implementar subsistemas de servicio
correspondientes al modelo de diseño.
X Verdadero
○ Falso
SP5 / H2: El Diagrama de Componentes
Componentes
Como ya mencionamos anteriormente, en la implementación se pone en marcha el sistema definido
términos de componentes. Un componente es una parte o componente físico reemplazable de un sistema
que empaqueta su implementación y está desarrollado conforme a un conjunto de interfaces, que serán las
que permitan que la realización de uno o varios casos de uso sea posible.
Algunos componentes tienen identidad y pueden poseer entidades físicas, que incluyen objetos en tiempo
de ejecución, documentos, bases de datos, etcétera. Los componentes existentes en el dominio de la
implementación son unidades físicas en la computadora que se pueden conectar con otros componentes,
también se pueden sustituir, trasladar, archivar, etcétera.
Los componentes tienen dos características: empaquetan el código que implementa la funcionalidad de
un sistema, y algunas de sus propias instancias de objetos que constituyen el estado del sistema, los
llamados "últimos componentes de la identidad", porque sus instancias poseen identidad y estado.
Código: Un componente contiene el código para las clases de implementación y otros elementos.
Un componente de código fuente es un paquete para el código fuente de las clases de
implementación. Algunos lenguajes de programación distinguen archivos de declaración de los
archivos de método, pero todos son componentes. Un componente de código binario es un
paquete para el código compilado. Una biblioteca del código binario es un componente. Cada tipo
de componente contiene el código para las clases de implementación que realizan algunas clases
e interfaces lógicas. La relación de realización asocia un componente con las clases y las
interfaces lógicas que implementan sus clases de implementación. Las interfaces de un
componente describen la funcionalidad que aporta. Cada operación de la interfaz debe hacer
referencia eventualmente a un elemento de la implementación disponible en el componente. La
estructura estática, ejecutable de una implementación de un sistema se puede representar como
un conjunto interconectado de componentes. Las dependencias entre componentes significan
que los elementos de la implementación en un componente requieren los servicios de los
elementos de implementación en otros componentes. Tal uso requiere que dichos elementos
sean de visibilidad pública.
Identidad: Un componente de identidad tiene identidad y estado. Posee los objetos físicos que
están situados en él. Puede tener atributos, relaciones de composición con los objetos
poseídos, y asociaciones con otros componentes. Desde este punto de vista es una clase. Sin
embargo la totalidad de su estado debe hacer referencia a las instancias que contiene.
Estructura: Un componente ofrece un conjunto de elementos de implementación, esto significa
que el componente proporciona el código para los elementos. Un componente puede tener
operaciones e interfaces. Un componente de identidad es un contenedor físico para las entidades
físicas como bases de datos. Para proporcionar manejadores para sus elementos contenidos,
puede tener atributos y asociaciones salientes, que deben ser implementadas por sus elementos
de implementación. Este componente se representa con un rectángulo con dos rectángulos más
pequeños que sobresalen en su lado izquierdo.
Las operaciones e interfaces disponibles para los objetos exteriores se pueden representar directamente en
el símbolo de clase. Estos son su comportamiento como clase. Los contenidos del subsistema se
representan en un diagrama separado.
Las dependencias de un componente con otros componentes o elementos del modelo se representan
usando líneas discontinuas con la punta de flecha hacia los elementos del proveedor. Si un componente es
la realización de una interfaz, se representa con un círculo unido al símbolo del componente por un
segmento de línea.
Gráficamente, los componentes se representan de la siguientes forma:
Notación de un Componente (Figura 5-2-1)
Esta notación gráfica permite visualizar un componente de forma independiente de cualquier

sistema operativo o lenguaje de programación.
Cada componente debe tener un nombre que lo distinga del resto de los componentes. Un nombre es una
cadena de texto. Normalmente, un componente se dibuja mostrando sólo su nombre pero puede contener,
si uno lo desea, valores etiquetados o compartimentos adicionales.
Como ya hemos indicado en otras situaciones profesionales, todo objeto de modelado UML puede
ser modificado mediante estereotipos, es decir nuevos sub-tipos que nos sirven de patrón para
modelar componentes no standard UML, los que define UML son:
Ejecutables: <<executable>>
Librerías: <<library>>
Tablas: <<table>>
Archivos: <<file>>
Documentos: <<document>>
Componentes e Interfaces
Una interfaz es una colección de operaciones que se utiliza para especificar un servicio de una clase o un
componente. La relación entre componente e interfaz es importante. Todas las aplicaciones más conocidas
de los sistemas operativos que están basadas en componentes (tales como COM+ y los Enterprise Java
Beans) utilizan las interfaces como vinculo que enlaza a los componentes entre sí.
Una interfaz que es realizada por un componente se denomina interfaz de exportación, lo que significa que
es una interfaz que el componente ofrece como servicio a otros componentes. La interfaz utilizada por un
componente se denomina interfaz de importación, lo que significa que es una interfaz con la que el
componente conforma y sobre la que se puede basar para construir. Un componente puede conformar con
muchas interfaces de importación. Además, un componente puede tanto importar como exportar
interfaces.
Una interfaz dada puede ser exportada por un componente e importada por otro. La existencia de esta interfaz
entre los dos componentes rompe la dependencia directa entre ellos. Un componente que utiliza una interfaz
determinada funcionará adecuadamente, independientemente del componente que realice la interfaz.
En la figura 5-2-2 tenemos un componente del software que forma parte del sistema operativo Windows. En
el diagrama de componentes de Windows debe salir este componente, ya que sin el sistema no funcionaría.
Debajo, tenemos el mismo componente, pero indicamos que dispone de un interfaz. Al ser una Librería de
tipo DLL * 21.1 la interfaz nos da acceso a su contenido. Esto nos hace pensar que la representación anterior
es incorrecta, pero no es así, sólo corresponde a un nivel diferente de detalle.
Componentes e Interfaces (Figura 5-2-2)
Diagrama de componentes
El Diagrama de Componentes de UML, se utiliza para modelar una vista estática de un sistema. Muestra la
organización y las dependencias entre un conjunto de componentes de software. No es necesario que un
diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama
describe una parte del sistema. En él situaremos librerías, tablas, archivos, ejecutables y documentos que
formen parte del sistema. Uno de los usos principales es que puede servir para ver que componentes
pueden compartirse entre sistemas o entre diferentes partes de un sistema.
Tipos de componentes
Se pueden distinguir básicamente dos tipos de componentes:
El primer tipo son los componentes de despliegue. Estos son los componentes necesarios y suficientes para
formar un sistema ejecutable, tales como las bibliotecas dinámicas * 21.1 y los ejecutables. Nos facilitan la
distribución del sistema a los clientes. Documenta sus necesidades y dependencias. Si disponemos de un
ejecutable que solo se necesita a el mismo para funcionar no necesitaremos el diagrama de componentes.
En la Figura 5-2-3 se muestra un ejecutable que utiliza dos librerías, estas dos librerías disponen de su
interfaz con el que ofrecen el acceso a sus servicios. Se puede ver que estas librerías son componentes que
pueden ser reutilizados en otras partes del sistema.
Diagrama de Componentes. Componentes de despliegue (Figura 5-2-3)
El segundo tipo son los componentes producto del trabajo. Estos componentes son básicamente
productos que quedan al final del proceso de desarrollo, y consisten en cosas tales como archivos de
código fuente y archivos de datos a partir de los cuales se crean los componentes de despliegue. Estos
componentes no participan directamente en un sistema ejecutable, pero son los productos del trabajo de
desarrollo que se utilizan para crear el sistema ejecutable.
Se utilizan para documentar las dependencias de los diferentes archivos de código fuente. Un ejecutable
o librería es una combinación de estos archivos, y al mostrar la dependencia entre ellos obtenemos una
visión de las partes necesarias para la creación del ejecutable o librería. Al tener documentadas las
relaciones se pueden realizar cambios en el código de un archivo teniendo en cuenta donde se utiliza, y
que otros archivos pueden verse afectados por su modificación.
Diagrama de Componentes. Componentes producto del trabajo (Figura 5-2-4)
Aquí tenemos la relación entre los diferentes archivos de un sistema, en este caso similar a Windows NT.
Cada archivo ".cpp" utiliza su archivo ".h" correspondiente, y "MiServicio.h" utiliza "NTService.h" o
"STdio.h".
Podríamos mencionar un tercer tipo, menos utilizado en el común de los desarrollos de software, ya que
estos están muy ligados a los sistemas operativos y las herramientas de programación: son los
componentes de ejecución. Estos componentes se crean como consecuencia de un sistema en
ejecución, como por ejemplo un objeto COM+, el cual se instancia a partir de una DLL. Como ejemplo de
ello podríamos mencionar a un objeto creado en un servidor COM+ de Windows 2000 Server.
Organización de componentes
Los componentes se pueden organizar agrupándolos en paquetes de la misma forma en que se organizan
las clases. En la etapa de Implementación esos paquetes se denominan subsistemas de implementación.
Los componentes también se pueden organizar especificando entre ellos relaciones de
dependencia, generalización, asociación (incluyendo agregación) y realización.
Como síntesis de lo aprendido en las anteriores situaciones profesionales, podemos decir que: creamos
diagramas de casos de usos para razonar sobre el comportamiento deseado de un sistema. El
vocabulario del sistema se especifica mediante diagrama de clases. Se crean diagramas de secuencia,
diagrama de colaboración, diagrama de estados y actividades para especificar la forma en que los
elementos del vocabulario colaboran entre sí para llevar a cabo su comportamiento. Finalmente, estos
planos lógicos serán convertidos en cosas pertenecientes al mundo de físico, como por ejemplo,
ejecutables, bibliotecas, tablas, archivos y documentos, es decir a través de los componentes.
REFERENCIAS 21
DLL
Una biblioteca de enlace dinámico o más comúnmente DLL (sigla en inglés de Dynamic Link Library) es el término con el
que se refiere a los archivos con código ejecutable que se cargan bajo demanda de un programa por parte del sistema
operativo. Esta denominación es exclusiva a los sistemas operativos Windows siendo ".dll" la extensión con la que se
identifican estos ficheros, aunque el concepto existe en prácticamente todos los sistemas operativos modernos.
Un Componente en UML representa a:
○ Un equipo que tiene procesamiento.

○ Un elemento de comunicación.
○ Una conexión.

Una de estas afirmaciones es incorrecta. Seleccione cuál:
○ Un componente es una clase.
○ Los sub-tipos de componentes se especifican en su estereotipo.
○ Los componentes pueden tener interfaz.
○ Un componente tiene identidad y estado.

Se dice que un componente tiene Estructura porque cuenta con atributos y
operaciones. ----------------------------------X Verdadero

Los programas fuente de un sistema se denominan componentes producto del trabajo.
X -----------------------------------------------------------Verdadero
SP5 / H3: El Diagrama de Despliegue
Para poder visualizar la parte estructural de un conjunto de nodos y sus relaciones se utilizan los diagrama
de despliegue. En el diagrama de despliegue se indica la situación física de los componentes lógicos
desarrollados. Es decir se sitúa el software en el hardware que lo contiene. Cada componente de hardware
se representa como un nodo dentro del sistema.
Un nodo se representa como un cubo, un nodo es un elemento donde se ejecutan los
componentes, representan el despliegue físico de estos componentes.
En el ejemplo de la Figura 5-3-1 tenemos dos nodos, el cliente y el servidor, cada uno de ellos contiene
componentes. El componente del cliente utiliza una interfase de uno de los componentes del servidor.
Diagrama de Despliegue (Figura 5-3-1)
Se muestra la relación existente entre los dos nodos. A esta relación podríamos asociarle un estereotipo
para indicar que tipo de conexión disponemos entre el cliente y el servidor, así como modificar su
cardinalidad, para indicar que soportamos diversos clientes.
Como los componentes pueden residir en más de un nodo podemos situar el componente de forma
independiente, sin que pertenezca a ningún nodo, y relacionarlo con los nodos en los que se sitúa.
Resulta obvio que para plantear un correcto diagrama de despliegue, es necesario contar con el
diagrama de componentes del sistema que muestra todos los elementos y sus dependencias.
Entonces, los nodos, al igual que los componentes, pertenecen al mundo material y son un bloque de
construcción importante en el modelado de los aspectos físicos de un sistema. Es por ello que decimos
que están íntimamente relacionados y que casi no pueden funcionar de manera independiente, es decir
que en un nodo, se pondrán los componentes de software desarrollados en las etapas anteriores del
proceso de desarrollo del sistema.
La notación de UML, es decir un cubo, nos permite visualizar un nodo independientemente de cualquier hardware
específico. Como podemos observar, gráficamente cada nodo debe tener un nombre que lo distinga del resto de
nodos. Un nombre es una cadena de texto simple y representativa del componente de hardware.
Un conjunto de objetos o componentes asignados a un nodo como un grupo se denomina una
unidad de distribución, como muestra en la siguiente gráfica.
Diagrama de Despliegue. Unidad de Distribución (Figura 5-3-2)
Los nodos se pueden organizar agrupándolos en paquetes, de la misma forma que se pueden organizar las
clases y los componentes. Los nodos también se pueden organizar especificando relaciones de
dependencia, generalización y asociación (incluyendo agregación) entre ellos. El tipo más común de relación
entre nodos es la asociación. Una asociación representa una conexión física entre nodos, como puede ser
una conexión Ethemet, una línea en serie o un bus compartido, como se muestra en la Figura 5-3-3.
Diagrama de Despliegue. Relaciones entre Nodos -conexiones- (Figura 5-3-3)

Un nodo correctamente estructurado:
Proporciona una abstracción bien definida de alguna cosa extraída del vocabulario del
hardware en el dominio de la solución.
Se descompone solo hasta el nivel necesario para comunicar la intención al lector.
Sólo muestra aquellos atributos y operaciones relevantes para el dominio que se
está modelando.
Despliega directamente un conjunto de componentes que residen en el nodo.
Está conectado con otros nodos de forma que refleje la topología de un sistema del mundo real.
Identifique el elemento que no corresponde al Diagrama de Despliegue:
○ Nodo.
○ Asociación Binaria.
○ Dependencia.
○ Componente.
X Servidor.

Un Nodo en UML es:
X Un equipo que tiene procesamiento.

○ Un elemento de comunicación.
○ Una unidad física de
software. ○ Una conexión.
3.
Indique la opción correcta
El Diagrama de Despliegue tiene como objetivo mostrar la distribución de los componentes de
software en la arquitectura de hardware diseñada.
X Verdadero
○ Falso
Los nodos son clases que se pueden asociar mediante relaciones de dependencia,
generalización, asociación y agregación.
X Verdadero
○ Falso
Para realizar el correspondiente diagrama de componentes debemos tener en cuenta que no
solamente podemos trabajar con los estereotipos del UML, sino que podemos agregarle además
nuestros propios componentes y a la vez ilustrar con gráficos que hagan más entendible el modelo.
En nuestra situación profesional necesitábamos varios nodos, componentes de hardware y nuestros
componentes que tendrán que estar distribuidos de la mejor manera para obtener el mejor rendimiento,
con las restricciones que pone el entorno; "Es por ello que decimos que el desarrollo basado en UML es
Centrado en la arquitectura, porque en todo momento tenemos presente este tema para el desarrollo de
las aplicaciones":
En la gráfica se muestra una combinación de los componentes y los nodos, como así también la topología
de red necesaria para la ocasión. Veamos en detalle como se ha distribuido:
En primer lugar, el servidor de seguridad estará situado en el medio de la comunicación, ya que es
el encargado de autorizar las operaciones y los usuarios, este tendrá una consola de administración y
un conjunto de librerías que realizarán las tareas de autorización (Similar a una tarjeta de crédito).
En segundo lugar, tendremos las aplicaciones POS de carga de saldo para viajar; estos son PCs
con dispositivos lectores que de la misma manera se comunican con el servidor de seguridad
para autorizar sus tareas a través de una red en línea TCP / IP.
Por último tenemos la red fuera de línea de colectivos que son los que descargarán los saldos e
informarán al servidor de liquidación para que este proceda al procesamiento de las
transacciones para su pago a las empresas transportistas.
Como vemos aquí, es de fundamental importancia en este tipo de aplicaciones, tener bien definida la
arquitectura, ya que de otra manera podríamos cometer errores en el diseño de nuestro sistema.
Por otro lado, es importante destacar que en este ejercicio se ha simplificado el despliegue de la aplicación
real, ya que llevaría una gran cantidad de componentes y de otros artefactos que no hacen al objetivo
fundamental que es el de entender la herramienta.

La organización ANSIKA S.A. de la ciudad de Río Tercero dedicada a la producción de lavandinas lo
ha contratado a usted como profesional de sistemas para que forme parte del grupo de desarrollo que
tiene internamente esta organización.
Usted en este grupo formará parte del equipo de implementación de sistemas, y tendrá como tarea relevar
en la organización todo el equipamiento de hardware, comunicaciones y software.
Luego de un relevamiento detallado se determinó que se cuenta con el siguiente equipamiento:
1 Servidor pentium III – 256 Mb. RAM – Disco de 20 Gb.

6 Estaciones de trabajo Pentium II – 64 Mb. RAM Dicso de 6 Gb.
1 Servidor de Comunicaciones AMD K62 400 64 Mb. RAM.
Red TCP/IP.
1 HUB 16 bocas.
2 Terminales VERIFONE de Tarjetas de Crédito.
El sistema a implementar cuenta con varios módulos y está desarrollado en tres capas con Visual Basic 6 y
SQL Server 2000. Los módulos son los siguientes:
Ventas
Compras
Stock
Contabilidad
Finanzas
Recursos Humanos
Además deberá tener en cuenta que sólo hay un contador que utiliza solo los módulos de finanzas y
contabilidad, 3 administrativos que utilizan compras, ventas, Stock. El gerente general que solo utiliza
el módulo de finanzas, y un encargado de recursos humanos que solo utiliza este módulo.
Deberá usted entonces desarrollar los diagramas de distribución o despliegue correspondientes
para implementar este sistema.
Los Diagramas de Despliegue son:
X Diagramas de Clases que modelan aspectos físicos del sistema.

○ Diagramas de Componentes que modelan aspectos físicos del sistema.
○ Modelos de Nodos que representan aspectos lógicos de implementación.
○ Gráficos de Objetos que representan instancias de hardware.
Identifique la afirmación incorrecta sobre los nodos:
○ Se descompone solamente hasta el nivel necesario para comunicar la intención al lector.

○ Solamente muestra aquellos atributos y operaciones relevantes para el dominio que se está
modelando.
○ Despliega directamente un conjunto de componentes que residen en el nodo.
○ Está conectado con otros nodos de forma que refleje la topología de un sistema del mundo real.
X Todas son correctas.
Los Componentes pueden ser de tres tipos: componentes de despliegue, componentes producto del
trabajo y componentes de ejecución.
X Verdadero
○ Falso
Los Componentes también se pueden organizar especificando entre ellos solamente relaciones de
dependencia y generalización.
○ Verdadero
X Falso
Un componente puede asumir los siguientes estereotipos: Ejecutables, Librerías, Tablas, Archivos,
Documentos y Servicios.
○ Verdadero
X Falso
Una interfaz es una colección de operaciones que se utiliza para especificar un servicio de una clase o un
componente, que se utiliza principalmente dentro del Diagrama de Despliegue.
○ Verdadero
X Falso
El Modelo de Implementación requiere de los diagramas de Componentes y Despliegue para presentar
cómo los componentes de software se distribuyen sobre la arquitectura de hardware diseñada.
X Verdadero ○
Falso
Situación profesional 6: Prueba
La empresa BYTEBAR, dedicada a la venta de impresoras de código de barras y servicios de impresión de
obleas ha decidido informatizar la atención de clientes a través de un sistema que permita ingresar los
pedidos de cada cliente.
Cada cliente se encuentra registrado en la empresa y en la base de datos se tienen registros que contienen
información sobre los formatos de las obleas que ellos solicitan (estos datos son fundamentalmente: tamaño
de la oblea, cantidad de campos que imprime la oblea, tipos de campos, imágenes a imprimir, etcétera).
Al solicitar un servicio de impresión el cliente deberá proporcionar los siguientes datos: tipo de oblea a
utilizar, datos a imprimir, tipo de código de barra, imagen a imprimir, datos del artículo y cantidad de obleas
a imprimir. Esta instancia de atención deberá generar una orden de trabajo, la que será identificada con un
número y su estado podrá ser consultado a través de este número.
Usted está a cargo de la conducción de la prueba de este módulo de software y deberá reportar los errores
en caso de encontrarlos.
SP6 / H1: El Modelo de Prueba
El papel de las Pruebas a lo largo del ciclo de vida del software
Antes de comenzar nos ubicaremos con el Modelo de Prueba * 22.1 dentro del ciclo de desarrollo de
software (ver Figura 6-1-1). Como vemos esta etapa es la última, pero abarca las fases de elaboración,
construcción y transición.
Este diagrama nos muestra que la realización de las pruebas se centra en las fases de elaboración y
construcción, cuando gran parte del sistema está implementado. En cambio, durante la fase de
transición, la atención se centra en la corrección de defectos durante los primeros usos.
Las Pruebas dentro del Proceso Unificado de Desarrollo (Figura 6-1-1)
Las pruebas se desarrollan de manera diferente y tienen diferentes tópicos de análisis a lo largo de las
diferentes fases. En la fase de inicio puede realizarse parte de la planificación inicial de las pruebas
que se realizarán una vez que se haya definido el ámbito del sistema.
Debe tenerse en cuenta que las pruebas definitivas se llevarán a cabo cuando una construcción (pieza de
software) ha pasado por las pruebas iniciales de aceptación en cuanto a diseño y contenidos y es sometida a
pruebas de integración (comportamiento de esta pieza en conjunto con otras desarrolladas).

Esta exposición nos lleva a confirmar que el verdadero momento de ejecución de las pruebas se centra en las
fases de elaboración, cuando se prueba la ejecución de la pieza sobre la base de la arquitectura, y en la fase de
construcción cuando casi la totalidad del sistema es implementado. Durante la fase de transición el centro de
evaluación se concentra en la corrección de defectos surgidos durante las primeras instancia de uso.
Es posible que el modelo de prueba que se diseñe pueda ser reutilizado en otros casos de uso y/o en las
sucesivas iteraciones. En algunos casos el modelo de prueba se podrá mantener estable, pero lo más común es
que el modelo de prueba deba ser redefinido. Estos cambios responderán a las siguientes situaciones:
La eliminación de casos de uso que se desechan por obsoletos.
El refinamiento de algunos casos de uso luego de las pruebas.
La creación de nuevos casos de uso para las nuevas construcciones.
Durante la etapa de prueba se debe verificar el resultado de la implementación, mediante la prueba de
cada construcción del sistema. Los objetivos de la prueba son los siguientes:
Planificar las pruebas incluyendo las pruebas de integración y del sistema.
Diseñar e implementar las pruebas creando para ello los casos de prueba que detallan qué
probar, creando los procedimientos de prueba que especifican cómo realizar las pruebas y
creando los componentes de prueba.
Realizar las pruebas y manejar los resultados de cada una de ellas. En aquellas donde se
detecten errores, éstos se corregirán y volverán al flujo de prueba.
El Modelo de Pruebas
El modelo de prueba describe cómo se prueban los componentes ejecutables, en el modelo de
implementación con pruebas de integración y de sistema. También puede describir cómo han de ser
probados los aspectos específicos del sistema, aquí se podrán tener en cuenta diversas situaciones como
por ejemplo: si el manual de usuario que se diseñó cumple con lo que el sistema hace, también si la interfaz
es utilizable y consistente a la situación que pretende dar solución.
El modelo de prueba consta de lo siguiente: /son 5/ Interactiva "Modelo de Pruebas"
Procedimiento de prueba: un procedimiento de prueba debe especificar cómo realizar uno o varios casos de prueba o parte de ellos.
Un procedimiento de prueba puede ser utilizado para otros casos de uso similares, utilizando diferentes valores de entrada y
resultado. El procedimiento de prueba es similar a la descripción del flujo de eventos de un caso de uso, aunque éste incluye
información adicional como los valores de entrada a utilizar, la forma en que éstos deben ser introducidos en la interfaz y qué se
debe verificar.
Componente de prueba: un componente de prueba automatiza uno o varios procedimientos de prueba o partes de ellos. Estos
componentes de prueba se utilizan para probar los componentes en el modelo de implementación, proporcionando entradas,
controlando la ejecución de los componentes e informando los resultados de la misma.
Plan de Prueba: éste describe las estrategias, recursos y planificación de la prueba. Aquí se incluye la definición del tipo de
pruebas a realizar, sus objetivos y el nivel de cobertura de la misma.
Defecto: un defecto es una anomalía del sistema. Este permitirá localizar cualquier cosa que se debe controlar y resolver.
Evaluación de la prueba: esta es una evaluación de los resultados donde se detalla la cobertura de los casos de prueba, la
cobertura de código y el estado de los defectos encontrados.
Objetivos de las Pruebas
En el contexto actual de la producción de software, cada vez son más las organizaciones que incluyen en
sus procesos de forma seria el testing, para estar a la altura de las exigencias de calidad del mercado y
para poder certificar estándares de calidad cada vez más altos en sus productos. En la mayoría de los
casos se implementan como un área dentro de los departamentos de sistemas, compuesta por un equipo
de personal especializado y dedicado a la detección de fallas en cualquiera de las fases de desarrollo. El
rol de Tester o Analista de Pruebas, tiene cada vez mayor demanda.
El objetivo de las pruebas es ni más ni menos presentar información sobre la calidad del producto a las
personas responsables de éste.
Para cumplirlo, el Tester debe requerir información de lo más variada. Esto hace que el proceso de "testing"
sea completamente dependiente del contexto en el que se desarrolla, siendo muy complejo implentar
"mejores prácticas, ya que una práctica puede ser ideal para una situación pero completamente inútil o
incluso perjudicial en otra. Es por esto que las actividades, técnicas, documentación, enfoques y demás
elementos que condicionaran las pruebas a realizar, deben ser seleccionadas y utilizadas de la manera más
eficiente según contexto del proyecto.
Tanto es así, que una prueba se considera exitosa cuando detecta un fallo, y no cuando todo
funciona aparentemente bien (mal que les pese a las áreas de desarrollo).
Casos de Prueba
Un caso de prueba es el que especifica la forma de probar el sistema; en él se incluyen la entrada o
resultado con el que debe probarse y especifica las condiciones bajo las cuáles debe probarse.
Es corriente que en la práctica lo que se tenga que probar esté directamente representado por un requerimiento
del sistema cuya implementación por sí misma justifica una prueba. Estas pruebas pueden estar orientadas a
verificar los resultados de la interacción entre los usuarios y el sistema, otra orientación puede ser a que estén
satisfechas las precondiciones y poscondiciones luego de la operación y que la secuencia de operaciones sea la
especificada. Otro enfoque a las pruebas puede ser presentado a través de la evaluación del comportamiento de
interacción con otros casos de uso que implementan a este o viceversa.
Existen otros puntos sobre los que se puede centra la evaluación de la prueba en los que se efectuará
una evaluación del mismo como un todo, estos son los casos de:
Interactiva "Casos de prueba"---------SON 4
Pruebas de Instalación: en estas pruebas se constata que el sistema se instala satisfactoriamente en la plataforma del cliente y
que el sistema funcionará correctamente una vez instalado.
Pruebas de Configuración: en estas se verifica que el sistema funciona correctamente bajo diferentes configuraciones, por
ejemplo diferentes configuraciones de red.
Pruebas Negativas: estas pruebas intentan provocar fallos en el sistema a los efectos de poder determinar puntos débiles.
Algunos ejemplos de estas pruebas son: una configuración de red incorrecta, insuficientes recursos de hardware, sobrecarga
de trabajo, etcétera.
Pruebas de Tensión: estas pruebas identifican problemas vinculados al sistema cuando éste opera en entornos escasos de
recursos o cuando otros sistemas compiten por el mismo recurso.
Procedimiento de Prueba
Planificar la Prueba
Vimos anteriormente la descripción estática de las pruebas, pero debe analizarse también su comportamiento
dinámico. El punto de partida para ello es la planificación de la prueba en cuanto a los esfuerzos; para ello se
describe una estrategia, se estiman los requisitos (recursos humanos y recursos de sistemas necesarios).
La planificación de la prueba apunta a planificar los esfuerzos de una prueba en una iteración
realizando lo siguiente:
Describiendo la estrategia de prueba.
Estimando los requisitos para el esfuerzo de la prueba.
Planificando el esfuerzo de la prueba.
Utilizando el modelo de casos de uso y los requisitos adicionales se decidirá el tipo de prueba; también
puede hacerse uso del modelo de diseño para afinar algunos detalles. Los encargados del diseño de la
prueba, deciden qué tipo de prueba ejecutar, cómo se ejecutarán, cuándo deben ser ejecutadas y cómo se
determinará el éxito de las mismas.
El propósito del diseño de la prueba tiene como principales puntos los de identificar y describir los casos
de prueba para cada construcción e identificar y estructurar los procedimientos de prueba especificando
cómo realizar los casos de prueba.
El diseño de la prueba dependerá del tipo de prueba a realizar, teniéndose los siguientes casos de diseño:
Prueba de Integración: se utiliza para verificar la interacción correcta entre los componentes después de
haber sido integrados en la pieza de software. La mayoría de estas pruebas pueden ser derivadas a las
realizaciones de casos de uso – diseño ya que las realizaciones de casos de uso describen como
interaccionan las clases y los objetos. Los constructores de las pruebas deben crear un conjunto de casos
de prueba que permitan alcanzar los objetivos que se plantea el plan de prueba con el mínimo esfuerzo.
Esto se logra utilizando casos de prueba que contengan un solapamiento mínimo. Cuando la prueba es
preparada, éstas se crean considerando como entrada los diagramas de interacción de las realizaciones de
casos de uso. También se buscan posibles combinaciones de entrada, salida y estado inicial del sistema
que proporcionen escenarios interesantes que utilicen la casi totalidad de las clases.
Prueba de Sistema: se utiliza para probar el comportamiento del sistema como un todo. Se realizan
combinaciones de casos de uso instanciados bajo diferentes condiciones. Estas diferentes condiciones
pueden ser diferentes configuraciones de hardware, diferentes niveles de carga del sistema, diferentes
números de actores, etc. En esta prueba los encargados de diseñarla debería dar prioridad a aquellas
combinaciones de casos de uso que:
Se necesita que funcionen en paralelo.
Posiblemente funcionen en paralelo.
Posiblemente se influencian mutuamente si se ejecutan en paralelo.
Involucran varios procesadores.
Utilizan frecuentemente recursos del sistema en forma compleja e impredecible.
Prueba de Regresión: se base en la repetición de las pruebas de una construcción (o parte de ella) que ya
había sido probada con anterioridad. Se realizan fundamentalmente para comprobar que una "funcionalidad
antigua" aún sigue comportándose de manera correcta cuando se añade "funcionalidad nueva". Alguno de
los diseños anteriores pueden ser utilizados para pruebas de regresión en construcciones subsiguientes.
Para ser adecuados los casos de prueba que se diseñan deben ser lo suficientemente flexibles para
resistentes a los cambios en el software que se está probando.
Implementación
El propósito de la implementación de las pruebas es el de automatizar los procedimientos de prueba
creando componentes de prueba si fuese posible, dado que a veces no todos los procedimientos de prueba
pueden ser automatizados.
Los componentes de prueba se crean usando procedimientos de prueba como entrada:
Cuando se utiliza una herramienta de automatización de pruebas realizamos las acciones que
se describen en el procedimiento de la prueba. Estas acciones son grabadas originando un
componente de prueba como por ejemplo un script en Visual Basic.
Cuando programamos los componentes de manera explícita usando los procedimientos de
prueba como especificaciones iniciales. Esto requerirá que quien los desarrolle sea un
excelente programador.
La realización de las Pruebas de Integración

Las pruebas de integración se ejecutan y se recopilan los resultados de ellas. Estas pruebas se llevan a
cabo en los siguientes pasos:
1) Como primera medida se llevan a cabo las pruebas de integración relevantes a la construcción que
se analiza, realizando los procedimientos de manera manual o automatizada.
2) Comparando los resultados obtenidos con los esperados y luego investigando los resultados que
no coinciden con los de las pruebas.
3) Informando de los defectos a los responsables de las construcciones que poseen fallas.
4) Informando de los defectos surgidos en el proceso de prueba a quienes diseñaron la prueba para
que ellos puedan medir el esfuerzo de la prueba o modificarla.
La realización de las Pruebas de Sistema
Esta prueba puede empezar cuando las pruebas de integración indican que el sistema satisface al
menos los objetivos de calidad de integración que se plantearon en el plan de prueba anterior. La forma
de realizar la prueba de sistema es exactamente igual a la planteada anteriormente.
Evaluación de la Prueba
Las personas encargadas de la realización de las pruebas evalúan los resultados de la prueba comparando los
resultados obtenidos con aquellos que proporcionó la prueba. Pueden prepararse métricas que permitan
determinar la calidad del software y qué cantidad de pruebas será necesario realizar.
Por lo general, los encargados de las pruebas realizan las siguientes métricas:
Compleción de la Prueba. Se obtiene a partir de los casos de prueba y de los
componentes probados. Esta métrica indica el porcentaje de casos de prueba que han
sido ejecutados y el porcentaje de código que ha sido probado.
Fiabilidad. Esta métrica se basa en el análisis de las tendencias en los defectos encontrados y en
las tendencias en las pruebas que se ejecutan con el resultado esperado. Basándose en el
análisis de las tendencias de los defectos, las personas encargadas del diseño de estas pueden
sugerir otras acciones a seguir como por ejemplo:
Realizar pruebas adicionales para localizar más defectos en aquellos casos en los que el
índice de fiabilidad se encuentra por debajo de lo esperado.
Disminuir las condiciones de exigencia que se plantearon a las pruebas para aquellos casos
en los que se los requerimientos de la prueba se pusieron demasiado altos.
REFERENCIAS
Modelo de Prueba También conocido como Testing (su traducción en idioma inglés).
Vincule el tipo de prueba correspondiente con el objetivo de la misma:
Busca provocar fallos en el sistema a los

Negativa
efectos de poder determinar puntos
débiles. Testea el comportamiento de
Regresión funcionalidad vieja del sistema ante
implementaciones nuevas.
Evalúa el comportamiento del sistema
Sistema
como un todo.
Identifica problemas del sistema cuando
Tensión
éste opera en entornos escasos de
recursos. Verifica la interacción correcta
Integración entre los componentes después de haber
sido integrados.

Cualquier anomalía detectada en el sistema durante las pruebas se denomina defecto, y
permite identificar lo que se debe controlar y resolver.
X Verdadero
○ Falso
Un componente de prueba automatiza uno o varios procedimientos de prueba, o partes de ellos.
Se utiliza para probar los componentes en el modelo de implementación.
X Verdadero
○ Falso
Hemos visto cómo debe llevarse adelante un Modelo de Prueba; para ello usted partirá de un modelo de
caso de uso, la lista de requerimientos adicionales y puede utilizar el modelo de diseño. Con estas
herramientas a mano, deberá escribir detalladamente cuáles serán los pasos de la prueba.
El detalle del procedimiento de la prueba se especifica tal como se lleva a cabo a través de la interfaz de
usuario, siguiendo el camino completo, proporcionando valores para ciertas entradas al sistema e
indicando qué se debe verificar en las salidas del sistema. Para esta situación tendríamos lo siguiente:
Caso de Uso: Generar Orden de Servicio de Impresión

1) Seleccionar del menú la opción Servicios de Impresión. Se abre la ventana de Servicios de Impresión.
2) En el campo Cliente, ingresar su código (ID 12345) o activar el botón de búsqueda alfabética (PERZ &
Co), para este caso verificar que el cliente seleccionado por la búsqueda haya quedado cargado
correctamente en el campo Cliente el código recuperado.
3) Verificar la apertura del subformulario de items del servicio de impresión.
4) En el subformulario, en el campo tipo de obleas, verificar que solamente aparezcan como
opciones disponibles los tipos asociados para este cliente (seleccionar AVERY 80x50).
5) En los check box de opción múltiple, seleccione todos los campos a imprimir (Código, Descripción
del Artículo, Código de Barras e Imagen).
6) Ingresar los datos correspondientes a los check box seleccionados, según el siguiente detalle:
Código = 1254-K56U
Descripción = "Amortiguador Patagónico"
Codigo de Barra = Code 39
Imagen = "amort_chico.bmp"
7) En el campo cantidad de obleas ingresar 120.
8) Finalizar la Orden de Servicio de Impresión con el botón Finalizar y Verificar la generación de la vista
previa en pantalla.
9) Aceptar al vista previa con el botón Aceptar y verificar que en las tablas de Orden_de_Servicio esté
almacenado el pedido correspondiente y en al tabla Items_Orden_de_Servicio se encuentre el datalle
de lo solicitado.
La ejecución de esta prueba nos permitirá corroborar el buen funcionamiento de varios componentes que
integran el caso de uso analizado, por ejemplo, se verificará el buen funcionamiento de la búsqueda del cliente a
través de las dos formas (ingresando sólo el código o, utilizando la búsqueda alfabética interactiva). También se
verificará el buen funcionamiento de la operación de selección de los tipos de obleas asociadas al cliente.
Se verificará la captura de datos relativos al diseño de la oblea y se verificará la grabación de los datos en
sus correspondientes tablas.
Tomando como base el siguiente prototipo de interfaz que se ha diseñado para el alta de artículos de ropa
informal, en la que de acuerdo a las opciones que se seleccionan en cada uno de los componentes
gráficos se construya de manera automática el código que le corresponderá al artículo, se le solicita que
diagrame el Plan de Prueba de la misma y especifique que cosas se deberán controlar en la misma.

Uno de estos elementos NO forman parte del Modelo de Pruebas, ¿cual es?:
○ Procedimiento de prueba
○ Componente de prueba
○ Plan de prueba
○ Evaluación de la prueba
Un Procedimiento de Prueba es:
○ Un componente que automatiza uno o varios procedimientos de prueba o partes de ellos. X

Una especificación de cómo se deben realizar uno o varios casos de prueba o parte de ellos.
○ Una especificación de las estrategias, recursos y planificación de la prueba.
○ Una evaluación de los resultados donde se detalla la cobertura de los casos de prueba.
○ Ninguna de las anteriores.
En el caso de estemos intentando evaluar cómo reacciona el sistema de prueba cuando otros
compiten por el mismo recurso de hardware, como por ejemplo cuando se comparte un servidor de
aplicaciones para varios sistemas, estaríamos efectuando una prueba de... :
○ Integración
○ Sistema
○ Configuración
○ Regresión
X Tensión
Una de las siguientes afirmaciones es FALSA, ¿cuál es?:
○ Una prueba se considera exitosa cuando detecta un defecto en el sistema. ○

Los casos de uso son unidades de prueba en el Modelo de Prueba.
○ El caso de prueba especifica cómo se debe probar una parte específica del sistema.
X El flujo de prueba demanda mayo esfuerzo durante la fase de Elaboración.
○ Un defecto es una anomalía del sistema.
En la Evaluación de la prueba, el análisis de las tendencias de los defectos sirven principalmente
para tomar las siguientes acciones (marque las correctas):
X Realizar pruebas adicionales para localizar más defectos los casos poco fiables.
○ Identificar nuevos casos de prueba.
○ Detectar fallas en el procedimiento de prueba.
X Disminuir las condiciones de exigencia para los casos de prueba con mas exigidos.
○ Interactuar con los usuarios para evaluar el grado de satisfacción del sistema.
Anexos
Es nuestra intención presentar en esta sección, material complementario extraprogramático, para uso
de alumnos y docentes.
En primer lugar, encontrará material introductorio para el uso de MS Visio 2010 como herramienta de
modelado y diagramación. Todos los modelos UML presentados en este TID fueron confeccionados con
esta herramienta.
En segundo lugar, y principalmente destinado a los profesores de la materia, hemos recopilado algunos
Ejercicios de aplicación que representan situaciones profesionales variadas y reales, para su utilización
como ejercicios complementarios o trabajos prácticos de clase. También encontrará en esta sección el
ejercicio resuelto en MS Visio 2010 del sistema VENTEL, correspondiente a las situaciones profesionales
2, 3 y 4 de este TID.
Esperamos que les sea de mucha utilidad.
Microsoft Visio 2010
La búsqueda de una herramienta adecuada para nuestra materia no fue una empresa sencilla.
Consideramos que el uso de una aplicación para dar soporte al desarrollo de los modelos UML es de suma
importancia para el desarrollo profesional del Analista de Sistemas. Las empresas y áreas que desarrollan
software utilizan para sus procesos de calidad, emplean aplicaciones que permiten a sus analistas
funcionales documentar los requerimientos del sistema, ya sea en forma sintética o en forma detallada hasta
incluir elementos de diseño, implementación y testing.
El mercado actual nos brinda múltiples opciones: Aplicaciones Licenciadas, Aplicaciones Libres,
Aplicaciones con funciones CASE, Diagramadores, etcétera; todas ellas con las prestaciones y alcances
necesarios para la confección de los modelos UML estudiados.
Después de analizar y evaluar en clase varias de las opciones antes mencionadas, hemos optado por la
utilización de Microsoft Visio 2010, aplicación integrada al paquete Microsoft Office 2010. Las razones
que fundamentan nuestra elección son las siguientes:
Es parte las aplicaciones que conforman el MSDN Academic Allance
http://www.ies21.edu.ar/laboratorios-de-informatica/microsoft-gratuito (convenio entre Microsoft y
el Colegio Universitario IES), por lo que cualquier alumno puede solicitarlo y descargarlo de forma
gratuita.
Su operación es simple e intuitiva debido a sus características similiares a cualquier
aplicación Microsoft Office, como Excel o Word.
Aunque no es una herramienta CASE (Computer Aided Software Engineering), cuenta con todas
las características necesarias para realizar los diagramas estudiados.
Incluye muchas plantillas prediseñadas.
Cuenta con el soporte de Microsoft, lo cual garantiza en gran medida la actualización de versiones
y toda la documentación sobre la herramienta a través de la biblioteca MSDN.
Está disponible en todos nuestros laboratorios, lo que permite su utilización no solo para el
dictado de las clases sino para el desarrollo de trabajos prácticos y evaluaciones parciales y
finales.
Instalación
Antes de comenzar la instalación debes recordar verificar que tu equipo cumpla con los Requerimientos de
Instalación
http://office.microsoft.com/es-ar/products/requisitos-del-sistema-para-microsoft-office-2010-HA101810407
.aspx especificados por Microsoft.
Paso 1: descargar el software desde la página suministrada (www.ies21.edu.ar). Tener en cuenta que el
proceso implica una registración como alumno del Colegio Universitario IES. La clave de producto será
enviada a la dirección de correo informada en el registro.
Paso 2: ejecutar el programa de instalación SETUP.EXE desde el dispositivo donde tengas el

producto descargado.
Paso 3: ingresar la clave de producto, suministrada por correo electrónico.
Paso 4: leer los términos de la licencia, y aceptar para poder continuar.
Paso 5: elegir "Instalar ahora". Esto comenzará la instalación con la configuración más común para todos
los usuarios.
Paso 6: presione el botón Cerrar para finalizar la instalación.

Configuración de Entorno y Características
Paso 1: ejecute el programa Microsoft Visio 2010. Se encuentra en el menú de Windows, dentro del grupo
de accesos Microsoft Office. La ubicación de este acceso puede variar dependiendo la versión de Windows
y la configuración del escritorio.
Paso 2: si es la primer ejecución de Microsoft Office en su equipo, el programa solicitará configurar las
opciones de actualizaciones del paquete. Recomendamos la primer opción, tratándose de software original.
Paso 3: Microsoft Visio 2010 (de ahora en más "Visio") presentará al inicio un asistente con plantillas
sugeridas para crear un nuevo documento. Una plantilla es una configuración de aspectos básicos de
diseño, formas y herramientas que se aplicará en el nuevo documento creado. Recordemos que Visio es
una aplicación de diagramación de propósito general, ya que se pueden confeccionar muchos tipos de
gráficos diferentes. Para nuestra materia, debemos utilizar la plantilla de Diagramas UML, que se encuentra
dentro de la categoría "Software y base de datos", como muestra la figura.
Paso 4: a continuación, debemos utilizar la plantilla "Diagrama de modelo UML". Usando la opción
"Crear", o haciendo doble clic sobre el icono de la plantilla, se creará un nuevo documento Visio listo para
construir diagramas UML.
Paso 5: reconocer el entorno de trabajo. Los archivos generados en Visio tienen extensión *.vsd.
Los elementos principales del entorno son los que se presentan en la figura:
Bloque de Formas: en este bloque se encuentran, agrupadas por tipo de modelo UML, las figuras
necesarias para realizar cada diagrama. Simplemente selecciona una y arrástrala hasta el cuerpo de la
página. Explorador de modelos: es muy útil para organizar y visualizar proyectos grandes. Es posible
ocultarlo si no se utiliza.
Solapas de Páginas: Cada archivo de Visio permite trabajar con varias Páginas. De esta manera se
puede documentar el análisis completo de un sistema en un solo archivo, presentando uno o más
diagramas por página.
Barra de herramientas: la barra de herramientas de Visio respeta los mismos patrones de funcionamiento
del paquete Office, resultando bastante intuitivo su uso.
Páginas: el cuerpo de cada página presenta una grilla que sirve como guía para la alineación visual
de las formas en un diagrama.
Paso 6: incorporar al entorno de trabajo el grupo de formas necesarias para confeccionar Prototipos de
Interfaz. Los Prototipos de Interfaz no son modelos UML estandarizados, y por este motivo, la plantilla
seleccionada no contará con las formas básicas para realizarlos: cajas de texto, botones de comando,
botones de opción, barras de desplazamiento, ventanas, etc. Para poder tener los prototipos dentro de
nuestro archivo de Visio, deberemos incorporar manualmente estos componentes, de la siguiente manera:
Paso 7: como último paso antes de comenzar con la confección de los diagramas UML, es conveniente revisar la
Configuración de la Página, para evitar inconvenientes durante la diagramación. La ventana de configuración se
activa utilizando la combinación de teclas MAYUS+F5 o SHIFT+F5. Como la mayoría de los diagramadores de
uso profesional, Visio cuenta con una opción de reubicación automática de formas, cuya función es mover
automáticamente los distintos elementos del diagrama en función de su posición relativa del elemento que se está
posicionando. Esta función no es recomendable para usuarios principiantes ya que resulta molesta y
contraproducente. Para desactivarla, se debe ingresar en la pestaña "Diseño y enrutamiento", y quitar el tilde del
botón "Mover las otras formas al colocar", como se muestra en la imagen.
Construcción de los modelos
Reglas generales para la diagramación
Antes de describir la metodología de armado de cada diagrama, estableceremos algunas reglas generales
que servirán para todos ellos. Varias de estas reglas son características comunes de Windows, que
seguramente usted conocerá del uso habitual del sistema operativo:
Todas las formas se incorporan en un diagrama seleccionándolas en el Bloque de Formas, y
arrastrándolas (haciendo clic sin soltar con la tecla izquierda del mouse) al cuerpo de la página.
Si se necesitan varias copias de una misma forma, esta operación debe repetirse tantas veces
como sea necesario.
Bloque de Formas: Seleccionar y arrastrar forma
Las propiedades de una forma en el diagrama, se pueden cambiar haciendo doble clic sobre la
misma, o utilizando la opción "Propiedades" del menú contextual (que se despliega haciendo clic
con la tecla derecha del mouse sobre la forma). Las propiedades de una forma varían de acuerdo
a su tipo. Por ejemplo: una forma que represente una "Clase", tendrá en sus propiedades
"atributos" y "operaciones"; pero una forma que represente una "Asociación", tendrá otras
propiedades específicas.
Las opciones de presentación de una forma en el diagrama, se pueden cambiar utilizando la
opción "Opciones de presentación de formas" del menú contextual (que se despliega haciendo
clic con la tecla derecha del mouse sobre la forma). Las opciones de presentación permiten
ocultar y/o mostrar diferentes características de la forma. Por ejemplo: en una forma que
represente una "Clase" se pueden ocultar el bloque de "atributos" y el bloque de "operaciones"
(métodos).
Utilizando el menú contextual (que se despliega haciendo clic con la tecla derecha del mouse
sobre la forma), se pueden modificar algunas características gráficas de la forma, como cambiar
el tipo, tamaño y color de la fuente; el color del fondo; el color del contorno; el tipo de conector
(muy útil para las relaciones de UML); etc.
Menú Contextual: Propiedades y Opciones de presentación de formas
Un documento Visio (*.vsd) se guarda, como cualquier archivo Office, utilizando la combinación
de teclas CTRL+S. Es recomendable guardar periódicamente y trabajar un diagrama por página.
Se pueden agregar nuevas páginas a un archivo utilizando la opción "Insertar página" ubicada
en las Solapa de Páginas.
Solapa de Páginas: Agregar una nueva Página
Recomendamos la utilización del Explorador de Modelos para la creación de nuevos modelos,

elementos y diagramas. Esta útil herramienta nos ayudará a mantener organizado el modelo completo,
permitiendo evitar la duplicación de elementos en el mismo. Por ejemplo: si usted crea un actor
Cliente, necesitará utilizar este objeto en más de un diagrama, como el de Casos de Uso y el de
Asociaciones. El Explorador de Modelos permitirá crear el actor una sola vez, y luego, mediante la
técnica que ya conocemos de "seleccionar y arrastrar" sobre el cuerpo de una página, podremos
incorporarlo en todos los diagramas en donde sea necesario (eso sí, el objeto Cliente será uno solo,
todas sus propiedades se definirán en un solo lado, y pertenecerá a un solo nivel dentro del árbol de
modelos). Usando el menú contextual (que se despliega haciendo clic con la tecla derecha del mouse
sobre cualquier rama del Explorador de Modelos), a través de la opción "Nuevo" se podrán incorporar
todos los elementos y diagramas contextualmente factibles * 23.1 .
Nuevos Diagramas: Menú Contextual del Explorador de Objetos
Es muy importante el correcto uso de los Conectores en todos los diagramas. Los Conectores son
las partes de una forma que pueden ser "conectadas" con otra. Por ejemplo, en el caso de un
Diagrama de Clases como el que vemos en la figura, los Conectores serían: los extremos de la
"asociación binaria" y, del lado de la clase, el punto medio del lado derecho del rectángulo que
forma su contorno. La "conexión" se realiza seleccionando uno de los conectores y arrastrándolo
hacia el otro, hasta que el punto de conexión se muestre como un pequeño cuadrado de
contorno rojo, con fondo blanco o con fondo rojo. Esto significa que las figuras están
"conectadas" correctamente, de lo contrario los conectores se muestran de color celeste. La
importancia del uso de los conectores en todas las asociaciones semánticamente correctas de
los diagramas, radica en dos aspectos:
La conexión gráfica en los modelos UML implica una conexión lógica entre elementos. Por
ejemplo, si en el caso de la figura no se conectaran las dos clases con su asociación binaria,
esa dependencia lógica no se establece, quedando inhibidas todas las restricciones de
multiplicidad e integridad referencial que deben existir en este tipo de relación. De la misma
forma, debería ser entre Estados y Transiciones en un Diagrama de Estados, entre Actores,
Relaciones y Casos de Uso en un Diagrama de Casos de Uso, entre Objetos y Enlaces en un
Diagrama de Colaboración, etc..
El otro aspecto es netamente gráfico. Al estar conectadas las figuras, permite al diseñador
reubicarlas en el diagrama sin perder sus conexiones con las otras. Esto es muy útil
cuando se trabajan diagramas con muchos elementos, que deben ser reorganizados
permanentemente para mantener la claridad del modelo y evitar cruces de líneas o
superposición de formas.
Conectores: Uso de Conectores en un Diagrama de Clases
Consideraciones finales
La construcción de los diagramas UML estudiados en este TID es bastante intuitiva. Estimamos que a un
alumno avanzado en la carrera como es usted, que ya ha tenido experiencia en manejo de herramientas de
ofimática o entornos de desarrollo como Visual Studio, MS Visio 2010 no le presentará mayor dificultad.
Como ya sabe, todos los diagramas de UML, así como otros modelos complementarios para nuestra
metodología como son los Prototipos de Interfaz, están basados en elementos muy simples. La complejidad
no radica en el uso de la herramienta de modelado, sino en los criterios que se deben aplicar en el análisis y
en el diseño de la arquitectura de cada modelo, y en cómo los distintos componentes se combinan para
formar un sistema de calidad que cumpla con los requisitos del usuario.
No es nuestra intención que el eje de la materia sea la herramienta de modelado, en este caso MS Visio
2010. Por el contrario, lo invitamos a que investigue otras herramientas y que elija usted la de su preferencia.
UML es un estándar, razón por la cual cualquier diagramador que lo soporte nos llevará a obtener modelos
que se corresponden con lo estudiado.
Lo invitamos, también, a visitar el sitio de Visio en Office.com http://office.microsoft.com/es-ar/visio/pagina-
principal-de-visio-2010-FX010048786.aspx Office.com http://office.microsoft.com/es-ar/visio/pagina-
principal-de-visio-2010-FX010048786.aspx para profundizar sobre cualquier aspecto de la herramienta.
REFERENCIAS 23
23.1 : Contextualmente factibles
Esto significa que cada rama dentro de un modelo de UML permitirá incorporar cierto tipo de elementos. Por ejemplo: a nivel
de un Paquete, se podrán incorporar nuevos paquetes, clases, interfaces, actores, diagramas, etc.; pero a nivel de una Clase,
solamente se podrán incorporar atributos, operaciones, subclases y diagramas de estados y actividades.
Ejercicios
1) Sistema VENTEL
Ejercicio de las situaciones profesionales 2, 3 y 4 (Requisitos, Análisis y Diseño respectivamente), resuelto con
MS Visio 2010. Presenta solamente los diagramas UML que forman parte de las Herramientas y de los
Ejercicios resueltos.
Sistema Ventel.vsd (spankb299) Sistema Ventel.vsd (spankb395)
2) Aplicación para celulares
La empresa MiniSoft SA, se dedica al desarrollo de sistemas operativos para dispositivos móviles. Entre
sus productos de cabecera se encuentra SOM 1, un sistema operativo diseñado para equipos de baja gama.
Utilizando la información obtenida de la evaluación de sus usuarios, se toma la decisión de reemplazar la
actual aplicación de envío de SMS por otra que sea más simple de operar para usuarios inexpertos. Los
equipos que utilizan SOM 1 son generalmente adquiridos por Clientes de muy bajo perfil tecnológico.
Usted ha sido contratado para analizar y diseñar la nueva aplicación, que será desarrollada por el equipo
de TI de MiniSoft en C++ (lenguaje orientado a objetos) en base a su modelado.
Debido a restricciones tecnológicas de operación de la interfaz, solamente pueden ser usados controles de
los siguientes tipos: cajas de texto, check-box, lista desplegable o combo-box o cualquiera de éstos últimos
con check-box. Solamente se podrán utilizar los botones que se muestran en la interfaz general del sistema
operativo, presentados a continuación:
La nueva aplicación de SMS debe permitir al usuario una vez iniciada, seleccionar los destinatarios del mensaje,
tomándolos de la lista de contactos del equipo. En caso de no existir en la lista, deberá permitir especificar también
números telefónicos de destino. No debe permitir desde esta aplicación dar de alta nuevos contactos.
Una vez ingresados o seleccionados los destinatarios, se deberá ingresar el texto de mensaje, a través del
método de entrada configurado en el equipo (predictivo con diccionario, secuencial, etc.). La aplicación
deberá permitir el ingreso de emoticonos en el cuerpo del mensaje, que se deberán presentar en una
pantalla para que el usuario los seleccione. Los emoticonos una vez seleccionados se convierten en
conjuntos de caracteres estandarizados como: ;-) :-(
La aplicación deberá permitir enviar el mensaje (validando los destinatarios y que el cuerpo del mensaje no
esté vacío ni supere los 120 caracteres), o cancelarlo. Los mensajes enviados deberán quedar registrados
en la bandeja de elementos enviados del equipo.
Se le solicita analizar el caso de uso "Enviar Nuevo Mensaje de Texto" completo, presentando la
siguiente documentación:
1) Lista de requerimientos.
2) Diagrama de Caso de Uso.
3) Diagrama de Asociaciones.
4) Ficha del Caso de Uso en trazo intermedio utilizando la plantilla suministrada.
5) Diagrama de Clases.
6) Prototipo de Interfaz.
7)
3) Estación de Servicio
Usted ha sido contratado por una estación de servicio, para realizar una pequeña aplicación que le
permita realizar el expendio de combustibles. Esta aplicación reemplazará a los actuales tableros
electrónicos de los surtidores, pasando a estar operada por los playeros de turno a través de un monitor
sensible al tacto. La disposición del equipo quedará como se muestra en la figura siguiente:
La aplicación tendrá dos funcionalidades básicas: Venta automática y venta manual, cuyo
funcionamiento esperado deberá ser el siguiente:
Venta automática
1) La aplicación se encontrará bloqueada e inactiva.
2) En el momento en que el playero descuelga cualquier manguera surtidora, se instancia el caso de
uso. El sistema detectará automáticamente el tipo de combustible y el precio por litro del mismo.
3) El playero deberá, antes de comenzar la carga de combustible en el vehículo, ingresar los
siguientes datos:
a) Código de playero (numérico de 2 dígitos).
b) Si el tope de la venta es en pesos o en litros.
c) La cantidad (de litros o pesos).
4) El playero comenzará la carga con la pistola surtidora.
5) Cuando la bomba haya surtido los litros especificados, cortará automáticamente el suministro,
debiendo emitir la aplicación una alerta sonora y visual en la pantalla.
6) En este momento se registrarán todos los datos de la venta en la base de datos: playero, surtidor,
tipo combustible, precio por litro, cantidad de litros, fecha y hora de la venta.
7) A continuación, el sistema se bloqueará automáticamente, volviendo al estado del punto 1.
Venta manual
Los pasos y el comportamiento de la aplicación son los mismos que en la venta automática, con la gran
diferencia de que en la venta manual el playero no ingresa el tope de la venta (en litros o pesos), sino
que el corte de suministro lo realiza de manera manual soltando el gatillo de la pistola surtidora.
En ambos casos (venta manual o automática), la aplicación deberá mostrar en pantalla el avance de la
carga en litros y en pesos, como feedback para el cliente y para el playero.
A pedido expreso del gerente de la estación, se debe minimizar la cantidad de operaciones del playero
en la nueva aplicación, para garantizar la productividad del proceso de ventas.
Se le solicita realizar el análisis del caso de uso "Realizar Venta Automática", presentando la
siguiente documentación:
1) Lista de requerimientos.
2) Diagrama de Caso de Uso.
3) Diagrama de Asociaciones.
4) Ficha del Caso de Uso en trazo intermedio utilizando la plantilla suministrada.
5) Diagrama de Clases.
6) Prototipo de Interfaz.
4) Biblioteca Pública
Una biblioteca pública de la ciudad de Córdoba ha contratado sus servicios profesionales para el desarrollo
de una aplicación que permita al bibliotecario de turno la administración de los préstamos de libros a
clientes. Esta biblioteca cuenta con varias salas de lectura propias, acondicionadas para que los clientes
puedan utilizarlas para la lectura de libros.
Existen tres tipos de clientes, y de acuerdo a estos tipos es la modalidad de préstamo:
El Visitante, quien recorre los estantes pudiendo tomar uno o más ejemplares para leer en las
salas de lectura propias de la biblioteca. Este cliente es anónimo, pero los ejemplares tomados
deben ser registrados por el bibliotecario.
El Socio, que es un tipo especial de cliente que puede llevarse hasta 2 ejemplares a su casa por
un plazo de 2 días hábiles. Debe existir en el sistema con todos sus datos personales, debiendo
quedar registrado el detalle del préstamo.
El Contribuyente, entran en esta categoría los socios que tienen mas de un año de antigüedad,
con el condicionante que deben realizar una contribución anual de un ejemplar nuevo en la
biblioteca o su equivalente en dinero. Como beneficio, este tipo de cliente puede retirar hasta 5
libros por un plazo de 2 semanas.
Se llama libro a un título específico, como por ejemplo "El código Da Vinci", y se identifica por el código
ISBN que figura en el código de barra impreso en el mismo.
Se llama ejemplar a cada copia existente de un libro, identificada por código interno impreso en un rótulo
autoadhesivo (con código de barras)que es aplicado por el bibliotecario cada vez que ingresan nuevas
unidades. Ejemplo: el libro "Diccionario RAE" tiene 5 ejemplares en la biblioteca, cada una de ellas
identificada por su propio código interno.
Los ejemplares se encuentran ubicados en estantes específicos a su rubro y ordenados por su un
código interno.
El bibliotecario deberá contar con dos interfaces:
Una pantalla que le permita gestionar los préstamos de ejemplares a cualquiera de los tipos
de cliente definidos. En esta pantalla el bibliotecario deberá poder escanear los códigos
internos de cada ejemplar y registrar el préstamo al cliente. Los préstamos pueden ser:
Interno: Los ejemplares se retiran de los estantes para ser leídos dentro de la biblioteca. En
este caso cualquier cliente puede sacar la cantidad de ejemplares que necesite, y no es
necesario registrar los datos del mismo (cliente anónimo).
Externo: Es aquel donde el cliente se lleva los ejemplares. Para registrar este tipo de
préstamo, se debe considerar el tipo de cliente y validar las reglas establecidas de plazos y
cantidad de ejemplares.
Una consulta que le permita conocer el stock de libros y su situación, pudiendo buscar por ISBN,
titulo, rubro, autor o editorial. Se entiende por "situación" de un libro a cuantos ejemplares
existen en la biblioteca, cuántos de ellos se encuentran disponibles y cuántos prestados. En el
caso de los prestados se debe poder ver en la misma interfaz los datos de que cliente lo tiene,
la fecha del préstamo, la fecha de devolución y un teléfono del cliente.
Se le solicita resolver y analizar el "Módulo Bibliotecario", que contiene los casos de uso "Gestionando
préstamos a clientes" y "Consultando libros". Debe presentar la siguiente documentación:
1) Para el módulo en general:
a) Lista de Requerimientos.
b) Diagrama de Casos de Uso.
c) Diagrama de Clases.
d) Diagrama de Estados de alguna clase del modelo, que presente como mínimo 5 posibles
situaciones de un objeto.
2) Para cada uno de los 2 casos de Uso:
a) Prototipos de interfaz.
b) Ficha del Caso de Uso en trazo fino.
c) Diagrama de Asociación de Casos de Uso.
d) Diagrama de Colaboración.
e) Diagrama de Secuencia.

Resumen Analisis Sistema

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Resumen Analisis Sistema

Uploaded by

Copyright:

Available Formats

Análisis de Sistemas

¿Cómo está organizado este texto? ...................................................................................................................... 5

Situación profesional 1: Conceptos Generales (cadena de ventas) .................................................. 9

Situación Profesional 2: Requisitos.................................................................................................................... 65

Situación Profesional 3: Análisis ....................................................................................................................... 154

Situación Profesional 4: Diseño ......................................................................................................................... 223

Situación Profesional 5: Implementación..................................................................................................... 302

Situación profesional 6: Prueba ......................................................................................................................... 332

Cierre ................................................................................................................................................................................... 350

Bibliografía ...................................................................................................................................................................... 351

Anexos ............................................................................................................................................................................... 352

REFERENCIAS 23 .............................................................................................................................................................. 361

Ejercicios ....................................................................................................................................................................... 362

Figura 1-1-1: Un ejemplo de Modelo

Particularmente en la aplicación de modelos en proyectos de desarrollo de sistemas informáticos, éstos

Especificación formal del significado y del comportamiento de algo.

Codificación o símbolo que se establece para un elemento perteneciente a un modelo.

2.3 : Metodología Descendente

1. Indique la opción correcta

3. Indique la opción correcta

Semántica Significado y Comportamiento

Metodología Orientada a Objetos por tres sencillas razones:

Características de los Modelos Orientados a Objetos

Metodologías Estructuradas vs. Metodologías Orientadas a Objetos

Metodologías Orientadas a Objetos

Elementos de la Programación Orientada a Objetos

Polimorfismo (Figura 1-2-5)

4. Indique la opción correcta

Objeto--------------------Instanciade una clase

Clase------ ------------------Categoría de objetos

Generalización---------------- Lo opuesto Especificación

Polimorfismo ------------Comportamiento diferente de un método de acuerdo al tipo de objeto

Encapsulamiento ------ Resguardo de datos y funcionalidad de un objeto

Jerarquía de Clases -------Árbol de relaciones entre clases padres e hijos

SP1 / H3: UML

Organización del modelo

Pueden usarse para almacenamiento, control de acceso, gestión de la configuración, y construcción de

Los Diagramas de UML

Diagrama de Casos de Uso:

Otras herramientas complementarias al modelado en UML

Las Vistas de UML

La visualización, especificación, construcción y documentación de un sistema con gran cantidad de software

Proceso de Desarrollo de Software (Figura 1-4-1)

Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo: Fases y Flujos de Trabajo (Figura 1-4-2)

Visión general del Proceso, sus áreas conceptuales, sus fases y

¿cómo hacemos para llegar a construir código ejecutable?

En el Flujo de Trabajo (ver la Figura 1-4-2

Interactiva "Fases del proceso unificado de desarrollo"

SP2 / H1: Captura de requisitos

El papel de los requisitos en el ciclo de vida software

El modelo de contexto del sistema mediante un modelo de dominio

La comprensión del contexto del sistema mediante un modelo de negocio

Interactiva "Captura de requerimientos"

Comprender el contexto del sistema

3. Indique la opción correcta

5. Indique la opción correcta

6. Indique la opción correcta

8. Indique la opción correcta

El Diagrama de Casos de Uso

Relaciones entre Casos de Uso

Relación de extensión entre Casos de Uso (Figura 2-2-

Las extensiones tienen las siguientes características:

Relaciones de Uso o Inclusión