1

Curso 2013-2014

Ingeniería del SoftwareUn enfoque crítico

“Probadlo todo y quedaos con lo bueno” (Pablo de Tarso)

Gonzalo GénovaAnabel Fraga

2

Contenido

• Tema I. Ingeniería de requisitos– Unidad 1. Introducción a la ingeniería de requisitos

– Unidad 2. Obtención y descripción de requisitos

– Unidad 3. Cómo escribir buenos requisitos

– Unidad 4. Tipos de requisitos

– Unidad 5. Propiedades, atributos y organización de los requisitos

• Tema II. Modelado conceptual– Unidad 6. Modelado conceptual (1)

– Unidad 7. Modelado conceptual (2)

– Unidad 8. Modelado conceptual (3)

– Unidad 9. Sobre la diferencia entre análisis y diseño (artículo)

• Tema III. Modelado arquitectónico– Unidad 10. Arquitectura del software

– Unidad 11. Componentes, dependencias e interfaces

– Unidad 12. Diseño por contratos

3

Introducción a la ingeniería de requisitos

• Qué es la Ingeniería de Requisitos– Captura y Análisis

– Definición de requisito

– El documento de especificación de requisitos

• Necesidad de la Ingeniería de Requisitos– Para construir algo, antes hay que entender qué es ese “algo”

• Por qué es necesario escribir los requisitos– Sin requisitos escritos es imposible...

– No hay ingeniería profesional sin requisitos escritos

• Dificultades de la Ingeniería de Requisitos– El precio pagado: es una necesidad, no un lujo

• La Ingeniería de Requisitos en el contexto del proyecto– Pre-proyecto: valor contractual, viabilidad, planificación, estimación...

4

La ingeniería del software

• Ingeniería del software– “Es la aplicación sistemática de conocimientos, métodos y experiencias

científicas y tecnológicas al diseño, implementación, pruebas y documentación de software” (IEEE 24765-2010 Systems and Software Engineering – Vocabulary).

• Ingeniería de requisitos:– “Es el desarrollo sistemático de los requisitos a través de un proceso

iterativo y cooperativo en el que se analiza el problema, se documentael resultado en diversos formatos de representación, y se comprueba la exactitud de la comprensión alcanzada” (Loucopoulos & Karakostas. Systems Requirements Engineering. McGraw-Hill, 1995).

• Peculiaridades de la ingeniería software / ingeniería informática– El “producto” software– Mucho desarrollo, poca disciplina ingenieril– Necesidad de describir y documentar lo que se va a producir– Cambios frecuentes en el producto

5

Un caso práctico

• “Necesito algo para organizar mejor mis actividades, una agenda para llevar al día mi horario, mis compromisos, etc.”

Día

Compromiso

Compromiso

Compromiso

%

x x x x x x xx x x x x x xx x x x x x xx x x x x x xx x x x x x x

MES

6

Definición de requisito

• Según IEEE (24765-2010), un requisito es:– Una condición o capacidad que un usuario necesita.

– Una condición o capacidad que debe poseer un sistema.

– Una representación documentada de una condición o capacidad.

• Dos tipos principales de requisitos:– Requisitos de capacidad (funcionales): funciones y operaciones

requeridas para resolver un problema o alcanzar un objetivo.

– Requisitos de restricción (no funcionales): restricciones impuestas sobre la manera en que el problema es resuelto o el objetivo es alcanzado.

7

The Chaos Report

• The Standish Group International: realiza estudios desde 1994

• 2003: datos de 13.522 proyectos de tecnologías de la información

1994 1996 1998 2000 2003

Proyecto exitoso 16% 27% 26% 28% 34%

Proyecto completo

pero deficiente53% 33% 46% 49% 51%

Proyecto

cancelado31% 40% 28% 23% 15%

8

The Chaos Report

0,00%10,00%20,00%30,00%40,00%50,00%60,00%70,00%80,00%90,00%

100,00%

1994 1996 1998 2000 2003

Años

Po

rce

nta

je

Proyecto exitoso Proyecto completo pero deficiente

Proyecto cancelado

9

Identificar

Entrevistar

Escribir

Revisar

[conforme]

[no conforme]

Obtención y descripción de requisitos del usuario

• Las fuentes de los requisitos • Plan de trabajo para obtener los requisitos• Identificación de stakeholders

– ¿Quiénes tienen interés en el producto? – ¿Quién es el cliente?– Intereses contrapuestos, requisitos

contradictorios– Negociar el equilibrio

• Cómo llevar adelante una entrevista– Antes, durante, después...

Requisitos Calidad

Presupuesto Recursos

Planificación Tiempo

10

Técnicas para la obtención y descripción de requisitos

• Textuales– Relativamente accesibles a un cliente sin formación específica

• Texto en prosa común y corriente

• Texto estructurado, lenguaje técnico

• Casos de uso

• Tabla de roles de usuario y servicios/funciones requeridos por cada uno

• Gráficas– Requieren un cierto grado de formación técnica en el cliente

– Tienen el peligro de convertir el análisis de requisitos en diseño

• Diagramas de flujo de datos

• Diagramas de actividad

• Diagramas de estados

• Interfaces de usuario y prototipos– No confundir con diseño, valorar la inversión

11

Ejemplo: Feria de subastas

• Se desea modelar un sistema informático para gestionar las transacciones en un recinto ferial de subastas. Cualquier persona que haya logrado acceso al recinto de la feria puede conectarse al sistema a través de alguno de los muchos terminales disponibles, y participar en las subastas que tengan lugar, en alguna de las modalidades ofrecidas por el sistema, es decir, como comprador, como vendedor, o como simple observador.

• Para subastar algún artículo es necesario darse de alta como vendedor. El vendedor puede registrar artículos en la subasta, rellenando una ficha por cada artículo (foto, descripción, etc.), que sale así inmediatamente a subasta.

• Análogamente, para participar en una subasta es necesario darse de alta como comprador. El comprador puede pujar por cualquiera de los artículos subastados en la feria. Cuando no se produce ninguna nueva puja, el artículo queda definitivamente adjudicado al comprador. Si un artículo no ha recibido ninguna puja, el vendedor puede modificar alguno de sus datos. La compra-venta se formaliza posteriormente en las oficinas ante un administrador que actúa como intermediario.

• Cualquier persona puede participar como observador en una subasta, es decir, puede consultar la lista de artículos subastados y seleccionar uno de ellos para examinar la lista de pujas. Un observador puede registrarse como vendedor o comprador para participar activamente en la subasta.

12

Feria de subastas: tabla de roles/servicios

Rol de Usuario Servicio o función requerido

Anónimo

Consultar lista de artículos subastados

Alta como usuario vendedor

Alta como usuario comprador

VendedorPoner un artículo en subasta

Modificar los datos del artículo no vendido

Comprador Pujar por un artículo subastado

Vendedor

Comprador

Administrador

Formalizar la compra-venta en oficinas

Administrador ...

13

Beneficio de la inversión en prototipos

Beneficio obtenido (% ahorro/gasto)

Gasto efectuado(% prototipo/total)

100%

Adaptado de E. Braude,Software Engineering: An Object-Oriented Perspective

0%

Beneficio óptimo

Recursos malgastados

GUI simplificada

14

Cómo debería ser una especificación de requisitos

• Completa: describe todas las necesidades relevantes para los stakeholders.

• Consistente: carece de conflictos entre requisitos.

• Correcta: todo es pertinente y no contiene errores.

• Modificable: facilidad para efectuar cambios de forma sencilla, completa y consistente.

• Verificable: existencia de un proceso acotado que determine si el sistema final satisface el requisito.

• Trazable: el origen del requisito está marcado de forma clara; y se puede seguir el impacto del requisito a lo largo del desarrollo.

• Clara y no ambigua: una única interpretación.

IEEE 830, 1998

15

Los siete pecados del especificador

• Ruido– Presencia en el texto de información irrelevante para el problema.

• Silencio– Existencia de aspectos del problema no cubiertos por la especificación.

• Sobre-especificación– Elementos que no corresponden al problema sino a una posible solución.

• Contradicción– Una misma característica definida de dos o más formas incompatibles.

• Ambigüedad– Elementos del texto que admiten varias interpretaciones distintas.

• Referencia futura– Referencia a una característica del problema definida más adelante.

• Pensamiento ilusorio– Definir el problema de tal forma que imposibilita una solución realista.

(Bertrand Meyer, On Formalism in Specification, IEEE Software, Jan 1985, pp. 6-26)

16

Especificación inteligente de requisitos

Sigla Concepto Descripción

S eSpecífico Claros y simples: qué, por quéT

M Medible Se puede cuantificar y evaluar

A Alineado Con la estrategia o con el fin del sistema

R Realista Puede conseguirse con un número de recursos lógico

T limitado en Tiempo

Establece un periodo de tiempo claro

"I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning

him safely to Earth"

17

Estructura de la especificación

• Un proyecto mediano puede tener centenares de requisitos

• Escribir los requisitos para no olvidarlos. De esta forma:– Pueden ser firmados, con lo que son pieza clave en contratos

– Son la fuente del diseño

– Se verificará el software contra ellos

• La correcta organización de los mismos es vital

• Claves:– Utiliza estándares de estructuración de especificaciones de requisitos

– Aclara el objetivo global a cumplir por el sistema

– Emplea descripciones textuales y gráficas

– Ordena y agrupa tus requisitos de forma lógica

– Relaciona unos requisitos con otros para facilitar su entendimiento

– Relaciona los requisitos con otros activos

18

Especificaciones completas

• ¿Qué podemos hacer para no olvidar nadaT?– Revisión por pares: junto con compañeros más experimentados, expertos

en la materia, cliente y otros interesados

– Emplear check-lists

– Comparar la especificación contra taxonomías propias de la materia

– Reutilizar requisitos de proyectos previos

• Reutilización de grano grueso: componentes reutilizables

• Reutilización de grano fino: buscadores avanzados

19

Especificaciones consistentes

• El primer paso hacia la consistencia es evitar redundanciaT– T y las inconsistencias provocan retrabajo

• Las revisiones en grupo permiten detectar parte de estas redundancias

• Técnicas automáticas para su apoyo:– Comparación de grafos semánticos

– Detección de unidades inconsistentes

• “NASA y ESA reconocen la pérdida de una sonda marciana por haber diseñado dos módulos empleando diferentes sistemas de medida”

• Revisiones globales de la especificación

• Detección automática de unidades de medida inconsistentes

20

Especificaciones consistentes

• Comparación de grafos semánticos:UR001: T.

UR023: El sistema deberá enviar notificaciones semanales de nuestras ofertas a todos los clientes

URxxx: T

UR842: La aplicación debe ser capaz de notificar periódicamente a sus clientes sobre nuestras ofertas

UR999: T

UR023

UR842

<<Notificar>>

Sistema Cliente Oferta

21

Una especificación de requisitos no es una novela (1)

Novela Especificación de requisitos

Múltiples estilos narrativos Estilo narrativo objetivo, “plano”

Abiertas a todo tipo de licencias poéticas y adornos:

Generalmente se viste de

manera victoriana, incluyendo un

traje, botas de montar, y una

ostentosa corbata de moño

intrincadamente atada/

Licencias poéticas no permitidas:

• Textos simples y claros para facilitar su lectura y entendimiento

• Siguiendo un conjunto de gramáticas fijas y simples

• Usando la voz activa en lugar del pasivo

• Evitando terminología técnica no definida, abreviaturasT

• Utilizando un vocabulario controlado, donde los términos estén bien consensuados

• Prescindiendo de especulaciones

Suelen jugar con nuestra imaginación:

La verdad es que Robert parecía

mayor, no aparentaba los 32

años que tenía.

No pueden jugar con nuestra imaginación ni dejar “cabos sueltos”:

• Los requisitos, además de simples, deben ser fáciles de medir.

• Ambigüedad cero, para que todos los interesados interpretemos cada requisito de una única forma.

22

Una especificación de requisitos no es una novela (2)

Novela Especificación de requisitos

Puede hacer referencias a otros textos o a elementos implícitos del entorno cultural del lector.

No deben dar ningún conocimiento por sentado:

• Deben ser autocontenidos.

• En el mejor de los casos, acompañados incluso de glosarios.

Pueden mezclar diferentes hilos argumentales, dar saltos atrás y adelante en el tiempoT

Debe adoptarse un orden lógico y bien estructurado.

• Cada requisito debe ser atómico, debe expresarse una única necesidad por requisito.

Se redactan con maravillosos procesadores de texto.

Deben escribirse con herramientas especializadas.

Con ello conseguimos:

• Identificarlos unívocamente

• Atomizarlos

• Organizarlos, categorizarlos y relacionarlos

• Reutilizarlos por separado o en conjunto

• Medir su calidad individual o global

23

Redacción del requisito: indicadores de calidad

• Tamaño del requisito: – El justo, ni muy breve ni muy largo

– Tamaño medido en caracteres, palabras, párrafos

• Legibilidad:– La máxima posible

– Procesadores como MS Word miden la legibilidad de los textos

• Tiempo verbal:– Forma “imperativa” en lugar de condicional, usar estilo uniforme en todos los requisitos

• el usuario puede ver (enviar, abrir...) / el usuario podrá ver (enviar, abrir...): ok

• el usuario debe poder ver / deberá ser capaz de ver: demasiado recargado

• Modo verbal:– Activa en lugar de pasiva

• Sentencias opcionales y especulativas: – Evitar sentencias del estilo “quizáT” , “posiblementeT”, “usualmenteT”, “casi siempreT”

• Expresiones ambiguas:– Evitar expresiones del estilo: “rápido”, “amigable”T

24

Redacción del requisito: indicadores de calidad

• Sentencias subjetivas:– Evitar sentencias del tipo: “yo creoT”, “en mi opiniónT”

• Sentencias implícitas (empleo de pronombres):– Evitar el abuso de los pronombres

– A la hora de la lectura, podríamos dudar en qué nombre sustituye cada nombre

• Conectores:– El abuso de conectores puede indicar que se está incluyendo más de una necesidad en el

mismo requisito

– También puede indicar un exceso de detalle

• Negaciones:– Más de una palabra negativa en la misma frase podría hacerla difícil de entender

• Sentencias incompletas:– Evitar sentencias del tipo “etcéteraT”, “Tentre otrosT”, “T”

• Términos propios de diseño o de flujo:– Evitar términos que denotan diseño como por ejemplo “clave ajena”, “tabla hash”T

25

Redacción del requisito: indicadores de calidad

• Número de términos del dominio:– Un exceso de términos del dominio puede indicar que se están mezclando diferentes

necesidades en el mismo requisito

– También puede indicar que se está dando un excesivo detalle

• Número de verbos principales (del dominio):– Un exceso de verbos del dominio puede indicar que se están mezclando diferentes

necesidades en el mismo requisito

– También puede indicar que se está dando un excesivo detalle

• Acrónimos y abreviaturas:– Sólo permitidos si están definidos en alguna sección del documento de requisitos

• Estructura gramatical:

Usuario El operador del Call CenterT

Acción T deberá ser capaz de verT

Objeto T detalles de cada compañía contactadaT

Cualificador T en menos de dos segundos.

26

• La información sobre los usuarios debería almacenarse en memoria dentro de una tabla hash, o bien en una tabla de base de datos, con una clave ajena a la tabla de Usuarios.– Evite el uso del modo condicional

– Sustitúyalo por el imperativo

• La información sobre de los usuarios deberá almacenarse en memoria dentro de una tabla hash, o bien en una tabla de base de datos, con una clave ajena a la tabla de Usuarios.

Errores típicos (1): modo condicional

27

Errores típicos (2): detalles de diseño

• La información sobre los usuarios deberá almacenarse en memoria dentro de una tabla hash, o bien en una tabla de base de datos, con una clave ajena a la tabla de Usuarios.– Evite detalles propios de diseño

• La información sobre los usuarios deberá almacenarse en el sistema.

28

• El administrador deberá ser capaz de insertar, borrar, mostrar y actualizar la información sobre los usuarios. Opcionalmente, deberá también ser capaz de generar un informe y enviarlo por e-mail al cliente.– Exprese la opcionalidad mediante un atributo del requisito, nunca como

texto dentro del requisito

• El administrador deberá ser capaz de insertar, borrar, mostrar y actualizar la información sobre los usuarios. Deberá también ser capaz de generar un informe y enviarlo por e-mail al cliente.– Necesidad: opcional.

Errores típicos (3): opcionalidad

29

Errores típicos (4): atomicidad

• El administrador deberá ser capaz de insertar, borrar, mostrar y actualizar la información sobre los usuarios. Deberá también ser capaz de generar un informe y enviarlo por e-mail al cliente.– Use un requisito individual para cada necesidad. Muchos verbos

concentrados en un requisito pueden implicar la mezcla de diferentes necesidades.

• El Administrador deberá ser capaz de añadir usuarios.– Necesidad: obligatorio.

• T

• El Administrador podrá generar un informe para enviarlo por e-mail al cliente.– Necesidad: opcional.

30

• El sistema debe ser capaz de importar ficheros ABC. El proceso debe ser amigable y rápido para el usuario.– Utilice acrónimos sólo cuando estén comúnmente aceptados por todos los

interesados.

– Términos como ‘amigable’ y ‘rápido’ son difíciles de medir y, por lo tanto, imposibles de probar de forma correcta.

– Utilice unidades físicas para expresar el rendimiento en un requisito.

– Utilice otros medios (p.e. WAI AA*) claramente definidos para indicar cómo de amigable o accesible debe ser un sistema.

* Web Accesibility Initiative, Nivel Doble-A

Errores típicos (5): acrónimos y vagüedad

31

• El administrador deberá ser capaz de crear facturas asociadas con las diferentes compañías que estén dadas de alta en el sistema y éste también deberá estar al tanto de facturas impagadas para que puedan generar un mail y enviárselos a ellos.– El uso apropiado de signos de puntuación hará los requisitos más fáciles

de leer.

– El número de sílabas por palabra y palabras por frase es también un buen indicador de la legibilidad del requisito.

• El administrador deberá ser capaz de crear facturas asociadas con las diferentes compañías que estén dadas de alta en el sistema. Éste también deberá estar al tanto de facturas impagadas para que puedan generar un mail y enviárselos a ellos.

Errores típicos (5): puntuación y legibilidad

32

• El administrador deberá ser capaz de crear facturas asociadas con las diferentes compañías que estén dadas de alta en el sistema y éste también deberá estar al tanto de facturas impagadas para que puedan generar un mail y enviárselos a ellos.– El exceso de pronombres puede hacer un requisito difícil de entender

– El pronombre ‘éste’, ¿se refiere al administrador o al sistema?

– El pronombre ‘ellos’, ¿se refiere al administrador o al cliente?

– ¿Por qué el pronombre ‘los’ está en plural?

• El administrador deberá ser capaz de crear facturas asociadas con las diferentes compañías que estén dadas de alta en el sistema. El administrador también deberá estar al tanto de facturas impagadas para que puedan generar un mail y enviarloa los clientes.

Errores típicos (6): pronombres

33

• El administrador deberá ser capaz de crear facturas asociadas con las diferentes compañías que estén dadas de alta en el sistema. El administrador también deberá estar al tanto de facturas impagadas para que puedan generar un mail y enviarlo a los clientes.El proceso para localizar impagados es el siguiente:1. Iterar sobre todas las facturas2. Si Fecha_Factura + CondicionesPago es mayor que la fecha actual, entonces:

• Si la categoría del cliente es A, entonces se le deja un mes extra• SI no, mientras la factura no esté pagada no se le permite generar nuevas facturas y se

le enviará un mail cada semana

– Evite el uso de pseudocódigo en sus requisitos.– Los requisitos extensos (en caracteres o párrafos) pueden indicar baja

calidad.

Errores típicos (7): pseudocódigo

34

• Los clientes podrán remitir órdenes por Internet. Estas órdenesdeben incluir fecha de envío y cantidad de artículos. Una vez que se recibe la orden, el equipo de empaquetado debe recoger todos los artículos y enviar un mail al cliente. Deben soportarse los protocolos http y https, así como los navegadores Explorer y Firefox. La resolución mínima será de 1024x768.– Un exceso de términos diferentes en el mismo requisito puede indicar:

• Que se están mezclando diferentes necesidades en un único requisito.

• Que se está proporcionando demasiado detalle.

– Igualmente, muchos verbos pueden involucrar diferentes necesidades mezcladas en un único requisito.

Errores típicos (8): número de términos

35

• En mi opinión, ningún cliente debería poder nunca enviar órdenes al equipo de empaquetado. Ya lo hicimos así en un proyecto hace tres años y el resultado fue nefasto.– No opine, no divague al redactar el requisito. Limítese a indicar qué es lo

que debe hacer el sistema.

• En mi opinión, ningún cliente debería poder nunca enviar órdenes al equipo de empaquetado. Ya lo hicimos así en un proyecto hace tres años y el resultado fue nefasto.– No mezcle demasiados términos negativos, ya que a veces puede

dificultar la lectura del requisito/restricción

• Un cliente no podrá enviar órdenes directamente al equipo de empaquetado.

Errores típicos (9): subjetividad, exceso de negaciones

36

• Generalmente, el sistema debe ser capaz de terminar el proceso de rastreo sin sobrecargar excesivamente el servidor.– Evite expresiones vagas como: ‘generalmente’, ‘comúnmente’.

– Verifique si cada aserción puede ser medida de forma sencilla.

• El sistema debe ser capaz de terminar el proceso de rastreo en un tiempo inferior a 2 segundos y sin que el proceso sobrepase la ocupación máxima de 250 MB de memoria.

Errores típicos (10): falta de precisión

37

Tipos de requisitos del software

• Dos niveles en los requisitos– Requisitos del Usuario, Requisitos del Software

• Clasificación de requisitos del software– Requisitos negativos

– Requisitos funcionales – decir el qué (análisis)

• Requisitos de información / Requisitos de operación

• Modelo del sistema: modelo conceptual + modelo de casos de uso

– Requisitos no funcionales – restringir el cómo (pre-diseño)

• Características distintivas

• Ejemplos

• Análisis y documentación

• Trazabilidad: hacia atrás / hacia delante

38

Requisitos del Usuario vs. Requisitos del Software

Requisitos del usuario

Diseño detallado

Diseño arquitectónico

Requisitos del software

IMPLEMENTACIÓN

ANÁLISIS

DISEÑO

39

Requisitos del Usuario-Requisitos del Software: diferencias

Requisitos del Usuario Requisitos del Software

objetivoplanteamiento del problema

captura de requisitos

refinamiento del problema

análisis de requisitos

fuente usuario/cliente usuario/cliente y analista

responsable usuario/cliente analista

audiencia usuario/cliente (y desarrollador) desarrollador (y usuario/cliente)

énfasis

perspectiva del producto

características de los usuarios

entorno operacional

captura mediante prototipos

conocimiento de expertos

modelado, métodos formales

organización, no dejar cabos sueltos

consistencia y completitud

40

Flujos de trabajo vs. Documentos

+ Implementación, Pruebas, Mantenimiento...

Flujos de trabajo Documentos

USDP Clásica IEEE ESA

RequisitosAnálisis de requisitos

Software Requirements Specification

(IEEE 830-1993)

User Requirements Document

AnálisisSoftware Requirements

Document

Diseño

Diseño arquitectónico Software Design

Document

(IEEE 1016-1987)

Architectural Design Document

Diseño detalladoDetailed Design

Document

41

Diferentes puntos de vista – Diferentes documentos

Lo que yo necesito es...

Lo que él necesita es...

Lo que tienes que hacer

es...

Lo que tengo que hacer

es...

Cliente

Analista Arquitecto

Diseñador

42

Requisitos no funcionales

• Consumo de recursos– memoria, capacidad de tráfico...

• Rendimiento– velocidad, tiempo de respuesta...

• Fiabilidad y disponibilidad– cuantificación de fallos permitidos

• Manejo de errores– errores del entorno, errores internos

• Requisitos de interfaz– comunicación con usuarios, con otras aplicaciones

• Restricciones– exactitud, lenguajes y plataformas, arquitectura, estándares...

• Seguridad– seguridad del sistema (security), seguridad de las personas (safety)

43

Matrices de trazabilidad

RU1 RU2 RU3

RS1 X

RS2 X X

RS3 X

RS4 X

RS5 X

RU RS Descripción

1 1,2

2 3

3 2,4,5

RS RU Título

1 1

2 1,3

3 2

4 3

5 3

RU RS Imp0..* 1..* 1..* 1..*

URD/SRD ADD/DDD

Matriz de doble entrada “dispersa” Matrices de tres columnas (una o las dos)

44

Propiedades y atributos de los requisitos del software

• Propiedades deseables globales– Completitud

• organización por tipos de requisitos

– Consistencia

• matriz de referencias cruzadas

• Propiedades deseables individuales– Tamaño adecuado

– Claridad

– Comprobabilidad: validación y verificación

– Condiciones de error

• Atributos definibles– Automáticos: identificador, creador, fecha de creaciónT

– Obligatorios: tipo, estado, descripción breve.

– Opcionales: descripción detallada, fuente, necesidad, prioridad, estabilidad, complejidad, riesgo, costeT

45

Consistencia: conflictos, acoplamientos y redundancias

R1 R2 R3 R4 R5 R6 R7

R1 + x x

R2

R3 + + +

R4 + x o

R5 x x

R6 x +

R7 o

Conflicto (x) Acoplamiento (+) Redundancia (o) Independencia

R1 y R5

R1 y R6

R4 y R5

R1 y R3

R3 y R4

R3 y R6

R4 y R7

(�R7xR5, R7+R3)R2

46

Plantilla de requisitos (ejemplo)

ID 007

Título Usuarios Visitantes

Creado por Ana García (analista)

Fecha 05-09-2011

Fuente Juan Gómez (responsable TIC)

Tipo Funcional

Necesidad Esencial

Estado Propuesto

Descripción Los usuarios Visitantes no son usuarios registrados del sistema: pueden acceder libremente a las funciones del rol Visitante sin necesidad de registrarse ni de iniciar sesión, y sin límite de sesiones simultáneas.

Pruebas 1. Comprobar que para todas las funciones del rol Visitante el sistema no requiere inicio de sesión.

2. Comprobar que el número de sesiones simultáneas de usuarios Visitantes es ilimitado.

47

Métodos para organizar los requisitos del software

• Técnicas ya mencionadas– Matrices de trazabilidad– Matriz de consistencia: conflicto, acoplamiento, redundancia– Modularidad y anidamiento de requisitos: áreas temáticas

• Organizar los requisitos según el modelo del sistema– Según el modelo de casos de uso

• Clases mencionadas• Operaciones utilizadas

– Según el modelo conceptual (clases)• Atributos• Operaciones

– Es esencial garantizar la coherencia entre el modelo y los requisitos

• Ciclo de vida de los requisitos• Uso de herramientas para analizar y organizar requisitos

48

Ciclo de vida de los requisitos

Propuesto

Implementado VerificadoValidado

Cancelado

creado eliminado

49

Características de una herramienta de gestión de requisitos (1)

• Herramienta multiproyecto y multiusuario– Gestión de usuarios: analistas, jefes de proyecto, administradores.– Permisos de acceso por proyecto: lectura o escritura.

• Configuración de un proyecto– Propiedades globales de un proyecto: nombre, descripción, ubicación...– Atributos habilitados en función del tipo de requisito, valores desplegables.

• Acceso, sesión y control de versiones– Registro automático de sesiones: inicio y fin, requisitos creados o modificados.– Control de versiones: sin control, control opcional, control obligatorio.– Notificación de modificaciones (opcional).– Seguimiento del ciclo de vida.

• Propiedades de los requisitos– Agrupación en paquetes y subpaquetes. – Atributos: automáticos, obligatorios, opcionales.– Relaciones entre requisitos: navegabilidad y asimetría. Requisitos “sospechosos”.– Otros artefactos asociados: escenarios, modelos...

50

Características de una herramienta de gestión de requisitos (2)

• Visualización, navegación y edición– Ficha o tabla, atributos visibles.

– Ordenación y filtrado.

– Búsqueda y reemplazamiento.

– Movilidad entre paquetes.

– Duplicación de requisitos.

• Informes– Listado de requisitos: ordenación, filtrado, atributos mostrados...

– Estadísticas varias: ritmo de creación/modificación, conflictos...

– Matrices de trazabilidad y consistencia.

• Utilidades– Asistencia en la creación del glosario de términos.

– Coherencia entre los requisitos y los elementos del modelo.

– Detección automática de solapamientos entre requisitos.

– Métricas de calidad.

51

Métricas de calidad en los requisitos del software

• Qué sentido tiene realizar medidas de calidad – Buscar la calidad desde el principio– Personal que las realiza– Coste añadido por la medición

• Métricas de calidad: cómo de bien están escritos los requisitos– ¿Qué debemos medir?

• Propiedades deseables (cualitativas)• Indicadores medibles (cuantitativos)

– ¿Cómo podemos medir?• Medidas manuales (inspección con ayuda de cuestionarios)• Medidas automáticas (características lingüísticas)

• Métricas de calidad: cómo de efectivos son los procesos– medidas de la efectividad de la inspección de requisitos– medidas de la efectividad del proceso de análisis de requisitos

52

Propiedades e indicadores de calidad

Morfológicos Tamaño, Legibilidad, Puntuación, Acrónimos, Abreviaturas

LéxicosTérminos negativos, conectivos, de flujo, anafóricos, ambiguos, incompletos, especulativos, de diseño

AnalíticosOrtografía, gramática, verbos imperativos, verbos condicionales, voz pasiva, términos del dominio

Relacionales Número de versiones, grado de anidamiento, dependencias, solapamientos

Validabilidad Verificabilidad Modificabilidad

Completitud Consistencia Comprensibilidad Inambigüedad Trazabilidad

Precisión Atomicidad

DESARROLLADORCLIENTE

Abstracción

53

Modelado conceptual con UML

• La necesidad de modelar• Qué significa “modelo conceptual”

– Es una vista gráfica de la información contenida en los requisitos.

• Objetos y clases– Notación básica de objetos y clases– Tipos de clases

• Atributos• Operaciones• Asociaciones

– Propiedades básicas: nombres, multiplicidad, navegabilidad– Relación con otros elementos: atributos, operaciones

• Generalizaciones– Generalización y clasificación– Jerarquías de clases

• Diagramas de clases y de objetos• Asociaciones especiales

54

Analogía arquitectónica

Ingeniería directa

Ingeniería inversa

• ¿Tiene sentido poner ladrillos sin hacer antes los planos?

• El modelo -los planos- ayuda a afrontar la complejidad del proyecto

• ¿Cuál es el lenguaje adecuado para representar los planos?

• Ingeniería directa e ingeniería inversa: una casa, un coche, un virus...

55

Comunicación y representación del conocimiento

• Para representar el conocimiento hace falta un lenguaje adecuado

• El conocimiento bien representado ayuda a hacerse las preguntas oportunas: ¿qué falta aquí? ¿qué pasaría si...? ¿por qué no se puede...?

Especificaciones

Documentación

Pruebas

Planificación

56

¿Qué es un modelo?

• Abstracción o simplificación de la realidad: divide y vencerás• Diversos tipos de modelos:

– estructura, electricidad, saneamientoT– estático, dinámico...

�¿cómo se relacionan entre sí?

• Modelos formales y modelos informales– Modelos informales: ad hoc, sin lenguaje común– Modelos formales: lenguaje universal, precisión, rigor, coherencia

• Modelado y lenguaje– El lenguaje es vehículo del pensamiento: ayuda a pensar con claridad

– El modelado es un elemento esencial del proceso de desarrollo de software

– El modelado requiere un lenguaje adecuado

• Modelar no es hacer diagramas sino pensar con diagramas

57

Propiedades deseables de un modelo

• Comprensible

– Expresado de tal forma que se pueda entender fácilmente.

• Preciso

– Representa fielmente el sistema modelado.

• Predictivo

– Se puede utilizar para obtener conclusiones correctas sobre el sistema.

• Barato

– Más económico que construir y estudiar el propio sistema.

58

Sistema, modelo, diagrama

• Un sistema es una colección de elementos organizados para cumplir una finalidad concreta– Un sistema puede estar dividido en subsistemas

• Un modelo es una abstracción de un sistema, es decir, una simplificación (completa y consistente) del sistema real, que sirve para comprenderlo mejor– Provisionalmente, un modelo puede ser incompleto (faltan elementos) o

inconsistente (contiene contradicciones)– Un sistema puede estar modelado desde distintos puntos de vista

complementarios, según lo que se considere relevante en cada caso

• Un diagrama es la representación gráfica de un conjunto de elementos interconectados, una vista parcial de un modelo– Un modelo no es meramente una colección de diagramas– Un modelo puede contener elementos no representados en un diagrama– Un modelo puede contener especificaciones textuales esenciales

59

Herramientas de modelado

• ¿Qué puede ofrecer una herramienta CASE para UML? – Dibujo– Corrección sintáctica– Coherencia entre diagramas– Integración con

otras aplicaciones– Trabajo multiusuario– Reutilización– Generación de código...

• Ejemplos– Visual Paradigm– Altova UModel– Magic Draw– Visual UML– Enterprise Architect

60

Objetos y clases

• Dos niveles de abstracción:– objeto: una entidad concreta con identidad, estado y comportamiento

– clase: un conjunto de entidades con estructura y comportamiento comunes

• La relación de clasificación / instanciación– un objeto es instancia de una clase

– la clase se usa como plantilla para construir (instanciar) objetos

• Objetos y clases en análisis y diseño:– Análisis = especificación, vista externa, caja negra

• clases, atributos y operaciones corresponden a conceptos del dominio

• es habitual usar una notación simplificada al máximo

– Diseño = implementación, vista interna, caja blanca

• clases, atributos y operaciones corresponden a fragmentos de código

• nuevos artefactos y soluciones que dependen del lenguaje y la plataforma

de implementación y no tienen por qué corresponder a conceptos del dominio

61

Notación básica de objetos y clases

Punto

posiciónXposiciónYsituar( )mover( )

p1 : Punto

posiciónX = 3posiciónY = -5

p2 : Punto

posiciónX = 0posiciónY = 2

«instance of»«instance of»

p1 : Punto

p1

: Punto

Punto

posiciónXposiciónY

Punto

situar( )mover( )

Punto

62

Tipos de clases

• Tipos de clases según los objetos representados: – objetos físicos: avión, persona, libro...

– objetos lógicos: cuenta corriente, asignatura, número complejoT

– objetos históricos: asiento bancario, reserva de habitaciónT

• Para entender lo que es una clase, hace falta entender cuáles serán sus instancias. Un caso especial lo constituyen los objetos que representan una colección, familia o tipo de cosas, más que una cosa en sí misma.

• Ejemplos: raza perruna, producto a la venta, título en la biblioteca.

• Es decir, un mismo concepto del mundo real puede ser modelado como objeto o clase según el contexto:– “Pastor Alemán”

– “Lata de Atún”

– “El Lenguaje Unificado de Modelado”

• Todo objeto representa una “entidad concreta”, pero esto no significa necesariamente “entidad física” o tangible.

63

Clase vs. Tipo de dato

Clase Tipo de dato (<<Datatype>>)

Concepto Representa un concepto definido dentro

de los límites del sistema

Representa un concepto general e independiente, definido fuera de los límites del sistema

Población La población es finita (tal vez ilimitada) y variable: existen tantas instancias como explícitamente sean creadas o destruidas en tiempo de ejecución

La población es finita o infinita, pero constante: las instancias existen implícitamente, sin necesidad de crearlas, y no pueden ser destruidas

Población finita: días, meses. Población infinita: años.

Estructura Pueden ser simples o estructuradas (lo normal es que tengan varios atributos)

Pueden ser simples o estructuradas (ambos casos son normales): número entero, fecha dd/mm/aaaa

Si es estructurado, entonces la población se obtiene como producto cartesiano de sus tipos de dato constitutivos, posiblemente con restricciones (fecha)

Valores Los valores de los atributos pueden ser fijos o variables (más normal variables)

Los valores simples o estructurados son fijos e

inmutables, el sistema no puede modificarlos

Comparación Por referencia (“son el mismo”) Por valor (“son iguales”)

Asociaciones Puede participar en asociaciones unidireccionales o bidireccionales

Sólo en asociaciones unidireccionales (atributos):

• ref. entrantes desde clase o tipo de dato propietario

• si es estructurado, ref. salientes hacia tipo de dato

Copiado Cuando se copia/clona un objeto, no se

copian los objetos referenciados

Cuando se copia un valor estructurado, se copian

simultáneamente los valores referenciados

Ejemplos Usuario, ¿Día-de-Calendario? Fecha, ¿Rol-de-Usuario?

64

Atributos

• Atributo: propiedad compartida por los objetos de una clase– cada atributo tiene un valor (probablemente diferente) para cada objeto

• Atributo derivado (concepto propio del análisis): – propiedad redundante que puede ser calculada a partir de otras

– /área ( = base * altura)

– pueden implementarse como operaciones al pasar a diseño

• Notación (más importante en diseño)– pueden suprimirse todos los elementos excepto el nombre de atributo

• visibilidad nombre multiplicidad : Tipo = valorInicial {propiedades}

– propiedades predefinidas de los atributos: changeable, addOnly, frozen

– ejemplos

• saldo : Moneda = 0

• teléfonoOficina [0..2] {addOnly}

65

Operaciones

• Operación: función o transformación que puede aplicarse a los objetos de una clase– pueden ser invocadas por otros objetos, o por el mismo objeto

– método: especificación procedimental (implementación) de una operación

• Notación (más importante en diseño)– pueden suprimirse todos los elementos excepto el nombre de operación

• visibilidad nombre (param: Tipo = valDef,T) : TipoRet {propiedades}

– propiedades predefinidas de las operaciones: isQuery

– ejemplos:

• obtenerSaldo ( ) : Moneda {isQuery}

• marcar (número : Teléfono; reintentos : Integer)

66

Enlaces y asociaciones

ArtículoVendedor

Juan : Vendedor

Ana : Vendedor

Estatuilla : Artículo

Cuadro : Artículo

Espejo : Artículo

Asociación: especificación de un conjunto de enlaces

representa la estructura y el comportamiento del sistema

Enlace: conexión entre objetosdetermina una tupla de objetosinstancia de una asociación

estado de los objetos enlazadosestado del sistema

hecho + posibilidad de comunicación

67

Nombre de asociación y nombre de rol

ArtículoVendedorsubasta

ArtículoPersonavendedor artículo

Nombre de asociación Dirección del nombre

Nombres de rol

Los nombres de asociación se pueden repetir en un modelo, excepto para asociaciones entre las mismas dos clases

Los nombres de rol se pueden repetir en asociaciones distintas, y pueden ser iguales que los nombres de las clases asociadas

68

• Valores típicos:– 0..1 cero o uno– 1..1 uno y sólo uno (abreviado como “1”)– 0..* desde cero hasta “muchos” (abreviado como “*”)– 1..* desde uno hasta “muchos”

• Otros valores:– rangos enteros: (2..*), (0..3), etc. – lista de rangos separados por comas: (1, 3, 5..10, 20..*), (0, 2, 4, 8), etc.

Multiplicidad de la asociación

• En una asociación binaria, la multiplicidad de un extremo de asociación

especifica el número de instancias destino que pueden estar enlazadas con una única instancia origen a través de la asociación

ArtículoPersonavendedor artículo

1..1 0..*Artículo participa

obligatoriamente

Persona “depende funcionalmente” de Artículo

Persona participa

opcionalmente

69

Navegabilidad de la asociación

• La navegabilidad de una asociación binaria especifica la capacidad que tiene una instancia de la clase origen de acceder a las instancias de la clase destino por medio de las instancias de la asociación que las conectan

• Acceder = nombrar, designar o referenciar el objeto para...– leer o modificar el valor de un atributo del objeto (desaconsejable)� invocar una operación del objeto (enviarle un mensaje)

– usar el objeto como argumento o valor de retorno en un mensaje– modificar (asignar o borrar) el enlace con el objeto

• No confundir:– dirección del nombre de la asociación: asimetría lingüística– navegabilidad o direccionalidad de la asociación: asimetría comunicativa

ArtículoVendedorsubasta

ArtículoVendedorsubasta

ArtículoVendedorsubasta

Navegabilidad no especificada

Asociación unidireccional

Asociación bidireccional

70Proyecto Práctico de Ingeniería de Requisitos

• Un atributo es equivalente a una asociación unidireccional

(referencia hacia el tipo de dato del atributo)

• Es conceptualmente incorrecto duplicar la representación

PuntoposiciónX: CoordenadaposiciónY: Coordenada

PuntoposiciónX: CoordenadaposiciónY: Coordenada

Coordenada

posiciónY

posiciónX

Asociación vs. Atributo

Punto

Coordenada

posiciónY

posiciónX«datatype»

«datatype»

ggf1

Diapositiva 70

ggf1 ggenova; 09/01/2013

71

Persona

Vehículo

arrancar( )conducir( )detener( )

poseePersona Vehículo

arranca

conduce

detiene

Asociación vs. Operación

• Toda asociación tiene un doble significado:– aspecto estático: estructura del sistema (estados posibles)

– aspecto dinámico: comportamiento del sistema (interacciones posibles)

• El nombre de la asociación puede reflejar más un aspecto que el otro:– nombres estáticos: contiene, situado-en, trabaja-para, matrimonio, etc.

– nombres dinámicos: subasta, publica, consulta, etc.

• Son preferibles los nombres estáticos, reservando los nombres dinámicos para nombres de operaciones, invocadas a través de la asociación mediante el envío de mensajes

• Una misma asociación permite la invocación de muchas operaciones

72

Generalización y clasificación

• Principio de sustitución (Barbara Liskov, 1987):– Extensión: todas los objetos de la subclase son también de la superclase.

– Intensión: la definición de la superclase es aplicable a la subclase.

• Generalización: clase-clase.– Gato es un tipo de Mamífero, Mamífero es un tipo de Animal.

• Clasificación: objeto-clase.– Fluti es un Gato, Fluti es un Mamífero, Fluti es un Animal.

Gato Mamífero Animal

Fluti

«instance of»

Instancias directas e indirectas

73

Generalización y especialización

• Dos puntos de vista complementarios:– Generalizar es identificar las propiedades comunes (atributos,

asociaciones, operaciones) de varias clases y representarlas en una clase más general denominada superclase.

• Elevar el nivel de abstracción, reducir la complejidad, organizar.– Especializar es capturar la propiedades específicas de un conjunto de

objetos dentro de una clase dada, que aún no han sido distinguidas en ella, y representarlas en una nueva clase denominada subclase.

• Reutilizar un concepto añadiendo propiedades variantes.

• Es una relación pura entre clases:– No tiene instancias, ni multiplicidad.– La subclase hereda todas las propiedades de la superclase.– Las propiedades heredadas de la superclase no se representan en la

subclase (a menos que sean operaciones redefinidas).– Toda generalización induce una dependencia subclase � superclase.

74

Transporte

AéreoTerrestre

Avión HelicópteroBicicleta Automóvil Ferrocarril

Jerarquías de clases

Generalización: - no-reflexiva- transitiva- asimétrica

Transporte

Aéreo

Terrestre

Avión Helicóptero

Bicicleta

Automóvil

Ferrocarril

Representaciones alternativas:- relaciones binarias- estructura en árbol

75

CuentaCorriente

CuentaPersonal CuentaSocial CuentaEuro CuentaDólar

titular {disjoint, complete} moneda {disjoint, incomplete}

Dimensiones de especialización

• Una superclase puede ser especializada en distintos grupos de subclases

de acuerdo con criterios independientes: discriminadores.

• Restricciones:– disjoint/overlapping: las subclases no pueden tener instancias en común / o sí.

– complete/incomplete: no hay otras subclases / o sí.

• Valor por defecto: disjoint, incomplete.

• Partición propiamente dicha: disjoint, complete.

76

Generalización múltiple vs. Clasificación múltiple

CuentaCorriente

CuentaPersonal CuentaEuro

CuentaPersonalEuro

miCuenta

«instance of»

CuentaCorriente

CuentaPersonal CuentaEuro

miCuenta

«instance of» «instance of»

77

Subclase vs. Atributo

• ¿Cómo modelar las propiedades de los objetos? Regla general:– Propiedad cambiante o rango de valores muy grande: atributo.– Propiedad fija con valores enumerados: especialización (cada propiedad se

traduce en un criterio de especialización, cada valor en una subclase).• También se puede modelar como un atributo con valor fijo.

• Problema de la clasificación dinámica: ¿puede un objeto cambiar de clase?– Permitiría modelar un cambio de propiedad como una reclasificación del objeto.– Interesante para aprovechar el polimorfismo (mediante un cambio de subclase).– No es habitual en los lenguajes de programación, aunque UML lo permite.

• Criterio final de especialización: comportamiento.

CuentaCorrientetitularmoneda

Coche

CocheRojoCocheVerdeCocheAzul

color

Alternativa a la doble especialización

¿Especialización exagerada?

78

Diagramas de clases y de objetos

• Diagrama de clases– captura y especifica el vocabulario del sistema:

• elementos: clases, atributos, operaciones...• relaciones: asociaciones, generalizaciones...• estructura del sistema, fundamento de su comportamiento

– sugerencias para mejorar la comunicación:• nombres adecuados: clases, atributos, operaciones, asociaciones, roles• distribución espacial de los elementos• evitar cruces de líneas• distinto nivel de detalle según el propósito y nivel de abstracción

• Diagrama de objetos– ilustra la estructura del sistema mediante situaciones particulares– “fotografía” del sistema: objetos, valores de atributos; enlaces– las instancias deben conformarse a sus especificaciones

• objetos, enlaces � clases, asociaciones• las especificaciones pueden estar representadas en distintos diagramas

79

Diagrama de clases vs. Diagrama de objetos

Sociedad

Sociedad

Anónima

Sociedad

Limitada Acme : Sociedad

Emca : SociedadLimitada

Ana : Persona

Clara : Persona

Pedro : Persona

accionista

empleado

empleado

accionista

No es correcto decir que “un diagrama de objetos es una instancia de un diagrama de clases”

Sociedad Personaaccionista

empleado

80

Restricciones y notas

{ningún accionista puede ser empleado}

falta determinar las subclasesde Sociedad

Sociedad Personaaccionista

empleado

El NIF es un número de 8 dígitos, seguido de una letra que se obtiene usando el resto de la división módulo 23 como índice en la siguiente cadena de caracteres (el 0 corresponde a la letra T):

TRWAGMYFPDXBNJZSQVHLCKE

81

Restricciones en asociaciones

Vuelo Aeropuerto

{ordered} escala

* 0..*

* 1origen

* 1destino

Cuenta

Sociedad

Persona

* 0..1

* 0..1

{xor} or exclusivo entre asociaciones

ordenación de los elementos

Cliente Mesa* *

{nonunique}reserva

UML 1.x: una asociación no puede contener tuplas repetidas

UML 2.x: la restricción {nonunique} en un extremo permite la repetición

82

Legibilidad de los diagramas

Diagrama ilegible: letra demasiado pequeña (Arial 9). Tamaño mínimo en torno a 14.

83

Legibilidad de los diagramas

Usar “índice” en miniatura.

84

Asociaciones actor-sistema y clase-clase

• Un mismo concepto puede ser modelado a la vez como actor y como clase:– Actor: representa entidades externas al sistema.– Clase: representa entidades modeladas dentro del sistema.

• No confundir asociaciones actor-sistema (casos de uso, relaciones con el exterior) con asociaciones clase-clase (relaciones internas):– “Para subastar algún artículo es necesario darse de alta como vendedor,

introduciendo el NIF, un nombre descriptivo (largo), un nombre de usuario (breve) y una contraseña de acceso. Una vez que el vendedor está dado de alta, puede registrar artículos en la subasta o modificar alguno de sus datos: descripción breve, descripción ampliada, fotografía en formato JPEG, y precio de salida.”

Vendedor

Registrarartículo

Modificardatos de artículo

Artículo

descripciónBrevedescripciónAmpliadafotografíaprecioSalida

Vendedor

nifnombreDescriptivonombreUsuariocontraseña

subasta

registra

modifica

85

Asociaciones reflexivas

• Una asociación reflexiva (o recursiva) es aquella en la que los dos extremos de la asociación están unidos a la misma clase.

• Los enlaces pueden conectar dos instancias diferentes de la misma clase, o incluso una instancia consigo misma.

• En una asociación reflexiva los nombres de rol son obligatorios, para poder distinguir los dos extremos de la asociación.

• Una asociación reflexiva no es simétrica: los extremos son distinguibles, aunque la asociación quiera significar equivalencia: es-amigo-de, es-igual-a...

Empleado Personadirige

0..1

0..*

jefe

subalterno

ama

0..*

0..*

amante

amado

dirige(Ana, Juan) ≠ dirige(Juan, Ana) ama(Pedro, Clara) ≠ ama(Clara, Pedro)

86

Ciclos de asociaciones y asociaciones derivadas

• ¿Puede un alumno matricularse en asignaturas que no son de su titulación? • Posibles interpretaciones alternativas del diagrama: la titulación

matriculadaT– se obtiene a partir de las asignaturas: asociación derivada.– actúa como restricción para elegir asignatura matriculada.– actúa como sugerencia para elegir asignatura matriculada.– titulación matriculada y asignatura matriculada son independientes.

{...}

Alumno

Asignatura

Titulaciónmatriculado

1 0..*

pertenece

1

1..*

matriculado0..*

0..*

87

Agregación

• Es un tipo especial de asociación que representa una relación todo-parte, transitiva y asimétrica– no impone ninguna restricción especial sobre la multiplicidad

– puede ser reflexiva para las clases, pero no para las instancias

PiezaMáquina0..* 1..*

0..*

0..*

m1 : Máquina

m2 : Máquina

p1 : Pieza p2 : Pieza

88

Composición

• Es un tipo especial de agregación no compartida

– la multiplicidad sólo puede ser 0..1 ó 1..1

– el todo es responsable de la existencia y almacenamiento de las partes

– propagación de las operaciones de copiado y borrado

• Composición no significa encapsulamiento ni acceso restringido

AviónEscuadrilla

Cabina Fuselaje Ala

Piloto0..3 1..* 0..* 0..2

1

0..1

1 2

ggf2

Diapositiva 88

ggf2 ggenova; 18/01/2013

89

Anidamiento – Clase interna

• Una clase puede anidarse dentro de otra, como los paquetes, con el fin de limitar la visibilidad desde el exterior

• La relación de anidamiento no es una asociación

• No tiene nada que ver con la agregación o la composición– la composición abstrae enlaces todo-parte entre objetos

– el anidamiento es una pura relación de inclusión entre clases

+B

A

-C

90

Diseño e implementación de asociaciones binarias

• Los lenguajes OO no proporcionan una construcción adecuada– combinación de atributos y operaciones para gestionar los enlaces

– colecciones para manejar la multiplicidad (comprobación de tipo...)

– referencias cruzadas sincronizadas para manejar la bidireccionalidad

Hombre Mujer0..1 0..1

esposo esposa

{sincronizado}

0..1

esposa

0..1

esposo

Hombre Mujer

Diagrama de análisis

Diagrama de diseño

Código demasiado simple:

public class Hombre {private Mujer esposa;T

}

public class Mujer {private Hombre esposo;T

}

91

Persona Empresa

trabaja-para

sueldopagar( )

Cuenta

trabaja-para1..* 0..*

pagar-en0..* 1

Clase-asociación

• Tiene todas las propiedades de una clase y de una asociación:– atributos, operaciones y asociaciones con otras clases.

– conexión entre clases que especifica enlaces entre ellas.

– multiplicidad, navegabilidad, agregación...

• Es un único elemento, por tanto tiene un nombre único.

• Como cualquier otra asociación, en UML 1.x no podía contener tuplas repetidas, aunque los valores de los atributos fueran distintos: sustituir clase-asociación por clase intermedia.

¿Representa el estado actual o el registro histórico?

¿Queremos permitir repeticiones?

92

Persona Empresa

trabaja-para

sueldopagar( )

trabaja-para1..* 0..*

Transformación de clase-asociación en clase intermedia

• Es una forma de implementar la clase-asociación, que consiste en sustituir la clase-asociación por una clase simple, cuyas instancias representan enlaces.

• Las multiplicidades originales se cruzan, y aparecen otras nuevas.

• Permite automáticamente la existencia de tuplas repetidas; hay que añadir una restricción

adicional si se desea evitarlas.

Persona Empresa

trabaja-para

sueldopagar( )

1

0..*

1

1..*

clase intermedia

clase-asociación

93

Asociación n-aria

• Asociación entre N clases: los enlaces conectan N instancias

– no permite: dirección del nombre, agregación– sí permite: navegabilidad (aunque significado problemático), clase-asociación

• Multiplicidad engañosa:– número permitido de instancias para cualquier posible combinación de

instancias de las otras n-1 clases– la multiplicidad mínima suele ser 0– efecto “rebote del uno”: la multiplicidad mínima 1 (o superior) en un extremo

implica que debe existir un enlace (o más) para cualquier posible combinación de instancias de los otros extremos

Equipo

Entrenador

Temporada* *

0..1

La multiplicidad mínima 1 implicaría la existencia de un enlace (o más) para toda

posible combinación de equipo y temporada.

Un equipo enlazado con una temporada siempre tiene un entrenador asignado: no hay “enlaces cojos”.

94

Equipo

Entrenador

TemporadaETE1 * 1*

1

*

Equipo

Entrenador

Temporada* *

0..1

Transformación de asociación n-aria en clase intermedia

?

clase intermedia

asociación n-aria• Sustituir la asociación n-aria por

una clase simple, cuyas instancias representan enlaces.

• Las multiplicidades originales se pierden, y aparecen otras nuevas.

• Permite la existencia de tuplas repetidas, cuando es necesario.

• Es una forma de implementar la asociación n-aria, pero hay que añadir restricciones adicionales para no permitir tuplas repetidas y para expresar las multiplicidades originales perdidas.

95

Modelado arquitectónico con UML

• Qué es la arquitectura de software– El modelo de 4+1 vistas arquitectónicas

– Cohesión y acoplamiento

– Cómo lograr una descomposición modular eficaz

– Criterios para la selección de una arquitectura

• Diagrama de componentes– Noción de componente y dependencia

– Noción de interfaz

– Uso de interfaces en OO

• Diseño por contratos– Noción de contrato

– Especificación formal del contrato: sintaxis y semántica

– Uso de pre- y post- condiciones

– Invariantes de clase

– Contratos y herencia: subcontratación

96

Arquitectura del software: definiciones

• Paul Clements 1996– La arquitectura del software es a grandes rasgos, una vista del sistema que

incluye los componentes principales del mismo, la conducta de esos componentes según se percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema.

• Len Bass 1998– La arquitectura del software de un programa o sistema de computación es la

estructura o las estructuras del sistema, que contienen componentes de software, las propiedades externamente visibles de dichos componentes y las relaciones entre ellos.

• IEEE Std. 1471-2000– La arquitectura del software es la organización fundamental de un sistema

encarnada en sus componentes, las relaciones entre ellos y con el entorno, y los principios que orientan su diseño y evolución.

97

El modelo de 4+1 vistas arquitectónicas

Vista lógica(conceptual)

Vista de proceso(ejecución)

Vista de desarrollo(implementación)

Vista física(despliegue)

Vista de casos de usoPráctica: capítulo 4 Práctica: capítulo 5

Vistas que no entran en la práctica

98Proyecto Práctico de Diseño de Software

Características de cada vista en el modelo 4+1

VistaLógica

(conceptual)

Proceso

(ejecución)

Desarrollo

(implementación)

Física

(despliegue)

AspectoModelo de información

Concurrencia y sincronización

Organización del software en el entorno de desarrollo

Correspondencia software-hardware

StakeholdersUsuarios finales

Integradores del sistema Programadores Ingenieros de sistemas

Requisitos Funcionales

Rendimiento

Disponibilidad

Fiabilidad

Concurrencia

Distribución

Seguridad

Gestión del software

Reuso

Portabilidad

Mantenibilidad

Restricciones impuestas por la plataforma o el

lenguaje

Rendimiento

Disponibilidad

Fiabilidad

Escalabilidad

Topología

Comunicaciones

NotaciónClases y

asociacionesProcesos y

comunicacionesComponentes y

relaciones de usoNodos y rutas de

comunicación

99Proyecto Práctico de Diseño de Software

Relaciones entre las cuatro vistas

Vista lógica(conceptual)

Vista de proceso(ejecución)

identificar clases activas

Vista de desarrollo(implementación)

minimizar dependencias

nuevas clases de diseño

Vista física(despliegue)

requisitos no funcionales

?

100

Cohesión y acoplamiento

1

2 3 4

5 6Alta cohesión Bajo acoplamientoPuente

componente

componente

Adaptado de E. Braude,Software Engineering: An Object-Oriented Perspective

101

Cómo lograr una buena descomposición modular

A B C

D E F

Mal

A D E

B C F

Bien

¿Cómo acertar de antemano? � Estilos arquitectónicos

102

Criterios para la selección de una arquitectura

• Criterios clásicos:– Extensibilidad: facilitar la adición de nuevas caracterísiticas

• Hace más complejo el diseño.• Aporta mayor grado de abstracción.

– Ejemplo: arquitectura que soporte no este juego de tablero particular, sino cualquier tipo de juego de tablero.

• Generalizar requiere invertir tiempo en el diseño: decidir qué tipo de extensiones pueden surgir, etc.

• La distinción de requisitos opcionales/deseables es útil aquí, ya que señala hacia dónde apunta el desarrollo del sistema.

– Modificabilidad: facilitar el cambio de requisitos.• Es distinto del anterior, aunque requiera técnicas similares.

– Ejemplo: posibilidad de cambiar las reglas del juego.

– Simplicidad: hacer fácil de entender, hacer fácil de implementar.• Difícil de coordinar con los dos anteriores.

– Eficiencia: lograr alta velocidad o pequeño tamaño.

• Otros criterios: Reuso, Escalabilidad, Coste, Requisitos no funcionalesT

103

Noción de componente y dependencia

<<component>>

A

<<component>>

B

<<component>>

C

E F

Dependencia A�C:

• A requiere la presencia de C

• Los cambios de C pueden afectar a A

104

Dependencia respecto a una interfaz

Dos componentes pueden ofrecer la misma interfaz

Dos interfaces no necesariamente

disjuntas

105

Representación de interfaces: abreviada y completa

Novedad en UML2

106

• Encapsulamiento: separación de interfaz e implementación:– una clase/componente puede realizar una o varias interfaces.

– una interfaz puede ser realizada por una o varias clases/componentes.

• Interfaz: conjunto de operaciones que ofrecen un servicio coherente:– no contiene la implementación de las operaciones (métodos).

– una interfaz no puede tener atributos ni asociaciones navegables (esta restricción ha desaparecido en UML 2.0).

– análoga a una clase abstracta con todas sus operaciones abstractas: no puede tener instancias directas.

Notaciones para uso y realización de interfaces

Documento

ImprimibleImpresora

Noción de interfaz

Documento

«interface»Imprimible

imprimir( )

Impresorauso

realización

107

«interface»Figura

Círculo Rectángulo

Cuadrado

«interface»Imprimible

Generalización vs. Realización• La realización puede entenderse como una

“generalización débil”: se hereda la interfaz, pero no la implementación:– reduce la dependencia.– disminuye la reutilización.– alternativa a la generalización múltiple, no soportada

por muchos lenguajes.

• Las interfaces son elementos generalizables:– jerarquías mixtas de interfaces y clases.

• Criterio de diseño: comprometerse sólo con la interfaz.– declarar el tipo de las variables y parámetros de

operaciones como interfaces, no como clases.– servirá cualquier instancia compatible con la interfaz.

• Ejemplo:Figura f = new Cuadrado ( );

f.imprimir

108

Interfaces proporcionadas y requeridas

requiere, usa

proporciona, realiza

109

Diagrama de componentes

“ball and socket”

cableado “en árbol”

cableado “independiente”

cableado con dependencia

110

Cómo instanciar las interfaces de un componente (1)

package GestiónEmpleados;

public interface iEmpleado {public modificar( ) { };T

}

public class EmpleadoFijo implements iEmpleado {public modificar( ) { };T

}

public class EmpleadoTemporal implements iEmpleado {public modificar( ) { };T

}

====================

class Departamento {TiEmpleado e = new EmpleadoFijo( );Te.modificar( );T

}

El componente proporciona

sólo una interfaz, el tipo

abstracto de datos.

Es necesario que la clase

cliente (Departamento)

conozca las clases concretas

EmpleadoFijo, etc.: estas

clases deben ser públicas.

Nada le impide usarlas sólo

para invocar los constructores

(salvo el buen estilo del

programador).

La dependencia es

potencialmente “peligrosa”.

111

Cómo instanciar las interfaces de un componente (2)

package GestiónEmpleados;

public interface iGestorEmpleados {public int crearEmpleado( ); // el gestor debe mantener algún tipo de listapublic modificarEmpleado(int e);T

}

class EmpleadoFijo {T} // no visible desde fuera, idem EmpleadoTemporal

public class GestorEmpleados implements iGestorEmpleados {public int crearEmpleado( ) {T}; // usa new EmpleadoFijo( )public modificarEmpleado (int e) {T}; // usa EmpleadoFijo.modificar( )T

}

====================

class Departamento {Tint e = ge.crearEmpleado ( ); // se supone que existe GestorEmpleados geTge.modificarEmpleado(e);T

}

GestorEmpleados no puede

recibir ni devolver valores de

tipo EmpleadoFijo,

EmpleadoTemporal, etc.

Es necesario un mecanismo

de traducción de los

identificadores públicos a las

instancias de EmpleadoFijo,

etc. (una lista interna).

El componente proporciona

sólo una interfaz, el gestor.

La clase cliente sólo usa el

gestor y los identificadores

públicos.

112

Cómo instanciar las interfaces de un componente (3)

package GestiónEmpleados;

public interface iEmpleado {public modificar( ) { };T

}

public interface iGestorEmpleados {public iEmpleado crearEmpleado( ); // el gestor debe mantener algún tipo de listapublic modificarEmpleado(iEmpleado e);T

}

====================

class Departamento {TiEmpleado e = ge.crearEmpleado ( ); // se supone que existe GestorEmpleados geTe.modificar( );T

}La clase cliente no puede usar

el constructor directamente,

pero sí el tipo abstracto en el

resto de operaciones.

El componente proporciona

dos interfaces, el tipo

abstracto de datos y el gestor.

113

Cómo instanciar las interfaces de un componente (4)

Caso 1 Caso 2

(parámetros int)

Caso 3

(parámetros iEmpleado)

114

Diseño por contratos: PPCs e invariantes

• PPCs de operación– CuentaCorriente.meterDinero(cantidad: Moneda)

• Pre:

• Post: saldo’ = saldo + cantidad

– CuentaCorriente.sacarDinero(cantidad: Moneda)

• Pre: saldo – cantidad ≥ 0

• Post: saldo’ = saldo – cantidad

• Invariantes de clase– CuentaCorriente: saldo ≥ 0

CuentaCorriente

saldo

meterDinero(cantidad)

sacarDinero(cantidad)

115

Diseño por contratos: subcontratación

• PPC’s de operación– CuentaCorriente.sacarDinero(cantidad: Moneda)

• Pre: saldo – cantidad ≥ 0

• Post: saldo’ = saldo – cantidad

• PPC’s de operación redefinida en la subclase– CuentaCredito.sacarDinero(cantidad: Moneda)

• Pre: saldo + credito – cantidad ≥ 0

• Post: saldo’ = saldo – cantidad

– Pre: menos restrictiva, o igual

– Post: más restrictiva, o igual

• Invariantes de clase (más restrictivo, o igual)– CuentaCorriente: saldo ≥ 0

– CuentaCredito: (credito ≥ 0) AND (saldo + credito ≥ 0)

CuentaCorriente

saldo

sacarDinero(cantidad)

CuentaCredito

credito

sacarDinero(cantidad)

¿Es correcta esta generalización?

116

Diseño por contratos: uso correcto de jerarquías

• CaminoOblicuo.distancia.post

• CaminoEsquinado.distancia.post

2

12

2

12 )()( yyxxd −+−=

)()( 1212 yyxxd −+−=

CaminoOblicuo

origen: Punto

distancia( ): Float

destino: Punto

CaminoEsquinado

origen: Punto

distancia( ): Float

destino: Punto

¿Cuál sería

correcta?

(x1, y1)

(x2, y2)