PROCESO UNIFICADO: ANÁLISIS El proc proceso eso uni unific ficado ado de desar desarrol rollo, lo, Iva Ivarr Jac Jacobs obson, on, Grady Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999 The unified unified software developme development nt process, process, Ivar Jacob Jacobson, son, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999
Análisis 1. Visión general. 2. El El análisi s en el Pro Proceso ceso Unific Unif ica ado de De Desarroll sarro llo. o. 2.1 2.1 Artefa Art efact ctos. os. 2.1. 2.1.1 1 Mod Modelo elo de d e análi análisi sis. s. 2.1.2 Clases de análisis. 2.1. 2.1.3 3 Realiza Realizaci ción ón en análisis anális is de los casos caso s de uso. us o. 2.1.4 Paquetes de análisis. 2.2 2.2 Activi Acti vidade dades. s. 2.2.1 .2.1.. Análisis Análisi s de d e los casos c asos de d e uso. 2.2. 2.2.2. 2. Anális An álisis is de las clase cl ases. s. 2.2. 2.2.3. 3. Anális An álisis is de los paquetes paqu etes .
Ingeniería del software
2
Análisis 1. Visión general. 2. El El análisi s en el Pro Proceso ceso Unific Unif ica ado de De Desarroll sarro llo. o. 2.1 2.1 Artefa Art efact ctos. os. 2.1. 2.1.1 1 Mod Modelo elo de d e análi análisi sis. s. 2.1.2 Clases de análisis. 2.1. 2.1.3 3 Realiza Realizaci ción ón en análisis anális is de los casos caso s de uso. us o. 2.1.4 Paquetes de análisis. 2.2 2.2 Activi Acti vidade dades. s. 2.2.1 .2.1.. Análisis Análisi s de d e los casos c asos de d e uso. 2.2. 2.2.2. 2. Anális An álisis is de las clase cl ases. s. 2.2. 2.2.3. 3. Anális An álisis is de los paquetes paqu etes .
Ingeniería del software
2
2. El análisis en el Proceso Unificado Fases Actividades Concepción
El E laboración
Construcción
Transición
Requisitos
Análisis
Diseño
Implementación
Pruebas Iteración preliminar
Itera. #1
Itera. #2
Itera. #n
IngenieríaIteraciones del software
Itera. #n+1
Itera. #n+2
Itera. #m
Itera. #m+1 3
1. Visión general Mo d el o d e c as o s d e u s o
Mo d el o d e an ál i s i s
- Lenguaje del cliente
- Lenguaje del desarrollador
- Vista externa del sistema
- Vista interna del sistema
- Estructurado en casos de uso
- Estructurado en clases de análisis y paquetes
- Co Como contrato
- Co Como precursor del diseño
- Puede contener redundancias, inconsistencias inconsistencias (entre requisitos)
- No debería contener redundancias
- Ca Capt ptura ura la func funcio iona nalilida dad d del del sist sistem ema a
- Da forma forma a la la arq arqui uite tect ctur uraa par paraa sop soport ortar ar tal tal funcionalidad
Utilizare ti lizaremos mos difere dif erentes ntes diagrama d iagramas s para p ara expresa xpr esarr el modelo m odelo de análisi análisi s Ingeniería del software
4
1. Visión general - Durante Durante la captur captura a de requisit requisitos: os: lenguaje del cliente cli ente . - Es impreciso: impreciso: deja problemas problemas sin resolver (ambigüedades). (ambigüedades). Modelo de d e análisis nális is::
- especificación especificación detallada detallada (precisa) de requisitos. - refina los los casos de uso como colaboraciones colaboraciones entre clasificadores: clasificadores: clasificadores: clases de análisis, paquetes. colaboraciones: realizaciones de los casos de uso.
Gestionar as asignaturas
UI asignaturas
Realización en en an análisis
Gestor de asignaturas Ingeniería del software
Asignatura 5
1. Visión general Modelo de Caso de Uso
Modelo de Análisis
Modelo de
Diagramas de Casos de Uso Diagramas de Clases
Incluidos paquetes
Diagramas de Componentes Diagramas de Despliegue
Diseño Diagramas de Secuencias Modelo de Despliegue
Diagramas de Colaboraciones
Modelo de
Diagramas de Estados
Implementación
Modelo de Pruebas
Diagramas de Interacción
Diagramas de Actividad Diagramas de Objetos
Ingeniería del software
6
1. Visión general Requisitos
Análisis
Diseño
dependencia de traza
Modelo de Casos de Uso
Modelo de Análisis
Modelo de Diseño
Modelo de Despliegue
Modelo de Implementación
Implementación
Modelo de Pruebas
Pruebas
Ingeniería del software
7
2. El análisis en el Proceso Unificado 2.1 Artefactos. 2.1.1 Modelo de análisis. 2.1.2 Clases de análisis. 2.1.3 Realización en análisis de los casos de uso 2.1.4 Paquetes de análisis. 2.2 Actividades. 2.2.1. Análisis de los casos de uso. 2.2.2. Análisis de las clases. 2.2.3. Análisis de los paquetes.
Ingeniería del software
8
2.1.1. Artefactos. Modelo de análisis 2.1 Artefactos. 2.1.1 Modelo de análisis.
Representa la estructura global del sistema (subsistemas y/o capas en el modelo de diseño).
2.1.2 Clases de análisis.
Descripción arquitectónica
2.1.3 Realización en análisis de los C.U. 2.1.4 Paquetes de análisis
*
*
2.2 Actividades. 2.2.1. Análisis de los casos de uso.
Modelo de análisis
Paquete de análisis
2.2.2. Análisis de las clases. 2.2.3. Análisis de los paquetes.
Responsabilidades Atributos Relaciones
*
*
Clase de análisis
Interfaz Control Ingeniería del software
**
Diagramas de clases Diagramas de interacción Descripción textual
Realización en análisis
Entidad 9
2.1.2. Artefactos. Clases de análisis 2.1 Artefactos.
2.1.1 Modelo de análisis.
2.1.2 Clases de análisis. 2.1.3 Realización en análisis de los C.U. 2.1.4 Paquetes de análisis
Representa una abstracción de lo que serán una o varias clases en diseño. Se centra en los requisitos funcionales.
2.2 Actividades. 2.2.1. Análisis de los casos de uso.
Resposabilidades Atributos Relaciones
Clase de análisis
2.2.2. Análisis de las clases. 2.2.3. Análisis de los paquetes.
Interfaz
Control Ingeniería del software
Entidad 10
Utilizamos el ejemplo…. Un sistema de enseñarza virtual Actor: Estudiante Caso de Uso: Matricularse …….. Sist. de enseñanza virtual Matricularse
Matricularse
Estudiante
Ingeniería del software
11
2.1.2. Artefactos. Clases de análisis Clases límite o interfaz <> IU Matriculación
IU Matriculación
IU Matriculación
- Modelan la interacción entre el sistema y los actores. - Representan la interfaz del sistema (ventanas, formularios, ...), pero con poco detalle. - Describen la información presentada al actor y las peticiones que hace el actor al sistema.
UI Matriculacion
Estudiante Ingeniería del software
12
2.1.2. Artefactos. Clases de análisis Clases Entidad
<> Alumno
Alumno
Alumno
- Representan la información significativa para el sistema. - Modelan la información de larga vida ( persistencia ). - Pueden provenir de las entidades del dominio o de las del negocio, pero no tienen por qué corresponderse completamente. - Pueden ser pasivas o activas (comportamiento complejo). - Encapsulan información y operaciones asociadas. - Por ejemplo: repositorios de información.
Estudiante
UI Matriculacion
GestorMatricula Alumno
Ingeniería del software
13
2.1.2. Artefactos. Clases de análisis Clases Control
<> GestorMatricula
GestorMatricula
GestorMatricula
- Se usan para representar el control de un caso de uso concreto - Representan la coordinación entre objetos. - Lógica del negocio, cálculos. - No representan ni interacciones con el usuario ni problemas de almacenamiento de información.
Estudiante
UI Matriculacion
GestorMatricula
Ingeniería del software
14
2.1.3. Artefactos. Realización en análisis de los casos de uso - Es una colaboración que describe cómo se realiza en análisis un caso de uso en términos de clases de análisis y sus interacciones.
2.1 Artefactos. 2.1.1 Modelo de análisis.
2.1.2 Clases de análisis. 2.1.3 Realización en análisis de los C.U. 2.1.4 Paquetes de análisis
Modelo de casos de uso
Modelo de análisis <>
2.2 Actividades. 2.2.1. Análisis de los casos de uso. 2.2.2. Análisis de las clases. 2.2.3. Análisis de los paquetes.
Use case
Realización en análisis
- La realización en análisis de un caso de uso, incluye: - diagramas de cl ases : clases participantes - diagramas de interacción : escenarios del CU. - descripción textual del flujo de eventos - nada de requisitos no funcionales (hasta el diseño). Ingeniería del software
15
2.1.3. Artefactos. Realización en análisis de los casos de uso. Diagramas de clase - Una clase de análisis puede participar en varios casos de uso . - Algunas responsabilidades, atributos y asociaciones suelen ser específicos de un sólo caso de uso.
Estudiante
UI Matriculación
Gestor Matricula
Alumno
Diagrama de clases para la realización del caso de uso “Matricularse”
Ingeniería del software
16
2.1.3. Artefactos. Realización en análisis de los casos de uso. Diagramas de interacción - La secuencia de acciones en un caso de uso comienza cuando un actor envía un mensaje a una clase límite. - Se van a utilizar diagramas de colaboración. - Ejemplo: Caso de uso “Publicar notas” del actor “Profesor” 3: seleccionar (asignatura, ficheroNotas) 4: publicar (asignatura, ficheroNotas) 1: publicar notas 5: notas (ficheroNotas)
: Profesor
: UI Profesor
7: OK
: GPr
6: OK
: Asignatura
2: visualizar ("asignaturas") 8: visualizar (notas publicadas) Ingeniería del software
17
2.1.3. Artefactos. Realización en análisis de los casos de uso. Flujo de eventos y Requisitos no funcionales Flujo de eventos.
- Para clarificar los diagramas de colaboración: descripción textual. - Si es muy complejo ¿no será mejor dividir el caso de uso? Requisitos No funcionales.
- Asignados a casos de uso. - Se recogen si aparecen.
Ingeniería del software
18
2.1.4. Artefactos. Paquetes de análisis 2.1 Artefactos.
*
2.1.1 Modelo de análisis.
2.1.2 Clases de análisis.
Paquete de análisis
2.1.3 Realización en análisis de los C.U. 2.1.4 Paquetes de análisis 2.2 Actividades. 2.2.1. Análisis de los casos de uso. 2.2.2. Análisis de las clases.
*
* Clase de análisis
Realización en análisis
2.2.3. Análisis de los paquetes.
- Para organizar los artefactos de análisis: clases de análisis, realización de casos de uso y otros paquetes. - Fuertemente cohesionados y débilmente acoplados. - No existen en tiempo de ejecución. Ingeniería del software
19
2. El análisis en el Proceso Unificado 2.1 Artefactos. 2.1.1 Modelo de análisis. 2.1.2 Clases de análisis. 2.1.3 Realización en análisis de los casos de uso 2.1.4 Paquetes de análisis. 2.2 Actividades. 2.2.1. Análisis de los casos de uso. 2.2.2. Análisis de las clases. 2.2.3. Análisis de los paquetes.
Ingeniería del software
20
2.2. Actividades
Para ilustrar las actividades, utilizaremos el ejemplo del cajero automático. Validar usuario
Sacar dinero Cliente del banco
Ingresar dinero
Transferencia
Ingeniería del software
21
2.2.1. Actividades. Análisis casos de uso 2.1 Artefactos.
2.1.1 Modelo de análisis.
2.1.2 Clases de análisis. 2.1.3 Realización en análisis de los C.U. 2.1.4 Paquetes de análisis
2.2 Actividades. 2.2.1. Análisis de los casos de uso. 2.2.2. Análisis de las clases.
Identificar las clases de análisis necesarias para la realización del caso de uso. Distribuir el comportamiento del caso de uso entre las clases de análisis. Capturar/asignar requisitos no funcionales a clases de análisis.
2.2.3. Análisis de los paquetes.
Ingeniería del software
22
2.2.1. Actividades. Análisis casos de uso Identificar las clases de análisis
Clases entidad se derivan de la descripción del caso de uso. Una clase interfaz por cada actor. Una clase de control que gobierne en flujo del caso de uso
Representar las clases de análisis en un diagrama de clases
Ingeniería del software
23
Análisis del caso de uso: “Validar usuario”
Validar usuario
Realización en análisis
Interfaz de cajero
UsuariosDelBanco
Autenticar
(from Logical View)
(from Logical View)
Ingeniería del software
24
2.2.1. Actividades. Análisis casos de uso Describir las interacciones entre objetos
Utilizar diagramas de colaboración instancias y enlaces 1 diagrama de colaboración por cada camino del caso de uso Sobre los diagramas de colaboración: inicia un actor expresión de las interacciones: mensajes
Ingeniería del software
25
Análisis del caso de uso: “Validar usuario” Camino Básico 3: código 1: introducir tarjeta
: Cliente del banco
4: autentica (datos, código)
7: visualiza (opciones) 2: teclear código : Interfaz de cajero : Autenticar 5: valida (datos, codigo)
8: seleccioneOpcion (opciones) 6: OK
: UsuariosDelBanco
Ingeniería del software
26
Análisis del caso de uso: “Validar usuario” Camino Alternativo: Código incorrecto 3: código 1: introducir tarjeta
: Cliente del banco
4: autentica (datos, código)
7: visualiza (error) 2: teclear código : Interfaz de cajero : Autenticar 5: valida (datos, codigo) 8: teclear código 6: Error
Faltaría: - anular transacción (después del 2) - si 3 veces error: cancelar y quedarse con la tarjeta. Ingeniería del software
: UsuariosDelBanco
27
Análisis del caso de uso: “Sacar dinero” Sacar dinero
Realización en análisis
Interfaz de cajero
(from Logical View)
Cliente del banco
Cuenta
Transacción
Interfaz de cajero
(from Logical View)
Transacción
Cuenta
(from Use Case View)
Ingeniería del software
28
Análisis del caso de uso: “Sacar dinero” Camino básico 11: dinero retirado 9: tarjeta retirada 3: importe 1: sacar dinero
: Cliente del banco
4: retirarDinero (importe)
7: expulsaDinero (importe) 2: teclee importe : Interfaz de cajero : Transacción 8: retirar tarjeta 10: retirar dinero
5: reintegro (importe) 6: OK
12: teclear código : Cuenta Ingeniería del software
29
Análisis del caso de uso: “Sacar dinero” Camino Alternativo: No hay saldo 10: tarjeta retirada 3: importe 1: sacar dinero
: Cliente del banco
4: retirarDinero (importe)
7: no hay fondos 2: teclee importe : Interfaz de cajero 8: no hay saldo suficiente 9: retirar tarjeta
: Transacción 5: reintegro (importe)
6: no hay saldo
11: teclear código
Falta:
: Cuenta
- en el cajero no hay dinero. - se ha superado el límite diario Ingeniería del software
30
Análisis del caso de uso: “Ingresar dinero” Ingresar dinero
Realización en análisis
Interfaz de cajero
Cliente del banco
Transacción
Cuenta
(from Logical View)
(from Logical View)
Interfaz de cajero
Transacción
Cuenta
(from Use Case View)
Ingeniería del software
31
Análisis del caso de uso: “Ingresar dinero” Camino básico 5: dinero introducido 6: validar (importe) 3: importe 1: ingresar dinero
: Cliente del banco
2: teclee importe : Interfaz de cajero
4: introducir dinero
7: ingresarDinero (importe)
10: OK : Transacción 8: ingreso (importe) 9: OK
11: dinero ingresado
: Cuenta
Ingeniería del software
32
Análisis del caso de uso: “Ingresar dinero” Camino alternativo: Cantidad incorrecta
: Cliente del banco
: Interfaz de cajero
Ingeniería del software
33
Análisis del caso de uso: “Ingresar dinero” Camino Alternativo: Cantidad incorrecta 5: dinero introducido 6: validar (importe) 3: importe 1: ingresar dinero
: Cliente del banco
2: teclee importe : Interfaz de cajero 4: introducir dinero 7: importe incorrecto
Ingeniería del software
34
Análisis del caso de uso: “Transferencia”
Suponemos que el usuario ya ha sido identificado. La cuenta origen es la de la tarjeta y hay que teclear la destino. El importe y el nº de cuenta destino se dan juntos. Mirar primero si hay saldo y luego sacar.
Transferencia
Realización en análisis
Interfaz de cajero
Transacción (from Logical View)
Ingeniería del software
Cuenta (from Logical View)
35
Análisis del caso de uso: “Transferencia” Camino básico 5: cuenta destino 3: cantidad 1: transferencia
: Cliente del banco
6: transferencia (cuenta, cantidad)
11: OK
: Interfaz de cajero
: Transacción
7: reintegro (cantidad)
2: teclee cantidad
9: ingreso (cantidad) 4: teclee cuenta destino
8: OK 10: OK
12: transferencia realizada
cuentaOrigen : Cuenta Ingeniería del software
cuentaDestino : Cuenta
36
Análisis del caso de uso: “Transferencia” C. Alternativo: No hay fondos en la cuenta origen 5: cuenta destino 3: cantidad 1: transferencia
: Cliente del banco
6: transferencia (cuenta, cantidad)
: Interfaz de cajero
: Transacción 7: reintegro (cantidad)
2: teclee cantidad 4: teclee cuenta destino
cuentaOrigen : Cuenta Ingeniería del software
cuentaDestino : Cuenta
37
Análisis del caso de uso: “Transferencia” C. Alternativo: No hay fondos en la cuenta origen 5: cuenta destino 3: cantidad 1: transferencia
6: transferencia (cuenta, cantidad)
9: no hay fondos : Interfaz de cajero : Transacción
: Cliente del banco
2: teclee cantidad 4: teclee cuenta destino
7: reintegro (cantidad)
8: no hay saldo
10: no hay fondos
cuentaOrigen : Cuenta Ingeniería del software
38
Análisis del caso de uso: “Transferencia” Camino Alternativo: Cuenta destino incorrecta 5: cuenta destino 3: cantidad 1: transferencia
6: transferencia (cuenta, cantidad)
: Interfaz de cajero
: Cliente del banco
: Transacción 7: reintegro (cantidad)
2: teclee cantidad
9: ingreso (cantidad) 4: teclee cuenta destino
8: OK
cuentaOrigen : Cuenta
Ingeniería del software
cuentaDestino : Cuenta
39
Análisis del caso de uso: “Transferencia” Cuenta destino 5:incorrecta cuenta destino
11: rollback
3: cantidad 1: transferencia
6: transferencia (cuenta, cantidad)
12: error
: Interfaz de cajero
: Cliente del banco
: Transacción
7: reintegro (cantidad)
2: teclee cantidad
9: ingreso (cantidad) 4: teclee cuenta destino
8: OK 10: error
13: error
cuentaOrigen : Cuenta
Ingeniería del software
cuentaDestino : Cuenta
40
Diagrama de clases completo (ejemplo)
Cuenta
Cliente del banco
Interfaz de cajero
Transacción
(from Use Case View)
UsuariosDelBanco
Ingeniería del software
41
2.2.3. Actividades. Análisis de las clases 2.1 Artefactos. 2.1.1 Modelo de análisis.
2.1.2 Clases de análisis.
2.1.3 Realización en análisis de los C.U. 2.1.4 Paquetes de análisis
2.2 Actividades. 2.2.1. Análisis de los casos de uso. 2.2.2. Análisis de las clases.
Identificar las responsabilidades de las clases de análisis Identificar atributos y relaciones de las clases de análisis. Capturar requisitos especiales
2.2.3. Análisis de los paquetes.
Ingeniería del software
42
2.2.3. Actividades. Análisis de las clases Identificar responsabilidades En cada caso de uso, ver qué papel juega (diagramas de colaboración). Combinar papeles y describirlos juntos.
Ingeniería del software
43
Análisis de las clases. Identificar responsabilidades. “Validar usuario”. Secuencia correcta 3: código 1: introducir tarjeta
4: autentica (datos, código)
7: visualiza (opciones) 2: teclear código : Interfaz de cajero : Autenticar
: Cliente del banco
5: valida (datos, codigo) 8: seleccioneOpcion (opciones) 6: OK
Interfaz de cajero
Transacción
visualizar “introducir tarjeta” autentica (datos, código) visualizar “teclear código” UsuariosDelBanco leer código valida (datos, código) visualizar (opciones) seleccioneOpcion (opciones) Ingeniería del software
: UsuariosDelBanco
44
Análisis de las clases. Identificar responsabilidades “Validar usuario”. Secuencia correcta 3: código 1: introducir tarjeta
: Cliente del banco
4: autentica (datos, código)
7: visualiza (opciones) 2: teclear código : Interfaz de cajero : Autenticar 5: valida (datos, codigo)
8: seleccioneOpcion (opciones) 6: OK
Interfaz de cajero Visualizar (mensaje)
Transacción
autentica (datos, código)
leer código UsuariosDelBanco seleccioneOpcion (opciones) valida (datos, código)
Ingeniería del software
: UsuariosDelBanco
45
Análisis de las clases. Identificar responsabilidades “Validar usuario”. Código incorrecto 3: código 1: introducir tarjeta
: Cliente del banco
4: autentica (datos, código)
7: visualiza (error) 2: teclear código : Interfaz de cajero : Autenticar 5: valida (datos, codigo) 8: teclear código
Interfaz de cajero
Transacción
autentica (datos, código) Visualizar (mensaje) leer código UsuariosDelBanco seleccioneOpcion (opciones) valida (datos, código)
Ingeniería del software
6: Error
: UsuariosDelBanco
46
Análisis de las clases. Identificar responsabilidades “Sacar dinero”. Secuencia correcta 11: dinero retirado 9: tarjeta retirada 3: importe
4: retirarDinero (importe)
1: sacar dinero
: Cliente del banco
2: teclee importe 7: expulsaDinero (importe) 8: retirar tarjeta : Interfaz de cajero : Transacción 10: retirar dinero 12: teclear código
Interfaz de cajero
Transacción
Visualizar (mensaje) leer código seleccioneOpcion (opciones) leer importe (3) expulsaDinero (importe) (7)
autentica (datos, código) retirarDinero (importe) (4) UsuariosDelBanco
valida (datos, código)
5: reintegro (importe) 6: OK
: Cuenta
Cuenta
reintegro (importe) (5) Ingeniería del software
47
2.2.3. Actividades. Análisis de las clases Identificar atributos
Suelen ser nombres. Los tipos son conceptuales Clases entidad: derivados del dominio. Clases interfaz con actores humanos: campos de texto, etiquetas, etc Clases interfaz con subsistemas externos: propiedades de la interfaz de comunicación. Clases control: estado de la sesión actual.
Ingeniería del software
48
Análisis de las clases. Identificar atributos “Validar usuario”. Secuencia correcta 3: código 1: introducir tarjeta
: Cliente del banco
4: autentica (datos, código)
7: visualiza (opciones) 2: teclear código : Interfaz de cajero : Autenticar 5: valida (datos, codigo)
8: seleccioneOpcion (opciones) 6: OK
Interfaz de cajero Transacción
códigoCuenta
: UsuariosDelBanco
UsuariosDelBanco
colección de pares (datosCuenta, codigo) Ingeniería del software
49
Análisis de las clases. Identificar atributos “Transferencia”. Secuencia correcta 5: cuenta destino 3: cantidad
6: transferencia (cuenta, cantidad)
1: transferencia
: Cliente del banco
2: teclee cantidad
11: OK
: Interfaz de cajero
: Transacción
4: teclee cuenta destino 7: reintegro (cantidad) 9: ingreso (cantidad)
12: transferencia realizada
8: OK
Interfaz de cajero
10: OK
Transacción Cuenta
saldo
códigoCuenta cantidad
cuentaOrigen : Cuenta
cuentaDestino : Cuenta
UsuariosDelBanco
colección de pares (datosCuenta, codigo) Ingeniería del software
50
Análisis de las clases Clase
Atributos
Responsabilidades
Interfaz de cajero
“Definir IU”
visualizar (mensaje) leer (tarjeta); leer (código) leer (importe) expulsarDinero (importe) noHayFondos validar (importe); errorIngreso seleccioneOpcion (opciones)
UsuariosDeBanco
colección de pares (datosCuenta, codigo)
validar (datos, código)
Cuenta
Saldo límite diario
reintegro (importe) ingreso (importe)
Transacción
código cuenta cantidad
autenticar (datos, código) retirarDinero (importe) ingresarDinero (importe) transferencia (cuenta, cantidad)
Ingeniería del software
51
2.2.3. Actividades. Análisis de las clases Identificar asociaciones y agregaciones Definir multiplicidad y papeles Agregación y composición Identificar generalizaciones y/o especializaciones entre clases
Ingeniería del software
52