EL MODELO DE ANÁLISIS

El propósito fundamental del modelo de análisis es resolver analizando los requisitos con mayor
profundidad, pero con diferencia de que puede utilizarse lenguaje de los desarrolladores de
proyectos para describir los resultados. En consecuencia podemos más sobre los sobre los
aspectos internos del sistema, y por tanto resolver aspectos relativos a la interferencia de casos de
uso y demás. Podemos estructurar los requisitos de manera que nos facilite su comprensión, su
preparación, su modificación y su mantenimiento.

Se puede considerar como una primera aproximación al modelo de diseño y es por tanto, una
entrada fundamental cuando se da “forma” al sistema en el diseño y la implementación.

REALIZACIÓN DE UN CASO DE USO

Una realización de Caso de Uso describe cómo es realizado un caso de uso en particular dentro del
modelo del diseño, en términos de la colaboración de sus objetos

Por cada Caso de Uso una carpeta

Clase del Análisis

Una clase de análisis representa la abstracción de una o varias clases y/o subsistemas del diseño
clases y/o subsistemas del diseño del sistema. Esta abstracción posee las siguientes características:

Una clase de análisis se centra en el tratamiento de los requisitos funcionales.

Una clase de análisis también define atributos, aunque esos son de alto nivel, pero normalmente
estos pasan normalmente a una clase en el diseño.

Las clases del análisis siempre encaja en uno de tres estereotipos básicos: Interfaz, Control,
Entidad.
CLASE DE INTERFAZ

Las clases de interfaz se utilizan para modelar la interacción entre el sistema y los actores.

Las clases de interfaz modelan las partes del sistema que dependen de sus actores lo cual implica
que clasifican y reúnen los requisitos en los límites del sistema

Las clases de interfaz representan a menudo abstracciones de ventanas, formularios, paneles,

interfaces de comunicaciones.

Clase de Entidad

Las clases de entidad modelan información y el comportamiento asociado de algún fenómeno o

concepto, como persona o un objeto.

Las clases de entidad reflejan la información de un entidad de un modo que beneficia a los
desarrolladores al diseñar e implementar el sistema, incluyendo su soporte de persistencia.

Las clases de entidad suelen mostrar una estructura de datos lógica y contribuyen a comprender
de qué información depende el sistema.
Clase de Gestor

Las clases de control representan coordinación, secuencia, transacciones y control de otros

objetos y se usan con frecuencia para encapsular el control de un caso de uso en concreto.

Los aspectos dinámicos 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.
MODELO CONCEPTUAL

Un modelo conceptual tiene como objetivo identificar y explicar los conceptos significativos en un
dominio de problema, identificando los atributos y las asociaciones existentes entre ellos.

Puede ser visto, también como una representación de las cosas, entidades, ideas, conceptos u
objetos del “mundo real” o dominio de interés. Es importante diferenciar que dichas entidades u
objetos no son componentes de software.

También podría ser considerado como un diccionario visual de abstracciones, conceptos,

vocabulario e información del dominio de problema.

No es absolutamente correcta o incorrecta, su intención en ser útil sirviendo como una

herramienta de comunicación.

Aclaraciones:

 Modelo conceptual, modelo de objetos del dominio y modelo de los objetos de análisis
son distintos nombres que suelen usarse indistintamente para referirse a este modelo.
 Clase conceptual, concepto, o entidad también suelen usarse indistintamente.

CLASES CONCEPTUALES

El proceso de desarrollo de software debe incluir en sus primeras etapas la construcción del
modelo conceptual. Dicha tarea suele encararse como parte del análisis de requerimientos: la
identificación de requerimientos debe acompañarse con la identificación de las entidades o
conceptos involucrados en los mismos. De igual manera, la identificación de entidades puede
contribuir con la refinación de requerimientos.

Estrategias para identificar clases conceptuales

 Utilizar lista de categorías de entidades.

 Identificar frases nominales (sustantivos o frases).

Utilizar lista de categorías de clases conceptuales

Categoría Ejemplo
Objetos tangibles o físicos Casa, Avión
PlanoDeLaCasa,
Especificaciones, diseños o descripciones
EspecificaciónDelProducto
de las cosas
DescripciónDelVuelo
Lugares Tiendo, Aula
Transacciones Venta, Pago, Reserva, Tranferencia
Líneas de la transacción LíneaDeVenta
Roles de la gente Cajero, Piloto, Jefe
Contenedores de otras cosas Aula, Ciolectivo, Lata, Mochila
Contenidos Pasajero, Artículo, ÚtilEscolar
Otros sistemas informáticos o SistemaDeAutorización,
electromecánicos externos al sistema ControlDeTraficoAéreo
Conceptos abstractos Amor, Celos, Ansia, Acrofobia
Organizaciones DepartamentoDeVentas, CompañiaAérea
Hechos Reunión, Vuelo, Aterrizaje, Venta, Pago
VentaDeUnProducto,
Procesos (normalmente no se representan
ReservaDeUnAsiento (no confundir con
como conceptos, pero podría ocurrir)
trasacciones)
PolíticaDeReintegro,
Reglas y políticas
PolíticaDeCancelación
Catálogos CatálogoDeProductos
Registros de finanzas, trabajo, contratos, Recibo, Remito, Factura,
cuestiones legales ContratoDeEmpleo, Expediente
Instrumentos y servicios financieros LíneaDeCrédito, Stock
Manuales, documentos, artículos de
ManualDeReparaciones, ListaDeCambios
referencia, libros
Amistad, Parentesco (podría estar en
conceptos abstractos pero es bueno
Relaciones
destacarlo ya que las relaciones no suelen
ser consideradas al modelar)

Identificar frases nominales (sustantivos o frases)

Se intenta identificar sustantivos o frases nominales en el vocabulario y descripciones del dominio

del problema. Esta técnica práctica no puede ser aplicada mecánicamente sino que hay que usar el
“sentido común” y capturar las abstracciones adecuadas puesto que el lenguaje natural es
ambiguo y los conceptos relevantes no siempre se encuentran de manera explícita.

Por ejemplo, si se quisiera modelar distintos torneos de fútbol, algunas entidades involucradas
serían:

Asociaciones

Una asociación es una relación entre dos conceptos que indica alguna conexión significativa entre
ellos. Las asociaciones útiles a determinar, suelen incluir el conocimiento de una relación que ha
de preservarse por algún tiempo: puede tratarse de milisegundos o de años (según el contexto).

Por ejemplo, ¿cómo reflejar que un equipo está compuesto por jugadores, qué uno de ellos es el
capitán, qué los equipos juegan partidos o que los torneos tienen varios partidos programados?

Los nombres de las asociaciones deben ser lo más claros posibles, y deben permitir leer y entender
fácilmente las relaciones entre conceptos.

Por lo general, se asume un orden en la lectura: de izquierda a derecha y de arriba hacia abajo. No
obstante, es posible indicar explícitamente algún otro orden.

Estrategias para identificar asociaciones

La siguiente lista de preguntas puede resultar útil para identificar asociaciones entre distintas
clases conceptuales.

• A es una parte física o lógica de B

 • A está lógica o físicamente contenido en B
• A es una descripción de B
• A es un elemento de línea (o renglón) en una transacción o reporte B
• A se conoce/introduce/registra/presenta/captura en B
• A es miembro de B
• A es una unidad organizacional de B
• A usa o dirige a B
• A se comunica con B
• A se relaciona con una transacción B
• A es una transacción relacionada con otra transacción B
• A es propiedad de B

Multiplicidad

La multiplicidad define cuántas instancias de un tipo A pueden asociarse a una instancia del tipo B
en determinado momento. Las expresiones de multiplicidad son las siguientes:

- 1 Exactamente uno
- 0..1 Cero o uno
- 0..* Cero o muchos
- 1..* Al menos uno: uno o muchos

Por ejemplo, continuando con el ejemplo: ¿cómo modelar los siguientes aspectos?

• Un jugador puede jugar en sólo un equipo o en ninguno (si es que está libre).
• Todo equipo tiene un capitán.
• Los partidos los juegan dos equipos: uno será local y otro visitante.
• Todos los equipos tienen asegurados al menos un partido como visitante y al menos un
partido como local.
• Cualquier torneo tiene al menos un partido programado.
• Todo partido se realiza en el contexto de un único torneo.
Roles

Dada una asociación entre dos entidades, decimos que cada entidad representa un rol en dicha
asociación.

Muchas veces, según el punto de vista de cada entidad, es posible nombrar a la asociación de
manera diferente.

Por ejemplo, así como un jugador “juega en” un equipo, también podríamos decir que un equipo
“está conformado” por varios jugadores. En estos casos resulta útil darle un nombre a cada rol.

Atributos

Las entidades suelen poseer características propias que en sí mismas no constituyen otros
conceptos, en estos casos decimos que son atributos.

Los posibles valores que un atributo podrá poseer en algún momento, pertenecen a un dominio en
particular. Por ejemplo, un jugador tiene un nombre y una fecha de nacimiento. El dominio del
atributo no debe pensarse como el tipo de datos del mismo.

Cuando se elabora el modelo conceptual no se está diseñando ni programando, simplemente se

está creando una abstracción, un modelo como parte de la especificación de un problema.

Clases de Asociación
Algunas veces se quiere modelar información que no es propia de una entidad sino que sólo tiene
sentido en el marco de una asociación entre varias entidades.

Por ejemplo, los jugadores de fútbol se incorporan a sus equipos firmando un contrato en el cual
se aclara que número de camiseta usará y cuanto cuál será su sueldo. Desde algún punto de vista,
dicho contrato provee más información a la asociación existente entre un jugador y su equipo, por
eso es que puede modelarse como una clase de asociación.

Herencia

Existe una asociación entre entidades que merece un tratamiento a parte: la relación de “es un”.
Muchas veces una entidad, además de representar algo en particular, es al mismo tiempo algo
más general.

Por ejemplo, existen vehículos aéreos y vehículos terrestres. En ambos casos, más allá de ser
terrestres o aéreos, son vehículos. A su vez existen vehículos aéreos que son helicópteros y otros
que son aviones. También es posible modelar este tipo de situaciones.
En todos los casos, depende de la interpretación que se esté haciendo, es posible obtener distintas
jerarquías. Por ejemplo, desde el punto de vista de quién o como se use, un vehículo aéreo puede
ser comercial o militar. Ahora bien, según de cómo sea estructuralmente, puede ser un
helicóptero o un avión.

Estos diagramas se deben interpretar de la siguiente manera: un avión posee todos los atributos
de un vehículo aéreo, y además puede poseer atributos propios. Por otro lado, cualquier
asociación que termine en la clase “Vehículo Aéreo”, también pertenecerá a cualquier helicóptero,
avión, vehículo aéreo comercial o vehículo aéreo militar. Sin embargo, una avocación que
involucre a la clase avión, no tendrá nada que ver con el resto de los vehículos aéreos.
Limitaciones

Dado un problema es posible confeccionar muchos modelos conceptuales, no necesariamente

consistentes entre sí. La elaboración del modelo conceptual es una tarea que requiere una
interpretación de la realidad, y en dicha interpretación juega un rol importante la subjetividad de
quien realiza la tarea.

Analizando el siguiente diagrama:

Pueden desprenderse las siguientes preguntas:

• ¿Qué garantías hay de que el jugador capitán de un equipo, juegue en ese equipo?
• ¿Qué garantías hay de que un equipo no juegue el mismo partido como visitante y local a
la vez?
• ¿Qué garantías hay de que en un equipo todos los jugadores tengan un número de
camiseta distinto?
• ¿Qué garantías hay de que no haya dos equipos con el mismo color de camiseta?

En todos los casos, la respuesta es ninguna. El modelo conceptual es una técnica que permite
modelar algunos aspectos relacionados con las entidades y sus relaciones, pero no todos. En estos
casos, será útil utilizar otras técnicas (por ejemplo OCL) con el fin de cubrir los aspectos ambiguos
o no especificados.

Notación

Pueden utilizarse distintas notaciones para representar un modelo conceptual. Utilizaremos el

Diagrama de Clases de UML para tal fin. La notación del diagrama de clases puede utilizarse
durante distintas etapas del proceso de software para representar distintas cosas: por ejemplo, en
una primera etapa lo utilizaremos para confeccionar el modelo conceptual y más adelante, lo
utilizaremos para confeccionar el diseño detallado, en el cual se diseñan las clases (componentes
de software) que finalmente se implementarán.

En ambos casos, las diferencias son más semánticas que sintácticas. Por tal motivo, para remarcar
aún más la diferencia, utilizaremos el siguiente estereotipo al notar las clases conceptuales.

La sintaxis provista por el diagrama de clases, también permite distinguir distintos tipos de
asociaciones, como la composición y agregación.