Ingeniería de Requisitos

Ingeniera del Software I 4Ingeniera Informtica
Procesos del Desarrollo de Software 3 Grado en Ingeniera Informtica
Proyecto Prctico
de Ingeniera de Requisitos
Curso 2010-2011
Gonzalo Gnova
Proyecto Prctico de Ingeniera de Requisitos
Presentacin
Ingeniera del Software I
Procesos del Desarrollo de Software
Jos Miguel Fuentes (fuentes [at] inf.uc3m.es) - COORDINADOR

Mnica Marrero (mmarrero [at] inf.uc3m.es)
Diego Martn (dmandres [at] inf.uc3m.es)
Isidro Hernanz (ihernanz [at] inf.uc3m.es)
Direccin para entregas: pds.uc3m [at] gmail.com
Aula Global 2 / Avisos / Web de la asignatura
Gonzalo Gnova (ggenova [at] inf.uc3m.es) - COORDINADOR

Roberto Galindos (rgalindo [at] inf.uc3m.es)
Eduardo Barra (ebarra [at] inf.uc3m.es)
Isidro Hernanz (ihernanz [at] inf.uc3m.es)
Direccin para entregas: is.uc3m [at] gmail.com
http://www.ie.inf.uc3m.es/grupo/docencia/reglada/Is1y2/IS1.htm
http://www.ie.inf.uc3m.es/grupo/docencia/reglada/Is1y2/PDS.htm
Un curso de anlisis y diseo en dos asignaturas:
IS1/PDS: requisitos del usuario (captura) y requisitos del software (anlisis)

IS2: diseo arquitectnico (alto nivel) y diseo detallado (bajo nivel)
Objetivos de la asignatura
Anlisis y definicin de los requisitos de una aplicacin informtica
Aprender...
Redaccin de un documento completo de requisitos

Desarrollo dirigido por modelos (MDA-MDD-MDE), evolucin de USDP
Estndares de documentacin de proyectos
Tcnicas del anlisis orientado a objetos para ingeniera de requisitos
Desarrollar capacidades
Abstraccin y resolucin de problemas

Lectura crtica y reflexiva
Trabajo en equipo
Exposicin de resultados propios
Revisin de trabajos ajenos
Aprendizaje a partir de errores propios y ajenos
Programa de la asignatura: teora
Tema I. Requisitos del usuario (captura de requisitos)
Unidad 1. Estndares de documentacin

Unidad 2. Introduccin a la ingeniera de requisitos
Unidad 3. Obtencin y descripcin de requisitos de usuario
Unidad 4. Modelado de casos de uso con UML
* Unidad 5. tica y responsabilidad profesional en la ingeniera del software
* Unidad 6. Educacin tica en la ingeniera del software (artculo y examen)
Tema II. Requisitos del software (anlisis de requisitos)
Unidad 11. Modelado conceptual con UML (1)

Unidad 10. Sobre la diferencia entre anlisis y diseo (artculo y examen)
Unidad 7. Tipos de requisitos del software
Unidad 8. Propiedades y atributos de los requisitos
Unidad 9. Organizacin y calidad de los requisitos
Programa de la asignatura: prcticas
Equipos de 4 alumnos
Trabajo en 2+2 fases (URD/SRD + ADD/DDD)
Actividades en cada fase
Desarrollo y documentacin del proyecto conforme al ndice de la prctica
recuento de horas dedicadas al proyecto y mtricas
contabilizadas al principio de cada documento
enviadas aparte por correo segn las plantillas (horas, mtricas)
Sesiones de tutora por equipo
no se califica, pero asistencia obligatoria
Revisiones cruzadas
informes de revisin redactados conforme a las normas
Exposiciones en pblico y defensa del proyecto
entrega de transparencias impresas el primer da de exposiciones (2xPg!)
exposicin individual de una parte del proyecto
respuestas a los revisores y a los profesores
Documentacin entregada
Atencin a nombres de archivos y fechas de entrega

Dos documentos parciales (el segundo completa al primero):
ej. ProyectoIS1-M05.doc: equipo M05, etc. (poner IS1 PDS segn convenga)
envo por correo a la direccin de entrega y miembros del equipo revisor
ver ndice adaptado del estndar ESA PSS-05-0
Dos documentos de revisin (el segundo completa al primero):

ej. RevisinIS1-M05-R07.doc: equipo M05 revisado por equipo M07, etc.
envo por correo a la direccin de entrega y miembros del equipo revisado
Proyecto final revisado (normas):
documento final + presentaciones + recuento de horas + mtricas

ej. ProyectoIS1-M05.doc + etc.
envo por correo la direccin de entrega
ejemplar impreso encuadernado en espiral con tapas duras, incluyendo:
revisiones recibidas y respuestas, revisiones enviadas
transparencias de las dos presentaciones
Propuesta de preguntas tericas para el examen de test

Descripcin de la prctica
Realizar un proyecto de ingeniera inversa sobre un portal inmobiliario real.
Describir brevemente el alcance total de la funcionalidad ofrecida por el portal.
Seleccionar un subconjunto coherente de la funcionalidad ofrecida por el portal, de

forma que sea abarcable dentro de los lmites de carga de trabajo de la asignatura.
Buscar en internet... Elegir un portal y ceirse a l.

Incluir tambin los requisitos de restriccin/no funcionales.
Es muy importante definir bien los lmites del sistema descrito.

Se califica la calidad de la descripcin realizada en la prctica, no la cantidad de
funcionalidad descrita, ni la importancia comercial o la calidad tcnica del portal.
Describir este subconjunto en forma de requisitos y con los modelos necesarios.

Una parte importante del trabajo de la prctica consiste en perfilar bien el lenguaje
utilizado para definir el sistema.
Realizar una evaluacin del portal (la parte seleccionada):

Sugerir mejoras en la concepcin del sistema (en forma de nuevos requisitos). Por
ejemplo, detectar carencias importantes en la funcionalidad ofrecida por el portal.
Sugerir mejoras en la implementacin del sistema. En principio, puesto que se trata de un
proceso de ingeniera inversa donde los requisitos se han extrado de la implementacin, se
da por supuesto los requisitos estn correctamente implementados; no obstante, pueden
existir obvios defectos de implementacin.
7
Formato de los documentos
Word, Times New Roman 12 Arial 10, interlineado sencillo.

Impreso a doble cara
Opcionalmente, formato PDF (con permisos de lectura y copia).
Extensin (porque queremos calidad, no cantidad):
URD: 15 a 20 pginas.
SRD: 30 a 40 pginas.
TOTAL: 45 a 60 pginas (sin contar ndices ni anexos). Trabajo excesivo?
Factor de penalizacin en la calificacin del documento por exceso de pginas.
penalizacin
1
1-(p-60)/60
0
0
60
120
pginas
8
Trabajo en equipo y dedicacin a la prctica
Un total de 60 horas/alumno dedicadas a la prctica es razonable.

Equivale a una hora de trabajo prctico por cada hora de clase terica.
20 horas de clase + 20 horas de trabajo personal = 40 horas/semana.
La proporcin entre trabajo individual y en equipo debera ser 4/1 3/1.

Para conseguirlo la distribucin y coordinacin del trabajo deben ser adecuadas.
Si el nmero de horas es igual para todos falta sinceridad pero si no se califica!
Nombre
Ind. Eq. TOTAL
Nombre
Ind. Eq. TOTAL
Ana Garca
25
35
60
Ana Garca
40
15
55
Juan Gmez
25
35
60
Juan Gmez
43
11
54
Isabel Lpez
25
35
60
Isabel Lpez
47
16
63
Pedro Fernndez
25
35
60
Pedro Fernndez
50
18
68
TOTAL 100 140
240
TOTAL 180
60
240
MAL
BIEN
9
Calendario de la asignatura
Dedicacin a la asignatura, aproximadamente:

30 horas de clase terica
30 horas de otras actividades en clase
60 horas de trabajo personal y en equipo
Clases tericas
Asistencia no controlada.
El examen de Test es un reflejo directo del aprovechamiento de las clases tericas, de ah la
importancia que se le da en la nota final.
Clases de laboratorio
Tutoras por equipo
Aprendizaje de herramientas.
Asistencia obligatoria.
Sirven para que el profesor pueda hacer un seguimiento efectivo del proyecto.
Aprovechad la tutora llevando un borrador bien trabajado.
Exposiciones/Revisiones
Asistencia obligatoria a todas las exposiciones, aunque no toque exponer.
Dos miembros exponen la prctica, dos responden a revisores y profesores.
Tiempo mximo de exposicin: 20 minutos entre ambos.
Calendario completo (IS1, PDS)

Atencin a las fechas de entregas.
10
Evaluacin de la asignatura
Individual
Prctica
Teora
Equipo
Tutoras*
00% Exp/Preparacin
10%
Exp/Ejecucin
05% Documentacin
25%
Exp/Respuestas
05% Revisiones
05%
Exmenes parciales 10% Propuesta de

Examen final
30% preguntas
50%
50%
10%
50%
50%
100%
* Asistencia obligatoria (0,5 penalizacin por falta no justificada)

Igualmente se penaliza la falta no justificada a las exposiciones ajenas.
Ms detalles
11
Bibliografa
Ingeniera de requisitos
Eric Braude. Software Engineering. An Object-Oriented Perspective. John
Wiley & Sons, 2001.
Captulos 3 y 4
Ian Sommerville. Ingeniera del Software. Pearson-Addison Wesley, 2005.
Captulos 6 y 7
Roger Pressman. Ingeniera del software: un enfoque prctico, 6 ed. McGrawHill.
Captulos 7 y 8
Modelado con UML

Martin Fowler, Kendall Scott. UML Distilled. A Brief Guide to the Standard
Object Modeling Language. Addison-Wesley, 2004.
Jim Arlow, Ila Neustadt. UML and the Unified Process. Practical ObjectOriented Analysis & Design. Addison-Wesley, 2002.
Perdita Stevens, Rob Pooley. Using UML. Software Engineering with Objects
and Components. Addison-Wesley, 2000.
Ms en la ficha de la asignatura (IS1, PDS)

12
Tema I
Requisitos del Usuario
Unidad 1. Estndares de documentacin

Unidad 2. Introduccin a la ingeniera de requisitos
Unidad 3. Obtencin y descripcin de requisitos de usuario
Unidad 4. Modelado de casos de uso
Unidad 5. tica y responsabilidad profesional
Unidad 6. Responsabilidad tica del ingeniero de software (artculo)
13
Flujos de trabajo vs. Documentos

Flujos de trabajo
USDP
Requisitos
Anlisis
Diseo
Documentos
Clsica
IEEE
ESA
Anlisis de
requisitos
Software
Requirements
Specification
(IEEE 830-1993)
User Requirements
Document
Diseo
arquitectnico
Diseo detallado
Software Design
Document
(IEEE 1016-1987)
Software Requirements
Document
Architectural Design
Document
Detailed Design
Document
+ Implementacin, Pruebas, Mantenimiento...

14
El Estndar de la ESA
GENERAL
European Space Agency software engineering standards

Guide to the software engineering standards
PRODUCTS
Guide to the user requirements definition phase

Guide to the software requirements definition phase
Guide to the software architectural design phase
Guide to the software detailed design and production phase
Guide to the software transfer phase
PROCEDURES Guide to the software operations and maintenance phase

Guide to software project management
Guide to software configuration
Guide to software verification and validation
Guide to software quality assurance
ESA Lite
Guide to applying the ESA standards to small software projects

15
Los requisitos del usuario en el Estndar ESA
ESA software engineering standards (PSS-05-0)

Chapter 2. The user requirements definition phase
2.3. Actividades: nociones importantes
Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1)

Chapter 3. Using Object-Oriented Methods with PSS-05
No afecta
Guide to the user requirements definition phase (PSS-05-02)

Chapter 2. The user requirements definition phase
2.3. Determinacin del entorno operacional
2.4. Requisitos de capacidad / Requisitos de restriccin
2.7. Revisin de los requisitos del usuario
Chapter 5. The user requirements document
5.1. Introduccin: lo que debe ser, lo que no debe ser
5.3. Estilo: claridad, consistencia, modificabilidad
5.6. Contenido adaptado
Preguntas ms frecuentes
16
Los requisitos del software en el Estndar ESA
ESA software engineering standards (PSS-05-0)

Chapter 3. The software requirements definition phase
3.3. Actividades: modelo lgico; tipos de requisitos y propiedades
Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1)

Chapter 3. Using Object-Oriented Methods with PSS-05
3.4. Modelo lgico = modelo de requisitos + modelo de anlisis
Guide to the software requirements definition phase (PSS-05-03)

Chapter 2. The software requirements definition phase
2.3. Construccin del modelo lgico (rendimiento, riesgos, prototipado)
2.4. Tipos y propiedades de los requisitos del software
2.6. Revisin de los requisitos del software
Chapter 5. The software requirements document
5.1. Introduccin: lo que debe ser, lo que no debe ser
5.3. Estilo: claridad, consistencia, modificabilidad
5.6. Contenido adaptado
Preguntas ms frecuentes
17
Introduccin a la ingeniera de requisitos

Qu es la Ingeniera de Requisitos
Captura y Anlisis
Resultado del proceso: el documento de requisitos
Necesidad de la Ingeniera 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 ingeniera profesional sin requisitos escritos
Dos niveles en los requisitos

Requisitos del Usuario, Requisitos del Software
Dificultades de la Ingeniera de Requisitos

El precio pagado: es una necesidad, no un lujo
La Ingeniera de Requisitos en el contexto del proyecto

Pre-proyecto: valor contractual, viabilidad, planificacin, estimacin...
18
Un caso prctico
Necesito algo para organizar mejor mis actividades, una
agenda para llevar al da mi horario, mis compromisos, etc.
x
x
x
x
x
x
x
x
x
x
x x x
x x x
x x x
MES
x x x
x x x
x
x
x
x
x
Da
x
x
x
x
x
Compromiso
Compromiso
Compromiso
19
The Chaos Report
The Standish Group International: realiza estudios desde 1994

2003: datos de 13.522 proyectos de tecnologas de la informacin
1994
1996
1998
2000
2003
Proyecto exitoso
16%
27%
26%
28%
34%
Proyecto completo
pero deficiente
53%
33%
46%
49%
51%
Proyecto
cancelado
31%
40%
28%
23%
15%
20
Porcentaje
The Chaos Report

100,00%
90,00%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,00%
0,00%
1994
1996
1998
2000
2003
Aos
Proyecto exitoso
Proyecto completo pero deficiente
Proyecto cancelado
21
Requisitos del Usuario vs. Requisitos del Software

Requisitos del usuario
ANLISIS
Requisitos del software
Diseo arquitectnico
DISEO
Diseo detallado
IMPLEMENTACIN
22
Diferentes puntos de vista Diferentes documentos

Lo que l
necesita es...
Lo que yo
necesito es...
Lo que tienes
que hacer es...
Analista
Arquitecto
Cliente
Lo que tengo
que hacer es...
Diseador
23
Obtencin y descripcin de requisitos del usuario
Las fuentes de los requisitos

Plan de trabajo para obtener los requisitos
Identificacin de stakeholders
Quines tienen inters en el producto?
Quin es el cliente?
Intereses contrapuestos, requisitos
contradictorios
Negociar el equilibrio
Requisitos
Calidad
Presupuesto
Recursos
Planificacin
Tiempo
Cmo llevar adelante una entrevista

Antes, durante, despus...
Identificar
Entrevistar
[no conforme]
Escribir
Revisar
[conforme]
24
Tcnicas para la obtencin y descripcin de requisitos
Textuales
Relativamente accesibles a un cliente sin formacin especfica
Texto en prosa comn y corriente
Texto estructurado, lenguaje tcnico
Casos de uso
Grficas
Requieren un cierto grado de formacin tcnica en el cliente
Tienen el peligro de convertir el anlisis de requisitos en diseo
Diagramas de flujo de datos
Diagramas de actividad
Diagramas de estados
Prototipos
No confundir con diseo, valorar la inversin
Interfaces de usuario
Protipado rpido
25
Beneficio de la inversin en prototipos

Beneficio obtenido
(% ahorro/gasto)
Beneficio
ptimo
GUI
simplificada
Recursos
malgastados
0%
Gasto efectuado
(% prototipo/total)
100%
Adaptado de E. Braude,
Software Engineering: An Object-Oriented Perspective
26
Modelado de casos de uso

Introduccin
Propsito y definicin
Casos de uso y extraccin de requisitos

El requisito no es la interaccin, sino el objetivo.
El modelo de casos de uso

Notacin. Actores y casos de uso. Actores cooperativos. Include y Extend.
Descripcin textual de casos de uso

Escenario bsico y escenarios alternativos. Pre- y postcondiciones.
Casos de uso y operaciones del sistema

Descripcin grfica de casos de uso
Casos de uso y procesos de negocio

27
Ejemplo: Agencia de viajes por internet
Ingeniero. Explcame cmo quieres que funcione la aplicacin.

Cliente. Bueno, lo primero es acceder a la pgina web de la agencia, no?,
entonces se seleccionan las ciudades de origen y destino, el nmero de
pasajeros, y las fechas de ida y vuelta. El sistema muestra el precio de los
billetes, y si el usuario est conforme introduce los datos de su tarjeta de
crdito para hacer efectivo el pago. Y hay que dar los nombres de los
pasajeros, claro.
Ingeniero. Eso es todo?
Cliente. Ah, s, por supuesto, si hay varios vuelos en el mismo da, el usuario
debe seleccionar uno de ellos. Tambin hay que tener en cuenta que algunos
usuarios estn dispuestos a variar sus fechas de viaje, con tal de obtener
tarifas ms baratas.
Ingeniero. As que habr que facilitar la bsqueda de vuelos en fechas
parecidas y que sean ms baratos, no? Por ejemplo, variando un da
adelante o atrs tanto la fecha de ida como la de vuelta.
Cliente. Exactamente, lo has cogido muy bien.
28
Descubrir el objetivo
agencia de viajes
por internet
Acceder a la pgina web
Vaga descripcin inicial
Seleccionar ciudad origen y destino,

nmero de pasajeros y fechas de ida y vuelta
Mostrar vuelos disponibles

y precio de los billetes
Patrn de
comportamiento
[no conforme]
[alternativas]
Mostrar alternativas ms baratas

en fechas parecidas
[conforme]
Objetivo
comprar billetes de avin por
internet facilitando la bsqueda
de tarifas baratas
Seleccionar un vuelo
[conforme]
[no conforme]
Introducir nombres de los pasajeros

y datos de la tarjeta de crdito
29
El modelo de casos de uso
La tcnica de los casos de uso (inventada por Ivar Jacobson):

Objetivo: identificar los requisitos funcionales de un sistema (subsistema, clase,
etc.), estructurados en torno a los diversos roles de usuarios.
Mtodo: descripcin de las interacciones tpicas usuario/sistema (escenarios).
Un caso de uso (anvndningsfall, en sueco) es una forma de usar el

sistema, habitualmente descrita a travs de un conjunto de usos tpicos.
Describe cmo un actor usa un sistema para conseguir un objetivo, y lo que
el sistema hace para ayudarle. Cuenta la historia de cmo el sistema y sus
actores colaboran para producir algo de valor, un uso completo del sistema.
El modelo de casos de uso sirve para definir y expresar grficamente el
sistema y su entorno:
Las funcionalidades que contiene el sistema: casos de uso.
Los agentes externos que interaccionan con el sistema: actores.
Las relaciones entre agentes externos y funcionalidades: asociaciones.
El modelo de casos de uso se expresa grficamente mediante uno o varios

diagramas de casos de uso.
Es posible estudiar los casos de uso sin utilizar ningn diagrama.
30
Ejemplo: Feria de subastas
Se desea modelar un sistema informtico 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 travs 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 algn artculo es necesario darse de alta como vendedor. El
vendedor puede registrar artculos en la subasta, rellenando una ficha por
cada artculo, que sale as inmediatamente a subasta.
Anlogamente, para participar en una subasta es necesario darse de alta
como comprador. El comprador puede pujar por cualquiera de los artculos
subastados en la feria. Cuando no se produce ninguna nueva puja, el artculo
queda definitivamente adjudicado al comprador. Si un artculo no ha recibido
ninguna puja, el vendedor puede modificar alguno de sus datos.
Cualquier persona puede participar como observador en una subasta, es
decir, puede consultar la lista de artculos 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.
31
Diagrama de casos de uso

Feria de subastas
Asociaciones
Registrar
artculo
Modificar
datos de artculo
Consultar
lista de artculos
Vendedor
Casos de uso
Actores
Registrar
usuario
Observador
Pujar por
artculo
Frontera del sistema
Comprador
32
Actores
Un actor representa el rol que adopta una entidad externa que interacciona
directamente con el sistema.
Todo actor tiene un nombre.
Los actores significan roles, no entidades concretas:
Varias entidades concretas pueden desempear el mismo rol.
Una misma entidad concreta puede desempear varios roles.
Un actor puede participar en varios casos de uso, desempeando un rol

diferente en cada uno, por tanto un actor, ms que un rol, es un conjunto
coherente de roles.
Tipos de actores (o agentes externos, concepto ms amplio que usuario):
Personas o cosas (otro sistema, un sensor, agua, fuego, tiempo...).
Primarios o secundarios (realizan tareas administrativas o de mantenimiento).
Utilidad: descubrir y organizar los casos de uso (quin quiere qu).

Peligro: identificar los actores con categoras de usuarios.
Vendedor, Comprador y Observador no son categoras disjuntas, sino roles.
33
Casos de uso
Un escenario es una secuencia de acciones del actor y acciones del sistema

que describe una interaccin tpica entre ambos (qu hace cada uno).
Escenario bsico: todo va bien.
Escenarios alternativos, manejo de errores, situaciones excepcionales...
Un caso de uso es una coleccin de escenarios con un objetivo comn:

El conjunto de escenarios especifica un comportamiento que proporciona un
resultado valioso para uno o ms de los interesados en el sistema.
Representa una tarea, o unidad coherente de funcionalidad, que el sistema
est obligado a proporcionar a los actores en beneficio de los interesados.
En un caso de uso pueden participar varios actores distintos, y adems:

Las acciones de un actor pueden ser beneficiosas para otros actores.
Puede haber interesados (stakeholders) que no sean actores en absoluto.
Dos niveles de abstraccin en la definicin:

Interaccin actor/sistema, secuencia de acciones (descripcin prototpica).
Servicio requerido, objetivo, finalidad, funcionalidad (descripcin abstracta).
34
Actores cooperativos
Qu significa conectar varios actores a un mismo caso de uso?
El caso de uso puede requerir la participacin de varios actores, y

Cada actor asociado a un caso de uso representa un rol distinto, y
Uno de los actores ser el iniciador del caso de uso, y
Los actores cooperan entre s para realizar el objetivo del caso de uso.
Simular vuelo
Piloto
Entrenador
Incorrecto: pretender que es el mismo caso de uso para

distintos actores, que lo ejecutan de modo independiente.
35
Include y Extend
Es posible definir relaciones entre casos de uso:
include: para describir un comportamiento comn reutilizable.
extend: para describir una variante del comportamiento base.
Sacar dinero
include
Validar
tarjeta
Inclusin
Base
Editar
documento
extend
Ayuda
Extensin
Significado problemtico en UML:

No est clara la diferencia entre ambas (reutilizacin / insercin).
No encajan con la definicin de unidad coherente de funcionalidad.
Pueden llevar por error al modelado de procesamiento secuencial.
No use estas relaciones si puede evitarlo.
36
Especificacin textual de casos de uso

Nombre
Frase verbal descriptiva
Actores
Actores que interaccionan con el sistema

participando en este caso de uso
Objetivo
Finalidad o servicio requerido (qu, no cmo)
Precondiciones
Descripcin del estado del sistema antes de la

ejecucin del caso de uso (aspecto relevante)
Postcondiciones
Descripcin del estado del sistema despus

de la ejecucin del caso de uso (diferencia)
Escenario bsico
Secuencia de acciones principales de la

interaccin en el escenario bsico, detallando
la informacin intercambiada, y los cambios
observados en el sistema
37
Ejemplo: Registrar artculo

Nombre
Registrar artculo
Actores
Vendedor
Objetivo
Registrar los datos de un artculo para

que salga a subasta
Precondiciones
Usuario registrado como Vendedor
Postcondiciones
Artculo registrado
Escenario bsico
Insertar tarjeta magntica

Abrir sesin como Vendedor
Introducir datos del artculo
Confirmar datos introducidos
Terminar
38
Escenarios alternativos
Nombre
Registrar artculo
Escenario bsico
1. Insertar tarjeta magntica

2. Abrir sesin como Vendedor
3. Introducir datos del artculo
4. Confirmar datos introducidos
5. Terminar
2-5a. Tarjeta invlida
1. Devolver tarjeta
2. Terminar
Escenarios alternativos
2-5a. Apertura de sesin incorrecta

1. Devolver tarjeta
2. Terminar
5a. Desea registrar otros artculos
1. Volver al paso 3
39
Precondiciones y postcondiciones
Son una forma de refinar o especificar con ms detalle el objetivo del caso de
uso, mediante la descripcin del estado del sistema antes y despus de la
ejecucin del caso de uso:
Precondiciones: pueden ser comprobadas en la secuencia de acciones del caso
de uso, pero no realizadas en ese momento.
Postcondiciones: pueden referirse a la salida normal o a una excepcional.
Precedencia entre casos de uso: toda precondicin de un caso de uso

debe cumplirse en el estado inicial del sistema, o bien, debe ser realizada
por alguno de los casos de uso del sistema, que la tendr por tanto como
postcondicin.
Caso de uso
Precondiciones
Registrar usuario
Postcondiciones
Usuario registrado
Registrar artculo
Usuario registrado como Vendedor
Pujar
Usuario registrado como Comprador Si no hay ms pujas,

artculo adjudicado
Artculo registrado y no adjudicado
Artculo registrado
40
Casos de uso y operaciones del sistema
Los casos de uso no son operaciones del sistema (no confundirlos):

Una operacin del sistema es un servicio elemental que el actor puede solicitar,
es la respuesta del sistema a un evento externo.
El caso de uso es un uso coordinado de operaciones del sistema: protocolo.
El actor no ejecuta el caso de uso (no lo invoca, en todo caso lo inicia).
Operaciones del sistema = bloques de acciones en un escenario.

Peticin
sacar dinero
Validacin
comprobar que hay saldo suficiente
Cambio de estado
alterar el saldo de la cuenta
Respuesta
entregar el dinero
Especificacin de operaciones mediante contratos.

41
Especificacin grfica de casos de uso

Una simple secuencia de acciones no puede describir
adecuadamente la riqueza de situaciones que se pueden
presentar en un caso de uso (alternativas, excepciones...).
Posibles soluciones:
Complicar la descripcin textual de la secuencia de acciones.
Emplear una descripcin grfica mediante diagramas de actividad.
Un diagrama de actividad representa un flujo de acciones

Secuencial, alternativo o concurrente.
Elementos principales:
Acciones: cada una de las unidades en que se descompone la actividad.
Transiciones: conexin entre el fin de una accin y el comienzo de otra.
Condiciones: deben ser expresiones booleanas mutuamente exclusivas.
42
Acciones y transiciones
Estados inicial y final
Decisiones y ramas alternativas
Sincronizacin de ramas concurrentes
Preparar desayuno
Abrir boca
Cortar
pan
Tomar alimento
Leer
peridico
Cerrar boca
[slido]
Beber
caf
Comer pan
[lquido]
[else]
Masticar
[terminado]
Limpiar cocina
Tragar
43
Correspondencia entre las especificaciones textual y grfica
Nombre: Consultar lista de artculos

Actores: Observador
Objetivo: Obtener lista de artculos con
datos de vendedores, y lista de pujas de
un artculo con datos de compradores
Precondiciones:
Postcondiciones:
Escenario bsico:
Abrir sesin como Observador
Mostrar la lista de artculos con los datos
de los vendedores
Opcionalmente:
Seleccionar un artculo
Mostrar la lista de pujas del artculo
con los datos de los compradores
[sesin abierta]

[error]
[ok]
Mostrar lista de artculos con datos de vendedores
[fin]
[mostrar pujas]
Seleccionar artculo
Mostrar lista de pujas con datos de compradores
44
Subactividades
Consultar lista
de artculos
[error]
Abrir sesin
Abrir sesin
[ok]
Mostrar lista de artculos con datos de vendedores
[sesin abierta]
[fin]
[mostrar pujas]
Seleccionar artculo
Mostrar lista de pujas con datos de compradores
45
Casos de uso y procesos de negocio

Procesos de negocio: acciones y agentes
Localizar la casa
Vendedor, Comprador, Web inmobiliaria
Obtener una hipoteca
Comprador, Representante del banco, SI del banco
Formalizar la compra
Vendedor, Comprador, Representante del banco,

SI del banco, Notario, SI del registro de la propiedad
Casos de uso: sistemas, casos de uso y actores

Web inmobiliaria
Localizar la casa
Vendedor, Comprador
Obtener una hipoteca Comprador, Representante del banco

SI del banco
SI del registro de
la propiedad
Vendedor, Comprador,
Representante del banco,
Notario, SI del registro de la propiedad
Vendedor, Comprador,
Representante del banco, SI del banco,
Notario
46
tica y responsabilidad profesional

Qu es la tica
tica, comportamiento y libertad
Racionalidad y creatividad de la tica
Responsabilidad tica y conciencia moral
Los tres pilares de la tica

Sneca, Kant y Epicuro
Lo tico y lo legal
Primaca de lo tico
Funcin educadora de la ley
Problemas ticos especficos de la ingeniera del software

El cdigo tico de ACM/IEEE
Prembulo
Los ocho principios y algunos ejemplos de clusulas
47
Los tres pilares de la tica

interioriza
insensibilidad
caballero
racionalidad
VIRTUD
(Sneca)
NORMA
(Kant)
autodominio
militar
rigorismo
disciplina
BIEN
(Epicuro)
da sentido
egosmo
felicidad
vividor
48
El cdigo tico de ACM/IEEE (v5.2, 1999)

1. Pblico. Los ingenieros de software debern actuar en consonancia con el inters
pblico.
2. Cliente y empleador. Los ingenieros de software debern actuar de forma que
respondan a los intereses de sus clientes y empleadores siendo consecuentes con el
inters pblico.
3. Producto. Los ingenieros de software debern asegurar que sus productos y las
modificaciones asociadas cumplen los ms altos estndares profesionales posibles.
4. Juicio. Los ingenieros de software debern mantener la integridad e independencia
en sus juicios profesionales.
5. Gestin. Los gerentes y lderes de la ingeniera del software debern suscribir y
promocionar un enfoque tico en la gestin del desarrollo y mantenimiento del
software.
6. Profesin. Los ingenieros de software debern mantener la integridad y reputacin
de la profesin de acuerdo con el inters pblico.
7. Colegas. Los ingenieros de software debern ser imparciales y apoyar a sus colegas.
8. Personal. Durante toda su vida, los ingenieros de software debern aprender lo
concerniente a la prctica de su profesin y promocionar un enfoque tico en la
prctica de su profesin.
49
Ejemplos de clusulas del cdigo tico

Pblico
1.03 certificar software: seguridad, especificaciones, pruebas, riesgos...

1.04 revelar peligros reales o potenciales
Cliente y
empleador
2.01 respetar el propio nivel de competencia

2.05 informacin confidencial obtenida en el trabajo profesional
2.06 informar al cliente si es probable que un proyecto fracase
Producto
3.08 buena documentacin

3.09 estimaciones cuantitativas realistas (= 5.05)
3.10 pruebas, depuraciones y revisiones adecuadas
Juicio
4.02 aprobar documentos supervisados

4.04 objetividad profesional
Gestin
5.07 justa remuneracin

5.08 no impedir el acceso a puestos al personal cualificado
Profesin
6.04 apoyar a otros ingenieros que intenten seguir este cdigo

6.07 veracidad y exactitud de las caractersticas del software
Colegas
7.04 revisar el trabajo de otros

7.06 ayudar a los colegas a mejorar su prctica profesional
Personal
8.05 conocer estndares relevantes y leyes aplicables

50
Tema II
Requisitos del Software
Unidad 7. Tipos de requisitos del software

Unidad 8. Propiedades y atributos de los requisitos
Unidad 9. Organizacin y calidad de los requisitos
Unidad 10. Sobre la diferencia entre anlisis y diseo (artculo)
Unidad 13. Herramientas de apoyo en ingeniera de requisitos
51
Tipos de requisitos del software

Qu son los requisitos del software
Descripcin de la naturaleza exacta de la aplicacin
Diferencia con los requisitos del usuario
Punto de vista del cliente, punto de vista del desarrollador
Clasificacin de requisitos del software

Requisitos inversos
Requisitos funcionales decir el qu (anlisis)
Requisitos de informacin / Requisitos de operacin
Modelo del sistema: modelo conceptual + modelo de casos de uso
Requisitos no funcionales restringir el cmo (pre-diseo)
Caractersticas distintivas
Ejemplos
Anlisis y documentacin
Trazabilidad: hacia atrs / hacia delante

52
Diferencias RU-RS
Requisitos del Usuario
Requisitos del Software
objetivo
planteamiento del problema

captura de requisitos
refinamiento del problema

anlisis 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

caractersticas de los usuarios
entorno operacional
captura mediante prototipos
conocimiento de expertos
modelado, mtodos formales
organizacin, no dejar cabos sueltos
consistencia y completitud
modelos
(modelo de dominio)
modelo de casos de uso

modelo conceptual
atributos
necesidad
(prioridad, estabilidad)
casos de
uso
nombre, actores
objetivo y escenario bsico
escenarios alternativos
pre- y postcondiciones
53
Nomenclatura de los modelos
Adaptacin
ESA
URD / SRD
Modelo
lgico
Modelo de
requisitos
SRD
Modelo de
casos de uso
Modelo del dominio
Modelo de
anlisis
Modelo
conceptual
Modelo del
sistema
54
Requisitos no funcionales
Consumo de recursos
memoria, capacidad de trfico...
Rendimiento
velocidad, tiempo de respuesta...
Fiabilidad y disponibilidad
cuantificacin de fallos permitidos
Manejo de errores
errores del entorno, errores internos
Requisitos de interfaz
comunicacin con usuarios, con otras aplicaciones
Restricciones
exactitud, lenguajes y plataformas, arquitectura, estndares...
Seguridad
seguridad del sistema (security), seguridad de las personas (safety)
55
Matrices de trazabilidad
RU
0..*
1..*
1..*
RS
URD/SRD
RS1
RS2
RS3
X
X
Imp
ADD/DDD
Matriz de doble entrada dispersa
RU1 RU2 RU3
1..*
Matrices de tres columnas (una o las dos)
RU
RS
Descripcin
RS
RU
1,2
1,3
2,4,5
RS4
RS5
Ttulo
56
Propiedades y atributos de los requisitos del software
Propiedades globales
Completitud
organizacin por tipos de requisitos
Consistencia
matriz de referencias cruzadas
Propiedades individuales
Tamao
Claridad
Comprobabilidad: validacin y verificacin
Condiciones de error
Atributos
Automticos: identificador, creador, fecha de creacin
Obligatorios: tipo, estado, descripcin breve.
Opcionales: descripcin detallada, fuente, necesidad, prioridad, estabilidad,
complejidad, riesgo, coste
57
Consistencia: conflictos, acoplamientos y redundancias

R1
R2
R1
R3
R4
R5
R6
R7
R2
R3
R4
R5
R6
+
x
x
+
R7
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
58
Mtodos para organizar los requisitos del software

Tcnicas ya mencionadas
Matrices de trazabilidad
Matriz de consistencia: conflicto, acoplamiento, redundancia
Modularidad y anidamiento de requisitos: reas temticas
Organizar los requistos segn el modelo del sistema

Segn el modelo de casos de uso
Clases mencionadas
Operaciones utilizadas
Segn 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
59
Ciclo de vida de los requisitos
creado
eliminado
Propuesto
Validado
Implementado
Verificado
Cancelado
60
Caractersticas de una herramienta de gestin de requisitos (1)
Herramienta multiproyecto y multiusuario

Gestin de usuarios: analistas, jefes de proyecto, administradores.
Permisos de acceso por proyecto: lectura o escritura.
Configuracin de un proyecto
Propiedades globales de un proyecto: nombre, descripcin, ubicacin...
Atributos habilitados en funcin del tipo de requisito, valores desplegables.
Acceso, sesin y control de versiones
Registro automtico de sesiones: inicio y fin, requisitos creados o modificados.

Control de versiones: sin control, control opcional, control obligatorio.
Notificacin de modificaciones (opcional).
Seguimiento del ciclo de vida.
Propiedades de los requisitos
Agrupacin en paquetes y subpaquetes.

Atributos: automticos, obligatorios, opcionales.
Relaciones entre requisitos: navegabilidad y asimetra. Requisitos sospechosos.
Otros artefactos asociados: escenarios, modelos...
61
Caractersticas de una herramienta de gestin de requisitos (2)
Visualizacin, navegacin y edicin
Ficha o tabla, atributos visibles.

Ordenacin y filtrado.
Bsqueda y reemplazamiento.
Movilidad entre paquetes.
Duplicacin de requisitos.
Informes
Listado de requisitos: ordenacin, filtrado, atributos mostrados...
Estadsticas varias: ritmo de creacin/modificacin, conflictos...
Matrices de trazabilidad y consistencia.
Utilidades
Asistencia en la creacin del glosario de trminos.

Coherencia entre los requisitos y los elementos del modelo.
Deteccin automtica de solapamientos entre requisitos.
Mtricas de calidad.
62
Mtricas 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 aadido por la medicin
Mtricas de calidad: cmo de bien estn escritos los requisitos

Qu debemos medir?
Propiedades deseables (cualitativas)
Indicadores medibles (cuantitativos)
Cmo podemos medir?
Medidas manuales (inspeccin con ayuda de cuestionarios)
Medidas automticas (caractersticas lingsticas)
Mtricas de calidad: cmo de efectivos son los procesos

medidas de la efectividad de la inspeccin de requisitos
medidas de la efectividad del proceso de anlisis de requisitos
63
Propiedades e indicadores de calidad

CLIENTE
DESARROLLADOR
Validabilidad
Completitud
Consistencia
Verificabilidad
Comprensibilidad
Precisin
Modificabilidad
Inambigedad
Trazabilidad Abstraccin
Atomicidad
Morfolgicos
Tamao, Legibilidad, Puntuacin, Acrnimos, Abreviaturas
Lxicos
Trminos negativos, conectivos, de flujo, anafricos, ambiguos, incompletos,

especulativos, de diseo
Analticos
Ortografa, gramtica, verbos imperativos, verbos condicionales, voz pasiva,

trminos del dominio
Relacionales
Nmero de versiones, grado de anidamiento, dependencias, solapamientos

64
Modelado conceptual con UML
Qu significa modelo conceptual
Objetos y clases
Es una vista grfica de la informacin contenida en los requisitos.

Notacin bsica de objetos y clases
Tipos de clases
Atributos
Operaciones
Asociaciones
Propiedades bsicas: nombres, multiplicidad, navegabilidad
Relacin con otros elementos: atributos, operaciones
Generalizaciones
Generalizacin y clasificacin
Jerarquas de clases
Diagramas de clases y de objetos

Asociaciones especiales
65
Objetos y clases
Dos niveles de abstraccin:

objeto: una entidad concreta con identidad, estado y comportamiento
clase: un conjunto de entidades con estructura y comportamiento comunes
La relacin de clasificacin / instanciacin

un objeto es instancia de una clase
la clase se usa como plantilla para construir (instanciar) objetos
Objetos y clases en anlisis y diseo:

Anlisis = especificacin, vista externa, caja negra
clases, atributos y operaciones corresponden a conceptos del dominio
es habitual usar una notacin simplificada al mximo
Diseo = implementacin, vista interna, caja blanca
clases, atributos y operaciones corresponden a fragmentos de cdigo
nuevos artefactos y soluciones que dependen del lenguaje y la plataforma
de implementacin y no tienen por qu corresponder a conceptos del dominio
66
Notacin bsica de objetos y clases
p1 : Punto
posicinX = 3
posicinY = -5
instance of
Punto
posicinX
posicinY
situar( )
mover( )
instance of
p2 : Punto
posicinX = 0
posicinY = 2
p1 : Punto
p1
Punto
: Punto
Punto
posicinX
posicinY
Punto
situar( )
mover( )
67
Tipos de clases
Tipos de clases segn los objetos representados:

objetos fsicos: avin, persona, libro...
objetos lgicos: cuenta corriente, asignatura, nmero complejo
objetos histricos: asiento bancario, reserva de habitacin
Para entender lo que es una clase, hace falta entender cules sern sus
instancias. Un caso especial lo constituyen los objetos que representan una
coleccin, familia o tipo de cosas, ms que una cosa en s misma.
Ejemplos: raza perruna, producto a la venta, ttulo en la biblioteca.
Es decir, un mismo concepto del mundo real puede ser modelado como
objeto o clase segn el contexto:
Pastor Alemn
Lata de Atn
El Lenguaje Unificado de Modelado
Todo objeto representa una entidad concreta, pero esto no significa

necesariamente entidad fsica o tangible.
68
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 anlisis):

propiedad redundante que puede ser calculada a partir de otras
/rea ( = base * altura)
pueden implementarse como operaciones al pasar a diseo
Notacin (ms importante en diseo)

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
telfonoOficina [0..2] {addOnly}
69
Operaciones
Operacin: funcin o transformacin que puede aplicarse a los
objetos de una clase
pueden ser invocadas por otros objetos, o por el mismo objeto
mtodo: especificacin procedimental (implementacin) de una operacin
Notacin (ms importante en diseo)

pueden suprimirse todos los elementos excepto el nombre de operacin
visibilidad nombre (param: Tipo = valDef,) : TipoRet {propiedades}
propiedades predefinidas de las operaciones: isQuery
ejemplos:
obtenerSaldo ( ) : Moneda {isQuery}
marcar (nmero : Telfono; reintentos : Integer)
70
Enlaces y asociaciones
Asociacin:
especificacin de un conjunto
de enlaces
Vendedor
Artculo
representa la estructura y el
comportamiento del sistema
Estatuilla : Artculo
Enlace:
conexin entre objetos
determina una tupla de objetos
instancia de una asociacin
Juan : Vendedor
estado de los objetos enlazados

estado del sistema
Ana : Vendedor
Cuadro : Artculo
Espejo : Artculo
hecho + posibilidad de comunicacin
71
Nombre de asociacin y nombre de rol

Direccin del nombre
Nombre de asociacin
subasta
Vendedor
Artculo
Los nombres de asociacin se pueden repetir en un modelo,

excepto para asociaciones entre las mismas dos clases
Persona
vendedor
artculo
Artculo
Nombres de rol
Los nombres de rol se pueden repetir en asociaciones distintas,
y pueden ser iguales que los nombres de las clases asociadas
72
Multiplicidad de la asociacin
En una asociacin binaria, la multiplicidad de un extremo de asociacin

especifica el nmero de instancias destino que pueden estar enlazadas con
una nica instancia origen a travs de la asociacin
Artculo participa
obligatoriamente
0..1
1..1
0..*
1..*
vendedor
0..*
artculo
Artculo
Persona participa
opcionalmente
Persona depende funcionalmente de Artculo
Valores tpicos:
Persona
1..1
cero o uno
uno y slo uno (abreviado como 1)
desde cero hasta muchos (abreviado como *)
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.
73
Navegabilidad de la asociacin
La navegabilidad de una asociacin 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 asociacin que las conectan
Acceder = nombrar, designar o referenciar el objeto para...
leer o modificar el valor de un atributo del objeto (desaconsejable)
invocar una operacin 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:
direccin del nombre de la asociacin: asimetra lingstica
navegabilidad o direccionalidad de la asociacin: asimetra comunicativa
Vendedor
Vendedor
Vendedor
subasta
subasta
subasta
Artculo
Navegabilidad no especificada
Artculo
Asociacin unidireccional
Artculo
Asociacin bidireccional
74
Asociacin vs. Atributo

Un atributo es equivalente a una asociacin unidireccional
Punto
posicinX: Coordenada
posicinY: Coordenada
Punto
posicinX
Coordenada
posicinY
Es incorrecto duplicar la representacin

Punto
posicinX: Coordenada
posicinY: Coordenada
posicinX
Coordenada
posicinY
75
Asociacin vs. Operacin
Toda asociacin tiene un doble significado:

aspecto esttico: estructura del sistema (estados posibles)
aspecto dinmico: comportamiento del sistema (interacciones posibles)
El nombre de la asociacin puede reflejar ms un aspecto que el otro:

nombres estticos: contiene, situado-en, trabaja-para, matrimonio, etc.
nombres dinmicos: subasta, publica, consulta, etc.
Son preferibles los nombres estticos, reservando los nombres dinmicos

para nombres de operaciones, invocadas a travs de la asociacin
mediante el envo de mensajes
Una misma asociacin permite la invocacin de muchas operaciones
arranca
Persona
conduce
Vehculo
Vehculo
Persona
posee
arrancar( )
conducir( )
detener( )
detiene
76
Generalizacin y clasificacin
Principio de sustitucin (Barbara Liskov, 1987):

Extensin: todas los objetos de la subclase son tambin de la superclase.
Intensin: la definicin de la superclase es aplicable a la subclase.
Generalizacin: clase-clase.
Gato es un tipo de Mamfero, Mamfero es un tipo de Animal.
Clasificacin: objeto-clase.
Fluti es un Gato, Fluti es un Mamfero, Fluti es un Animal.
Gato
Mamfero
Animal
instance of
Fluti
Instancias directas e indirectas
77
Generalizacin y especializacin
Dos puntos de vista complementarios:
Generalizar es identificar las propiedades comunes (atributos,
asociaciones, operaciones) de varias clases y representarlas en una clase
ms general denominada superclase.
Elevar el nivel de abstraccin, reducir la complejidad, organizar.
Especializar es capturar la propiedades especficas de un conjunto de
objetos dentro de una clase dada, que an no han sido distinguidas en
ella, y representarlas en una nueva clase denominada subclase.
Reutilizar un concepto aadiendo propiedades variantes.
Es una relacin 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 generalizacin induce una dependencia subclase superclase.
78
Jerarquas de clases
Representaciones alternativas:
- relaciones binarias
- estructura en rbol
Bicicleta
Terrestre
Transporte
Automvil
Areo
Ferrocarril
Avin
Transporte
Helicptero
Terrestre
Generalizacin:
- no-reflexiva
- transitiva
- asimtrica
Bicicleta
Automvil
Areo
Ferrocarril
Avin
Helicptero
79
Dimensiones de especializacin
Una superclase puede ser especializada en distintos grupos de subclases

de acuerdo con criterios independientes: discriminadores.
CuentaCorriente
titular {disjoint, complete}
CuentaPersonal
CuentaSocial
moneda {disjoint, incomplete}
CuentaEuro
CuentaDlar
Restricciones:
disjoint/overlapping: las subclases no pueden tener instancias en comn / o s.
complete/incomplete: no hay otras subclases / o s.
Valor por defecto: disjoint, incomplete.

Particin propiamente dicha: disjoint, complete.
80
Generalizacin mltiple vs. Clasificacin mltiple
CuentaCorriente
CuentaPersonal
CuentaCorriente
CuentaEuro
CuentaPersonal
CuentaPersonalEuro
CuentaEuro
instance of
instance of
instance of
miCuenta
miCuenta
81
Subclase vs. Atributo
Cmo modelar las propiedades de los objetos? Regla general:

Propiedad cambiante o rango de valores muy grande: atributo.
Propiedad fija con valores enumerados: especializacin (cada propiedad se
traduce en un criterio de especializacin, cada valor en una subclase).
Tambin se puede modelar como un atributo con valor fijo.
Problema de la clasificacin dinmica: puede un objeto cambiar de clase?

Permitira modelar un cambio de propiedad como una reclasificacin del objeto.
Interesante para aprovechar el polimorfismo (mediante un cambio de subclase).
No es habitual en los lenguajes de programacin, aunque UML lo permite.
Criterio final de especializacin: comportamiento.

CuentaCorriente
titular
moneda
Alternativa a la doble
especializacin
Coche
Especializacin
exagerada?
color
CocheAzul
CocheVerde
CocheRojo
82
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 comunicacin:
nombres adecuados: clases, atributos, operaciones, asociaciones, roles
distribucin espacial de los elementos
evitar cruces de lneas
distinto nivel de detalle segn el propsito y nivel de abstraccin
Diagrama de objetos
ilustra la estructura del sistema mediante situaciones particulares
fotografa 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
83
Diagrama de clases vs. Diagrama de objetos
Sociedad
accionista
Persona
empleado
Sociedad
accionista Ana : Persona

Annima
Limitada
Acme : Sociedad
accionista Clara : Persona
Emca : Limitada
empleado
Pedro : Persona
empleado
84
Legibilidad de los diagramas
Diagrama ilegible: letra

demasiado pequea (Arial 9).
Tamao mnimo en torno a 14.
85
Legibilidad de los diagramas
Usar ndice en miniatura.
86
Restricciones y notas
Vendedor
nif {regla nif}
nombreDescriptivo
nombreUsuario
contrasea
falta determinar
las subclases
de Sociedad
Sociedad
accionista
Persona
empleado
{ningn accionista
puede ser empleado}
87
Restricciones en asociaciones
0..1
Persona
{xor}
Cuenta
*
Vuelo
or exclusivo entre asociaciones

0..1
Sociedad
origen 1
destino 1 Aeropuerto
ordenacin de los elementos
0..*
{ordered} escala
Cliente
*
reserva
Mesa
una asociacin no puede

contener tuplas repetidas
(desaparecer en UML 2.0)
88
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 algn artculo es necesario darse de alta como vendedor,
introduciendo el NIF, un nombre descriptivo (largo), un nombre de usuario (breve)
y una contrasea de acceso. Una vez que el vendedor est dado de alta, puede
registrar artculos en la subasta o modificar alguno de sus datos: descripcin
breve, descripcin ampliada, fotografa en formato JPEG, y precio de salida.
Registrar
artculo
Vendedor
Modificar
datos de artculo
Vendedor
nif
nombreDescriptivo
nombreUsuario
contrasea
subasta
registra
modifica
Artculo
descripcinBreve
descripcinAmpliada
fotografa
precioSalida
89
Asociaciones reflexivas
Una asociacin reflexiva (o recursiva) es aquella en la que los dos extremos

de la asociacin estn unidos a la misma clase.
Los enlaces pueden conectar dos instancias diferentes de la misma clase,
o incluso una instancia consigo misma.
En una asociacin reflexiva los nombres de rol son obligatorios, para poder
distinguir los dos extremos de la asociacin.
Una asociacin reflexiva no es simtrica: los extremos son distinguibles,
aunque la asociacin quiera significar equivalencia: es-amigo-de, es-igual-a...
0..1
jefe
0..* amante
dirige
Empleado
0..*
Persona
subalterno
dirige(Ana, Juan) dirige(Juan, Ana)
ama
0..* amado
ama(Pedro, Clara) ama(Clara, Pedro)
90
Ciclos de asociaciones y asociaciones derivadas
Puede un alumno matricularse en asignaturas que no son de su titulacin?

Posibles interpretaciones alternativas del diagrama: la titulacin
matriculada
se obtiene a partir de las asignaturas: asociacin derivada.

acta como restriccin para elegir asignatura matriculada.
acta como sugerencia para elegir asignatura matriculada.
titulacin matriculada y asignatura matriculada son independientes.
{...}
Titulacin
0..*
matriculado
Alumno
0..*
pertenece
1..*
Asignatura
matriculado
0..*
91
Agregacin
Es un tipo especial de asociacin que representa una relacin todo-parte,

transitiva y asimtrica
no impone ninguna restriccin especial sobre la multiplicidad
puede ser reflexiva para las clases, pero no para las instancias
0..*
Mquina
0..*
1..*
Pieza
0..*
m1 : Mquina
p1 : Pieza
p2 : Pieza
m2 : Mquina
92
Composicin
Es un tipo especial de agregacin no compartida

la multiplicidad slo puede ser 0..1 1..1
el todo es responsable de la existencia y almacenamiento de las partes
propagacin de las operaciones de copiado y borrado
Composicin no significa encapsulamiento ni acceso restringido
Escuadrilla
0..3
1..*
Avin
0..*
0..2
Piloto
0..1
1
Cabina
Fuselaje
2
Ala
93
Anidamiento Clase interna

Una clase puede anidarse dentro de otra, como los paquetes,
con el fin de limitar la visibilidad desde el exterior
La relacin de anidamiento no es una asociacin
No tiene nada que ver con la agregacin o la composicin
la composicin abstrae enlaces todo-parte entre objetos
el anidamiento es una pura relacin de inclusin entre clases
A
+B
-C
94
Clase-asociacin
Tiene todas las propiedades de una clase y de una asociacin:
atributos, operaciones y asociaciones con otras clases.
conexin entre clases que especifica enlaces entre ellas.
multiplicidad, navegabilidad, agregacin...
Es un nico elemento, por tanto tiene un nombre nico.

Como cualquier otra asociacin, no puede contener tuplas
repetidas, aunque los valores de los atributos sean distintos:
sustituir clase-asociacin por clase intermedia.
Persona
1..*
Representa el estado actual

o el registro histrico?
trabaja-para
0..*
Empresa
trabaja-para 0..*
pagar-en
sueldo
pagar( )
Cuenta
95
Transformacin de clase-asociacin en clase intermedia

clase-asociacin
Sustituir la clase-asociacin por

una clase simple, cuyas
instancias representan enlaces.
Las multiplicidades originales se

cruzan, y aparecen otras nuevas.
Permite la existencia de tuplas

repetidas, cuando es necesario.
Es una forma de implementar la

clase-asociacin, pero hay que
aadir una restriccin adicional
para no permitir tuplas repetidas.
Persona
1..*
trabaja-para
0..*
Empresa
trabaja-para
sueldo
pagar( )
Persona
1
Empresa
0..* trabaja-para 1..*

sueldo
pagar( )
clase intermedia
96
Asociacin n-aria
Asociacin entre N clases: los enlaces conectan N instancias

no permite: direccin del nombre, navegabilidad, agregacin
s permite: clase-asociacin
Multiplicidad engaosa:
nmero permitido de instancias para cualquier posible combinacin de
instancias de las otras n-1 clases
la multiplicidad mnima suele ser 0
efecto rebote del uno: la multiplicidad mnima 1 (o superior) en un extremo
implica que debe existir un enlace (o ms) para cualquier posible combinacin de
instancias de los otros extremos
Un equipo enlazado con una
temporada siempre tiene un
*
*
Equipo
Temporada
entrenador asignado: no hay
enlaces cojos.
0..1
Entrenador
La multiplicidad mnima 1 implicara la

existencia de un enlace (o ms) para toda
posible combinacin de equipo y temporada.
97
Transformacin de asociacin n-aria en clase intermedia

asociacin n-aria
Sustituir la asociacin n-aria por

una clase simple, cuyas
instancias representan enlaces.
Equipo
Temporada
0..1
Las multiplicidades originales se

pierden, y aparecen otras nuevas.
Permite la existencia de tuplas

repetidas, cuando es necesario.
Entrenador
?
Equipo
Es una forma de implementar la

asociacin n-aria, pero hay que
aadir restricciones adicionales
para no permitir tuplas repetidas y
para expresar las multiplicidades
originales perdidas.
ETE
Temporada
*
1
Entrenador
clase intermedia
98
Herramientas para IR: Requirements Studio

Herramienta gratuita para la gestin de requisitos de usuario.
Principales caractersticas:
Herramienta multiproyecto y multiusuario.

Gestin de usuarios y permisos de acceso por proyecto.
Registro automtico de sesiones de usuario.
Control de versiones de cada requisito.
Agrupacin de requisitos en paquetes y subpaquetes.
Relaciones entre requisitos: traza, subordinacin jerrquica,
acoplamiento, conflicto, redundancia.
Otros artefactos asociados a un requisito: escenarios, modelos...
Glosario de trminos.
Visualizacin, navegacin y edicin de requisitos de modo amigable.
Generacin de informes: listado de requisitos en varios formatos,
estadsticas, matrices de trazabilidad y consistencia.
Exportacin e importacin de proyectos.
99
Instalacin
Descarga (previo registro): http://www.kr.inf.uc3m.es/reqstudio/.
Requisitos HW
Pentium IV 2,4 GHz 512 MB o similar
Requisitos SW
Microsoft Windows XP Service Pack 2
.NET Framework 2.0
Herramientas ofimticas:
Microsoft Office Word: para la generacin de informes.
Microsoft Office Excel: para la generacin de tablas.
Microsoft Office Access: para exportacin/importacin.
Servidor: Microsoft SQL Server 2005 Express Edition.
Posibilidad de bonificacin en la calificacin final.
100

Ingeniería de Requisitos

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ingeniería de Requisitos

Încărcat de

Drepturi de autor:

Formate disponibile

Ingeniera del Software I 4Ingeniera Informtica

Procesos del Desarrollo de Software 3 Grado en Ingeniera Informtica

Proyecto Prctico de Ingeniera de Requisitos

Ingeniera del Software I

Procesos del Desarrollo de Software

Jos Miguel Fuentes (fuentes [at] inf.uc3m.es) - COORDINADOR

Aula Global 2 / Avisos / Web de la asignatura

Gonzalo Gnova (ggenova [at] inf.uc3m.es) - COORDINADOR

Un curso de anlisis y diseo en dos asignaturas:

IS1/PDS: requisitos del usuario (captura) y requisitos del software (anlisis)

Proyecto Prctico de Ingeniera de Requisitos

Anlisis y definicin de los requisitos de una aplicacin informtica

Redaccin de un documento completo de requisitos

Abstraccin y resolucin de problemas

Programa de la asignatura: teora

Tema I. Requisitos del usuario (captura de requisitos)

Unidad 1. Estndares de documentacin

Tema II. Requisitos del software (anlisis de requisitos)

Unidad 11. Modelado conceptual con UML (1)

Programa de la asignatura: prcticas

Atencin a nombres de archivos y fechas de entrega

Dos documentos de revisin (el segundo completa al primero):

Proyecto final revisado (normas):

documento final + presentaciones + recuento de horas + mtricas

Propuesta de preguntas tericas para el examen de test

Realizar un proyecto de ingeniera inversa sobre un portal inmobiliario real.

Describir brevemente el alcance total de la funcionalidad ofrecida por el portal.

Seleccionar un subconjunto coherente de la funcionalidad ofrecida por el portal, de

Buscar en internet... Elegir un portal y ceirse a l.

Es muy importante definir bien los lmites del sistema descrito.

Describir este subconjunto en forma de requisitos y con los modelos necesarios.

Realizar una evaluacin del portal (la parte seleccionada):

Proyecto Prctico de Ingeniera de Requisitos

Formato de los documentos

Word, Times New Roman 12 Arial 10, interlineado sencillo.

Extensin (porque queremos calidad, no cantidad):

Trabajo en equipo y dedicacin a la prctica

Un total de 60 horas/alumno dedicadas a la prctica es razonable.

La proporcin entre trabajo individual y en equipo debera ser 4/1 3/1.

Ind. Eq. TOTAL

Ind. Eq. TOTAL

TOTAL 100 140

Proyecto Prctico de Ingeniera de Requisitos

Dedicacin a la asignatura, aproximadamente:

Tutoras por equipo

Calendario completo (IS1, PDS)

Exmenes parciales 10% Propuesta de

* Asistencia obligatoria (0,5 penalizacin por falta no justificada)

Proyecto Prctico de Ingeniera de Requisitos

Modelado con UML

Ms en la ficha de la asignatura (IS1, PDS)

Unidad 1. Estndares de documentacin

Proyecto Prctico de Ingeniera de Requisitos

Flujos de trabajo vs. Documentos

+ Implementacin, Pruebas, Mantenimiento...

European Space Agency software engineering standards

Guide to the user requirements definition phase

PROCEDURES Guide to the software operations and maintenance phase

Guide to applying the ESA standards to small software projects

Los requisitos del usuario en el Estndar ESA

ESA software engineering standards (PSS-05-0)

Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1)

Guide to the user requirements definition phase (PSS-05-02)

Los requisitos del software en el Estndar ESA