FLUJO DE ANALISIS

ANLISIS
Durante el anlisis, analizamos los requisitos que se describieron en la captura de requisitos, refinndolos y
describindolos.
En el anlisis podemos razonar ms sobre los aspectos internos del sistema, y por tanto resolver aspectos
relativos a la interferencia de casos de uso y dems. Tambin podemos utilizar un lenguaje ms formal para
apuntar detalles relativos a los requisitos del sistema. Llamaremos a esto refinar los requisitos.
Breve comparacin del modelo de casos de uso con el modelo de anlisis
Modelo de Casos de uso
Modelo de anlisis
Descrito con el lenguaje del cliente
Descrito con el lenguaje del desarrollador
Vista externa del sistema

Vista interna del sistema

Estructurado por los casos de uso;

proporciona la estructura a la vista externa

Estructurado
por
clases y paquetes
estereotipados; proporciona la estructura a la
vista interna

Utilizado fundamentalmente como contrato

entre el cliente y los desarrolladores sobre
qu debera y qu no debera hacer el
sistema

Utilizado
fundamentalmente
por
los
desarrolladores para comprender cmo
debera darse forma del sistema, es decir,
cmo debera ser diseado e implementado

Puede
contener
redundancias,
inconsistencias, etc., entre requisitos.

No
debera
contener
redundancias,
inconsistencias, etc., entre requisitos

Captura la funcionalidad del sistema, incluida

la funcionalidad en el modelo de anlisis

Esboza cmo llevar a cabo la funcionalidad

dentro del sistema, incluida la funcionalidad
significativa para la arquitectura; sirve como
una primera aproximacin al diseo

Define casos de uso que se analizarn con

mas profundidad en el modelo de anlisis

Define realizaciones de casos de uso, y cada

una de ellas representa el anlisis de un caso
de uso de uso del modelo de casos de uso

Artefactos y trabajadores implicados en el anlisis.

LSC. ANA ELENA COTA RAMIREZ

Pgina 1

FLUJO DE ANALISIS
ARTEFACTO: MODELO DE ANLISIS
El modelo de anlisis se representa mediante un sistema de anlisis que denota el paquete de ms alto nivel
del modelo. La utilizacin de otros paquetes de anlisis es por tanto una forma de organizar el modelo de
anlisis en partes manejables que representan abstracciones de subsistemas y posiblemente capas
completas del diseo del sistema. Las clases de anlisis representan abstracciones de clases y posiblemente
de subsistemas del diseo del sistema. Dentro del modelo de anlisis, los casos de uso se describen
mediante clases de anlisis y sus objetos. Esto se representa mediante colaboraciones dentro del modelo de
anlisis que llamamos realizaciones de caso de uso-anlisis.

ARTEFACTO: CLASES DE ANALISIS

Una clase de anlisis representa una abstraccin de una o varias clases y/o subsistemas del diseo del
sistema. Esta abstraccin posee las siguientes caractersticas:
-

Una clase de anlisis se centra en el tratamiento de los requisitos funcionales y pospone los no
funcionales, denominndolos requisitos especiales, hasta llegar a las actividades de diseo e
implementacin subsiguientes.
Esto hace que una clase de anlisis sea ms evidente en el contexto del dominio del problema, ms
conceptual, a menudo de mayor granularidad que sus contrapartidas de diseo e implementacin.
Una clase de anlisis raramente define u ofrece un interfaz en trminos de operaciones y de sus
signaturas. En cambio, su comportamiento se define mediante responsabilidades en un nivel ms
alto y menos formal. Una responsabilidad en una descripcin textual de un conjunto cohesivo del
comportamiento de una clase.
Una clase de anlisis define atributos, aunque esos atributos tambin son de un nivel bastante alto.
Normalmente los tipos de esos atributos son conceptales y reconocibles en el dominio del problema,
mientras que los tipos de los atributos en las clases de diseo y la implementacin suelen ser tipos
de lenguaje de programacin. Adems, los atributos identificados durante el anlisis con frecuencia
pasan a ser clases en el diseo y la implementacin.
Una clase de anlisis participa en relaciones, aunque esas relaciones son ms conceptuales que sus
contrapartidas de diseo e implementacin. Por ejemplo, la navegabilidad de las asociaciones no es
muy importante en el anlisis, pero es fundamental en el diseo, o por ejemplo, pueden utilizarse
generalizaciones durante el anlisis, pero podra no ser posible utilizarlas en el diseo si no las
soporta el lenguaje de programacin.
Las clases de anlisis siempre encajan en uno de tres estereotipos bsicos de interfaz, de control o
de entidad. Cada estereotipo implica una semntica especfica, lo cual constituye un mtodo potente
y consistente de identificar y describir las clases de anlisis y contribuye a la creacin de un modelo
de objetos y una arquitectura robustos. Sin embargo es mucho ms difcil estereotipar las clases de
diseo e implementacin de esta manera clara e intuitiva. Debido a que tratan requisitos no
funcionales, estas ultimas viven en el contexto de un dominio de la solucin, y a menudo se
describen mediante sintaxis de lenguajes de programacin y tecnologas similares de bajo nivel.

LSC. ANA ELENA COTA RAMIREZ

Pgina 2

FLUJO DE ANALISIS
UML proporciona tres estereotipos de clases estndar que podemos utilizar en el anlisis:
Clases de interfaz.- Se utilizan para modelar la interaccin entre el sistema y sus actores. Esta interaccin a
menudo implica recibir informacin y peticiones de los usuarios externos.
Las clases de interfaz modelan las partes del sistema que dependen de sus actores, lo cual implica que
clarifican y renen los requisitos en los limites del sistema. Por tanto, un cambio en un interfaz de usuario o
en un interfaz de comunicaciones que da normalmente aislado en una o mas clases de interfaz.
Las clases de interfaz representan a menudo abstracciones de ventanas, formularios, paneles, interfaces de
comunicaciones, interfaces de impresoras, sensores terminales. Es suficiente con que las clases de interfaz
describan lo que se obtiene con la interaccin. No es necesario que describan como se ejecuta fsicamente la
interaccin, ya que esto se considerara en las actividades de diseo e implementacin subsiguiente.
Las clases de interfaz debera asociarse con al menos un actor y viceversa.
Clases de entidad.- se utilizan para modelar informacin que posee una vida larga y que es a menudo
persistente. Las clases de entidad modelan la informacin y el comportamiento asociado de algn fenmeno
o concepto, como una persona, objeto del mundo real o un suceso del mundo real.
En la mayora de los casos, las clases de entidad se derivan directamente de una clase de entidad del
negocio (o de una clase del dominio) correspondiente, tomada del modelo de objetos del negocio (o del
modelo de dominio).
Las clases de entidad suelen mostrar una estructura de datos lgica y contribuyen a comprender de qu
informacin depende el sistema.
Clases de control.- Representan coordinacin, secuencia, transacciones y control de otros objetos y se usan
con frecuencia para encapsular el control de un caso de uso en concreto. Las clases de control tambin se
utilizan para representar derivaciones y clculos complejos, como la lgica del negocio, que no pueden
asociarse con ninguna informacin concreta, de larga duracin, almacenada por el sistema.
Los aspectos dinmicos del sistema se modelan con clases de control, debido a que ellas manejan y
coordinan las acciones y los flujos de control principales, y delegan trabajo a otros objetos.
La clase control no encapsula aspectos relacionados con las interacciones con los actores, ni tampoco
aspectos relacionados con informacin de larga vida y persistente gestionada por el sistema.

ARTEFACTO: REALIZACIN DE CASO DE USO-ANLISIS

Una realizacin de caso de uso-anlisis es una colaboracin dentro del modelo de anlisis que describe
como se lleva a cabo y se ejecuta un caso de uso determinado en trminos de las clases del anlisis y de sus
objetos del anlisis en interaccin. Una realizacin de caso de uso proporciona por tanto una traza directa
hacia un caso de uso concreto del modelo de caso de uso.

LSC. ANA ELENA COTA RAMIREZ

Pgina 3

FLUJO DE ANALISIS
Una realizacin de caso de uso posee una descripcin textual del flujo de sucesos, diagramas de clases que
muestran sus clases de anlisis participantes y diagramas de interaccin que muestren la realizacin de un
flujo o escenario particular del caso de uso en trminos de interacciones del objeto del anlisis. Adems,
debido a que describimos una realizacin de caso de uso en trminos de clases del anlisis y de sus objetos,
se centra de manera natural en los requisitos funcionales. Por tanto, al igual que las propias clases del
anlisis, puede posponer el tratamiento de los requisitos no funcionales hasta las actividades subsiguientes
de diseo e implementacin, llamndoles requisitos especiales en la realizacin.
Diagramas de Interaccin
La secuencia de acciones en un caso de uso comienza cuando un actor invoca el caso de uso mediante el
envi de algn tipo de mensaje al sistema. Si consideramos el interior del sistema, un objeto interfaz
recibir este mensaje del actor. El objeto de interfaz enviara a su vez un mensaje a algn otro objeto, y de
esta forma los objetos implicados interactuaran para llevar a cabo el caso de uso. En el anlisis preferimos
mostrar esto con diagramas de colaboracin ya que nuestro objetivo fundamental es identificar requisitos y
responsabilidad sobre los objetos, y no identificar secuencias de interaccin detalladas y ordenadas
cronolgicamente (diagrama de secuencias).
En los diagramas de colaboracin, mostramos las interacciones entre objetos creando enlaces entre ellos y
aadiendo mensajes a esos enlaces. El nombre de un mensaje debera denotar el propsito del objeto
invocante en la interaccin con el objeto invocado.
En relacin con la creacin y finalizacin de los objetos del anlisis dentro de una realizacin de caso de uso,
objetos diferentes tienen diferentes ciclos de vida.
- Un objeto de interfaz no tiene por que ser particular de una realizacin de caso de uso si, por
ejemplo, debe aparecer en una ventana y participa en dos o mas instancias de caso de uso. Sin
embargo, los objetos de interfaz a menudo se crean y se finalizan dentro de una sola realizacin de
caso de uso.
- Un objeto entidad normalmente no es particular de una realizacin de caso de uso. Al contrario, un
objeto de entidad suele tener una vida larga y participa en varias realizaciones de caso de uso antes
de su derivacin.
- Las clases de control suelen encapsular el control asociado con un caso de uso concreto, lo cual
implica que debera crearse un objeto de control cuando el caso de uso comienza, y ese objeto de
control debera destruirse cuando termina el caso de uso, cuando varios objetos de control participan
en una misma realizacin de caso de uso, y cuando una realizacin de caso de uso no requiere
ningn objeto de control.

LSC. ANA ELENA COTA RAMIREZ

Pgina 4

FLUJO DE ANALISIS
ARTEFACTO: PAQUETE DEL ANLISIS
Los paquetes del anlisis proporcionan un medio para organizar los artefactos del modelo de anlisis en
piezas manejables. Un paquete de anlisis puede constar de clases de anlisis, de realizaciones de casos de
uso, y de otros paquetes del anlisis.

Los paquetes del anlisis tienen las siguientes caractersticas:

-

Los paquetes del anlisis pueden representar una separacin de inters de anlisis.
Los paquetes del anlisis deberan crearse basndose en los requisitos funcionales y en el dominio
del problema y deberan ser reconocibles por las personas con conocimiento del dominio. Los
paquetes del anlisis no deberan basarse en requisitos no funcionales o en el dominio de la
solucin.
Los paquetes del anlisis probablemente se convertirn en subsistemas en las dos capas de
aplicacin superiores del modelo de diseo, o se distribuirn entre ellos. En algunos casos, un
paquete del anlisis podra incluso una capa completa de primer nivel en el modelo de diseo.

Paquetes de servicio.- Aparte de proporcionar casos de uso a sus actores, todo sistema tambin proporciona
un conjunto de servicios a sus clientes. Un cliente adquiere una combinacin adecuada de servicios para
ofrecer a sus usuarios los casos de uso necesarios para llevar a cabo su negocio:
-

Un caso de uso especifica una secuencia de acciones: un actor inicia un hilo, seguido de
interacciones entre el actor y el sistema, que termina tras haber devuelto un valor al actor.
Normalmente, los casos de uso no existen aisladamente.
Un servicio representa un conjunto coherente de acciones relacionadas funcionalmente que se utiliza
en varios casos de uso. Un servicio es indivisible en el sentido de que el sistema necesita ofrecerlo o
todo entero o nada en absoluto.
Los casos de uso son para los usuarios, y los servicios son para los clientes. Los casos de uso
atraviesan los servicios, es decir, un caso de uso requiere acciones de varios servicios.

En RUP, el concepto de servicio esta soportado por los paquetes de servicio. Los paquetes de servicio se
utilizan en un nivel mas bajo de la jerarqua de paquetes del anlisis para estructurar el sistema de acuerdo a
los servicios que proporciona. Podemos observar lo siguiente acerca de los paquetes de servicio:
-

Un paquete de servicio contiene un conjunto de clases relacionadas funcionalmente.

Un paquete de servicio es indivisible. Cada cliente obtiene o bien todas las clases o bien ninguna del
paquete de servicio.

LSC. ANA ELENA COTA RAMIREZ

Pgina 5

FLUJO DE ANALISIS
-

Cuando se lleva a cabo un caso de uso, puede que sean participantes uno o mas paquetes de
servicio. Adems, es frecuente que un paquete de servicio concreto participe en varias realizaciones
de caso de uso diferentes.
Un paquete de servicio, depende a menudo de otro paquete de servicio.
Un paquete de servicio normalmente solo es relevante para uno o unos pocos actores.
La funcionalidad definida por un paquete de servicio, cuando se disea e implementa, puede
gestionarse como una unidad de distribucin separada. Un paquete de servicio puede, por tanto,
representar cierta funcionalidad adicional del sistema. Cuando un paquete de servicio queda
excluido, tambin lo queda todo caso de uso cuya realizacin requiera el paquete de servicio.
Los paquetes de servicio pueden ser mutuamente excluyentes, o pueden representar diferentes
aspectos o variantes del mismo servicio.
Los aspectos de servicio constituyen una entrada fundamental para las actividades de diseo e
implementacin subsiguientes, dado que ayudaran a estructurar los modelos de diseo e
implementacin en trminos de subsistemas de servicio.
Identificacin de paquetes de servicio

La identificacin adecuada de los paquetes de servicio se suele hacer cuando el trabajo de anlisis esta
avanzado, momento en el que los requisitos funcionales se comprenden bien y existen la mayora de las
clase del anlisis. Todas las clases del anlisis dentro del mismo paquete de servicio contribuyen al mismo
servicio.
Al identificar paquetes de servicio, debemos hacer lo siguiente;

Identificar un paquete de servicio por cada servicio opcional. El paquete de servicio ser una unidad
de compra.

Identificar un paquete de servicio por cada servicio que podran hacerse opcional, incluso aunque
todos los clientes siempre lo quieran. Debido a que los paquetes de servicio contienen clases
relacionadas funcionalmente, obtendremos con ellos una estructura de paquetes que asla la mayora
de los cambios en paquetes individuales. Podramos haber descrito este criterio tambin el siguiente
modo: identificar un paquete se servicio por cada servicio proporcionado por clases relacionadas
funcionalmente. Los siguientes ejemplos de cuando una clase A y una clase B estn relacionadas
funcionalmente:
un cambio en A requerir muy probablemente un cambio en B
La eliminacin de A hace que B sea superflua
Los objetos de A interactan intensamente con objetos de B, posiblemente a travs de varios
mensajes diferentes.

ARTEFACTO: DESCRIPCIN DE ARQUITECTURA (VISTA DEL MODELO DE ANALISIS)

Los siguientes artefactos del modelo de anlisis normalmente se consideran significativos para la
arquitectura:
-

La descomposicin del modelo de anlisis en paquetes de anlisis y sus dependencias. Esta

descomposicin suele tener su efecto en los subsistemas de las capas superiores durante el diseo y
la implementacin y es por tanto relevante para la arquitectura en general.
Las clase fundamentalmente de anlisis como las clase de entidad, control e interfaz. Suele ser
suficiente con considerar significativa para la arquitectura una clase abstracta pero no sus subclases.
Realizaciones de casos de uso que describen cierta funcionalidad importante y critica; que implica
muchas clases del anlisis y por tanto tienen una cobertura amplia, posiblemente a lo largo de varios
paquetes de anlisis; o que se centran en un caso de uso importante que debe ser desarrollado al
principio del ciclo de vida del software, y que por tanto es probable que se encuentre en la vista de la
arquitectura del modelo de casos de uso.

LSC. ANA ELENA COTA RAMIREZ

Pgina 6

FLUJO DE ANALISIS
FLUJO DE TRABAJO

ACTIVIDAD: ANALISIS DE LA ARQUITECTURA

El propsito de la arquitectura es esbozar el modelo de anlisis y la arquitectura mediante la identificacin de
paquetes del anlisis, clases anlisis evidente y requisitos especiales comunes.
Identificacin de paquetes de anlisis.- Los paquetes del anlisis proporcionan un medio para organizar el
modelo de anlisis en piezas ms pequeas y ms manejables. Pueden, bien identificarse inicialmente como
forma de dividir el trabajo de anlisis, o bien encontrarse a medida que el modelo de anlisis evoluciona y
crece convirtindose en una gran estructura que debe descomponerse.
Una identificacin inicial de los paquetes del anlisis se hace de manera natural basndonos en los requisitos
funcionales y en el dominio del problema, es decir, en la aplicacin o negocio que estamos considerando.
Debido a que capturamos lo requisitos funcionales en la forma de casos de uso, una forma directa de
identificar paquetes del anlisis es asignar la mayor parte de un cierto numero de casos de uso a un paquete
concreto y despus realizar la funcionalidad correspondiente dentro de ese paquete. Entre las asignaciones
adecuadas de caso de uso a un paquete en concreto tenemos las siguientes:
-

Los casos de uso requeridos para dar sopote a un determinado proceso de negocio
Los casos de uso requeridos para dar soporte a un determinado actor del sistema
Los casos de uso estn relacionados mediante relaciones de generalizacin y de extensin. Este tipo
de conjunto de casos de uso es coherente en el sentido de que los casos de uso o bien especializan
o bien extienden a los otros.

Los paquetes de estos tipos localizan los cambios respectivamente en un proceso del negocio, en el
comportamiento de un actor, y en un conjunto de casos de uso estrechamente relacionados. Esta tcnica
simplemente nos ayuda inicialmente a asignar casos de uso a paquetes. Por tanto, a medida que se
desarrolla el trabajo de anlisis, cuando los casos de uso sean realizados como colaboraciones entre clases,
posiblemente en diferentes paquetes, se evolucionara hacia una estructura de paquetes mas refinada.

Modelo del negocio

(o modelo del dominio)

LSC. ANA ELENA COTA RAMIREZ

Pgina 7

FLUJO DE ANALISIS
Identificacin de clases de entidad obvias.- La mayora de las clases se identificaran al crear las realizaciones
de los casos de uso. Debido a esto, deberamos tener cuidado de no identificar demasiadas clases en esta
etapa y quedar atrapados en demasiados detalles. Debera ser bastante con un esbozo inicial de las clases
significativas para la arquitectura.
Las agregaciones y asociaciones entre clases del dominio en el modelo del dominio pueden utilizarse para
identificar un conjunto provisional de asociaciones entre las correspondientes clases de entidad.
Identificacin de requisitos especiales comunes.- Un requisito especial es un requisito que aparece durante el
anlisis y que es importante anotar de forma que pueda ser tratado adecuadamente en las subsiguientes
actividades de diseo e implementacin. Como ejemplo citamos las limitaciones o restricciones sobre:
-

Persistencia
Distribucin y concurrencia
Caractersticas de seguridad
Tolerancia a fallos
Gestin de transacciones
ACTIVIDAD: ANALIZAR UN CASO DE USO

Analizamos un caso de uso para:

-

Identificar las clases del anlisis cuyos objetos son necesarios para llevar a cabo el flujo de sucesos
del caso de uso
Distribuir el comportamiento del caso de uso entre los objetos del anlisis que interactan
Capturar requisitos especiales sobre la realizacin del caso de uso

Modelo del negocio

(o modelo del dominio)

Identificacin de clases de anlisis.- Aqu identificamos las clases de control, entidad e interfaz necesarias
para realizar los casos de uso y esbozamos sus nombres, responsabilidades, atributos y relaciones.
Para identificar las clases del anlisis puede que tengamos que refinar las descripciones de los casos de uso
de lo referente al interior del sistema. Este refinamiento debe recogerse en la descripcin textual de flujos de
sucesos.
Podemos utilizar las siguientes normas generales para identificar las clases del anlisis:
-

Identificar clases de entidad mediante el estudio en detalle de la descripcin del caso de uso y de
cualquier modelo del dominio que se tenga, y despus considerar qu informacin debe utilizarse y
manipularse en la realizacin del caso de uso. Sin embargo, debemos ser conscientes de la
informacin que es mejor capturar como atributo, la que es preferible asociar a clases de interfaz o
control, o la que simplemente no es necesaria para la realizacin del caso de uso.
Identificar una clase de interfaz central para cada actor humano, y dejar que esta clase represente la
ventana principal del interfaz de usuario con el cual interacta el actor. Si el actor ya interacta con
una clase de interfaz, deberamos considerar el reutilizarla para conseguir una buena facilidad de uso

LSC. ANA ELENA COTA RAMIREZ

Pgina 8

FLUJO DE ANALISIS

de la interfaz de usuario y para minimizar el nmero de ventanas principales que cada actor requiere
para interactuar con ellas.
Identificar una clase de control responsable del tratamiento del control y de la coordinacin de la
realizacin del caso de uso, y despus refinar esta clase de control de acuerdo a los requisitos del
caso de uso. Por ejemplo, en algunos casos el control se encapsula mejor dentro de una clase de
interfaz, especialmente si el actor maneja gran parte del control. En esos casos la clase de control no
es necesaria. En otros casos el control es tan complejo que es mejor encapsularlo en dos o ms
clases de control. En estos casos es necesario dividir la clase de control.

Descripcin de interacciones entre objetos del anlisis.- Cuando tenemos un esbozo de las clases necesarias
para realizar el caso de uso, debemos describir cmo interactan sus correspondientes objetos del anlisis.
Esto se hace mediante el diagrama de colaboracin que contienen las instancias de actores participantes, los
objetos del anlisis y sus enlaces. Si el caso de uso tiene flujos o subflujos diferenciados y distintos, suele ser
til crear un diagrama de colaboracin para cada flujo. Esto contribuye a hacer ms clara la realizacin del
caso de uso, y tambin hace posible extraer diagramas de colaboracin que representan interacciones
generales y reutilizables.
ACTIVIDAD: ANALIZAR UNA CLASE
Los objetivos de analizar una clase son:
-

Identificar y mantener las responsabilidades de una clase del anlisis, basadas en su papel en las
realizaciones de caso de uso.
Identificar y mantener los atributos y relacin de la clase del anlisis
Capturar requisitos especiales sobre la realizacin de la clase del anlisis

Identificar responsabilidades.- Las responsabilidades de una clase pueden recopilarse combinando todos los
roles que cumple en 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 sus diagramas de clases u de interaccin.
Hay varias maneras de recopilar las responsabilidades de una clase. Una tcnica simple es extraer las
responsabilidades de cada rol uno detrs de otro, aadiendo responsabilidades adicionales o modificando las
existentes basndose en una realizacin de caso de uso tras otra.
Identificacin de atributos.- Un atributo especifica una propiedad de una clase de anlisis, y normalmente es
necesaria para las responsabilidades de su clase. Deberamos tener en mente las siguientes normas
generales cuando identificamos atributos:
-

Un nombre de un atributo debera ser un nombre

Recurdese que el tipo de los atributos debera ser conceptual en el anlisis, y , si es posible, no
debera verse restringido por el entorno de implementacin. Por ejemplo, cantidad puede ser un tipo
adecuado en el anlisis, mientras que su contrapartida en el diseo podra ser entero.

LSC. ANA ELENA COTA RAMIREZ

Pgina 9

FLUJO DE ANALISIS
-

Al decidir el tipo de un atributo, debemos intentar reutilizar tipos ya existentes.

Una determinada instancia de un atributo no puede compartirse por varios objetos del anlisis. Si se
necesita hacer esto, el atributo debe definirse en su propia clase.
Si una clase de anlisis se hace demasiado difcil de entender por culpa de sus atributos, algunos de
esos atributos podra separarse en clases independientes.
Los atributos de las clases de entidad suelen ser bastantes ser bastante evidentes. Si una clase de
entidad tiene una traza con una clase del dominio o con una clase de entidad del negocio, los
atributos de esas clases son una entrada til.
Los atributos de las clases de interfaz que interactan con los actores humanos suelen representar
elementos de informacin manipulados por los actores, tales como campos de texto etiquetados.
Los atributos de las clases de control son poco frecuente debido a su corto tiempo de vida. Sin
embargo, las clases de control pueden poseer atributos que representan valores acumulados o
calculados durante la realizacin de un caso de uso.
A veces no son necesarios los atributos formales. En su lugar, puede ser suficiente con una sencilla
explicacin de una propiedad tratada por una clase del anlisis, y pueden aadirse a la descripcin
de las responsabilidades de la clase.

Identificacin de asociaciones y agregaciones.- Los objetos del anlisis interactan unos con otros mediante
enlaces en los diagramas de colaboracin. Estos enlaces suelen ser instancias de asociaciones entre sus
correspondientes clases. Los enlaces pueden implicar la necesidad de referencias y agregaciones entre
objetos.
Deberamos minimizar el nmero de relaciones entre clases. Debemos modelar las relaciones que deben
existir en respuesta a las demandas de las diferentes realizaciones de caso de uso. Tambin se debe definir
la multiplicidad de las asociaciones, los nombre de los roles, auto asociaciones.
Las agregaciones deberan utilizarse cuando los objetos representan:
- Conceptos que se contienen fsicamente uno al otro, como un coche que contiene al conductor y a
los pasajeros.
- Conceptos que estn compuestos uno de otro, como cuando decimos que un coche consta de un
motor y ruedas.
- Conceptos que forman una coleccin conceptual de objetos, como una familia que consta de un
padre, una madre y los nios.
Identificacin de generalizaciones.-Las generalizaciones deberan utilizarse durante el anlisis para extraer
comportamiento compartido y comn entre varias clases de anlisis diferentes. Las generalizaciones
deberan mantenerse en un nivel alto y conceptual, y su objetivo fundamental debera ser hacer el modelo de
anlisis ms fcil de comprender.
Durante el diseo ajustaremos las generalizaciones para que encajen mejor con el entorno de
implementacin elegido, es decir, con el lenguaje de programacin. Una generalizacin podra desaparecer y
convertirse en su lugar en otra relacin, como una asociacin.
ACTIVIDAD: ANALIZAR UN PAQUETE
Los objetivos de analizar un paquete, son:
-

Garantizar que el paquete del anlisis es tan independiente de otros paquetes como sea posible.
Garantizar que el paquete del anlisis cumple su objetivo de realizar algunas clases del dominio o
casos de uso.
Describir las dependencias de forma que pueda estimarse el efecto de los cambios futuros.

Las siguientes son algunas normas generales para esta actividad:

Definir y mantener las dependencias del paquete con otros paquetes cuyas clases contenidas estn
asociadas con l.
Asegurarnos de que el paquete contiene las clases correctas. Intentar hacer cohesivo el paquete
incluyendo solo los objetos relacionados funcionalmente.
Limitar las dependencias con otros paquetes. Considerar la reubicacin de aquellas clases
contenidas en paquetes que son demasiado dependientes de otros paquetes.

LSC. ANA ELENA COTA RAMIREZ

Pgina 10