Ingeniería del Software de Gestión. Tema 3

tema 3 – análisis de
sistemas

enrique barreiro
departamento de informática
universidade de vigo

escuela superior de ingeniería informática
ingeniería del software de gestión

introducción al análisis
tema 3 – análisis de sistemas

ingeniería de requisitos
los casos de uso son una buena herramienta para capturar
requisitos, pero siempre quedan aspectos sin resolver o que
son de especial complejidad y hay que estudiar
posteriormente:
deben mantenerse lo más independientes posibles unos de
otros, obviando detalles relativos a interacciones, concurrencia,
recursos compartidos,...
ejemplo: Ingresar Dinero y Retirar Dinero son dos casos de uso que
acceden a la misma cuenta y por tanto están relacionados
deben escribirse utilizando el lenguaje del cliente: al usarse
lenguaje natural se pierde poder expresivo y en la captura de
requisitos pueden quedar sin describir adecuadamente detalles
que requieren notaciones más formales

© enrique barreiro alonso
universidade de vigo - departamento de informática ingeniería del software de gestión 2 / 92


análisis
objetivo:
conseguir una comprensión más precisa de los
requisitos y una descripción de los mismos
que sea fácil de mantener y ayude a
estructurar todo el sistema, incluyendo su
Ingeniería de
arquitectura
requerimientos
diversos enfoques
Modelo de casos
estructurado
de uso
prototipado
:Modelo
orientado a objetos
Análisis
se analizan los requisitos descritos durante la
ingeniería de requisitos:
Modelo de
análisis
analizándolos con mayor profundidad: se
:Modelo
puede razonar más sobre los aspectos
internos del sistema, resolviendo cuestiones
sobre interacciones de casos de uso, recursos
Diseño
compartidos,...
utilizando el lenguaje de los desarrolladores,
lo que permite indicar detalles no
Modelo de
especificados antes (refinar los requisitos)
diseño
:Modelo
se pueden estructurar los requisitos para
facilitar su comprensión, preparación,
modificación y mantenimiento



Comparación del modelo de casos de uso con el modelo de análisis

Modelo de casos de uso Modelo de análisis

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 Estructurado por clases y paquetes
Utilizado fundamentalmente como contrato entre Utilizado fundamentalmente por los
el cliente y los desarrolladores sobre qué debería desarrolladores para comprender cómo debería
y qué no debería hacer el sistema darse forma al sistema, es decir, cómo debería ser
diseñado e implementado
Puede contener redundancias, inconsistencias,... No debe contener redundancias,
entre los requisitos inconsistencias,... entre los requisitos
Captura la funcionalidad del sistema, incluida la Esboza cómo llevar a cabo la funcionalidad dentro
funcionalidad significativa para la arquitectura del sistema, incluida la funcionalidad significativa
para la arquitectura; sirve como una primera
aproximación al diseño
Define casos de uso que se analizarán con más Define realizaciones 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



requerimientos cambiantes
habitual en grandes sistemas
razones
muchos usuarios (contradicciones, conflictos de intereses,...)
los que pagan el sistema y los usuarios no suelen ser la misma persona,
por lo que pueden tener requerimientos en conflicto
el entorno de negocios y técnico cambia: nuevo hardware, nuevos
sistemas, cambios en las prioridades del negocio, cambios legislativos,...
administración de requerimientos
proceso de comprender y controlar los cambios en los requerimientos del
sistema
requerimientos duraderos: aquellos relativamente estables, derivados
de la actividad principal de la organización, y relacionados
directamente con el dominio del sistema. Por ejemplo, en un hospital
siempre habrá requerimientos referidos a pacientes, doctores,
enfermeros, medicinas,...
requerimientos volátiles: cambian probablemente durante el
desarrollo del sistema o después de que se haya puesto en
explotación. Por ejemplo, cambios en las normativas de salud.



planificación de la administración de requerimientos
identificación de requerimientos
proceso de administración del cambio
análisis del problema y especificación del cambio
análisis del cambio y evaluación económica
implementación del cambio
políticas de rastreo: definen la relación entre requerimientos
y la de éstos y el diseño del sistema
información de rastreo de la fuente: identificación de quién
propone el cambio y la razón
información de rastreo de los requerimientos: vincula los
requerimientos dependientes en el RAD. Es necesario para
comprobar cómo se ven afectados otros requerimientos por el
cambio propuesto y la magnitud de este impacto.
información de rastreo del diseño: vincula los requerimientos a
los componentes de diseño (clases, métodos, módulos,...) en
que serán implementados. Necesario para evaluar cómo se ve
afectado el diseño y la implementación por el cambio
propuesto.
ayuda de herramientas CASE


el análisis en el proceso unificado

actividades del análisis en el proceso unificado
crear el Modelo de Dominio
refinar el Modelo de Casos de Uso
refinar la Especificación Complementaria
refinar el Glosario

se llevan a cabo a lo largo de varias iteraciones en la fase
de elaboración


modelo del dominio

artefacto de UML: modelo del dominio (o modelo conceptual)
muestra clases conceptuales significativas en un dominio del
problema, es decir, en el mundo real
no muestra componentes software, clases software u objetos
software con responsabilidades
es el artefacto más importante en un análisis orientado a objetos
(AOO)
UML utiliza diagramas de clases para representar el modelo del
dominio, que muestran:
objetos del dominio o clases conceptuales
asociaciones entre las clases conceptuales
atributos de las clases conceptuales

principal tarea del AOO: identificar diferentes conceptos en el
dominio del problema y documentar el resultado en un modelo del
dominio

ejemplo: en el dominio de ventas pueden identificarse clases
conceptuales como Tienda, Registro o Venta.
el modelo del dominio se construye incrementalmente a lo largo de
varias iteraciones en la fase de elaboración


modelo del dominio

Modelo del dominio: ejemplo de un Diagrama de Clases

concepto u Registra-venta-de
LineaDeVenta Artículo
objeto del
cantidad
dominio 0..1 1
*
1..n
asociación Contenida-en Almacenado-en
1
Tienda
1
atributos dirección
Venta
tienda
fecha
hora
1 1
1 Capturada-en
Alberga

1
Pagada-mediante
1.. *
Registro
1
Pago
cantidad


modelo del dominio

pasos en la realización de un modelo del dominio
1. identificar y listar las clases conceptuales candidatas
2. representarlas en un modelo del dominio
3. añadir las asociaciones necesarias para registrar las
relaciones que hay que mantener en memoria
4. añadir los atributos necesarios para satisfacer los requisitos
de información
importante:
utilizar el vocabulario del dominio al nombrar las clases
conceptuales y atributos
excluir las características irrelevantes
no añadir cosas que no se encuentran en el dominio del
problema que se está estudiando


modelo del dominio

Los modelos del dominio no son modelos de
Los modelos del dominio no son modelos de
componentes software.
componentes software.
Elementos que no son adecuados en un modelo del
Elementos que no son adecuados en un modelo del
dominio:
Venta
dominio:
• Artefactos software: ventanas, bases de datos,...
fecha • Artefactos software: ventanas, bases de datos,...
• Responsabilidades o métodos
• Responsabilidades o métodos
hora

imprimir()

BaseDeDatosVentas

Son artefactos software o
clases s oftware, por lo que
no forman parte del m odelo
del do m ini o

Componente
Acti veX


modelo del dominio

clases conceptuales
informalmente: una clase conceptual es una idea, cosa u objeto
formalmente puede considerarse en términos de:
símbolo: palabras o imágenes que representan una clase conceptual
definición de la clase
extensión: conjunto de ejemplos a los que se aplica la clase

símbolo del concepto

Venta

fecha
hora venta-3
venta-1

venta-4
definición del concepto
venta-2

Una venta representa el
hechoventa representa el
Una de una transición
de compra.una transición
hecho de Sucede un
día ycompra. Sucede un
de a una hora.
día y a una hora.
extensión del concepto


modelo del dominio

identificación de clases conceptuales
para cada escenario se identifican las
clases conceptuales relacionadas con él
Identificar clases
mejor especificar en exceso un modelo
c oncept uales candidat as
del dominio con muchas clases
conceptuales “de grano fino” que
especificar por defecto
Representar las clases en
estrategias complementarias para
un modelo del dominio
identificar clases conceptuales
utilización de una lista de categorías de
clases conceptuales
identificación de frases nominales
Añadir las asociac iones
necesarias

Añadir los atributos
necesarios


modelo del dominio: identificación de clases

identificación de clases conceptuales mediante una lista de categorías
se utiliza una lista de categorías habituales que normalmente merece la pena tener
en cuenta

Categoría de clase conceptual Ejemplos
objetos tangibles o físicos Registro
Avión
especificaciones, diseños o descripciones EspecificacionDelProducto
de las cosas DescripcionDelVuelo
lugares Tienda
transacciones Venta, Pago
Reserva
líneas de la transacción LineaDeVenta
roles de la gente Cajero
Piloto
contenedores de otras cosas Tienda, Almacén
Avión
cosas en un contenedor Artículo
Pasajero
otros sistemas informáticos o SistemaAutorizaciónPagoCrédito
electromecánicos externos al sistema ControlDeTraficoAereo
...
...



análisis del lenguaje natural: identificación de clases
conceptuales mediante frases nominales
heurística de Abbot (1983)
identificar nombres y frases nominales en las descripciones
textuales de un dominio, considerándolos como clases
conceptuales o atributos candidatos
punto débil: imprecisión del lenguaje natural, ambigüedades
(sinónimos, redundancias,...)
se realiza a partir de las descripciones completas de los
casos de uso



Escenario principal de éxito (o flujo básico) de Procesar Venta.
Escenario principal de éxito (o flujo básico) de Procesar Venta.
1. El Cliente llega al terminal PDV con mercancías y/o servicios que comprar
1. El Cliente llega al terminal PDV con mercancías y/o servicios que comprar
2. El Cajero inicia una nueva venta
2. El Cajero inicia una nueva venta
3. El Cajero introduce el identificador del artículo
3. El Cajero introduce el identificador del artículo
4. El Sistema registra la línea de venta y presenta la descripción del artículo,
4. El Sistema registra la línea de venta y presenta la descripción del artículo,
precio y suma parcial. El precio se calcula a partir de un conjunto de reglas
precio y suma parcial. El precio se calcula a partir de un conjunto de reglas
de precios.
de precios.
El Cajero repite los pasos 3-4 hasta que se indique
El Cajero repite los pasos 3-4 hasta que se indique
5. El Sistema muestra el total con los impuestos calculados
5. El Sistema muestra el total con los impuestos calculados
6. El Cajero le dice al Cliente el total, y solicita el pago
6. El Cajero le dice al Cliente el total, y solicita el pago
7. El Cliente paga y el Sistema gestiona el pago
7. El Cliente paga y el Sistema gestiona el pago
8. El Sistema registra la venta completa y envía la información de la venta y el
8. El Sistema registra la venta completa y envía la información de la venta y el
pago al sistema de Contabilidad externo (para la contabilidad y las
pago al sistema de Contabilidad externo (para la contabilidad y las
comisiones) y al sistema de Inventario (para actualizar el inventario).
comisiones) y al sistema de Inventario (para actualizar el inventario).
9. El sistema presenta el recibo
9. El sistema presenta el recibo
10. El Cliente se va con el recibo y las mercancías
10. El Cliente se va con el recibo y las mercancías
Extensiones (o flujos alternativos)
Extensiones (o flujos alternativos)
...
...
7a. Pago en efectivo:
7a. Pago en efectivo:
1. El Cajero introduce la cantidad de dinero entregada en efectivo.
1. El Cajero introduce la cantidad de dinero entregada en efectivo.
2. El sistema muestra la cantidad de dinero aa devolver y abre el cajón de
2. El sistema muestra la cantidad de dinero devolver y abre el cajón de
caja.
caja.
3. El Cajero deposita el dinero entregado y devuelve el cambio al Cliente
3. El Cajero deposita el dinero entregado y devuelve el cambio al Cliente
4. El Sistema registra el pago en efectivo
4. El Sistema registra el pago en efectivo



no se menciona de forma explícita, pero en la
no se menciona de forma explícita, pero en la
descripción se habla de “información enviada
conocimiento descripción se habla de “información enviada
conocimiento por el OficialCampo”.
del dominio por el OficialCampo”.
informar del dominio Al hablar con el cliente se descubre que a esta
Al hablar con el cliente se descubre que a esta
emergencia información se la conoce como informe de
información se la conoce como informe de
emergencia, por lo que se le da ese nombre a la
emergencia, por lo que se le da ese nombre a la
clase correspondiente
clase correspondiente
Ubicación Descripción del caso de uso
Ubicación
Descripción deldel caso de usouso
Descripción
Ubicación caso de
Estación 1. El OficialCampo activa la función Informar
Ubicación
OficialCampo DescripciónOficialCampo activa la función Informar
Emergencia en su PDA. uso
El del caso de
1.
Emergencia en su PDA.
1. El OficialCampo activa la función Informar
2. El sistema COMUNICA responde presentando un
formulario alCOMUNICA responde presentando un su PDA. la función Informar
1. El OficialCampo activa
2. El sistema OficialCampo. El formulario incluye
Emergencia en
Estación un menú de al OficialCampo. El formulario incluye
formulario tipos de emergencia (incendio,
accidente, de tipos de emergencia para introducir en su PDA.
Emergencia
un menú disturbios,...) y campos (incendio,
OficialCampo accidente, disturbios,...)del incidente, petición de
y campos para introducir
la ubicación, descripción El sistema COMUNICA responde presentando
la 2.
ubicación, descripción del incidente, petición de
recursos,...
2. unEl sistema COMUNICA responde presentando
formulario al OficialCampo. El formulario
recursos,...
un formulario al OficialCampo. El formulario
3. El OficialCampo cubre el formulario, y puede
El OficialCampo cubre el formulario, a la menú de tipos de emergencia
incluye un
InformeDeEmergencia
3. también describir respuestas posibles y puede
Controlador
también describir respuestas posibles a la
(incendio, un menú de tipos de emergencia
incluye accidente, disturbios,...) y campos
situación de emergencia y solicitar recursos
específicos. Una vez que hasolicitar recursos
situación de emergencia y llenado el formulario,
elespecíficos. Una vez que ha(incendio, accidente, disturbios,...) y campos
OficialCampo lo envía oprimiendo elel formulario, ubicación, descripción del
para introducir la
llenado botón
“Enviar Informe” ylo envíaincidente,notifica al la ubicación, descripción del
el OficialCampo en ese momento seel botón
oprimiendo le
para introducir
“Enviar Informe” y en ese momento se le petición de recursos,...
notifica al
Controlador
incidente, petición de recursos,...
Controlador
4. Al Controlador se le notifica un nuevo informe de
Estación
incidente mediante le notifica un nuevo informe de cubre el formulario, y puede
Al 3.
Controlador se un cuadro OficialCampo
El de diálogo
4.
Controlador
desplegable. El Controlador revisa diálogo
incidente mediante un cuadro de la información
3. El OficialCampo cubre el formulario, y puede
también describir respuestas posibles a la
recibida y crea El Controlador revisa la información
desplegable. un Incidente en la base de datos
llamando alcrea un Incidente también datos
situaciónde describir respuestas posibles a la
en la base de emergencia y solicitar recursos
recibida y caso de uso AbrirIncidente. Toda la
información contenidauso específicos.de emergencia y llenado el
llamando al caso de en el formulario delToda la
AbrirIncidente.
información se incluye automáticamente en Una vez que ha solicitar recursos
situación
OficialCampocontenida en el formulario del el
OficialCampo Incidente
OficialCampo se incluye automáticamente en el Una vez que ha llenado el
específicos.
formulario, el OficialCampo lo envía oprimiendo
Incidente. El Controlador selecciona una respuesta
Incidente. El Controlador selecciona una respuesta
asignando recursos al incidente (con el caso de
uso AsignarRecursos) yincidente (con el“Enviar OficialCampo lo envía oprimiendo
el formulario, al Informe” y en ese momento se
botón caso el
asignando recursos al da un acuse de recibode
uso AsignarRecursos) y da un acuse de recibo al
informe de emergencia enviando botónal Controlador
informe de emergencia le el notifica “Enviar Informe” y en ese momento se
un mensaje
breve al OficialCampo. enviando un mensaje
le notifica al Controlador
breve al OficialCampo.
Estación 5. El OficialCampo recibe el acuse de recibo y la
respuesta seleccionada. el acuse de recibo y la se le notifica un nuevo informe
El 4.
OficialCampo recibe Al Controlador
5.
OficialCampo
respuesta seleccionada.
4. deAl Controlador se le notifica un de diálogo
incidente mediante un cuadro nuevo informe
Estación
desplegable. Elmediante un cuadro la diálogo
de incidente Controlador revisa de
Controlador
desplegable. El Controlador revisa la
información recibida y crea un Incidente en la
base de datos recibida y al caso de uso
información llamando crea un Incidente en la

descripción de los objetos y clases
AbrirIncidente. Toda la informaciónde uso
base de datos llamando al caso contenida
enAbrirIncidente. Toda la informaciónincluye
el formulario del OficialCampo se contenida
automáticamente en el Incidente. El se incluye
en el formulario del OficialCampo Controlador
selecciona una respuesta Incidente. El Controlador
automáticamente en el asignando recursos al
inicialmente, breve
incidente (conunacaso de uso AsignarRecursos) al
selecciona el respuesta asignando recursos
y da un acuse deel caso al informe de
incidente (con recibo de uso AsignarRecursos)
y da un acuse de recibo al informe de
emergencia enviando un mensaje breve al
documentación de atributos y
OficialCampo. enviando un mensaje breve al
emergencia
OficialCampo.
responsabilidades únicamente si son
Estación 5. El OficialCampo recibe el acuse de recibo y la
OficialCampo 5. respuesta seleccionada. el acuse de recibo y la
El OficialCampo recibe
obvios
respuesta seleccionada.

una vez que el modelo es estable, la
descripción de cada clase será tan
detallada como sea posible
entrevistas
con cliente
y usuarios



lista de clases conceptuales candidatas del dominio
generada a partir de
lista de categorías
análisis de lenguaje natural (frases nominales)
restringida a los requisitos que se están estudiando actualmente
ejemplo: lista de clases candidatas del caso de uso Procesar
Venta.
Registro EspecificaciónDelProducto

Artículo LíneadeVenta
Tienda Cajero
Venta Cliente
Pago Encargado
CatálogoDeProductos ...

informes: por lo general, no se recogen en el modelo de dominio
porque muestran información derivada de otras fuentes,
duplicando información.
a discutir: ¿es el Recibo una clase conceptual?



error habitual al identificar clases candidatas:
considerar como un atributo algo que debería ser un concepto
en caso de duda, debe considerarse un concepto separado,
puesto que los atributos no deben ser muy habituales en un
modelo del dominio

NO SI

Tienda
Venta
Venta dirección
tienda
teléfono
En el mundo real, una tienda o un
aeropuerto no real, una tienda o un
En el mundo se consideran un
número o un no se consideran un
aeropuerto texto. Estos términos
sugieren una entidadEstos términos
número o un texto. legal, una
organización, yentidad legal, una
sugieren una algo que ocupa
organización, y algo que ocupa
espacio. Por tanto, deben ser un
espacio. Por tanto, deben ser un
concepto.
concepto.
Aeropuerto
Vuelo Vuelo
nombre
destino



Si se consumen todos los
ObjetoOrdenador,todos los
Si se consumen desaparecerá del
ObjetoOrdenador :
Artículo
sistema también su desaparecerá del
ObjetoOrdenador, precio, porque
Artículo
artículoID se encontraba como atributo porque
sistema también su precio, en las
ObjetoOrdenador :
instancias que se eliminaron en las
se encontraba como atributo
numeroSerie
Artículo instancias que se eliminaron
cuando se vendieron.
descripción ObjetoOrdenador : cuando se vendieron.
precio Artículo

clases conceptuales de especificación o descripción
se utilizan para especificar o describir otras clases
una clase EspecificaciónDelArtículo no representa un Artículo, sino una
descripción de la información sobre los artículos:
aunque se vendan todos los elementos inventariados, eliminándose las
correspondientes instancias software de Artículo, permanecerá la
EspecificaciónDelArtículo
habituales en entornos de gestión (sistemas de compras, ventas,
inventarios,...) y fabricación (descripciones de los productos
fabricados)
se usan cuando:
se necesita la descripción de un artículo o servicio independientemente de
la existencia actual de algún item de esos artículos o servicios
la eliminación de instancias de las cosas que describen provocan pérdida de
información que necesitaría mantenerse
reduce información redundante o duplicada



NO SI

Artículo
EspecificaciónDelProducto
artículoID
desc ribe Artículo
numeroSerie descripción
precio numeroSerie
descripción
1 n
artículoID
precio

Vuelo
Vuelo
descrit o por DescripcionVuelo
fecha fecha
numero
numero hora
1 n
hora
n
n describe vuelos a
vuela a

1
1 Aeropuerto
Aeropuerto nombre
nombre



reducción del salto en la
representación (salto Modelo del Dominio
semántico): Vista del personal involucrado de los conceptos más relevantes del
dominio
una de las grandes ventajas Visualiza los modelos del mundo real.
de la tecnología de objetos Venta
Pagada-median te Pago
reducción de la diferencia fecha
cantidad
entre el modo en el que el hora
1 1
personal involucrado concibe
el dominio y su representación
en el software inspira objetos y
nombres en el
ejemplo: modelo de diseño
un pago en el Modelo del
Dominio es una clase
conceptual (un concepto)
Venta
un pago en el Modelo de Pago
pagada mediant e
fecha : Date
Diseño es una clase software cantidad : Dinero
hora : Tiempo
no son lo mismo, pero el 1 1
getDevolucion() : Dinero
primero “inspiró” el nombre getTotal() : Dinero

y definición del segundo
Modelo del Diseño
El desarrollador orientado a objetos se ha inspirado en el dominio
del mundo real al crear las clases software.
Visualiza los componentes software


modelo del dominio: representar las clases

representar las clases en un modelo
del dominio
se utiliza la notación de clase de UML
Identificar clases

nombre clase


Persona
lista de atributos
nombre : Nombre
idEmpleado : Integer
Añadir las as ociac iones
necesarias cargo : String

obtenerFoto()
obtenerInformaciónDeContacto()
obtenerRegistrosPersonales()
necesarios

lista de operaciones (no se suelen
reflejar en el modelo del dominio)


modelo del dominio: representar las clases

Representación de las clases conceptuales del Sistema PDV

Registro Artículo Tienda Venta

LineaDeVenta Cajero Cliente Encargado

CatalogoDe Especificacion
Pago
Productos DelProducto


modelo del dominio: asociaciones

asociación
según UML, una asociación es “la relación semántica entre dos o
más clasificadores que implica conexiones entre sus instancias”

se registran las asociaciones:
de las que es necesario conservar el conocimiento de la relación
durante algún tiempo (por ejemplo, la relación entre
LíneaPedido y Pedido)
Identificar clases
derivadas de la Lista de Asociaciones Comunes

importante: registrar únicamente asociaciones útiles para
mantener el diagrama legible
es más importante dedicar tiempo a localizar las clases
conceptuales que a identificar las asociaciones

Flecha de dirección de
lectura. Normalmente
nombre de la se excluye.
asociación
Añadir las as ociac iones
necesarias

Venta
necesarios Pagada-median te Pago
fecha
cantidad
hora
1 1

multipli cidad



lista de asociaciones comunes
relación de categorías habituales que, normalmente, merece la
pena tener en cuenta
Categoría Ejemplos
Categoría Ejemplos
A es una parte física de Caja-Registro
A es miembro de B Cajero-Tienda
Ala-Avión
B Piloto-CompañíaAerea

A es una parte lógica de LineaDeVenta-Venta A utiliza o gestiona B Cajero-Registro
EtapaVuelo-RutaVuelo Piloto-Avión
B
A se comunica con B Cliente-Cajero
A está contenido Registro-Tienda, Artículo-
AgenteReservas-Pasajero
Estantería
físicamente en B
Pasajero-Avión
A está relacionado con Cliente-Pago
Pasajero-Billete
una transacción B
A está contenido DescripciónArtículo-
Catálogo
lógicamente en B
A es una transacción Pago-Venta
Vuelo-PlanificaciónVuelo
Reserva-Cancelación
relacionada con otra
A se conoce/registra/ Venta-Registro
transacción B
Reserva-ListaPasajeros
recoge/informa/captura
en B A está al lado de B LíneaDeVenta-
LíneaDeVenta
A es una descripción de DescripciónDelArtículo- Ciudad-Ciudad
Artículo
B
A es propiedad de B Registro-Tienda
DescripciónDelVuelo-Vuelo
Avión-CompañíaAerea
A es una línea de una LíneaDeVenta-Venta
A es un evento Venta-Cliente, Venta-
TrabajoMantenimiento-
transacción o importe Tienda
RegistroDeMantenimiento relacionado con B
de B Salida-Vuelo

A es una subunidad Departamento-Tienda relaciones cuya inclusión
relaciones cuya inclusión
Mantenimiento- en el Modelo de Dominio
organizativa de B en el Modelo de Dominio
CompañíaAerea es especialmente útil
es especialmente útil



Tienda
nombre de las
asociaciones 1
formato: NombreTipo –
FraseVerbal – Alberga
NombreTipo donde la
frase verbal crea una
secuencia legible y con 1..*
significado en el contexto Captura Pagada-mediante
del modelo Venta Pago
Registro
normalmente la dirección 1 1 1
1
por defecto para la
lectura de los nombres de
asociaciones es de Compañía
izquierda a derecha o
Aerea
arriba abajo

1
Emplea

1..n
Asignado-a Asignado-a
Persona Vuelo Avión
1 n n 1
n
1

fuente: C. Larman, UML y patrones, Prentice Hall, 2002
Supervisa



PÓLIZAS
PÓLIZAS



multiplicidad
indica cuántas instancias de una clase A pueden asociarse
con una instancia de una clase B
en un momento concreto
NO a lo largo de un periodo de tiempo
indica una restricción de diseño que será (o podrá ser)
reflejada en el software

*
Clase cero o más; muchos

1..*
Clase uno o más

1..40
Clase de uno a 40

5
Clase exactamente 5

3,5,8
Clase exactamente 3, 5 u 8



multiplicidad
puede existir cualquier tipo de multiplicidad,
pero en la práctica la mayoría de las
asociaciones pertenecen a uno de los
siguientes tipos
asociación de uno a uno: tiene una
multiplicidad de 1 a cada extremo. Significa
que existe solamente un vínculo entre
OficialPolicía NúmeroIdentificación
instancias de cada clase. Por ejemplo,
1 1
OficialPolicía tiene exactamente un
NúmeroIdentificación, y éste representa a uno
y sólo a un OficialPolicía

asociación de uno a muchos: tiene una
Asegurado Automó vil
1 1..*
multiplicidad de 1 en un extremo y 0..n en el
otro (a veces representado con un asterisco)
+propietario +propiedad

asociación de muchos a muchos: tiene una
multiplicidad de 0..n o 1..n en ambos
extremos. Indica que pueden existir una
escribe
Autor Libro
cantidad arbitraria de vínculos entre instancias
de las dos clases. Es el tipo más complejo de
* *
asociación.



pueden existir dos o más asociaciones entre dos clases
conceptuales

Vuela-a

n 1
Vuelo Aeropuerto

n Vuela-desde 1



Categoría Ejemplos

A es una parte física de B Registro-Caja

A es una parte lógica de B LineaDeVenta-Venta
A está contenido físicamente en B Registro-Tienda,
Artículo-Tienda
A está contenido lógicamente en B EspecificacionDelProducto-CatalogoDeProductos
CatalogoDeProductos-Tienda
A es una descripción de B EspecificacionDelProducto-Articulo

A es una línea de una transacción o informe de B LíneaDeVenta-Venta

A se conoce/registra/recoge/informa/captura en B (completa) Venta-Tienda
(actual) Venta-Registro
A es miembro de B Cajero-Tienda
A es una subunidad organizativa de B No aplicable
A utiliza o gestiona B Cajero-Registro
Encargado-Registro
Encargado-Cajero, aunque probablemente no es aplicable
A se comunica con B Cliente-Cajero
A está relacionado con una transacción B Cliente-Pago
Cajero-Pago
A es una transacción relacionada con otra Pago-Venta
transacción B
A está al lado de B LineaDeVenta-LineaDeVenta
A es propiedad de B o informe de B Registro-Tienda



navegabilidad
indica que es posible enviar mensajes en la dirección de la flecha en
uno de los dos extremos de asociación
no hay que especificarla hasta que el diagrama de clases sea estable

está cursando
Estudi ante Asignatura

En este caso, la clase Asignatura conoce
a la clase Estudiante, pero no al revés.



asociaciones reflexivas

+hijo
Persona
*
2
+padre
Crea



agregación
es un tipo de asociación que se utiliza para modelar las relaciones
todo-parte entre las cosas. El todo se denomina compuesto
normalmente se identifica en el Modelo de Diseño, pero puede ser
útil o necesario identificar algunas relaciones de agregación en el
Modelo del Dominio.
representación en UML: un rombo hueco o relleno en el extremo del
compuesto de una asociación todo-parte
el nombre de la asociación se suele excluir porque se piensa
normalmente como Tiene-parte

1 4
Coche Rueda

11

0..1
Radio
1
Motor



agregación de composición Coche
la parte es un miembro de un único objeto
compuesto y existe una dependencia de existencia y
1
disposición de la parte sobre el compuesto
la multiplicidad en la parte del compuesto sólo
puede ser 1
1
ejemplo: en una relación Coche – Motor, el motor
tiene sentido como tal (existe) únicamente si está Motor
asociado a un coche
representación en UML: un rombo relleno

agregación compartida
DiagramaUML
la multiplicidad en el extremo del compuesto puede
ser más de uno: la parte puede estar
simultáneamente en muchas instancias del *
compuesto
se utiliza para conceptos abstractos, no físicos
representación en UML: un rombo hueco *
ElementoUML



identificación de la agregación
si hay duda, se descarta
se debe mostrar una agregación:
cuando el tiempo de vida de la parte está ligado al tiempo de
vida del compuesto (existe una dependencia de creación –
eliminación de la parte en el todo).
cuando existe un ensamblaje obvio todo-parte físico o lógico
cuando alguna propiedad del compuesto se propaga a las
partes, como la ubicación
cuando las operaciones que se aplican sobre el compuesto se
propagan a las partes, como la destrucción, movimiento o
grabación

Venta LineaDeVenta

1 1..n

CatalogoDeProductos EspecificacionDelProducto
1..n
1



generalización
actividad de identificar elementos comunes
entre los conceptos y definir las relaciones
de superclase (concepto general) y PAGO
subclase (concepto especializado). Así, los
conceptos se representan en jerarquías de
clases. Pago con cheque
Pago en efectivo
superclase conceptual: su definición es
más general y abarca más que la definición
de una subclase Pago a crédito
subclase conceptual: debe ser un
miembro del conjunto de la superclase, es
decir, es un tipo de superclase
todos los miembros del conjunto de una
subclase conceptual son miembros del
conjunto de su superclase

Un Pago representa la
Un Pago representa la
transacción de transferir Pago
transacción de transferir
dinero para una compra cantidad : Dinero
dinero para una compra
de una parte a otra.
de una parte a otra.
PagoACredito es una
transferencia dees una
PagoACredito dinero
por medio de una dinero
transferencia de
por medio de una
institución de crédito que
autoriza la operación. que
institución de crédito PagoACredito
PagoEnEfectivo PagoConCheque
autoriza la operación.
Por tanto, Pago es una
Por tanto, Pago es una
definición más amplia y
general quemás amplia y
definición la de
PagoACredito. de
general que la fuente: C. Larman, UML y patrones, Prentice Hall, 2002
PagoACredito.


Ingeniería del Software de Gestión. Tema 3

Ingeniería del Software de Gestión. Tema 3

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Destacado

Destacado (20)

Similar a Ingeniería del Software de Gestión. Tema 3

Similar a Ingeniería del Software de Gestión. Tema 3 (20)

Más de Enrique Barreiro

Más de Enrique Barreiro (9)

Último

Último (20)

Ingeniería del Software de Gestión. Tema 3