2.

Fase Inicio
Esta fase no es un estudio completo del sistema propuesto, porque en ella se busca
los casos de uso necesarios para fundamentar el Análisis Inicial del Negocio.
El sistema deberá proporcionar ingresos u otros beneficios a la inversión necesaria
con un margen suficiente para construirlo. La intención es minimizar los gastos en
tiempo de planificación, esfuerzo y fondos en esta fase. En el caso de un sistema
completamente nuevo, en un dominio poco explotado, esta consideración puede
extenderse a varias iteraciones convirtiéndose en un proyecto de investigación completo.
Caso contrario esta fase puede ser completada en pocos días, una persona recopilar una
declaración de objetivos, esbozar una arquitectura usando diversos diagramas y
desarrollar un análisis del negocio razonable.
Si se trata de hacer una nueva versión de un producto, gran parte del trabajo de
planificación de la primera iteración del nuevo producto habría sido hecha en la última
iteración del ciclo anterior. Caso contrario, si se trata de un producto nuevo, quienes lo
originaron pueden querer ver su idea desarrollada más profundamente.
Para realizar el análisis del negocio inicial se deberá realizar los siguientes cuatro
pasos.
 Delimitar el ámbito del sistema propuesto en cual se definen los límites del
sistema y empezar a identificar las interfaces con los sistemas relacionados.
 Describir o esbozar una propuesta de la arquitectura del sistema, y en especial de
aquellas partes del sistema que son nuevas, arriesgas o difíciles. La arquitectura
candidata se describe pero raramente se llega hasta un prototipo ejecutable.
 Identificar riesgos críticos. En esta fase consideramos sólo los riesgos que afectan
la viabilidad, es decir, aquellos que amenazan el desarrollo del éxito del sistema.
Cualquier riesgo no crítico que se identifica es colocado en la lista de riesgos
para su posterior análisis.
 Demostrar a los usuarios o clientes potenciales que el sistema propuesto es capaz
de solventar sus problemas o de mejorar sus objetivos de negocio construyendo
un prototipo (interfaces de usuario o algún algoritmo interesante). Generalmente
este prototipo es posteriormente descartado.
De cada punto manifestado anteriormente se deberá analizar respectivamente los
siguientes textos: el primer punto hace referencia a la Captura de Requisitos, el segundo
punto a la Arquitectura Fase de Inicio, el tercer punto Gestión de Riesgos y el cuarto
punto referencia Prototipar la Interfaz de Usuario.
Desarrollados los cuatro pasos confeccione un plan provisional para clasificar los
requisitos concernientes a los objetivos iniciales y detallarlos en los correspondientes
casos de uso. Planifique la creación de una arquitectura candidata sólo hasta el punto de
establecer que el proyecto es factible esbozando vistas de la misma.
Tenga en cuenta que el plan inicial es provisional. A medida que vaya recopilando
más información va modificándose y ajustándose continuamente.
Una vez completado estos cuatro pasos hemos logrado gran parte del objetivo
principal de la fase de inicio: determinación del ámbito del sistema, esbozar una
arquitectura, identificar los riesgos críticos para el éxito del proyecto y perfilar un plan
para mitigarlos.

Diseño de Sistemas Página 1 de 23 UTN

 Si es un nuevo sistema será necesario hacer una demostración del sistema y su uso
construyendo un prototipo descartable o un algoritmo de software para llevar a cabo los
requerimientos iniciales.
El analista de sistemas identifica los casos de uso y actores para definir el ámbito del
sistema. El arquitecto establece prioridades entre los casos de uso, seleccionando
aquellos que son relevantes para la arquitectura candidata, y prepara una descripción
inicial de la vista de la arquitectura de modelos de casos de uso. Los encargados de
especificar los casos de uso detallan algunos caminos a través de los casos de uso
identificados por el arquitecto.
En el flujo de trabajo de análisis, creamos un modelo de análisis para la mayoría de
los casos de uso y escenarios tratados en la fase de inicio. La iteración puede concluir con
la descripción de la arquitectura candidata incluyendo bocetos de las vistas de los
modelos. Esta arquitectura deberá mostrar ser capaz de funcionar, y que el riesgo es
menos crítico o mitigable.

2.1. Flujo de Trabajo

Detallamos el flujo del trabajo en forma continua para esta fase, Flujo de Trabajo -
Fase Inicio, y posteriormente comprobaremos que se ha desarrollado cada uno de los
siguientes flujos:

2.1.1. Requisitos
Ya hemos enumerado los requisitos candidatos en la lista de característica para
comprender el contexto, representado por los requisitos funcionales pertinentes en casos
de uso y extraído de los requisitos no funcionales relacionados.

2.1.2. Análisis
Se pueden analizar y redefinir algunos casos de uso del 10% que ha sido identificado
y sólo se analizan en más detalle un 5%, el objetivo de este análisis es focalizarse en
aquellos casos de uso que comparten recursos del sistema como ser: bases de datos,
recursos computacionales, etc. El modelo de análisis revela recursos compartidos que
debemos analizar hasta el punto de resolver estos conflictos.

2.1.3. Diseño
Si necesitamos desarrollar un prototipo de demostración lo haremos utilizando
módulos prefabricados, lenguajes de cuarta generación (4GLs) o cualquier técnica de
desarrollo rápido para mostrar la idea. La demostración de interfaces de usuario y
algoritmos no habituales hace creíble a todos los involucrados en el proyecto que merece
la pena seguir adelante.
Deberemos esbozar un modelo inicial de diseño tomando como primer paso la vista
de arquitectura del modelo de diseño, como se realizan los casos de usos identificados en
el flujo de trabajo de requisitos y sus como colaboraciones entre subsistemas o clases.

Diseño de Sistemas Página 2 de 23 UTN

 Para ello será necesario identificar interfaces (como mucho definir algunas de sus
operaciones) entre los subsistemas o clases incluso si se trata simplemente de un esbozo.
Estas interfaces son importantes porque forman el núcleo de la arquitectura. Más aún
necesitamos identificar los mecanismos genéricos de diseño que utilizaremos en las capas
subyacentes de los subsistemas para a llevar a cabo los casos de uso identificados.
Elegiremos el software del sistema y los marcos de trabajo necesarios en la capa
intermedia.
El modelo de diseño deberá atender no solo los requerimientos funcionales
representados por los casos de uso sino también los requisitos no funcionales como ser el
rendimiento, el cual puede ser un riesgo importante. Si el sistema propuesto va a ser
distribuido sobre varios nodos el arquitecto diseñará una versión en pequeña escala del
modelo de despliegue limitado, sobresaltando los nodos cuyo rendimiento es cuestionado
a las conexiones entre nodos. El jefe de proyecto puede solicitarle a un ingeniero de casos
de uso que modele las partes de los nodos y de la interacción entre ellos en donde reside
la amenaza.

2.1.4. Implementación
Debe finalizar la fase de inicio con la descripción de la arquitectura candidata, seguir
con el flujo de trabajo de implementación no siempre es necesario. Pero si las exigencias
desean ver desarrollado un prototipo el flujo continuará hasta la prueba del mismo por
más pequeño que sea el trabajo. La responsabilidad de decir hasta donde se desarrolla la
arquitectura candidata es responsabilidad del jefe del proyecto.

2.1.5. Pruebas
Los ingenieros de pruebas se van poniendo en tema la naturaleza general del sistema
y van considerando que pruebas se requerirán desarrollando alguno planes provisionales
de pruebas.
No se realiza un trabajo significativo de pruebas durante la fase de inicio, ya que el
prototipo exploratorio de demostración tiene por lo general carácter ilustrativo más que
operativo. El jefe del proyecto igualmente puede decidir o no dedicarle un esfuerzo de
pruebas al mismo.

2.2. Ejemplificación
 Minuta 1.2.2.doc
Extiende la funcionalidad del departamento de depósito permitiendo tener
una visión más amplia del mismo.
 Características 1.2.1.doc
El primer número contiene “1” se utiliza para la versión del producto, el
segundo número contiene “2” indicando el departamento de depósito y el tercer
número contiene “1” para relacionarlo con la iteración del documento Word.
Este documento detalla los eventos relacionados con el departamento de
depósito que permitirán definir su modelo de negocio.

Diseño de Sistemas Página 3 de 23 UTN

  Planillas
En el directorio (“Capítulo 2”, “Anexo”) existe un directorio llamado
(“Planillas”) y en su interior se describen en planillas EXCEL varios conceptos
mencionados en el documento (“Glosario .1.1.1doc”).
 Laboratorio 1.1.2.ea
Dentro del modelo de casos de uso<Negocio> (“Artefacto <Negocio>”) se
agregan dos paquetes ( “Entidad <Negocio>” y “Gestor <Negocio>”). Cada
paquete contiene un modelo de casos de uso <Negocio>, el primer paquete
describe todas las entidades del negocio encontradas (“Entidad <Negocio>”) y
el segundo paquete describe los gestores de negocio necesarios para poder
cumplir con los procesos de negocio (“Gestor <Negocio>”).
El paquete (“Depósito <Negocio>”) se ha modificado ilustrando ahora
todos los casos de uso de negocio basados en los eventos definidos en el
documento ("Características 1.2.1.doc"), y dentro de cada caso de uso también
se detalla su correspondiente realización de caso de uso, involucrando las
entidades de negocio participantes en cada una de las realizaciones.
 Glosario 1.1.1.doc
El primer número contiene “1” se utiliza para la versión del producto, el
segundo número contiene “1” indicando el laboratorio en general y el tercer
número contiene “1” para relacionarlo con la iteración del documento Word.
Para cada posible entidad del sistema se define un código que la identifica y
se detalla para su mejor comprensión.
 Laboratorio 1.1.3.ea
Al crear un modelo de dominio el EA crea automáticamente un paquete y
modelo de dominio denominados (“Domain Model”) cambiados por (“Modelo
Dominio <Negocio>”) y dentro del paquete crea otro paquete y modelo de
dominio por defecto llamados (“Domain Objects”) cambiados por
(“Laboratorio <Negocio>”) y dentro de este paquete contiene tres clases por
defecto (“class1”, “class2” y “class3”) las cuales son eliminadas.
El (“Laboratorio <Negocio>”) contiene diferentes paquetes para
representar a los diferentes departamentos del Laboratorio (“Compras
<Negocio>”, “Control Calidad <Negocio>”, “Depósito <Negocio>” y
“Producción <Negocio>”).
Y en el interior del paquete (Depósito <Negocio>) podemos observar en su
modelo de dominio la gráfica de algunas de las entidades definidas en el
documento "Glosario 1.1.doc".
 Minuta 1.2.3.doc
Mayor comprensión de la funcionalidad del departamento de depósito.
 Glosario 1.1.2.doc
Ampliación de entidades por que se toma más conocimiento del negocio.

Diseño de Sistemas Página 4 de 23 UTN

  Laboratorio 1.1.4.ea
Se crear un nuevo modelo de casos de uso y el Enterprise Architech y
automáticamente genera un nuevo paquete con su correspondiente modelo de
casos de uso denominado (“Use Case Model”) cambiados por (“Modelo Caso
Uso”).
Además un nuevo paquete su modelo de caso de uso llamados (“Actors”) y
una instancia de actor bajo el nombre (“User”) y un último paquete con su
modelo de casos de uso llamados (“Primary Use Cases”) y dos instancias de
casos de uso, estos artefactos son eliminados del modelo.
Dentro del modelo se casos de uso (“Modelo Caso Uso”) se crea un
paquete y su correspondiente modelo de casos de uso definidos (“Laboratorio”)
y dentro de este se crea otro paquete y su modelo de casos de uso llamados
(“Artefacto”) y en su interior otro paquete y su modelo de casos de uso
denominados (“Actor”) allí se ilustran los actores encontrados en el documento
("Minuta 1.2.3.doc"). Además cinco paquetes con sus correspondientes modelo
de casos de uso para representar los departamentos del Laboratorio (“Compra”,
Control Calidad”, “Depósito”, “Dirección” y “Producción).
En el interior del paquete y en su modelo de casos de uso (“Depósito”) se
grafican todos los casos de uso detectados hasta el momento en la ("Minuta
1.2.3.doc"). Existen cuatro casos de uso ampliados para su mejor comprensión.
Podemos observar que se mantienen casi los mismos nombres de los casos de
uso de negocio u otros se pueden cambiar más los nuevos casos de uso
detectados por la ampliación de los relevamientos.
 Glosario 1.1.3.doc
Ampliación de actores de caso de uso.
 Planificación 1.1.2.mpp
Podemos observar cómo en la sección “Fase Inicio” se ha incorporado una
nueva sección denominada “Glosario” y en su interior sus correspondientes
versiones (“Glosario 1.2.1” y “Glosario 1.2.2”).
En la cadena de secciones (“Fase Inicio”-“Depósito”-“Documentación”)
también se ha incorporado otra nueva sección (“Característica”) y su primera
versión (“Característica 1.2.1”).
Para la sección (“Fase Inicio”-“Depósito”-“Documentación”-“Minuta”) se
agregan dos nuevas versiones (“Minuta 1.2.2” y “Minuta 1.2.3”).
Se incorporó en la sección (“Fase Inicio”-“Depósito”-“Modelo
Negocio”-“Modelo Caso Uso Negocio”) su primera versión (“MCUN 1.2.1”). Y
en la sección (“Fase Inicio”-“Depósito”-“Modelo Negocio”-“Modelo
Dominio”) también se ha incorporado su primera versión (“MD 1.2.1”).
Otra sección incorporó (“Fase Inicio”-“Depósito”-“Modelo Caso
Uso”-“Diagrama Caso Uso”) su primera versión (“MCU 1.2.1”). Y en la
sección (“Fase Inicio”-“Depósito”-“Modelo Caso Uso”-“Diagrama
Actividad”) agrega a la versión (“MCU 1.2.1”) dos diagrama de actividad.
A continuación se realiza una evaluación de esta fase y se detalla la
planificación de la siguiente fase Planificación de la Fase Elaboración.

Diseño de Sistemas Página 5 de 23 UTN

Vínculos

Vínculo: Análisis Inicial del Negocio

Desde una perspectiva económica debemos considerar las exigencias de los recursos
del proyecto, los costos de la inversión, las estimaciones de los beneficios y la aceptación
del sistema. La otra cara de la moneda, las ganancias derivadas del eventual uso del
producto.
Las fórmulas de estimación subyacentes a la apuesta económica, dependen
normalmente el tamaño del producto final. Al finalizar esta fase el tamaño puede llegar a
variar un 50%, hay que recordar que solo se detallaron unos pequeños porcentaje del
conjunto de casos de uso.
Si realizamos la estimación basándonos solo en un promedio de tiempo para
desarrollar cada caso de uso, estaremos perdiendo objetividad de cálculo. Debido a que
cada uno puede diferir de manera significativa por su complejidad desarrollada dentro de
ellos.
Si no cuenta con una fuerte experiencia en uso UML deberá tratar de estimar
tiempos de la manera en que venia haciéndolo pero notará cómo los mismo disminuirán
drásticamente, los plazos de entrega han mejorado enormemente y la calidad y fiabilidad
de los sistemas han aumentado.
En esta fase no es posible estar hacer un análisis definitivo hasta que no se haya
finalizado por completo la fase de elaboración. Por esta razón toma el nombre de análisis
inicial del negocio.
Las organizaciones deben guardar registros de las métricas adecuadas para la fase de
inicio. Estas cifras les proporcionarán una base para estimar cuales podrían ser las cifras
para las iteraciones en la fase de inicio de próximos proyectos.
Tampoco existe una fórmula clara para calcular las ganancias proporcionadas por el
software. En el caso en que el software vaya a ser puesto en el mercado, el número de
unidades vendidas, el precio, y el cuanto se prolongará las ventas son aspectos a ser
considerados por los expertos de ventas y serán juzgados por los ejecutivos.
Si el producto es de uso interno, solicite a los departamentos afectados que estimen
cuanto ahorro esperan conseguir. El margen de error es grande, pero al menos, la
estimación proporcionará una base para ponderar las ganancias frente a los costos.
Lo que necesitamos para concluir la fase de inicio no son cifras exactas, sino el
conocimiento de cómo el sistema está económicamente al alcance de la organización del
desarrollo y de sus clientes. Una vez completada toda la información esta fase debe
designar a un grupo de personas para evaluarla, en donde deberá incluir representantes
del cliente o los usuarios. Examine los objetivos de esta fase -ámbito, riesgos críticos,
arquitectura candidata- y decida continuar o finalizar. Pero esta decisión no es
arbitraria requiere la conformidad de las personas involucradas, en particular los
inversores y los representantes de los usuarios.

Diseño de Sistemas Página 6 de 23 UTN

Vínculo: Captura de Requisitos
El propósito fundamental del flujo de trabajo de los requisitos es guiar
correctamente al desarrollo de sistemas. Esto se consigue mediante una descripción de
los requisitos del sistema, condiciones o capacidades que el sistema debe cumplir.
Fundamentalmente el cliente debe ser capaz de leer y comprender los resultados de
la captura de requisitos. Para alcanzar este objetivo debemos utilizar el lenguaje del
cliente para describir estos resultados. Por ello deberemos tener mucho cuidado de
introducir en los resultados formalidades o estructuras cuando incluimos el
funcionamiento interno del sistema.
Existen diferentes puntos de partida para la captura de requisitos. En algunas
ocasiones comenzamos haciendo un modelo de negocio. En otros casos, el software es un
sistema empotrado que no da soporte directamente al negocio, comenzaríamos con el
modelo de dominio. O el cliente pudo haber desarrollado una especificación de requisitos
completa y detallada que no está basada en un modelo de objetos, a partir de cual
podemos comenzar y negociar los cambios.
Ciertos pasos son factibles en la mayoría de los casos y permiten crear un flujo de
trabajo arquetípico:
 Requisitos candidatos durante la vida del sistema los clientes, usuarios,
analistas y desarrolladores generan buenas ideas para convertirse en verdades
requisitos. Creamos una lista de ideas para contenerlas y su crecimiento o
descenso depende de alguna característica y su conversión en requisito
transformándose en otros aparatos como los casos de uso.
Podemos crear una lista característica y por cada una de ella posee un
nombre y una descripción con un conjunto de atributos: estado (propuesto,
aprobado, incluido o válido), costo estimado de implementación (tipos de
recursos y horas-hombre), prioridad (crítico, importante o secundario), nivel de
riesgo asociado a la implementación de la característica (crítico, significativo u
ordinario).
 Contexto del sistema existen por lo menos dos aproximaciones para expresar el
contexto de un sistema modelo de dominio y modelo de negocio. El modelo de
dominio describe conceptos importantes del contexto como objetos del negocio y
enlaza estos objetos con otros. El modelo de negocio puede describir los procesos
-existentes u observables- con el objetivo de comprenderlos estableciendo las
competencias requeridas en cada proceso: sus trabajadores, sus responsabilidades
y las operaciones que se realizan. Por supuesto este conocimiento es decisivo en
la identificación de casos de uso.
 Capturar requisitos funcionales la técnica utilizada para identificar los
requisitos del sistema se basa en los casos de uso, ya sean funcionales y no
funcionales específicos a cada caso de uso. Cada usuario maneja el sistema para
hacer algo y llevar a cabo cierto caso de uso. En consecuencia, si los analistas
pueden describir todos los casos de uso necesario para el usuario, entonces saben
lo que debe hacer el sistema.
Como accesorio de los casos de uso, los analistas deben especificar también
cuál será la apariencia de la interfaz gráfica cuando utilicen los casos de uso,
esbozar varias versiones mostrando cómo la información se transfiere, discutir
los esbozos con los usuarios y construir visualizaciones o prototipos concretos
para que los usuarios lo prueben.

Diseño de Sistemas Página 7 de 23 UTN

  Capturar requisitos no funcionales especifican las propiedades del sistema,
como restricciones del entorno o de la implementación, rendimiento,
dependencias de la plataforma, facilidad de mantenimiento, extensibilidad, y
fiabilidad.
Un requisito de rendimiento impone condiciones sobre los requisitos no
funcionales como la velocidad, rendimiento, tiempo de respuesta, y uso de
memoria. La mayoría de los requisitos de rendimiento afectan sólo a ciertos
casos de uso y por lo tanto deberían conectarse como valores etiquetados a ese
caso de uso.
Algunos requisitos no funcionales son más genéricos y no pueden
relacionarse con un caso de uso concreto o una clase concreta del mundo real.
Estos deberían gestionarse aparte en una lista de requisito adicionales.
Por lo tanto, las especificaciones de los requisitos tradiciones en el pasado son
reemplazadas por un conjunto de artefactos: el modelo de casos de uso y los requisitos
adiciones. Los artefactos necesarios para establecer el contexto del sistema son los
modelos de dominio y de negocio. Para controlar los requisitos utilizamos las iteraciones
reflejando los cambios en el conjunto de requisitos, y este número de cambios
normalmente disminuirán cuando comencemos a trabajar en la fase de la construcción a
medida que se estabilizan los requisitos.

Trabajo a realizar Artefactos resultantes

Enumerar requisitos candidatos Lista de características
Comprender el contexto del sistemas Modelo Dominio o Negocio
Capturar los requisitos funcionales Modelo Caso de Uso
Capturar los requisitos no funcionales Requisitos adicionales

 Modelo de Dominio
Un modelo de dominio captura los tipos más importantes de objetos en el contexto
del sistema, representando las cosas existentes o eventos que suceden en el entorno de
trabajo el sistema.
Podemos enumerar entre 10 a 50 clases de dominio para un sistema de tamaño
moderado. Los sistemas más grandes pueden involucrar más clases.
Las restantes clases serán incorporadas al artefacto glosario de términos caso
contrario se construiría un modelo de dominio demasiado difícil de comprender en esta
etapa del proceso de desarrollo del producto.
Muchas de estos objetos de dominio o clases se obtienen de la especificación de los
requisitos o mediante las entrevistas con los expertos del dominio. Los objetos de
dominio pueden ser clasificados en tres formas: objetos de negocio (representan las cosas
que se manipulas en el negocio, como ser pedidos, cuentas y contratos), objetos del
mundo real y conceptos de los que el sistema debe hacer un seguimiento (como la
aviación enemiga, misiles y trayectorias), sucesos a futuro o ocurridos (como la llegada
de un avión, su salida y la hora de comida).
El modelo de dominio se describe mediante diagramas de UML (especialmente
diagramas de clases).

Diseño de Sistemas Página 8 de 23 UTN

  Modelo de Negocio
El modelado del negocio es una técnica para comprender los procesos de negocio de
la organización. El objetivo es identificar los casos de uso del software y las entidades
del negocio relevantes que el software debe soportar.
El modelado del negocio está soportado por dos tipos de modelos UML: modelo de
casos de uso y modelos de objetos.
Describe cómo cada caso de uso de negocio es llevado a cabo por parte de un
conjunto de trabajadores para realizar un conjunto de entidades del negocio y de las
unidades de trabajo. Cada realización de un caso de uso de negocio puede mostrarse en
un diagrama de interacción y diagramas de actividad.
Una entidad del negocio representa algo, como una factura, los trabajadores la
crean, la toman, inspeccionan, manipulan, producen u utilizan en un caso de uso de
negocio. Una unidad de trabajo es un conjunto de entidades que conforman un todo
reconocible para un usuario final.
Cada trabajador, entidad de negocio, y unidad de trabajo pueden participar en más
de un caso de uso del negocio.
El modelo de negocio se desarrolla en dos pasos:
 Los modeladores del negocio deben confeccionar un modelo de casos de uso del
negocio para identificar los actores del negocio y los casos de uso del negocio
que utilicen los actores.
 Los modeladores deben desarrollar un modelo de objetos compuesto por
trabajadores, entidades del negocio, y unidades de trabajo que juntos realizan los
casos de uso del negocio. Se asocian a estos diferentes objetos las reglas del
negocio y otras impuestas por el negocio.
Las clases del dominio y las entidades del negocio son conceptos muy parecidos, y
utilizamos ambos términos indistintamente.

Existen algunas diferencias importantes entre los dos modelos:

 Las clases de dominio se obtienen de la base del conocimiento de unos pocos
expertos del dominio. Las entidades del negocio se derivan a partir de los clientes
del negocio identificando los casos de uso del negocio y después buscando
entidades, cada entidad debe venir motivada por su utilización en un caso de uso
del negocio.
 Las clases de dominio tienen atributos pero normalmente ninguna o muy pocas
operaciones. La técnica de modelado de negocio no sólo identifica a las entidades
sino que también a todos los trabajadores que participan en la realización de los
casos de uso del negocio utilizando a las entidades. Identifica cómo utilizarán
esos trabajadores las entidades a través de operaciones ofrecidas por cada
entidad.
 Los trabajadores identificados en el modelado del negocio se utilizarán como
punto de partida para derivar un primer conjunto de actores y casos de uso para el
sistema de información en construcción.

Diseño de Sistemas Página 9 de 23 UTN

  Búsqueda de casos de uso partiendo del modelo de
negocio
Para cada trabajador identificamos todas las relaciones de casos de uso del
negocio diferentes en las que participa. El trabajador cumple un papel en cada una
de forma similar al papel que desempeña una clase en cada realización de cada
caso de uso.
Una vez que hemos encontrado todos los papeles o roles de un trabajador o de
un actor del negocio, uno por cada caso de uso del negocio en el que participa,
podemos encontrar los casos de uso de los actores del sistema de información.
Cada trabajador y cada actor del negocio corresponde con un actor del sistema de
información. Por cada papel de un trabajador o actor del negocio necesitamos un
caso de uso.
Algunos requisitos no pueden asociarse a ningún caso de uso concreto y se
conocen como requisitos adicionales.
El problema de en esta fase será restringir el volumen de trabajo ignorar las
alternativas o caminos dentro de un caso de uso o los casos de uso no relevantes
para el ámbito del sistema o la arquitectura candidata, los que no planteen riesgos
críticos o los que tengan poco efecto en el análisis inicial de negocio.
Es posible planificar futuras iteraciones al mismo tiempo que se detallan los
casos de uso encontrados. Este plan de la iteración es el resultado final para
mostrar las prioridades de los casos de uso asociados al objetivo de esta fase.
Se especifican los casos de uso complejos para saber hacia donde nos
dirigimos, sin embargo se deberá tener en cuenta que no es necesario trabajar sobre
un gran número de casos de uso. Debido a que no se construye un prototipo de la
arquitectura en esta fase, no son necesarias las labores de implementación y
prueba.
Deberemos fraccionar una parte de los casos de uso, si hemos detectado un
50% del total de casos de uso y del mismo nos damos cuenta que solo es necesario
detallar un 20% habremos trabajado en detalle un 10%. Por estos motivos en esta
fase no es necesario estructurar los casos de uso.

 Requisitos Adicionales
Los requisitos adicionales se capturan de forma muy parecida a como se hacían
tradicionalmente con una lista de requisitos. Después se utilizan durante el análisis y el
diseño de casos de uso.
Un requisito de interfaz especifica la interfaz con un elemento externo con el cual
debe interactuar el sistema o se establecen restricciones condicionantes en formatos,
tiempos u otros factores de relevancia en esa interacción.
Un requisito físico especifica una característica física propia de un sistema, como su
material, forma, tamaño o peso. Por ejemplo para representar requisitos de hardware
como las configuraciones físicas de red requeridas.

 Artefactos
Los artefactos fundamentales son utilizados en la captura de requisitos en el modelo
de casos de uso que incluye los casos de uso y los actores pertenecientes al sistema.

Diseño de Sistemas Página 10 de 23 UTN

 Siendo posible manejar otros tipos de artefactos como ser prototipos de interfaz de
usuario.
También podría ser importante utilizar diagramas de actividad o diagramas de
estados para obtener una descripción formal de algunos casos de uso.

 Artefacto: Modelo de casos de uso

Sirve como un acuerdo entre clientes y desarrolladores, y proporcionan la
entrada fundamental para el análisis, diseño y las pruebas.
Un único modelo de casos de uso del sistema sería demasiado grande para
comprenderlo en su totalidad, por esta razón UP utiliza el artefacto paquete para
poder segmentarlo en porciones.

≈ Actor
El modelo de casos de uso describe lo que hace el sistema para cada tipo
de usuario. Cada uno de estos se representa mediante uno o más actores.
También se representa mediante uno o más actores cada sistema externo con
el que interactúa el sistema.
Un actor juega un papel por cada caso de uso con el que colabora. Cada
vez que un usuario en concreto (humano u otro sistema) interactúa con el
sistema una instancia correspondiente al actor está desarrollando ese papel.
Una instancia de un actor es por tanto un usuario concreto que interactúa con
el sistema.

≈ Caso de uso
Cada forma en que los actores usan el sistema se representa con un caso
de uso donde se especifica una secuencia de acciones que el sistema debe
llevar a cabo interactuando con sus actores, incluyendo alternativas de la
secuencia. Por lo tanto un caso de uso es una especificación. Especifica un
comportamiento de cosas dinámicas.
Un caso de uso es un clasificador para UML, el cual contiene
operaciones y atributos. Un caso de uso puede incluir diagramas (estados,
actividad, colaboración, secuencia y clases), modelo de casos de uso, archivos
y URL.
Los diagramas de estados especifican el ciclo de vida de las instancias de
los casos de uso en términos de estados y transiciones entre los estados. Cada
transición es una secuencia de acciones. Los diagramas de actividad muestran
el ciclo de vida con más detalle describiendo también la secuencia temporal
de acciones que tiene lugar dentro de cada transición, por ejemplo, una
instancia típica de un actor y una instancia de un caso de uso.

Diseño de Sistemas Página 11 de 23 UTN

 Una instancia de un caso de uso es una realización (o ejecución) de un
caso de uso, y está interactúa con instancias de actores y ejecuta una secuencia
de acciones según se especifica en el caso de uso. Esta secuencia se especifica
en un diagrama de estados o un diagrama de actividad, es un camino a lo
largo del caso de uso. Puede haber muchos caminos y muchos de ellos pueden
ser muy parecidos. Estas son alternativas de la secuencia de acciones para el
caso de uso. La mayoría de las veces es una instancia de un actor la que
invoca a la instancia del caso de uso, pero también puede ser un evento
interno al sistema el que invoque a la instancia, como cuando un temporizador
programado se dispara.
Los casos de uso tienen atributos y estos representan los valores de una
instancia de un caso de uso utilizada y manipulada durante la ejecución de su
caso de uso. Estos valores son locales a la instancia del caso de uso, es decir,
no pueden ser utilizados por otras instancias el caso de uso. Consideramos
atómicas a las instancias de caso de uso y cada una de ellas se ejecuta por
completo o no se ejecuta nada sin interferencias por partes de otras instancias
de otros casos de uso.
Sin embargo, existen temas de interferencias entre los diferentes casos de
uso de un sistema, pero estos no son resueltos en el modelado de casos de uso
sino que se posponen al análisis y diseño, en los cuales realizamos los casos
de uso como colaboraciones entre clases y/o subsistemas.

≈ Flujo de sucesos
Se plantea como una descripción textual de la secuencia de acciones de
un caso de uso, especifica lo que hace el sistema cuando se lleva a cabo el
caso de uso especifico y los actores que interviene con el mismo.

≈ Requisitos especiales
Es una descripción textual para agrupar todos los requisitos del tipo
requisitos no funcionales sobre el caso de uso y que deben tratarse en flujos
de trabajos posteriores como ser: análisis, diseño o implementación.

 Artefacto: Descripción de la arquitectura

La vista de arquitectura del modelo de casos de uso debe incluir los casos de
uso que describen alguna funcionalidad importante y crítica o que impliquen algún
requisito importante a ser desarrollado pronto dentro del ciclo de vida del software.
Esta vista se utiliza como entrada cuando se priorizan los casos de uso para su
desarrollo (análisis, implementación) dentro de cada iteración.

 Artefacto: Glosario
Podemos utilizar un glosario para definir términos comunes importantes
donde los analistas utilizan para describir el sistema. Habitualmente podemos
obtener un glosario a partir del negocio o de un modelo del dominio, pero cómo es
menos formal es más fácil de mantener y más intuitivo para utilizarlo con terceras
personas externas como usuarios o clientes, el mismo no incluye clases o
relaciones explícitas.

Diseño de Sistemas Página 12 de 23 UTN

  Artefacto: Prototipo de interfaz de usuario
Nos ayudan a comprender y a especificar las interacciones entre actores
humanos y el sistema durante la captura de requisitos. No solo nos ayuda a
desarrollar una interfaz gráfica mejor sino también a comprender los casos de uso.

 Trabajadores
Un trabajador es un puesto al cual se puede asignar uno o más personas. Con cada
trabajador tenemos una descripción de las responsabilidades y el comportamiento
esperado del mismo. Un trabajador no se corresponde a un cargo concreto de una
empresa porque representa una abstracción de un ser humano/s con ciertas capacidades
que se requieren en un caso de uso del negocio en UML para el desarrollo del software.
Una persona físicamente puede cumplir el rol de un o más trabajadores.

 Analista de sistemas
Es el responsable del conjunto de los requisitos a ser modelado en los casos
de uso, incluye todos los requisitos funcionales y no funcionales por medio de los
casos de usos. Tienen la responsabilidad de delimitar el sistema, encontrando los
actores y los casos de uso y asegurando cómo el modelo de casos de uso es
completo y consistente. Para la consistencia el analista puede utilizar un glosario
para conseguir un acuerdo de términos, nociones y conceptos durante la captura de
los requisitos.
El analista es responsable del modelo de casos de uso y de los actores que
contiene, no es responsable de cada caso de uso en particular. También es el
encargado de la creación del glosario.

 Especificador de casos de uso

Es responsable de especificar los casos de uso que le han sido asignado
teniendo que trabajar estrechamente con los usuarios reales de sus casos de uso.

 Diseñador de interfaces
Dan una forma visual a las interfaces de usuarios. Esto implica la
responsabilidad del desarrollo de prototipos de interfaces de usuarios para
algunos casos de uso dando forma a las interfaces de uno o más actores.

 Arquitecto
Responsable de la descripción de la arquitectura y del modelo de casos de
uso es una entrada importante para planificar las iteraciones.
No es responsable del desarrollo y mantenimiento continuo de los diferentes
artefactos del modelo de casos de uso.

Vínculo: Arquitectura Fase Inicio

Para presentar el sistema es muy útil visualizarlo desde diferentes perspectivas para
poder comprender mejor su diseño. Estas perspectivas son vistas del modelo, proyección
de un modelo visto desde un lugar estratégico omitiendo las entidades no relevantes para
esta perspectiva. Todas las vistas juntas representan la arquitectura.

Diseño de Sistemas Página 13 de 23 UTN

 La arquitectura abarca decisiones importantes: la organización del sistema de
software, los elementos estructurales y sus interfaces conjuntamente con sus
comportamientos. Tal y como se especifican en las colaboraciones entre estos elementos.
La composición de los elementos estructurales y del comportamiento en subsistemas
progresivamente más grandes.
La arquitectura no sólo se ve afectada por la estructura y el comportamiento, sino
también por el uso, la funcionalidad, el rendimiento, la flexibilización, la reutilización, la
facilidad de comprensión, las restricciones y compromisos económicos, tecnológicos y
de estética.
La descripción de la arquitectura incluye las vistas arquitectónicas de los modelos.
Vista arquitectónica, vista arquitectónica del modelo de uso de casos, vista arquitectónica
del modelo de análisis, vista arquitectónica del modelo de diseño, vista arquitectónica del
modelo de despliegue y vista arquitectónica del modelo de implementación.

 Comprensión de los sistemas

Para que una organización desarrolle un sistema debe ser comprendido por todos los
que vayan a intervenir en él.
Para comprender a los sistemas se debe contemplar varias razones: abarcan un
comportamiento complejo, operan en entornos complejos; son tecnológicamente
complejos, a menudo combinan procesamientos distribuidos con productos y plataformas
comerciales (sistemas operativos y gestores de bases), reutilizan comportamientos y
marcos de trabajos (micro-arquitectura que proporcionan una plantilla incompleta para
sistemas de un determinado dominio), deben satisfacer demandas individuales y de la
organización, y en algunos casos son tan grandes que deben ser divididos en varios
proyecto que además están a menudo en distintos lugares geográficos añadiendo
complejidad a la hora de coordinarlos.

 Organización del desarrollo

Cuanto mayor sea la organización del proyecto de software, mayor será la
sobrecarga de la comunicación entre los desarrolladores para intentar coordinar sus
esfuerzos. Dividiendo al sistema en subsistemas con las interfaces claramente definidas y
con un responsable o un grupo de responsables establecido en cada subsistema. Una
buena arquitectura define explícitamente estas interfaces reduciendo la comunicación.
Una buena interfaz bien definida comunica eficientemente a los desarrolladores de
ambas partes qué necesitan saber sobre lo que los otros equipos están haciendo.
Hay que prevenir estas posibles fallas comprendiendo correctamente al sistema. Los
diagramas de UML que se utilizan para describir la arquitectura ofrecen facilidad para
dicha comprensión.

 Fomento de la reutilización
Los componentes de software reutilizables están diseñados y probados para encajar,
y así el tiempo de construcción y los costos son menores. Una buena arquitectura ofrece a
los desarrolladores un andamio estable para trabajar. Un buen arquitecto es el responsable
de definir ese andamio y los subsistemas reutilizables que el desarrollador pueda utilizar.

Diseño de Sistemas Página 14 de 23 UTN

  Evolución del sistema
Los sistemas informáticos constantemente están evolucionando y los mismos
deberían ser capaces de implementar nuevas funcionalidades (es decir, casos de uso) en el
sistema sin tener que pensar en el impacto dramático sobre el diseño y la implementación
existente. Las arquitecturas pobres, por el contrario, suelen degradarse con el paso del
tiempo y necesitan ser parcheadas hasta el final siendo imposible arreglarlas con un
costo razonable.

 Arquitectura
La arquitectura esta condicionada por los casos de uso y ellos son los que la dirigen
el proceso de UML, pero a su vez la arquitectura guía a los casos de uso. Se seleccionan
los casos de uso más significativos, al principio unos pocos, para representar los casos de
uso arquitectónicos y poder brindar las necesidades del cliente en la próxima versión y
quizás futuras versiones. La arquitectura no solamente se ve afectada por estos casos de
uso también por otros factores:
 Cuáles son los productos de software que el sistema deberá necesitar para ser
desarrollado (Sistemas Operativos, Base de Datos, etc.).
 Cuales son los productos middleware capa intermedia, capa para ofrecer bloques
de construcción reutilizables (paquetes o subsistema) a marcos de trabajo y
servicios independientes de plataformas que queremos utilizar. Por ejemplo un
object request broker (ORB) para objetos distribuidos o interoperabilidad en
entornos heterogéneos.
 Que sistemas queremos heredar para utilizar en nuestro sistema, de ser así,
debemos tener en cuenta cual es nuestra arquitectura y poder encajar con el
producto antiguo.
 A que estándares y políticas corporativas debemos adaptarnos.
 Requisitos no funcionales generales (no específicos de los casos de uso), como
ser, los tiempos de recuperación o uso de memoria, etc.
 Las necesidades de distribuir el sistema, quizás a través de una arquitectura
cliente/servidor.
En esta etapa del proyecto trabajamos con las partes generales de la aplicación en
cuanto al dominio, y que no son específicas del sistema a desarrollar. Seleccionamos
software, middleware, los sistemas heredados, los estándares y las políticas de uso.
Decidimos cuales son los nodos, elemento físico que existe en tiempo de ejecución para
representar un recurso computacional con memoria y en general con capacidad de
procesamiento, contenidos en nuestro modelo de desarrollo y como deben interactuar. Y
decidimos también como manejar los requisitos no funcionales.

Vínculo: Gestión de Riesgos

Un riesgo es una exposición que nos puede acarrear pérdidas o daños. El riesgo es
un factor, cosa, elemento o camino que constituye un peligro cuyo grado es incierto.
UP trata los riesgos importantes en las dos primeras fases inicio y elaboración, y
cualquier riesgo restante al principio de las otras fases mediante iteraciones.
Durante estas iteraciones iniciales se empiezan a reducir riesgos importantes y
cuando se comienza a trabajar en la fase de construcción, quedan pocos riesgos

Diseño de Sistemas Página 15 de 23 UTN

 importantes y el trabajo prosigue sin problemas. En contraste si utilizamos el modelo de
cascada, los riesgos importantes no se tratan hasta la integración del código al estilo de
un "big bang".
La inversión realizada en estas etapas es menor comparada con las posteriores. Al
finalizar las primeras iteraciones podemos realizar la evaluación inicial de la arquitectura
y cambiar a la misma si observamos anomalías, siempre y cuando se ajusten a las
necesidades de los casos de uso y a los requisitos no funcionales.
A diferencia del método en cascada que descubrimos la necesidad de cambio en la
arquitectura cuando ya hemos invertido tanto en el desarrollo que hacer un cambio
produce costos considerables sin olvidarnos de la fecha de entrega. Quedando atrapados
en costos y calendario.
Desde la perspectiva de los usuarios es más productivo hacer evolucionar el
producto a lo largo de una serie de versiones ejecutables o "construcciones", que
presentar montañas de documentación difíciles de leer.
Al trabajar con iteraciones permitimos incorporar cambios que se adaptan a
necesidades mal informadas, olvidadas o cambios que debemos realizar. Si estos cambios
son incorporados cuando se realiza la prueba en cascada, el gran volumen de problemas y
la precipitación inevitable del momento producen retrasos, debido a que las soluciones
propuestas no han sido del todo bien pensadas. En consecuencia el desarrollo iterativo
termina en mucho menos tiempo que el desarrollo en cascada.
Identificamos, priorizamos y llevamos a cabo iteraciones sobre la base de los riesgos
y su orden de importancia.
Otros riesgos están basados en los requisitos adicionales, los cuales no son visibles
hasta que se implementa y prueba el software porque ejecutan las funciones subyacentes.
Por ello es necesario probarlos en las iteraciones de las fases de inicio y elaboración y
subsiguientes para poder acabar con los riesgos.
En principio todos los riesgos técnicos pueden hacerse corresponder con un caso de
uso o un escenario de un caso de uso. El riesgo se atenúa si se desarrolla el caso de uso
con sus requisitos funcionales y no funcionales. La reducción del riesgo es un eje de las
iteraciones que hacemos en las fases de inicio y elaboración, en la construcción los
riesgos se han reducido hasta un nivel de rutina.
Se han identificado cuatro categorías amplias:
 Riesgos relacionados con nuevas tecnologías: como ser trabajar por primera vez
con el paradigma orientado a objetos y el entrono de trabajo, lenguaje aplicado,
etc. Procesos distribuidos lo cual puede traer problemas de sincronización.
 Riesgos relativos a la arquitectura: mediante el establecimiento temprano de
una arquitectura se acomodan los riesgos, eliminamos el riesgo de no ser capaces
de incorporar fácilmente modificaciones. Marcos de trabajos planificados para su
reutilización y el riesgo reside en que un marco de trabajo no funcionará bien con
otro o que no sea fácil la reutilización. La nueva versión del sistema operativo
que se pretende utilizar puede no haber alcanzado el nivel de calidad necesario
para que confiemos en él.
 Riesgos relativos a construir el sistema adecuado: es decir, que cumpla con su
misión y sus usuarios. Este riesgo subraya la importancia de identificar los
requisitos funcionales y no funcionales, lo que significa identificar casos de uso
correctos con las interfaces de usuarios correctas.

Diseño de Sistemas Página 16 de 23 UTN

 Es necesario encontrar las funciones más importantes al principio para estar
seguros de que son implementadas correctamente, por esta razón ordenamos a los
casos de uso en grado de importancia relativa al cumplimiento de los clientes y
de los requisitos de rendimiento.
Por ejemplo un caso de uso determinado permite a un abonado redireccionar
sus llamadas a otro número, pero, hay que tener en cuenta cuales son las
llamadas a separar por ejemplo no se debe re-direccionar las llamadas del
despertador. El abonado probablemente querrá que esa llamada no se desvíe.
 Algunos riesgos relativos al rendimiento: el tiempo de respuesta debe ser menor
a 1 segundo, el número de instancias concurrentes de un caso de uso sobrepasa
los 100.000 en una hora.
Seguramente es probable que ninguna persona tenga la experiencia necesaria por lo
tanto se deberá estudiar el sistema por varias personas haciendo una lista de posibles
problemas y reuniéndose en sesiones de identificación de riesgos, simplemente se los
identifica y prioriza en el orden en que se van a ser estudiados en las iteraciones de las
dos primeras fases.
Algunos riesgos no técnicos pueden detectados y desviados. La organización a fecha
de hoy no cuenta con gente con experiencia en ciertos aspectos poco usuales del proyecto
cómo se la implementación de un lenguaje desconocido en algunas partes del sistema
propuesto. Se podrá cumplir con los plazos si terceras empresas subcontratadas pueden
entregar a tiempo ciertos subsistemas.
Una vez identificados y priorizados los riesgos el equipo decide que como tratarlos a
cada uno de ellos. Algunos pueden evitarse, quizás mediante una planificación o un
cambio de requisitos. Otros deberían limitarse, es decir, restringirlos y de ese modo solo
afecten a una pequeña parte el proyecto. Algunos pueden atenuarse observando su
comportamiento si aparecen o no y aprendiendo de ellos para encontrar una forma de
evitarlo, limitarlo o controlarlo.
Sin embargo hay riesgos que no pueden ser atenuados y lo único que se puede hacer
es controlarlo, por lo tanto el equipo debe seguir un plan de contingencia. De aparecer un
riesgo asesino se deberá abortar el sistema.
El controlar un riesgo implica la selección de un mecanismo de control, su puesta en
marcha, y su ejecución. Debido a que el tratamiento de los riesgos insume tiempo, una
organización raramente puede tratarlos todos a le vez. Este es el motivo por el cual es
necesaria la priorización en las iteraciones. Esto es lo que definimos como un desarrollo
iterativo dirigido por los riesgos. Y es una gestión de riesgos sólida.

Vínculo: Prototipar la Interfaz de Usuario

Se realiza en varios pasos. Primero comenzamos con los casos de uso e intentamos
discernir que necesitan las interfaces de usuarios para habilitar los casos de uso para cada
actor. Esto se realiza haciendo un diseño lógico de la interfaz de usuarios y después
creamos el diseño físico de la interfaz de usuario desarrollando unos prototipos para
ilustrar como pueden utilizarse por el sistema cuando los usuarios ejecutan los casos de
uso.
Cuando los actores interactúan con el sistema utilizarán y manipularán elementos de
interfaces de usuario para representar atributos de los casos de uso. Estos elementos
pueden ser íconos, listas de elementos u objetos de map en 2D. El diseñador de interfaces
identifica y especifica estos elementos actor por actor recorriendo todos los casos de uso

Diseño de Sistemas Página 17 de 23 UTN

 donde el actor puede acceder e identificando los elementos apropiados de la interfaz de
usuario para cada caso de uso.
Una forma práctica de trabajo es representar los elementos de la interfaz de usuario
mediante una nota adhesiva y posteriormente describir como pueden utilizar los actores
estos elementos cuando trabajan con los casos de uso. Asegurándose que cada caso de
uso es accesible a través de sus elementos de las interfaces de usuario.
Luego, se bosquejan elementos adicionales necesarios para combinar varios
elementos de interfaces de usuarios en interfaces completas. Estos elementos pueden
incluir contenedores de los elementos de la interfaz, ventanas, herramientas y controles.
Puede haber varios prototipos, quizás uno por cada actor para verificar cómo cada
actor puede ejecutar el caso de uso que necesita. Desarrollaremos prototipos ejecutables
de GUI cuando tenemos mucho que ganar en facilidad de uso, actores más importantes, y
utilizaremos bocetos cuando no tenemos tanto que ganar.
Las validaciones de las interfaces de usuarios a través de revisiones de prototipos y
esquemas en los primeros momentos pueden prevenir muchos errores que serán más
caros de corregir en etapas posteriores.

Vínculo: Flujo de Trabajo - Fase Inicio

Describimos los flujos de trabajos como una secuencia de actividades donde están
ordenadas y cada actividad produce una salida que sirve de entrada a la siguiente
actividad. Por lo general no es necesario trabajar mediante actividades en secuencia sino
que podemos trabajar por múltiples vías para producir un resultado final equivalente.
Una actividad puede ser retornada muchas veces y cada una de éstas puede acarrear
la ejecución de una sola fracción de la actividad.
Primero el analista debe estar seguro del modelo de casos de uso captura todos los
requisitos que son entradas del flujo de trabajo, es decir, la lista de las características y
el modelo de dominio y/o del negocio. Entonces el arquitecto identificará los casos de
uso relevantes arquitectónicamente hablando, para proporcionar entradas a la priorización
de los casos de uso (y posiblemente otros requisitos) que van a ser desarrollados en la
iteración actual. Los especificadores de casos de uso (varios individuos) describen todos
los casos de uso priorizados. Más tarde o paralelamente los diseñadores de interfaces
(varios individuos) sugieren interfaces de usuario adecuadas para cada actor basándose en
los casos de uso. Entonces el analista de sistema reestructura el modelo de casos de uso
definiendo generalizaciones entre los casos de uso para hacerlo más comprensible
posible.
Los resultados de la primera iteración a través de este flujo de trabajo consisten en
una primera versión del modelo de casos de uso, los casos de uso y cualquier prototipo
de interfaz de usuario aceptable. Los resultados de cualquier iteración subsiguiente
consistirán entonces en nuevas versiones de estos artefactos. Recordar que todos los
artefactos se complementan y mejoran incrementalmente a través de las iteraciones.

 Actividad

 Actividad: Encontrar actores y casos de uso

Algunas veces puede contamos con un modelo de negocio para iniciar el
modelo, si es así podemos preparar un primer borrador del modelo de casos de uso.
Otras veces podemos partir del modelo de dominio, el cual contiene una breve

Diseño de Sistemas Página 18 de 23 UTN

 explicación general o la especificación de los requisitos en forma detalla que
incluyan las características generales que se requieren. O tener como entrada los
requisitos adicionales que no se relacionan con ningún caso de uso específico.
Esta actividad consta de cuatro pasos los cuales no tiene por que ser
ejecutados en ningún orden particular y a menudo se hacen simultáneamente:
 Encontrar actores: depende del punto de partida. Si contamos con un
modelo de negocio el analista puede asignar un actor por cada trabajador
del negocio y un actor por cada actor del negocio. Si parte del modelo de
dominio el analista conjuntamente con el cliente identifica a los usuarios e
intenta organizarlos en categorías representadas por actores.
En ambos casos debemos identificar los actores para representar el
sistema externo y los actores para el mantenimiento y operación del
sistema.
El analista de sistema da nombres a los actores y describe brevemente
los papeles de cada actor y cómo el sistema utiliza al actor. La descripción
breve de cada actor debe esbozar sus necesidades y responsabilidades.
 Encontrar casos de uso: Se propone un caso de uso para cada rol de cada
trabajador que participa en la realización de casos de uso del negocio y que
utilizará información del sistema. En otros casos el analista va repasando
los actores uno por uno y proponiendo los casos de uso para cada actor por
medio de entrevistas.
El actor necesitará normalmente casos de uso para soportar su trabajo
de creación, cambio, rastreo, eliminación o estudio de los objetos del
negocio (como ser Pedidos, Cuentas, Orden de Entrada, etc.) utilizados en
los casos de uso del negocio. El actor también puede informar al sistema
acerca de algunos sucesos externos u otras formas de representación.
Puede también haber actores adicionales que inician el sistema, su
mantenimiento o terminación.
Elegimos un nombre para cada caso de uso de forma que nos haga
pensar en la secuencia de acciones concreta que añade valor a un actor. Por
lo general este nombre comienza con un verbo y debe referirse al objetivo
de la interacción entre el actor y el sistema.
Cuando decidimos si un caso de uso candidato debe ser caso de uso
como tal, debemos considerar si es completo por sí mismo o si siempre se
ejecuta a continuación de otro caso de uso. Hay que recordar que un caso
de uso entrega un resultado concreto que se puede observar, valor, a un
actor concreto.
 Describir brevemente cada caso de uso: Al principio cada caso de uso se
describe brevemente con algunas frases para resumir las acciones y más
tarde, con una descripción paso a paso de lo que el sistema necesita hacer
cuando interactúa con sus actores.
 Descripción del modelo de casos de uso en su totalidad: preparamos
diagramas y descripciones para explicar el modelo de casos de uso en su
totalidad, especialmente como se relacionan los casos de uso entre sí y con
los actores. El modelo de casos de uso requiere ser un modelo plan que
también puede organizarse en conjuntos de casos de uso llamados
paquetes de casos de uso.

Diseño de Sistemas Página 19 de 23 UTN

  Actividad: Priorizar los casos de uso
Priorizar los casos de uso determinando cuales son necesarios para el
desarrollo del sistema y los resultados se recogen de la vista de arquitectura
anteriormente comentada.

 Actividad: Detallar un caso de uso

El objetivo principal de detallar cada caso de uso es describir su flujo de
sucesos en detalle incluyendo cuando comienza, termina e interactúa con los
actores.
Un caso de uso define los estados de las instancias de los casos de uso que
pueden tener y la posible transición entre estos estados. Cada transición es una
secuencia de acciones a ser ejecutadas en una instancia del caso de uso cuando ésta
se dispara por efecto de un suceso (como podría ser un mensaje).
Debemos describir la posible transición de estados de manera simple y
precisa. Una técnica probada es elegir un camino básico completo (las flechas
rectas) desde el estado de inicio al estado final en una sección de la descripción. Y
luego describir en secciones diferentes el resto de los caminos alternativos o
desviaciones del camino básico. Si estas desviaciones son relativamente sencillas
se describen directamente en el camino básico. Recordar que el objetivo es hacer
una descripción precisa pero fácil de lectura.

La descripción de un caso de uso debe definir su estado inicial

(precondición), como y cuando comienza, el orden de las acciones, los posibles
estados finales (poscondición), los caminos no permitidos, la descripción de los
caminos alternativos, la interacción del sistema con los actores y que cambios
producen, la utilización de objetos, valores y recursos del sistema y explicitar que
hace el sistema.
Por lo general los casos de uso tienen pocos estados y no es necesario
explicitar cada uno de ellos. Pero en sistemas complejos de tiempo real si es
necesario poseer una descripción más estructura. La interacción entre los actores y
los casos de uso pueden transitar por varios estados y varias transiciones
alternativas que es casi imposible mantener consistente la descripción textual de
los casos de uso.
Se puede utilizar los diagramas de estados y los diagramas de actividad para
describir las transiciones entre estados, dependiendo de la complejidad, además
contamos con los diagramas de interacción para describir como interactúa una
instancia de caso de uso con la instancia de un actor reflejando el caso de uso y los
actores participantes. Algunas veces estos tipos de diagramas son muy largos,
difíciles de leerlos y entenderlos e insumen mucho tiempo de construcción y de
mantenimiento consistente con otros modelos. Se deben utilizar con cuidado

Diseño de Sistemas Página 20 de 23 UTN

 siendo aconsejable las descripciones simples y textuales porque con frecuencia son
suficientes.

 Actividad: Prototizar la interfaz de usuario

Este punto hace referencia al texto Prototipar la Interfaz de Usuario.

 Actividad: Estructurar el modelo de casos de uso

El analista puede reestructurar el conjunto completo de casos de uso para
hacer que el modelo sea más fácil de entender y de trabajar, buscando
comportamientos compartidos y extensiones.

≈ Generalización
A medida que identificamos y esbozamos las acciones de cada caso de
uso debemos también ir buscando acciones o partes de acciones comunes o
compartidas. Con el fin de reducir la redundancia utilizando la relación de
reutilización mediante una generalización (llamada relación de uso). La
generalización entre casos de uso es una clase de herencia para las instancias
de los casos de uso generalizados porque pueden ejecutar todo el
comportamiento descrito en el caso de uso generalizador.
Se emplea para simplificar la forma de trabajo y la compresión del
modelo de casos de uso y para reutilizar casos de uso semi-fabricados. Cada
caso de uso terminado se denomina caso de concreto. Los inicia un actor y
sus instancias constituyen una secuencia de acciones completas ejecutadas por
el sistema. El caso de uso semi-fabricado existe solamente para que otros
casos de uso lo reutilicen y se les llama casos de uso abstractos no puede ser
instanciado por sí mismo, pero, una instancia de un caso de uso concreto
contiene el comportamiento de un caso de uso abstracto que lo reutiliza
denominados a esta instancia caso de uso real que el actor(es) percibe cuando
interactúa con el sistema.

≈ Extensión
Se comporta como si fuera algo que se añade a la descripción original de
un caso de uso. Incluye tanto la condición para la extensión como la
referencia a un punto de extensión en el caso de uso destino, es decir, una
posición en el caso de uso donde se pueden hacer adiciones.
Los caso de uso reales se obtienen aplicando las relaciones de
generalización y extensión para utilizar casos de uso en el modelo. Y son los
aquellos que aportan valor a los usuarios.
Una vez identificados los casos de uso concretos, los abstractos y las
extensiones de los casos de uso podemos combinarlos para obtener un caso de
uso real. Sin embargo si el modelado es un nuevo sistema normalmente
seguimos el camino contrario porque comenzamos por los casos de uso reales
e identificando comportamientos comunes para distinguir a los casos de uso
concretos de los casos de uso abstractos. Y por los comportamientos
adicionales que tratamos como extensiones de otros casos de uso.

≈ Inclusión
Es una relación inversa a la de extensión porque proporciona una
extensión explícita e incondicional a un caso de uso. Cuando incluimos un

Diseño de Sistemas Página 21 de 23 UTN

 caso de uso la secuencia de comportamiento y los atributos se encapsulan y no
pueden modificarse o accederse a diferencia de las relaciones de
generalización.

≈ Relaciones
Debe tenerse en cuenta que la estructura de los casos de uso y sus
relaciones debe reflejar los casos de uso real tanto como sea posible. Cuanto
más alejadas están estas estructuras de los casos de uso real más complicado
será comprender los casos de uso y sus propósitos.
Cada caso de uso individual necesita ser tratados como un artefacto
individual. Por este motivo los casos de uso no deberían ser demasiados
grandes o demasiados pequeños conllevando así una sobrecarga de gestión
significativa.
Una buena práctica evita descomponer funcionalmente los casos de uso
en el modelo de casos de uso. Esto se hace mejor mediante el refinamiento de
cada caso de uso en el modelo de análisis porque la funcionalidad
perteneciente a los casos de uso se descompondrán a su vez en colaboraciones
de objetos de análisis conceptuales.

Vínculo: Planificación de la Fase Elaboración

Hacia el fin de esta fase podemos ser conscientes de los costos y del calendario de la
fase de elaboración. Intentaremos determinar alrededor del 80% de los requisitos;
trataremos de no pasar por alta nada que sea importante para la arquitectura. De este
80%, puede resultar necesario analizar el 50% para comprender correctamente los
requisitos.
Seleccionaremos la parte más significativa del conjunto total de casos, examinando
el 40% de los casos de uso y el 20% de cada uno de ellos. El producto de estos dos
porcentajes es un conjunto de casos de uso de solo el 8%. Usaremos esta fracción para
dirigir la línea base de la arquitectura incluyendo una descripción de la arquitectura y
versiones de todos los modelos.
La experiencia indica que gran parte el diseño y la implementación desarrolladas en
la fase de inicio, como los prototipos exploratorios y los usados para mostrar conceptos
no serán adecuados para utilizarlos en la fase siguiente.

Casos de Uso
Modelo de Descripción Casos de Uso Diseñado,
Fases Casos de Uso
Negocio Casos de Uso Analizados Implementado
s y Probados
Inicio 50-70% 50% 10% 5% Pequeño %
para prototipo
Elaboración Casi 100% 80% o + 40%-80% 20%-40% Menos del
10%
Construcción 100% 100% 100% 100% si se 100%
mantienen
Transición

Diseño de Sistemas Página 22 de 23 UTN

 Todas las personas involucradas en el proyecto deberían en este momento tener una
comprensión bastante clara del proyecto y su factibilidad para concluirlo en los tiempos
esperados.

Diseño de Sistemas Página 23 de 23 UTN