3.

Fase Elaboración
Al comienzo de esta fase recibimos de la primera fase un plan para la fase
elaboración, un modelo de casos de uso parcialmente completo y una descripción de la
arquitectura candidata, también contamos con un modelo de análisis y diseño
rudimentarios. Los cuales no sirven para ser reutilizados porque son tomados como guía
para elaborar con mayor profundidad a estos modelos sin llegar a ser completados en su
totalidad. Pero los mismos alcanzan para especificar la línea base de la arquitectura.
Detallamos este estudio en el párrafo que se describe el Análisis.
También podemos disponer de un prototipo para mostrar el funcionamiento del
sistema, debemos conocer cómo este prototipo ha sido diseñado solamente para mostrar
la funcionalidad primitiva del sistema y por lo tanto no se reutilizará.
Durante el diseño de la arquitectura recopilaremos, analizaremos, diseñaremos,
implementaremos y probaremos solamente aquellos requisitos relevantes desde el punto
de vista de la arquitectura. Apenas prestaremos atención a los detalles que no sean
significativos, postergándolos hasta la fase de la construcción. La línea base de la
arquitectura será simplemente un esqueleto.
El arquitecto establece la prioridad de los casos de uso y realiza la actividad de
análisis, diseño e implementación de la arquitectura del producto. Otros trabajadores
llevan a cabo actividades de diseño, analizarán clases y paquetes, y diseñarán las clases y
subsistemas.
Ahora no estamos buscando simplemente casos de uso para representar riesgos
críticos sino los casos de uso significativos desde el punto de vista de la arquitectura. En
esta fase se concluye con una línea base de arquitectura ejecutable, una línea base estable
sobre la que podamos añadir cosas en la fase de construcción.

3.1. Flujo de Trabajo

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

3.1.1. Requisitos
El analista de sistemas identifica casos de uso y actores adicionales de aquellos
identificados en la fase de inicio. Aunque es necesario comprender alrededor del 80% de
los casos de uso para alcanzar los objetivos de esta fase no es necesario detallar toda esa
cantidad. Por comprender queremos decir aprender lo que es significativo desde el punto
de vista de la arquitectura y estar seguros de no haber pasado nada por alto que pueda
tener un impacto en la arquitectura o la apuesta económica.
Los casos de uso son seleccionados dependiendo de su funcionalidad importante o
crítica o porque impliquen algún requisito importante que deba desarrollarse pronto
dentro del ciclo de vida del software. La vista de arquitectura utiliza a los mismos como
entrada cuando los casos de uso se priorizan para su desarrollo (análisis, diseño e
implementación) dentro de cada iteración. Para estructurar los analistas utilizan
mecanismos de extensión o de generalización, logrando una visión mucho la clara y fácil
de entender los casos de uso.

Marcelo Fabián Grispino Página 1 de 21 mgrispino@hotmail.com

3.1.2. Análisis
En esta sección abordaremos las actividades de análisis de la arquitectura analizando
un caso de uso, una clase y un paquete. En total podemos necesitar considerar el 50 por
ciento de los casos de uso detectados anteriormente.

3.1.3. Diseño
Es esta fase diseñaremos e implementaremos menos del 10 % de los casos de uso.
Solamente nos abocaremos a diseñar los casos de uso, clases y subsistemas que sean
arquitectónicamente significativos.
El arquitecto vuelve a considerar la capa software del sistema y la capa intermedia
seleccionando los productos que el va a utilizar finalmente.
Es necesario que trabaje en los niveles más altos de la arquitectura. Normalmente
intentará hacer de cada paquete de servicio del modelo de análisis un subsistema de
servicio en el diseño.
También traducirá las clases de análisis que sean interesantes desde el punto de vista
de la arquitectura y la describirá en la descripción de la arquitectura.
Deberá tomar contacto con las funcionalidades principales del sistema sobre su
concurrencia y distribución, estudiando los hilos y procesos necesarios y la red física de
procesadores y otros dispositivos. Transformará los objetos usados en los diagramas de
interacción en clases activas, las cuales serán asignadas a procesadores y otros
dispositivos.
Estos casos de uso significativos son diseñados en términos de subsistemas de
servicio y clases de diseño. Los paquetes y clases del análisis nos proporcionan una
forma directa de encontrar subsistemas y clases de diseño. Una vez encontrados
describiremos no sólo las responsabilidades que estos elementos de diseño deben asumir,
sino también el detalle de las interacciones entre ellos.
Diseñar las clases que participan en los casos de uso y sus conjuntos de escenarios
de realización significa detallar sin completar enteramente cada clase, ya que a su vez
estas mismas podrán participar en las futuras especificaciones de casos y sus
correspondientes escenarios de realizaciones.
Y los ingenieros de componentes diseñan los subsistemas resultantes del diseño de
la arquitectura.
Todos estos puntos serán expuestos detalladamente en la fase de construcción.

Marcelo Fabián Grispino Página 2 de 21 mgrispino@hotmail.com

3.1.4. Implementación
El resultado es la línea base de la arquitectura, implementada normalmente a partir
de menos del 10 % de los casos de uso.
Basándose en la vista de la arquitectura del modelo de diseño y la vista del modelo
de despliegue, se identifican los componentes necesarios para implementar los
subsistemas de servicio. Los componentes ejecutables se asignan a los nodos de la red de
computadores en la que van a ejecutarse.
En este flujo de trabajo los ingenieros de componentes implementarán estas clases
en términos de componentes. Y el responsable de integrar el sistema establece la
secuencia de integración en un plan de integración y a continuación integra los
subsistemas y los componentes correspondientes en una línea base de la arquitectura.
En estos momentos comenzamos a manejar versiones y por lo tanto se necesitarán
herramientas de control de configuración.

3.1.5. Pruebas
Empezar por las capas más bajas de la arquitectura significa probar los mecanismos
de distribución, almacenamiento, recuperación (persistencia) y concurrencia de objetos.
Lo que necesitamos probar que las capas superiores hacen uso de las inferiores.
Los ingenieros de pruebas seleccionarán los objetivos para evaluar la línea base de la
arquitectura. Tomando como base estos objetivos el ingeniero de pruebas evaluará los
casos de pruebas necesarios y preparará procedimientos de pruebas para comprobar la
sucesiva integración de los subsistemas hasta acabar con la línea base completa.
Estos ingenieros revisarán los resultados de las pruebas del sistema para verificar
cómo se cumplen los objetivos originales o para decidir cómo se deben modificar los
casos de pruebas con el objeto de alcanzar estos objetivos.
Todos estos puntos serán expuestos detalladamente en la fase de implementación.

3.2. Desarrollo del Análisis del negocio

Existen dos límites del negocio. Uno es la planificación, esfuerzo y costos estimados
para una calidad dada. El otro es la recuperación de la inversión indicando cómo el
sistema propuesto será económicamente un éxito.
Para hacer una estimación realista se deberá tener una buena apreciación del trabajo
definida en la fase de elaboración porque en ella se determina la línea base de la
arquitectura. También se deberá tener en cuenta la magnitud de los riesgos para ello
habrá que investigarlos hasta el extremo de estimar cuánto tiempo y esfuerzo llevará
superarlos.
También será necesario estudiar la recuperación de la inversión teniendo en cuenta la
particularidad de no existir una fórmula clara para calcular las ganancias que brindará el
software.
Si es un sistema que va a ser puesto en el mercado se deberá contemplar el número
de unidades vendidas, el precio a ser vendido y el período de tiempo que se prolongarán
las ventas.

Marcelo Fabián Grispino Página 3 de 21 mgrispino@hotmail.com

 Si es de uso interno solicite a los departamentos afectados que estimen el ahorro
esperado del mismo. Normalmente el margen de error es grande, pero, al menos la
estimación proporcionará una base para ponderar las ganancias frente a los costos.

3.2.1. Puntos Claves

 Un modelo completo de negocio.
 Una nueva versión de todos los modelos: casos de uso, análisis, diseño y
despliegue e implementación.
 Una línea de base de la arquitectura.
 Una descripción de la arquitectura.
 Una lista de riesgos actualizada.
 El plan del proyecto para las fases de construcción y transición.
 Un manual del usuario preliminar (opcional).
 El análisis de negocio completo, incluida la apuesta económica.

3.3. Ejemplificación
 Minuta 1.2.4.doc
Estructuración de los casos de uso desde el punto de vista del cliente
(funcional).
 Laboratorio 1.1.5.ea
En el interior del paquete (“Modelo Caso Uso - “Laboratorio” –
“Depósito”) podemos observar el modelo de caso de uso para dicho
departamento, el cual está basado en requerimientos definidos en el documento
("Minuta 1.2.4.doc").
En este modelo realizamos la estructuración conceptual del modelo de caso
de uso (“Laboratorio 1.1.4”) desde la perspectiva del usuario. Existen cuatro
paquetes reflejando el ingreso y egreso de los movimientos del sector y cuatro
paquetes para administrar los ingresos y egresos.
 Laboratorio 1.1.6.ea
La explicación de los diagramas de actividad complicaron el diálogo con los
usuarios, por lo tanto se construyeron dos cursogramas. En esta situación los
profesionales farmacéuticos poseían conocimientos administrativos
(organigramas, cursogramas, etc.) y a través de ellos se facilito el detalle de los
requerimientos del sistema.
En el modelo de casos de uso (“Modelo Caso Uso - “Laboratorio” –
“Depósito”) vemos la gráfica de colaboración (“Cursograma Ingreso Materia
Prima”) donde se detalla el movimiento de los documentos participantes en el
ingreso de materia prima.

Marcelo Fabián Grispino Página 4 de 21 mgrispino@hotmail.com

 También podemos observar otra colaboración (“Cursograma Egreso
Materia Prima”) y en ella se detalla el movimiento de los documentos
participantes en el egreso de la materia prima.
 Planificación 1.1.3.mpp
Podemos observar en la sección (“Fase de Elaboración”) cómo se ha
extendido el detalle de cada nueva actividad realizada.
 Minuta 1.2.5.doc
Se incorpora la funcionalidad de llamar a la Dirección de Planta antes de
rechazar un mercadería que intenta ingresar al Laboratorio.
 Laboratorio 1.1.7.ea
En el modelo de caso de uso se visualiza el paquete (“Laboratorio”) y en
su interior se encuentran tres paquetes: dos de ellos (“Modelo Caso Uso -
Laboratorio” y “Realización Caso Uso – Laboratorio <Análisis>”) se
localizan en su capa superior para especificar la aplicación, los cuales dependen
de la capa inferior (“Artefacto”) allí se detallan los elementos comunes de los
diferentes modelos que participan en más de un caso de uso o realización de caso
de uso de análisis.
A su vez podemos observar la dependencia de traza donde cada caso de uso
en el modelo de casos de uso tiene una relación con una colaboración en el
modelo de análisis.
En la versión “Laboratorio 1.1.6.ea” existe un paquete denominado
(“Laboratorio”) y en la versión “Laboratorio 1.1.7.ea” la denominación fue
modificada por (“Modelo Caso Uso –Laboratorio”), además tiene en su interior
un paquete (“Artefacto”) el cual se subió un nivel perteneciendo ahora al paquete
(“Modelo Caso Uso”) en la versión “Laboratorio 1.1.7.ea”. Y en esta última
versión se agrego el actor “Dirección Planta”.
 Recepcionar Materia Prima (Análisis).doc
En este documento detallamos del modelo anterior las instancias
(escenarios) de la realización del caso de uso (“Recepcionar Materia Prima
<Análisis>”). Por lo general se modelan y detallan los escenarios de
realizaciones de casos de uso importantes para el entendimiento del sistema.
 Glosario 1.1.4.doc
Ampliación de actores en la vista de caso de uso de Análisis.
 Dependencia 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 especifica dentro de cada caso de uso las entidades del
análisis utilizadas detallando: nombre de la entidad, su modo de acceso y el
nombre de paquete dueño de la entidad.
Por medio de este documento podemos declarar las dependencias entre los
paquetes de análisis que conforman el modelo.

Marcelo Fabián Grispino Página 5 de 21 mgrispino@hotmail.com

  Planificación 1.1.4.mpp
Podemos observar que en la sección “Fase de Elaboración” se ha extendido
el detalle del modelo de casos de uso y se crea la primera versión de la
realización de casos de uso de análisis (“Laboratorio 1.1.7.ea”) con su
respectivo archivo de dependencias (“Dependencia 1.2.1.doc””).
 Laboratorio 1.1.8.ea
En la sección (Use Case View) y en el interior del paquete (Depósito)
estudiamos y detallamos las dependencias entre los paquetes de análisis y los
paquetes de servicios opcionales.
En nuestro ejemplo especificamos dos paquetes de servicios opcionales
como globales (Mensaje y Anomalía). Mostrando en las realizaciones de caso de
uso los objetos de los paquetes de servicios opcionales para brindar soporte a los
paquetes de análisis.
 Dependencia 1.2.2.doc
Por medio de este documento podemos declarar las dependencias entre los
paquetes de servicios opcionales (globales) y los paquetes de análisis para
conformar el modelo.
 Planificación 1.1.5.mpp
En la sección ”Fase de Elaboración” se ha extendido el modelo de
realización de casos de uso (“Laboratorio 1.1.8.ea”) con su respectivo archivo
de dependencias (“Dependencia 1.2.2.doc”).
 Laboratorio 1.1.9.mdl
En nuestro ejemplo especificamos un paquete de servicio que encapsula
clases relacionadas denominado Stock. Mostrando en las realizaciones de caso
de uso los objetos de los paquetes de servicios que encapsula clases
relacionadas para brindar soporte a los paquetes de análisis.
 Glosario 1.1.5.doc
Ampliación de entidades históricas al conocer más detalle del negocio.
 Dependencia 1.2.3.doc
Por medio de este documento podemos declarar las dependencias entre los
paquetes de servicios que encapsulan clases relacionadas y los paquetes de
análisis para conformar el modelo. Además se agregó un nuevo paquete
(“Stock”) y en su interior se agregaron cuatro nuevos paquetes para administrar
la gestión de stock (“SMPC”, “SMPA”, “SPTC” y “SPTA”).
 Planificación 1.1.6.mpp
En la sección ”Fase de Elaboración” se ha extendido el modelo de
realización de casos de uso (“Laboratorio 1.1.9.ea”) con su respectivo archivo
de dependencias (“Dependencia 1.2.3.doc”). También fue necesario expandir el
glosario en (glosario 1.1.3.doc).
Se realiza una evaluación de esta fase y se detalla la planificación para la siguiente
fase.

Marcelo Fabián Grispino Página 6 de 21 mgrispino@hotmail.com

3.4. Planificación de la Fase de Construcción
El jefe de proyecto comienza a planificar la forma detallada de la primera iteración
de la fase de construcción y a esbozar en términos más generales las iteraciones restantes.
La lista de riesgos contendrá aún mucho más riesgos tratando de reducir los mismos
antes de que interrumpan la secuencia de construcción.
Al definir los subsistemas establecidos en la línea base de la arquitectura se tomarán
en cuenta sus interfaces que son el núcleo de dicha arquitectura. Con estos dos principios
subsistemas e interfaces estamos en condiciones de trabajar en paralelo.
Muchas veces las especificaciones de las interfaces son denominadas contratos
porque comprometen a los desarrolladores actuales con aquellos de los ciclos siguientes.
Se logra obtener una arquitectura estable cuando las interfaces están claramente
definidas.

Marcelo Fabián Grispino Página 7 de 21 mgrispino@hotmail.com

Vínculos

Vínculo: Análisis
Durante el análisis estudiamos los requisitos descriptos en la captura de requisitos
refinándolos y estructurándolos.
El objetivo de hacerlo es conseguir una comprensión más precisa de los requisitos y
una descripción de los mismos para que sea más fácil de mantenerlos y nos ayude a
estructurar el sistema entero, incluyendo su arquitectura.
Si conseguimos llegar a un acuerdo con el cliente sobre lo que debería hacer el
sistema es probable que aún queden aspectos sin resolver relativos a los requisitos del
sistema. Este es el precio que hay que pagar por el uso del lenguaje intuitivo pero
impreciso del cliente durante la captura de requerimientos. Para comunicarnos
eficientemente con el cliente debemos tener en claro:
 Los casos de uso deben mantenerse tan independientes unos de otros como sea
posible. Esto se consigue no quedando en detalles relativos a las interfaces,
concurrencias y conflictos entre los casos de uso cuando estos compiten por
recursos compartidos internos al sistema.
 Los casos de uso deben describirse utilizando el lenguaje del cliente. Esto se
consigue fundamentalmente mediante el uso del lenguaje natural en las
descripciones de casos de uso y siendo cuidadosos al utilizar notaciones más
formales, como un diagrama de estados o actividad o interacción.
 Deben estructurarse los casos de uso para poder armar una especificación de
funcionalidad completa e intuitiva reflejando los casos de uso reales que el
sistema proporciona. Por ejemplo, no deberían estructurarse en casos de uso
pequeños, abstractos y no intuitivo para minimizar redundancias. Por lo tanto, los
aspectos relativos a esas redundancias entre los requisitos descritos puede que
queden sin resolver durante la captura de requisitos.
En el análisis podemos razonar más los aspectos internos del sistema y por lo tanto
resolver los aspectos relativos a la interferencia de casos de uso. También podemos
utilizar un lenguaje más natural para reflejar los detalles relativos a los requisitos del
sistema.
Además en el análisis podemos estructurar los requisitos de manera que nos facilite
su comprensión, preparación, modificación y en general su mantenimiento. Esta etapa se
basa en clases de análisis y paquetes, la cual es independiente de la estructura que se dio
en los requisitos (basada en casos de uso).

Marcelo Fabián Grispino Página 8 de 21 mgrispino@hotmail.com

 Modelo de casos de uso Modelo de análisis
Descrito con el lenguaje del cliente. Descrito con el lenguaje del desarrollador.
Estructurado por los casos de uso, proporciona Estructurado por clases y paquetes
la estructura a la vista externa. estereotipados, proporciona la estructura de la
vista interna.
Utilizado fundamentalmente como contrato Utilizado por desarrolladores para comprender
entre el cliente y los desarrolladores sobre que como debería darse forma al sistema, es decir,
debería y que no debería hacer el sistema. como debería ser diseñado e implementado.
Puede contener redundancia, inconsistencia, No debería contener redundancia,
etc., entre requisitos. inconsistencia, etc., entre requisitos.
Captura la funcionalidad del sistema, incluida Esboza como llevar la funcionalidad dentro del
la funcionalidad significativa para la sistema, incluida la funcionalidad significativa
arquitectura. para la arquitectura. Sirve como primera
aproximación del diseño.
Define casos de uso que se analizarán con más Define relaciones de casos de uso, y cada una
profundidad en el modelo de análisis. de ellas representa el análisis de un caso de uso
del modelo de casos de uso.

Se basa en un modelo de objetos conceptuales, tratando de preservar esta estructura

a medida que damos forma al sistema y tomamos las decisiones sobre su diseño e
implementación. La razón por la cual esta conservación no siempre tienen lugar en la
práctica es sencillamente porque en el diseño se debe considerar la plataforma de
implementación, lenguaje de programación, sistemas operativos, marcos de trabajos
prefabricados, sistemas heredados, y demás. Por economía, puede conseguirse una
arquitectura mejor mediante la modificación de la estructura del modelo de análisis
durante la transición al modelo de diseño, al ir dando forma al sistema.
Es mejor no analizar los requisitos y al mismo tiempo diseñar e implementar.
Debido a que el diseño y la implementación son mucho más que el análisis (refinamiento
y estructuración de los requisitos) por lo que requieren una separación de intereses, ya
que los mismos deben tomar decisiones de rendimiento, distribución, como explotar de
manera eficiente (BD, ORB, como utilizar de manera eficiente el lenguaje de
programación, etc.).
El diseño e implementación se preocupa en realidad de dar forma al sistema de
manera de que dé vida a todos los requisitos, incluidos los no funcionales. Antes de
comenzar a diseñar e implementar deberíamos contar con una comprensión precisa y
detallada de los requisitos, un nivel de detalle que no preocupa al cliente.
Mediante la realización separada del análisis podemos analizar sin grandes costos
una gran parte del sistema. Y podemos después utilizar el resultado para planificar el
trabajo de diseño e implementación subsiguiente: quizás en varios incrementos sucesivos,
donde cada incremento solo diseña e implementa una pequeña parte del sistema o quizás
en varios incrementos concurrentes. Sin los resultados del análisis, la identificación y
planificación de estos incrementos puede ser más difícil de hacer.

Marcelo Fabián Grispino Página 9 de 21 mgrispino@hotmail.com

 El análisis proporciona una visión general del sistema sin ella puede ser más difícil
de obtenerla porque el estudio de resultados del diseño y la implementación contienen
demasiados detalles. Esta visión puede ser muy valiosa para los recién incorporados al
sistema o para los desarrolladores encargados de mantener el sistema.
Algunas partes del sistema tienen diseños y/o implementaciones alternativas. Por
ejemplo, sistemas críticos como el control aéreo o ferroviario pueden constar de varios
programas distintos para calcular concurrencias de operaciones, y solo se puede llevar a
cabo una maniobra importante si dichos cálculos arrojan los mismo resultados. El
modelo de análisis puede en este caso proporcionar una vista conceptual, precisa y
unificadora de estas implementaciones alternativas. En este caso el modelo de análisis
debería mantenerse a lo largo de la vida del sistema.
Si el sistema se construye utilizando un sistema heredado complejo. La reingeniería
de este sistema heredado puede hacerse en términos del modelo de análisis para que los
desarrolladores comprendan el sistema sin entrar en demasiados detalles de su diseño e
implementación.
Podemos decidir realizar o no el modelo de análisis teniendo en cuenta la gran
desventaja inexistencia del mismo, porque seguramente pasar directamente a la etapa del
diseño producirá mayores costos y la experiencia demuestra que solamente esto es
posible si los requisitos son simples y muy conocidos, o si el cliente es capaz de
comprender los resultados de los requisitos o si los desarrolladores cuentan con una cierta
comprensión intuitiva de los requisitos y son capaces de construir un sistema que los
encare de una manera bastante directa. Rara vez ocurre.
Luego nos queda por analizar si debemos sopesar las ventajas de mantener el
modelo análisis con el costo de mantenerlo durante varias iteraciones o generaciones. Por
lo tanto deberemos realizar un análisis costo/beneficio correcto.
Dentro del modelo de análisis los casos de uso se describen mediante clases de
análisis y sus objetos. Esto se representa mediante colaboraciones dentro del modelo de
análisis que llamaremos realizaciones de caso de uso de análisis.

 Artefactos

 Artefacto: Modelo de análisis

Dentro del modelo de análisis los casos de uso se describen mediante clases
de análisis y sus objetos. Esto se representa mediante colaboraciones dentro del
modelo de análisis llamadas realizaciones de caso de uso análisis.

 Artefacto: Clase de análisis

Una clase de análisis representa una abstracción de una o varias clases y/o
subsistema del diseño del sistema. Esta abstracción posee las siguientes
características:
- Se centra en los requisitos funcionales y pospone los no funcionales, a
menudo son utilizadas en el contexto del dominio. Definen
responsabilidades en un nivel bastante alto y menos formal, y cada
responsabilidad es una descripción textual de un conjunto cohesivo del
comportamiento de una clase.

Marcelo Fabián Grispino Página 10 de 21 mgrispino@hotmail.com

 - Los atributos definidos también son de un nivel bastante alto ya que son
conceptuales y los mismos pueden llegar a ser clases en el diseño e
implementación. Participan en relaciones las cuales son conceptuales
porque nos es importante definir las asociaciones con su navegabilidad.
- Por último estas clases encajan en uno de los tres estereotipos básicos:
interfaz, entidad o control. Cada estereotipo especifica una semántica
claramente definida lo cual constituye un método potente y consistente de
identificar y describir las clases de análisis contribuyendo a la creación de
un modelo de objetos y una arquitectura robusta.

≈ Clase interfaz
Estas clases se utilizan para modelar la interacción entre el sistema y sus
actores (usuarios y sistemas externos), clarifican y reúnen los requisitos en los
límites del sistema. Deben mantener un nivel conceptual describiendo lo que
se obtiene con la interacción (informaciones y peticiones que se intercambian
entre el sistema y sus actores). Sin ser necesario que se describan como se
ejecutan físicamente estas interacciones.
Las clases de interfaz a menudo representan abstracciones de ventanas,
formularios, paneles, interfaces de comunicación, interfaces de impresoras,
sensores, terminales y API.

≈ Clase entidad
Se utilizan para modelar información que posee una larga vida y que es a
menudo persistente. Modelando la información y el comportamiento asociado
de algún fenómeno o concepto. En la mayoría de los casos las clases entidad
se derivan directamente de una clase de entidad del negocio o domino
correspondiente.
Un objeto entidad no ha de ser necesariamente pasivo y puede tener en
ocasiones un comportamiento complejo relativo a la información que
representa. Las clases entidad suelen mostrar una estructura de datos lógica y
contribuyen a comprender cuál es la información dependiente el sistema.

≈ Clase control
Representan coordinación, secuencia, transacciones y control de otros
objetos, se usan con frecuencia para encapsular el control de un caso de uso
concreto. Las clases de control también se utilizan para representar
derivaciones y cálculos complejos que no pueden asociarse con ninguna
información concreta, de larga duración, almacenada por el sistema.
Los aspectos dinámicos del sistema se modelan con clases de control
porque ellas manejan y coordinan las acciones y los flujos de control
principales, delegando trabajo a otros objetos (interfaz y entidad).

Marcelo Fabián Grispino Página 11 de 21 mgrispino@hotmail.com

  Artefacto: Realización de un caso de uso análisis
Es una colaboración dentro del modelo del análisis para describir como se
lleva a cabo y se ejecuta un caso de uso determinado en términos de clases del
análisis y de sus objetos del análisis de interacción.
Una realización de caso de uso análisis proporciona una traza directa hacia un
caso de uso concreto. Posee una descripción textual del flujo de sucesos,
diagramas de clase que muestran las clases de análisis participantes y diagramas
de interacción para mostrar la realización de un flujo o escenario particular del
caso de uso.

≈ Diagramas de clases
Una clase de análisis y sus objetos normalmente participan en varias
realizaciones de casos de uso, y algunas de las responsabilidades, atributos y
asociaciones de una clase concreta suelen ser relevantes para una única
realización de caso de uso-análisis. De esta manera adjuntamos diagramas de
clases a las realizaciones de casos de uso, mostrando sus clases participantes y
sus relaciones.

≈ Diagrama de interacción
En los diagramas de colaboración, mostramos las interacciones entre
objetos creando enlaces entre ellos y añadiendo mensajes a esos enlaces. El
nombre del mensaje debería denotar el propósito del objeto invocante en la
interacción con el objeto invocado. Con los diagramas de colaboración en el
análisis podemos identificar requisitos y responsabilidades, y no identificar
secuencias de interacción detalladas y ordenadas cronológicamente (para ello
utilizamos diagramas de secuencias).
En relación con la creación y finalización de los objetos del análisis
dentro de la realización de un caso de uso podemos observar:
 Un objeto interfaz no tiene porque ser particular de una realización de
caso de uso, pero a menudo se crean y se finalizan dentro de una sola
realización
 Un objeto entidad suele tener una vida larga y participa en una o
varias realizaciones de caso de uso antes de su destrucción
 Un objeto de control suele encapsular el control asociado con un caso
de uso concreto, lo cual implica que debería crearse cuando el caso de
uso comienza y ese objeto de control debería destruirse cuando
termina el caso de uso. Sin embargo existen excepciones cuando
participa en más de un caso de uso, cuando existe más de un objeto
control para una realización de caso de uso o cuando una realización
de caso de uso no requiere ningún objeto control.

≈ Flujo de sucesos-análisis
Los diagramas, especialmente los de colaboración, dentro de una
realización de caso de uso pueden ser difícil de leer por sí mismo siendo
necesario acompañarlos con un texto adicional para explicarlos.

Marcelo Fabián Grispino Página 12 de 21 mgrispino@hotmail.com

 Este texto debería escribirse en términos de objetos y particularmente
objetos de control que interactúan para llevar a cabo el caso de uso. El mismo
no debería mencionar ninguno de los atributos, responsabilidades y
asociaciones del objeto porque cambian con bastante frecuencia y sería difícil
mantenerlos.

≈ Requisitos especiales
Los requisitos especiales son descripciones textuales que recogen todos
los requisitos no funcionales sobre una realización de caso de uso. Algunos de
estos requisitos ya se habían capturado pero los mismos pueden ser requisitos
nuevos o derivados encontrados a medida que avanza el trabajo de análisis.

 Artefacto: Paquetes de análisis

Proporcionan un medio para organizar los artefactos del modelo de
análisis en piezas más manejables conteniendo clases de análisis,
realizaciones de casos de uso y de otros paquetes de análisis.
Los paquetes de análisis deberían ser cohesivos (sus contenidos deberían
estar fuertemente relacionados), y deberían ser débilmente acoplados (sus
dependencias unos de otros deberían minimizarse). Los cuales se crean
basándose en los requisitos funcionales y en el dominio del problema
(aplicación o negocio) deberían ser reconocidos por las personas que poseen
conocimiento el dominio. Por lo general estos paquetes se convertirán en
subsistemas.

≈ Paquetes de servicios
Representa un conjunto coherente de acciones relacionadas
funcionalmente y utilizado en varios casos de uso. Un servicio es indivisible
porque el sistema necesita ofrecerlo todo entero o nada en absoluto.
En UML el concepto de servicio esta representado por los paquetes de
servicios los cuales se utilizan en un nivel más bajo, agregación de la
jerarquía de los paquetes de análisis para estructurar el sistema de acuerdo a
los servicios que brinda.
Contienen un conjunto de clases relacionadas funcionalmente, es
indivisible y cuando se lleva a cabo un caso de uso puede llegar a participar
uno o más paquetes de servicio. Además es frecuente que un paquete de
servicio concreto participe en varias realizaciones de caso de uso diferentes, y
generalmente es relevante para uno o pocos actores.
Cuando un paquete de servicio queda excluido también lo que todo caso
de uso cuya realización requiere el paquete. Pueden ser mutuamente
excluyentes o representar diferentes aspectos o variantes del mismo servicio,
por ejemplo corrección ortográfica del inglés británico y corrección
ortográfica del inglés americano.
Los subsistemas de servicios tienen una influencia decisiva en la
descomposición del sistema en componentes binarios y ejecutables. Tienen
muchas características buenas como ser: cohesivos, indivisibles, débilmente
acoplados, distribuidos de manera separada y haciéndolos principalmente
candidatos a ser reutilizados.

Marcelo Fabián Grispino Página 13 de 21 mgrispino@hotmail.com

 Los paquetes de servicio cuyos servicios se centran alrededor de una o
más clases de entidad, son probablemente reutilizables en diferentes sistemas
para soportar el mismo negocio o dominio.

 Artefacto: Descripción de la arquitectura

Contiene una vista de la arquitectura del modelo de análisis que muestra los
artefactos más significativos, estos son:
 La descomposición del modelo de análisis en paquetes de análisis y sus
dependencias. Esta descomposición suele tener su efecto en los
subsistemas de las capas superiores durante el diseño y la implementación
y es por lo tanto relevante para la arquitectura general.
 Las clases de análisis son un impacto importante, dentro de estas clases
podemos encontrar las clases (entidad, interfaz, control). Las clases del
análisis las cuales son generales, centrales y con muchas relaciones con
otras clases del análisis. Suele ser suficiente considerar para la arquitectura
una clase abstracta pero no sus subclases.
 Realizaciones de caso de uso para describir cierta funcionalidad importante
y crítica: que implican muchas clases de análisis y por tanto tiene una
cobertura amplia, posiblemente a lo largo de varios paquetes de análisis o
porque se centran en un caso de uso importante que debe ser desarrollado
al principio en el ciclo de vida del software y el mismo puede llegar a ser
encontrado en la vista de la arquitectura del modelo de casos de uso.

 Trabajadores

 Arquitecto
Durante el flujo de trabajo del análisis el arquitecto es responsable de la
integridad del modelo de análisis garantizando que éste sea correcto, consistente y
legible como un todo. Será responsable del paquete de nivel superior del modelo
de análisis conforme con la descripción de la arquitectura.
El modelo de análisis es correcto cuando realiza la funcionalidad descrita en
él modelo de casos de uso y solo esa funcionalidad. Es responsable de la
descripción de la arquitectura y del modelo de análisis.
No es responsable del desarrollo y mantenimiento continuo de los diferentes
artefactos del modelo de análisis.

 Ingeniero de casos de uso

Es el responsable de la integridad de una o más realizaciones de caso de
uso.
Una realización de caso de uso debe llevar a cabo correctamente el
comportamiento de su correspondiente caso de uso del modelo de casos de uso y
solo ese comportamiento.
Esto incluye garantizar que todas las descripciones textuales y los diagramas
que describen la realización del caso de uso sean legibles y se ajusten a su
objetivo.

Marcelo Fabián Grispino Página 14 de 21 mgrispino@hotmail.com

 No es responsable de las clases de análisis ni de las relaciones que se usan en
la realización del caso de uso. Posteriormente veremos cómo también será
responsable del diseño de las realizaciones de los casos de uso.

 Ingeniero de componentes
Es responsable de definir y mantener las responsabilidades, atributos,
relaciones y requisitos especiales de una o varias clases del análisis,
asegurándose cómo cada clase del análisis cumple con los requisitos esperados de
acuerdo a las realizaciones de caso de uso en las que participa.
Debe mantener la integridad de uno o varios paquetes del análisis. Esto
incluye garantizar sus contenidos: las clases y las relaciones deben correctas y las
dependencias entre otros paquetes del análisis también sean correctas y mínimas.
En general si es responsable de un paquete del análisis también lo será de las clases
de análisis contenidas en él. Posteriormente será responsable de los posibles
subsistemas que pueden llegar a estar conformados por los paquetes de análisis a
cargo de él.

Vínculo: Flujo de Trabajo - Fase Elaboración

Los arquitectos comienzan la creación del modelo de análisis identificando los
paquetes de análisis principales, las clases de entidades evidentes y los requerimientos
comunes. Después, los ingenieros de casos de uso realizan cada caso de uso en términos
de clases de análisis participantes exponiendo los requisitos de comportamiento de cada
clase. Los ingenieros de componentes especifican posteriormente estos requisitos y los
integran dentro de cada clase creando responsabilidades, atributos y relaciones
consistentes para cada clase.

 Actividad

 Actividad: Análisis de la arquitectura

Toma como entrada el modelo de casos de uso, los requisitos adicionales, el
modelo de negocio y/o dominio y la arquitectura candidata. Para esbozar el modelo
de análisis y la arquitectura mediante la identificación de paquetes de análisis,
clases de análisis evidentes y requisitos especiales comunes.

≈ Identificación de paquetes del análisis

Proporcionan un medio para organizar el modelo de análisis en piezas
más pequeñas y más manejables. Se pueden identificar inicialmente como una
forma de dividir el trabajo de análisis o encontrarse a medida que el modelo
de análisis crece convirtiéndose en una gran estructura que debe
descomponerse.
Esta descomposición se realiza de manera natural basándose en los
requisitos funcionales y en el dominio del problema. Esta división se puede
llegar a dar por casos de uso requeridos a un soporte a un determinado
proceso de negocio, casos de uso requeridos a un determinado actor del
sistema, casos de uso relacionados mediante relaciones de generalización y de
extensión. Este tipo de conjunto de casos de uso es coherente porque los casos
de uso o bien se especializan o bien se extienden.

Marcelo Fabián Grispino Página 15 de 21 mgrispino@hotmail.com

 Con frecuencia se puede llegar a encontrar aspectos comunes entre
paquetes. Por ejemplo cuando uno o más paquetes de análisis necesitan
compartir la misma clase de análisis, se puede extraer la clase compartida
colocarla dentro de su propio paquete o simplemente fuera de cualquier otro
paquete y después que los otros paquetes sean dependientes de este paquete o
clase general.
Por lo general las clases de compartidas tienen una relación de traza
directa con las clases de entidades del dominio o las clases de entidad del
negocio. Por este motivo podemos partir inicialmente para que identifiquen
paquetes de análisis tentativos.

Cliente
Pagar Enviar Enviar aviso Cuenta de Pago
Factu Factura

Gestión Facturas Gestión Facturas Gestión de Gestión de

de Comprador de Vendedor Cuenta Clientes de
Pago

Identificación de paquetes de análisis Identificación de paquetes de análisis

a partir de los casos de uso a partir de clases dominio o negocio

≈ Identificación de paquetes de servicio opcionales

La identificación de los paquetes de servicio opcional se suele hacer
cuando el trabajo de análisis está avanzado, momento en el cual los requisitos
funcionales se comprenden bien y existen la mayoría de las clases del análisis.
Identificar el paquete por cada servicio opcional y cada uno de ellos será
una unidad de compra. Por ejemplo si debemos enviar avisos en forma
automática o manual, podemos contar con un paquete de servicio opcional
avisos automáticos y otro paquete de servicio opcional avisos manuales.

Enviar
aviso
Gestión de Facturas
de Vendedor

<<service package>> <<service package>>

Avisos Avisos
Automáticos Manuales

Marcelo Fabián Grispino Página 16 de 21 mgrispino@hotmail.com

 ≈ Identificación de paquetes de servicio que encapsula
clases relacionadas funcionalmente
Identificar paquetes de servicio analizando si los servicios brindados
están vinculados a clases relacionadas funcionalmente entre sí: un cambio en
A producirá muy probablemente un cambio en B, la eliminación de A hace
que sea innecesario contar con B por ende que sea superflua. Los objetos de A
interactúan intensamente con los objetos B, posiblemente a través de
mensajes.

<<service package>>
Gestión de Cuentas

<<service package>> <<service package>>

Cuentas Riesgos

Cuenta Transferencias
entre cuentas Estimación
Historia de Riesgo
de riesgos
Cuenta

Estos dos paquetes de servicio Cuentas y Riesgos tienen cada uno de

ellos clases relacionadas funcionalmente.

≈ Definición de dependencias entre paquetes del análisis

Deberían definirse dependencias entre los paquetes del análisis si sus
contenidos están relacionados. La dirección de la dependencia debe ser la
misma dirección de relación (navegabilidad).
El objetivo es conseguir paquetes que sean relativamente independientes
y débilmente acoplados pero que posean una alta cohesión interna. La
cohesión alta y el acoplamiento débil permite que los paquetes sean más
fáciles de mantener, porque de cambiar alguna clase del paquete afectará a
clases dentro del mismo paquete. Intentar reducir el número de relaciones
entre clases de paquetes diferentes evita la dependencia entre paquetes.
Generalmente se modela los paquetes de análisis graficando a los
paquetes específicos de la aplicación en una capa de nivel superior y los
paquetes generales queden en una capa inferior.

Gestión Facturas Gestión Facturas

de Comprador de Vendedor

Gestión de
Cuentas

Marcelo Fabián Grispino Página 17 de 21 mgrispino@hotmail.com

 Como podemos observar el paquete Gestión de Cuentas contiene
internamente la clase Cuenta, por tales motivos los paquetes Gestión de
Facturas de Comprador y Gestión de Facturas de Vendedor dependen del
paquete Gestión de Cuentas.

≈ Identificación de clases de entidades obvias

Generalmente podemos encontrar en 10 o 20 clases más importante en el
modelo de dominio o el modelo de negocio. Sin embargo la mayoría de las
clases serán identificadas al crear las realizaciones de casos de uso en el
modelo de análisis. Una clase que no participa en ninguna realización de
casos de uso no es necesaria.
Las agregaciones y asociaciones entre clases del dominio del modelo de
dominio o las entidades de negocio del modelo de negocio, pueden ser
utilizadas para identificar un conjunto provisional de asociaciones entre las
correspondientes clases de entidad.

≈ Identificación de requisitos especiales comunes

Un requisito especial es un requisito detectado durante el análisis para ser
posteriormente tratado en las próximas actividades de diseño e
implementación. Como ser: persistencia, distribución y concurrencia,
características de seguridad, tolerancia a fallos y gestión de las
transacciones.
Deberían identificarse las características fundamentales de cada requisito
especial para soportar mejor el diseño y las implementaciones posteriores.

 Actividad: Analizar un caso de uso

≈ Identificación de clases de análisis

Utilizamos como entrada el modelo de casos de uso, los requisitos
adicionales, el modelo de negocio y/o dominio y la descripción de la
arquitectura desde el punto de vista del modelo de análisis para poder
identificar las clases (control, entidad e interfaz) necesarias para realizar los
casos de uso y esbozamos nombre, responsabilidades, atributos y relaciones.
Para poder realizar este procedimiento podemos utilizar normas
generales:
 Identificar clases de entidad, y después considerar que información
debe utilizarse y manipularse en la realización del caso de uso.
 Identificar una clase interfaz central para cada actor humano, y dejar
que esta clase represente la ventana principal de interfaz de usuarios
con el cual el actor interactúa. Las cuales se consideran agregados de
las clases de interfaz primitiva.
 Identificar una clase de interfaz primitiva para cada clase de entidad
que hayamos encontrado anteriormente.
 Identificar una clase interfaz central para cada actor que sea un
sistema externo, y dejar que esta clase represente la interfaz de
comunicación.

Marcelo Fabián Grispino Página 18 de 21 mgrispino@hotmail.com

  Identificar una clase control responsable del tratamiento del control y
de coordinación de la realización de caso de uso. En algunos casos el
control se encapsula mejor dentro de una clase de interfaz,
especialmente si el actor maneja gran parte del control evitando de
esta manera la creación de una clase control. En otros casos el control
es tan complejo que es mejor encapsularlo dentro de dos o más clases
control.
Deberemos construir en un diagrama de clases las clases del análisis
participantes en una realización de caso de uso. Utilizaremos este diagrama
para mostrar las relaciones utilizadas en la realización del caso de uso.

≈ Descripción de interacciones entre objetos del análisis

Cuando tenemos un esbozo de las clases necesarias para realizar el caso
de uso, debemos describir como interactúan sus correspondientes objetos de
análisis. Si el caso de uso tiene flujos o sub-flujos diferenciados y distintos
suele ser útil crear un diagrama de colaboración para cada flujo. En los
diagramas de colaboración podemos observar:
 El caso de uso se invoca mediante un mensaje proveniente de una
instancia de un actor sobre un objeto interfaz.
 Cada clase del análisis identificada en el paso anterior debería tener al
menos un objeto participante en el diagrama de colaboración.
 Los mensajes no se asocian a operaciones debido a que no
especificamos operaciones en las clases de análisis. Un mensaje
debería reflejar el propósito y este propósito es el origen de una
responsabilidad.
 Los enlaces en el diagrama normalmente deben ser instancias de
asociaciones entre clases de análisis y deberían mostrarse en el
diagrama de clases asociado en la realización del caso de uso.
 La secuencia en el diagrama no debería ser nuestro principal objetivo
y puede eliminarse si es difícil de mantener o crea confusiones en el
diagrama.
En algunos casos es apropiado complementar el diagrama de
colaboración con descripciones textuales, especialmente si el mismo caso de
uso tiene muchos diagramas de colaboraciones que le describen o si hay que
representar flujos complejos.

≈ Captura de requisitos especiales

En este paso recogemos todos los requisitos sobre una reutilización de
casos de uso identificados en el análisis pero deberían tratarse en el diseño y
en la implementación, tales como los requisitos no funcionales.

Marcelo Fabián Grispino Página 19 de 21 mgrispino@hotmail.com

  Actividad: Analizar una clase

≈ Identificar responsabilidades
Las responsabilidades de una clase pueden obtenerse combinando todos
los roles que cumple en las diferentes realizaciones de caso de uso. Podemos
identificar todas las realizaciones de caso de uso en las cuales participa la
clase mediante el estudio de clases y diagramas de interacción.

≈ Identificación de atributos
Un atributo especifica una propiedad de una clase del análisis y
normalmente es necesaria para las responsabilidades de su clase.
 Un atributo debe posee un nombre. Los atributos de una clase entidad
suelen ser bastantes evidentes.
 El tipo debería ser conceptual en el análisis no debería verse
restringido por el entorno de implementación. Al decidir su tipo
debemos intentar reutilizar uno ya existente.
 Si una clase de análisis se hace demasiado difícil de entender por sus
atributos algunos de estos atributos debería separarse en una clase
independiente.
 Los atributos de las clases de interfaz que interactúan con los actores
humanos, suelen representar elementos de información manipulados
por los actores.
 Los atributos de las clases control son poco frecuentes debido a su
corto tiempo de vida. Sin embargo, las clases control pueden poseer
atributos para representar valores acumulados o calculados durante la
realización de un caso de uso.
 Si una clase tiene muchos atributos o atributos complejos podemos
representarlos en un diagrama de clases aparte, que solo muestre la
sección de atributos.

≈ Identificación de asociaciones y agregaciones

Los objetos del análisis interactúan unos con otros mediante enlaces en
los diagramas de colaboración. Los enlaces pueden implicar la necesidad de
referencias y agregaciones entre objetos.
Deberíamos minimizar el número de relaciones entre clases. En el
análisis el centro de atención no debería ser el modelado de rutas de
búsquedas óptimas a través de las asociaciones o agregaciones. Esto es mejor
tratarlo durante el diseño y la implementación.

≈ Identificación de generalizaciones
Las generalizaciones deberían utilizarse durante el análisis para extraer
comportamiento compartido y común entre varias clases de análisis
diferentes, deberían mantenerse en un nivel alto y conceptual, y su objetivo
fundamental debería ser hacer el modelo de análisis más fácil de comprender.

Marcelo Fabián Grispino Página 20 de 21 mgrispino@hotmail.com

 Durante el diseño ajustaremos las generalizaciones para que encajen
mejor con el entorno de implementación elegido, es decir con el lenguaje de
programación. Una generalización podría desaparecer y convertirse en su
lugar en otra relación como una asociación.

≈ Captura de requisitos especiales

Recogeremos todos los requisitos de una clase del análisis identificados
en el análisis pero que deberían tratarse en el diseño y en la implementación
(los requisitos de una clase no funcionales). Como ser: rango de tamaño,
volumen, frecuencia de actualización (creación/borrado, actualizaciones,
lectura).

 Actividad: Analizar un paquete

Garantizar que el paquete del análisis es tan independiente de otros paquetes
como sea posible cumpla con su objetivo de realizar algunas clases del dominio o
casos de uso, describir las dependencias de forma para poder estimar el efecto de
los cambios futuros.
Para poder realizar las garantías anteriormente mencionadas se deberá definir
y mantener las dependencias del paquete con otros paquetes cuyas clases
contenidas estén asociadas a él y asegurarse cómo el paquete contiene las clases
correctas. Intentar hacer cohesivo el paquete incluyendo solo objetos relacionados
funcionalmente. Limitar las dependencias con otros paquetes. Considerar la
reubicación de aquellas clases contenidas entre los paquetes que son demasiado
extensos.

Dependientes de otros paquetes.

Gestión Facturas de Gestión Facturas de

Vendedor Vendedor
Requiere

Gestión de Cuentas Gestión de Cuentas

Cuenta Cuenta

Dependencias necesarias entre paquetes sugieren acciones en una descripción

de la evaluación de la prueba.

Marcelo Fabián Grispino Página 21 de 21 mgrispino@hotmail.com