Unidades Requisitos PDF

Ingeniería del Software I – 4°Ingeniería Informática
Procesos del Desarrollo de Software – 3º Grado en Ingeniería Informática
Proyecto Práctico
de Ingeniería de Requisitos
Curso 2010-2011
Gonzalo Génova
Proyecto Práctico de Ingeniería de Requisitos 1
Presentación
• Ingeniería del Software I
– Gonzalo Génova (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)
– Dirección para entregas: is.uc3m [at] gmail.com
• Procesos del Desarrollo de Software

– José Miguel Fuentes (fuentes [at] inf.uc3m.es) - COORDINADOR
– Mónica Marrero (mmarrero [at] inf.uc3m.es)
– Diego Martín (dmandres [at] inf.uc3m.es)
– Isidro Hernanz (ihernanz [at] inf.uc3m.es)
– Dirección para entregas: pds.uc3m [at] gmail.com
• Aula Global 2 / Avisos / Web de la asignatura

– 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 análisis y diseño en dos asignaturas:

– IS1/PDS: requisitos del usuario (captura) y requisitos del software (análisis)
– IS2: diseño arquitectónico (alto nivel) y diseño detallado (bajo nivel)

Objetivos de la asignatura
• Análisis y definición de los requisitos de una aplicación informática
• Aprender...
– Redacción de un documento completo de requisitos
– Desarrollo dirigido por modelos (MDA-MDD-MDE), evolución de USDP
– Estándares de documentación de proyectos
– Técnicas del análisis orientado a objetos para ingeniería de requisitos
• Desarrollar capacidades
– Abstracción y resolución de problemas
– Lectura crítica y reflexiva
– Trabajo en equipo
– Exposición de resultados propios
– Revisión de trabajos ajenos
– Aprendizaje a partir de errores propios y ajenos
Programa de la asignatura: teoría

• Tema I. Requisitos del usuario (captura de requisitos)
– Unidad 1. Estándares de documentación
– Unidad 2. Introducción a la ingeniería de requisitos
– Unidad 3. Obtención y descripción de requisitos de usuario
– Unidad 4. Modelado de casos de uso con UML
– * Unidad 5. Ética y responsabilidad profesional en la ingeniería del software
– * Unidad 6. Educación ética en la ingeniería del software (artículo y examen)
• Tema II. Requisitos del software (análisis de requisitos)

– Unidad 11. Modelado conceptual con UML (1)
– Unidad 10. Sobre la diferencia entre análisis y diseño (artículo y examen)
– Unidad 7. Tipos de requisitos del software
– Unidad 8. Propiedades y atributos de los requisitos
– Unidad 9. Organización y calidad de los requisitos

Programa de la asignatura: prácticas
• Equipos de 4 alumnos
• Trabajo en 2+2 fases (URD/SRD + ADD/DDD)
• Actividades en cada fase
– Desarrollo y documentación del proyecto conforme al índice de la práctica
• recuento de horas dedicadas al proyecto y métricas
• contabilizadas al principio de cada documento
• enviadas aparte por correo según las plantillas (horas, métricas)
– Sesiones de tutoría por equipo
• no se califica, pero asistencia obligatoria
– Revisiones cruzadas
• informes de revisión redactados conforme a las normas
– Exposiciones en público y defensa del proyecto
• entrega de transparencias impresas el primer día de exposiciones (¡2xPág!)
• exposición individual de una parte del proyecto
• respuestas a los revisores y a los profesores
Documentación entregada
• Atención 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 según convenga)
– envío por correo a la dirección de entrega y miembros del equipo revisor
– ver índice adaptado del estándar ESA PSS-05-0
• Dos documentos de revisión (el segundo completa al primero):
– ej. RevisiónIS1-M05-R07.doc: equipo M05 revisado por equipo M07, etc.
– envío por correo a la dirección de entrega y miembros del equipo revisado
• Proyecto final revisado (normas):
– documento final + presentaciones + recuento de horas + métricas
– ej. ProyectoIS1-M05.doc + etc.
– envío por correo la dirección 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 teóricas para el examen de test

Descripción de la práctica
• Realizar un proyecto de ingeniería inversa sobre un portal inmobiliario real.
– Buscar en internet... Elegir un portal y ceñirse a él.
• Describir brevemente el alcance total de la funcionalidad ofrecida por el portal.
– Incluir también los requisitos de restricción/no funcionales.
• Seleccionar un subconjunto coherente de la funcionalidad ofrecida por el portal, de
forma que sea abarcable dentro de los límites de carga de trabajo de la asignatura.
– Es muy importante definir bien los límites del sistema descrito.
– Se califica la calidad de la descripción realizada en la práctica, no la cantidad de
funcionalidad descrita, ni la importancia comercial o la calidad técnica del portal.
• Describir este subconjunto en forma de requisitos y con los modelos necesarios.
– Una parte importante del trabajo de la práctica consiste en perfilar bien el lenguaje
utilizado para definir el sistema.
• Realizar una evaluación del portal (la parte seleccionada):
– Sugerir mejoras en la concepción del sistema (en forma de nuevos requisitos). Por
ejemplo, detectar carencias importantes en la funcionalidad ofrecida por el portal.
– Sugerir mejoras en la implementación del sistema. En principio, puesto que se trata de un
proceso de ingeniería inversa donde los requisitos se han extraído de la implementación, se
da por supuesto los requisitos están correctamente implementados; no obstante, pueden
existir obvios defectos de implementación.
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).
• Extensión (porque queremos calidad, no cantidad):
– URD: 15 a 20 páginas.
– SRD: 30 a 40 páginas.
– TOTAL: 45 a 60 páginas (sin contar índices ni anexos). ¿Trabajo excesivo?
– Factor de penalización en la calificación del documento por exceso de páginas.
penalización
1 1-(p-60)/60
0
0 60 120 páginas

Trabajo en equipo y dedicación a la práctica
• Un total de 60 horas/alumno dedicadas a la práctica es razonable.
– Equivale a una hora de trabajo práctico por cada hora de clase teórica.
– 20 horas de clase + 20 horas de trabajo personal = 40 horas/semana.
• La proporción entre trabajo individual y en equipo debería ser 4/1 ó 3/1.
– Para conseguirlo la distribución y coordinación del trabajo deben ser adecuadas.
– Si el número de horas es igual para todos falta sinceridad… ¡pero si no se califica!
Nombre Ind. Eq. TOTAL Nombre Ind. Eq. TOTAL

Ana García 25 35 60 Ana García 40 15 55
Juan Gómez 25 35 60 Juan Gómez 43 11 54
Isabel López 25 35 60 Isabel López 47 16 63
Pedro Fernández 25 35 60 Pedro Fernández 50 18 68
TOTAL 100 140 240 TOTAL 180 60 240
MAL BIEN
Calendario de la asignatura
• Dedicación a la asignatura, aproximadamente:
– 30 horas de clase teórica
– 30 horas de otras actividades en clase
– 60 horas de trabajo personal y en equipo
• Clases teóricas
– Asistencia no controlada.
– El examen de Test es un reflejo directo del aprovechamiento de las clases teóricas, de ahí la
importancia que se le da en la nota final.
• Clases de laboratorio
– Aprendizaje de herramientas.
• Tutorías por equipo
– Asistencia obligatoria.
– Sirven para que el profesor pueda hacer un seguimiento efectivo del proyecto.
– Aprovechad la tutoría llevando un borrador bien trabajado.
• Exposiciones/Revisiones
– Asistencia obligatoria a todas las exposiciones, aunque no toque exponer.
– Dos miembros exponen la práctica, dos responden a revisores y profesores.
– Tiempo máximo de exposición: 20 minutos entre ambos.
• Calendario completo (IS1, PDS)
– Atención a las fechas de entregas.

Evaluación de la asignatura
Individual Equipo
Tutorías* 00% Exp/Preparación 10%
Práctica Exp/Ejecución 05% Documentación 25% 50%
Exp/Respuestas 05% Revisiones 05%
Exámenes parciales 10% Propuesta de
Teoría 10% 50%
Examen final 30% preguntas
50% 50% 100%
* Asistencia obligatoria (0,5 penalización por falta no justificada)

Igualmente se penaliza la falta no justificada a las exposiciones ajenas.
Más detalles
Bibliografía
• Ingeniería de requisitos
– Eric Braude. Software Engineering. An Object-Oriented Perspective. John
Wiley & Sons, 2001.
• Capítulos 3 y 4
– Ian Sommerville. Ingeniería del Software. Pearson-Addison Wesley, 2005.
– Roger Pressman. Ingeniería del software: un enfoque práctico, 6ª ed. McGraw-
Hill.
• 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 Object-
Oriented Analysis & Design. Addison-Wesley, 2002.
– Perdita Stevens, Rob Pooley. Using UML. Software Engineering with Objects
and Components. Addison-Wesley, 2000.
• Más en la ficha de la asignatura (IS1, PDS)

Tema I
Requisitos del Usuario
– Unidad 1. Estándares de documentación

– Unidad 2. Introducción a la ingeniería de requisitos
– Unidad 3. Obtención y descripción 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 (artículo)
Flujos de trabajo vs. Documentos
Flujos de trabajo Documentos
USDP Clásica IEEE ESA
Software User Requirements

Requisitos
Análisis de Requirements Document
requisitos Specification
Software Requirements
Análisis (IEEE 830-1993) Document
Diseño Architectural Design

arquitectónico Software Design Document
Diseño Document
(IEEE 1016-1987) Detailed Design
Diseño detallado
Document
+ Implementación, Pruebas, Mantenimiento...

El Estándar 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
Los requisitos del usuario en el Estándar 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. Determinación del entorno operacional
• 2.4. Requisitos de capacidad / Requisitos de restricción
• 2.7. Revisión de los requisitos del usuario
– Chapter 5. The user requirements document
• 5.1. Introducción: lo que debe ser, lo que no debe ser
• 5.3. Estilo: claridad, consistencia, modificabilidad
• 5.6. Contenido adaptado
• Preguntas más frecuentes

Los requisitos del software en el Estándar ESA
• ESA software engineering standards (PSS-05-0)
– Chapter 3. The software requirements definition phase
• 3.3. Actividades: modelo lógico; 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 lógico = modelo de requisitos + modelo de análisis
• Guide to the software requirements definition phase (PSS-05-03)
– Chapter 2. The software requirements definition phase
• 2.3. Construcción del modelo lógico (rendimiento, riesgos, prototipado)
• 2.4. Tipos y propiedades de los requisitos del software
• 2.6. Revisión de los requisitos del software
– Chapter 5. The software requirements document
• 5.1. Introducción: lo que debe ser, lo que no debe ser
• 5.3. Estilo: claridad, consistencia, modificabilidad
• 5.6. Contenido adaptado
• Preguntas más frecuentes
Introducción a la ingeniería de requisitos

• Qué es la Ingeniería de Requisitos
– Captura y Análisis
– Resultado del proceso: el documento 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
• Dos niveles en los requisitos
– Requisitos del Usuario, Requisitos del Software
• 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...

Un caso práctico
• “Necesito algo para organizar mejor mis actividades, una
agenda para llevar al día mi horario, mis compromisos, etc.”
x x x x x x x Día
x x x x x x x
Compromiso
x x MES
x x x x x
x x x x x x x Compromiso
x x x x x x x Compromiso
…
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
53% 33% 46% 49% 51%
pero deficiente
Proyecto
31% 40% 28% 23% 15%
cancelado

The Chaos Report
100,00%
90,00%
80,00%
70,00%
Porcentaje
60,00%
50,00%
40,00%
30,00%
20,00%
10,00%
0,00%
1994 1996 1998 2000 2003
Años
Proyecto exitoso Proyecto completo pero deficiente

Proyecto cancelado
Requisitos del Usuario vs. Requisitos del Software
Requisitos del usuario

ANÁLISIS
Requisitos del software
Diseño arquitectónico
DISEÑO
Diseño detallado
IMPLEMENTACIÓN

Diferentes puntos de vista – Diferentes documentos
Lo que él
necesita es... Lo que tienes
que hacer es...
Lo que yo
necesito es...
Analista Arquitecto
Lo que tengo
que hacer es...
Cliente
Diseñador
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? Identificar
– ¿Quién es el cliente?
– Intereses contrapuestos, requisitos
contradictorios
Entrevistar
– Negociar el equilibrio
Requisitos [no conforme]

Calidad Escribir
Presupuesto Planificación
Recursos Tiempo
Revisar
• Cómo llevar adelante una entrevista

[conforme]
– Antes, durante, después...

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
• 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
• Prototipos
– No confundir con diseño, valorar la inversión
• Interfaces de usuario
• Protipado rápido
Beneficio de la inversión en prototipos
Beneficio obtenido
(% ahorro/gasto) Beneficio
óptimo
GUI
simplificada
Recursos
malgastados
0% Gasto efectuado 100%

(% prototipo/total)
Adaptado de E. Braude,
Software Engineering: An Object-Oriented Perspective

Modelado de casos de uso
• Introducción
– Propósito y definición
• Casos de uso y extracción de requisitos
– El requisito no es la interacción, sino el objetivo.
• El modelo de casos de uso
– Notación. Actores y casos de uso. Actores cooperativos. Include y Extend.
• Descripción textual de casos de uso
– Escenario básico y escenarios alternativos. Pre- y postcondiciones.
• Casos de uso y operaciones del sistema
• Descripción gráfica de casos de uso
– Diagramas de actividad
• Casos de uso y procesos de negocio
Ejemplo: Agencia de viajes por internet

• Ingeniero. Explícame cómo quieres que funcione la aplicación.
• Cliente. Bueno, lo primero es acceder a la página web de la agencia, ¿no?,
entonces se seleccionan las ciudades de origen y destino, el número 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
crédito 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 día, el usuario
debe seleccionar uno de ellos. También hay que tener en cuenta que algunos
usuarios están dispuestos a variar sus fechas de viaje, con tal de obtener
tarifas más baratas.
• Ingeniero. Así que habrá que facilitar la búsqueda de vuelos en fechas
parecidas y que sean más baratos, ¿no? Por ejemplo, variando un día
adelante o atrás tanto la fecha de ida como la de vuelta.
• Cliente. Exactamente, lo has cogido muy bien.

Descubrir el objetivo
Acceder a la página web
• Vaga descripción inicial
– “agencia de viajes
por internet” Seleccionar ciudad origen y destino,
número de pasajeros y fechas de ida y vuelta
Mostrar vuelos disponibles

y precio de los billetes
• Patrón de
comportamiento
[no conforme] [alternativas]
Mostrar alternativas más baratas
en fechas parecidas
[conforme]
• Objetivo
Seleccionar un vuelo
– “comprar billetes de avión por [conforme] [no conforme]
internet facilitando la búsqueda
de tarifas baratas” Introducir nombres de los pasajeros
y datos de la tarjeta de crédito
El modelo de casos de uso

• La técnica 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.
– Método: descripción de las interacciones típicas usuario/sistema (escenarios).
• Un caso de uso (“användningsfall”, en sueco) es una “forma de usar” el
sistema, habitualmente descrita a través de un conjunto de “usos típicos”.
• Describe cómo un actor usa un sistema para conseguir un objetivo, y lo que
el sistema hace para ayudarle. Cuenta la historia de cómo 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 gráficamente 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 gráficamente mediante uno o varios
diagramas de casos de uso.
• Es posible estudiar los casos de uso sin utilizar ningún diagrama.
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, 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.
• 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.
Diagrama de casos de uso
Feria de subastas
Asociaciones
Registrar
artículo Modificar
datos de artículo
Consultar
lista de artículos
Vendedor
Casos de uso
Actores Registrar
usuario
Observador
Pujar por Frontera del sistema

artículo
Comprador

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 desempeñar el mismo rol.
– Una misma entidad concreta puede desempeñar varios roles.
• Un actor puede participar en varios casos de uso, desempeñando un rol
diferente en cada uno, por tanto un actor, más que un rol, es un conjunto
coherente de roles.
• Tipos de actores (o agentes externos, concepto más 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 (quién quiere qué).
• Peligro: identificar los actores con “categorías de usuarios”.
– Vendedor, Comprador y Observador no son categorías disjuntas, sino roles.
Casos de uso
• Un escenario es una secuencia de acciones del actor y acciones del sistema
que describe una interacción típica entre ambos (qué hace cada uno).
– Escenario básico: todo va bien.
– Escenarios alternativos, manejo de errores, situaciones excepcionales...
• Un caso de uso es una colección de escenarios con un objetivo común:
– El conjunto de escenarios especifica un comportamiento que proporciona un
resultado valioso para uno o más 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 además:
– Las acciones de un actor pueden ser beneficiosas para otros actores.
– Puede haber interesados (stakeholders) que no sean actores en absoluto.
• Dos niveles de abstracción en la definición:
– Interacción actor/sistema, secuencia de acciones (descripción prototípica).
– Servicio requerido, objetivo, finalidad, funcionalidad (descripción abstracta).

Actores cooperativos
• ¿Qué significa conectar varios actores a un mismo caso de uso?
– El caso de uso puede requerir la participación 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.
Include y Extend
• Es posible definir relaciones entre casos de uso:
– «include»: para describir un comportamiento común reutilizable.
– «extend»: para describir una variante del comportamiento base.
«include» Validar
Sacar dinero
tarjeta
Inclusión
Base
Extensión
Editar «extend»
Ayuda
documento
• Significado problemático en UML:

– No está clara la diferencia entre ambas (reutilización / inserción).
– No encajan con la definición de “unidad coherente de funcionalidad”.
– Pueden llevar por error al modelado de procesamiento secuencial.
No use estas relaciones si puede evitarlo.
Especificación textual de casos de uso
Nombre Frase verbal descriptiva
Actores que interaccionan con el sistema

Actores
participando en este caso de uso
Objetivo Finalidad o servicio requerido (qué, no cómo)
Descripción del estado del sistema antes de la

Precondiciones
ejecución del caso de uso (aspecto relevante)
Descripción del estado del sistema después
Postcondiciones
de la ejecución del caso de uso (diferencia)
Secuencia de acciones principales de la
interacción en el escenario básico, detallando
Escenario básico
la información intercambiada, y los cambios
observados en el sistema
Ejemplo: Registrar artículo
Nombre Registrar artículo

Actores Vendedor
Registrar los datos de un artículo para
Objetivo
que salga a subasta
Precondiciones Usuario registrado como Vendedor
Postcondiciones Artículo registrado
Insertar tarjeta magnética
Abrir sesión como Vendedor
Escenario básico Introducir datos del artículo
Confirmar datos introducidos
Terminar

Escenarios alternativos
Nombre Registrar artículo
1. Insertar tarjeta magnética
2. Abrir sesión como Vendedor
Escenario básico 3. Introducir datos del artículo
4. Confirmar datos introducidos
5. Terminar
2-5a. Tarjeta inválida
1. Devolver tarjeta
2. Terminar
2-5a. Apertura de sesión incorrecta
Escenarios alternativos
1. Devolver tarjeta
2. Terminar
5a. Desea registrar otros artículos
1. Volver al paso 3
Precondiciones y postcondiciones
• Son una forma de refinar o especificar con más detalle el objetivo del caso de
uso, mediante la descripción del estado del sistema antes y después de la
ejecución 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 precondición 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
postcondición.
Caso de uso Precondiciones Postcondiciones
Registrar usuario Usuario registrado
Registrar artículo Usuario registrado como Vendedor Artículo registrado
Usuario registrado como Comprador Si no hay más pujas,
Pujar
Artículo registrado y no adjudicado artículo adjudicado

Casos de uso y operaciones del sistema
• Los casos de uso no son operaciones del sistema (no confundirlos):
– Una operación 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.
Petición sacar dinero
Validación comprobar que hay saldo suficiente
Cambio de estado alterar el saldo de la cuenta
Respuesta entregar el dinero
• Especificación de operaciones mediante contratos.
Especificación gráfica 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 descripción textual de la secuencia de acciones.
– Emplear una descripción gráfica 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: conexión entre el fin de una acción y el comienzo de otra.
– Condiciones: deben ser expresiones booleanas mutuamente exclusivas.

Diagramas de actividad
• Acciones y transiciones Preparar desayuno
• Estados inicial y final

• Decisiones y ramas alternativas
• Sincronización de ramas concurrentes
Abrir boca Cortar Beber

pan café
Tomar alimento Leer

periódico
Cerrar boca Comer pan
[sólido] [líquido]
[else]
Masticar
[terminado]
Tragar Limpiar cocina
Correspondencia entre las especificaciones textual y gráfica
• Nombre: Consultar lista de artículos [sesión abierta]

• Actores: Observador
• Objetivo: Obtener lista de artículos con
datos de vendedores, y lista de pujas de Abrir sesión como Observador
un artículo con datos de compradores

[error]
• Precondiciones:
[ok]
• Postcondiciones:
• Escenario básico: Mostrar lista de artículos con datos de vendedores
– Abrir sesión como Observador [fin]

– Mostrar la lista de artículos con los datos
de los vendedores [mostrar pujas]
– Opcionalmente:
• Seleccionar un artículo Seleccionar artículo
• Mostrar la lista de pujas del artículo

con los datos de los compradores
Mostrar lista de pujas con datos de compradores

Subactividades
Consultar lista
de artículos
[error]
Abrir sesión
Abrir sesión
[ok]
Mostrar lista de artículos con datos de vendedores [sesión abierta]
[fin]
Abrir sesión como Observador

[mostrar pujas]
Seleccionar artículo
Mostrar lista de pujas con datos de compradores
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
Vendedor, Comprador, Representante del banco,
Formalizar la compra
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 Vendedor, Comprador,
Formalizar la compra Representante del banco,
Notario, SI del registro de la propiedad
Vendedor, Comprador,
SI del registro de
Formalizar la compra Representante del banco, SI del banco,
la propiedad
Notario

É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
– Séneca, Kant y Epicuro
• Lo ético y lo legal
– Primacía de lo ético
– Función educadora de la ley
• Problemas éticos específicos de la ingeniería del software
• El código ético de ACM/IEEE
– Preámbulo
– Los ocho principios y algunos ejemplos de cláusulas
Los tres pilares de la ética

interioriza racionalidad
insensibilidad VIRTUD NORMA militar
caballero (Séneca) (Kant) rigorismo
autodominio disciplina
BIEN
(Epicuro) felicidad
da sentido
vividor
egoísmo
El código ético de ACM/IEEE (v5.2, 1999)
1. Público. Los ingenieros de software deberán actuar en consonancia con el interés
público.
2. Cliente y empleador. Los ingenieros de software deberán actuar de forma que
respondan a los intereses de sus clientes y empleadores siendo consecuentes con el
interés público.
3. Producto. Los ingenieros de software deberán asegurar que sus productos y las
modificaciones asociadas cumplen los más altos estándares profesionales posibles.
4. Juicio. Los ingenieros de software deberán mantener la integridad e independencia
en sus juicios profesionales.
5. Gestión. Los gerentes y líderes de la ingeniería del software deberán suscribir y
promocionar un enfoque ético en la gestión del desarrollo y mantenimiento del
software.
6. Profesión. Los ingenieros de software deberán mantener la integridad y reputación
de la profesión de acuerdo con el interés público.
7. Colegas. Los ingenieros de software deberán ser imparciales y apoyar a sus colegas.
8. Personal. Durante toda su vida, los ingenieros de software deberán aprender lo
concerniente a la práctica de su profesión y promocionar un enfoque ético en la
práctica de su profesión.
Ejemplos de cláusulas del código ético

1.03 certificar software: seguridad, especificaciones, pruebas, riesgos...
Público
1.04 revelar peligros reales o potenciales
2.01 respetar el propio nivel de competencia
Cliente y
2.05 información confidencial obtenida en el trabajo profesional
empleador
2.06 informar al cliente si es probable que un proyecto fracase
3.08 buena documentación
Producto 3.09 estimaciones cuantitativas realistas (= 5.05)
3.10 pruebas, depuraciones y revisiones adecuadas
4.02 aprobar documentos supervisados
Juicio
4.04 objetividad profesional
5.07 justa remuneración
Gestión
5.08 no impedir el acceso a puestos al personal cualificado
6.04 apoyar a otros ingenieros que intenten seguir este código
Profesión
6.07 veracidad y exactitud de las características del software
7.04 revisar el trabajo de otros
Colegas
7.06 ayudar a los colegas a mejorar su práctica profesional
Personal 8.05 conocer estándares relevantes y leyes aplicables

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

– Unidad 8. Propiedades y atributos de los requisitos
– Unidad 9. Organización y calidad de los requisitos
– Unidad 10. Sobre la diferencia entre análisis y diseño (artículo)
– Unidad 13. Herramientas de apoyo en ingeniería de requisitos
Tipos de requisitos del software

• Qué son los requisitos del software
– Descripción de la naturaleza exacta de la aplicación
– Diferencia con los requisitos del usuario
• Punto de vista del cliente, punto de vista del desarrollador
• Clasificación de requisitos del software
– Requisitos inversos
– 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

Diferencias RU-RS
Requisitos del Usuario Requisitos del Software
planteamiento del problema refinamiento del problema
objetivo
captura de requisitos análisis de requisitos
fuente usuario/cliente usuario/cliente y analista
responsable usuario/cliente analista
audiencia usuario/cliente (y desarrollador) desarrollador (y usuario/cliente)
perspectiva del producto conocimiento de expertos
características de los usuarios modelado, métodos formales
énfasis
entorno operacional organización, no dejar cabos sueltos
captura mediante prototipos consistencia y completitud
modelo de casos de uso
modelos (modelo de dominio)
modelo conceptual
atributos necesidad (prioridad, estabilidad)
casos de nombre, actores escenarios alternativos
uso objetivo y escenario básico pre- y postcondiciones
Nomenclatura de los modelos
Adaptación
ESA
URD / SRD SRD
Modelo de Modelo de
requisitos casos de uso
Modelo Modelo del
Modelo del dominio
lógico sistema
Modelo de Modelo
análisis conceptual

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)
Matrices de trazabilidad
0..* 1..* 1..* 1..*

RU RS Imp
URD/SRD ADD/DDD
Matriz de doble entrada “dispersa” Matrices de tres columnas (una o las dos)
RU1 RU2 RU3 RU RS Descripción RS RU Título

RS1 X 1 1,2 1 1
RS2 X X 2 3 2 1,3
RS3 X 3 2,4,5 3 2
RS4 X 4 3
RS5 X 5 3

Propiedades y atributos de los requisitos del software
• Propiedades globales
– Completitud
• organización por tipos de requisitos
– Consistencia
• matriz de referencias cruzadas
• Propiedades individuales
– Tamaño
– Claridad
– Comprobabilidad: validación y verificación
– Condiciones de error
• Atributos
– Automáticos: identificador, creador, fecha de creación…
– Obligatorios: tipo, estado, descripción breve.
– Opcionales: descripción detallada, fuente, necesidad, prioridad, estabilidad,
complejidad, riesgo, coste…
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 R3
R4 y R7
R1 y R6 R3 y R4 R2
(R7xR5, R7+R3)
R4 y R5 R3 y R6

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 requistos 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
Ciclo de vida de los requisitos
creado eliminado
Propuesto
Validado Implementado Verificado
Cancelado
60
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...
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.

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
Propiedades e indicadores de calidad
CLIENTE DESARROLLADOR
Validabilidad Verificabilidad Modificabilidad
Completitud Consistencia Comprensibilidad Inambigüedad Trazabilidad Abstracción
Precisión Atomicidad
Morfológicos Tamaño, Legibilidad, Puntuación, Acrónimos, Abreviaturas

Términos negativos, conectivos, de flujo, anafóricos, ambiguos, incompletos,
Léxicos
especulativos, de diseño
Ortografía, gramática, verbos imperativos, verbos condicionales, voz pasiva,
Analíticos
términos del dominio
Relacionales Número de versiones, grado de anidamiento, dependencias, solapamientos

Modelado conceptual con UML
• 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
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

Notación básica de objetos y clases
Punto
p1 : Punto «instance of» posiciónX «instance of» p2 : Punto
posiciónX = 3 posiciónY posiciónX = 0
posiciónY = -5 situar( ) posiciónY = 2
mover( )
p1 : Punto
Punto Punto
p1 Punto posiciónX situar( )
posiciónY mover( )
: Punto
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 complejo…
– objetos históricos: asiento bancario, reserva de habitación…
• 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.

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}
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,…) : TipoRet {propiedades}
– propiedades predefinidas de las operaciones: isQuery
– ejemplos:
• obtenerSaldo ( ) : Moneda {isQuery}
• marcar (número : Teléfono; reintentos : Integer)

Enlaces y asociaciones
Asociación:
especificación de un conjunto Vendedor Artículo
de enlaces
representa la estructura y el
comportamiento del sistema
Estatuilla : Artículo
Enlace:
conexión entre objetos Juan : Vendedor
determina una tupla de objetos
instancia de una asociación Cuadro : Artículo
estado de los objetos enlazados Ana : Vendedor

estado del sistema
hecho + posibilidad de comunicación Espejo : Artículo
Nombre de asociación y nombre de rol
Nombre de asociación Dirección del nombre
subasta
Vendedor Artículo
Los nombres de asociación se pueden repetir en un modelo,

excepto para asociaciones entre las mismas dos clases
Persona Artículo
vendedor artículo
Nombres de rol
Los nombres de rol se pueden repetir en asociaciones distintas,
y pueden ser iguales que los nombres de las clases asociadas

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ículo participa Persona participa

obligatoriamente 1..1 0..* opcionalmente
Persona Artículo
vendedor artículo
Persona “depende funcionalmente” de Artículo

• 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.
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
subasta
Vendedor Artículo Navegabilidad no especificada
subasta
Vendedor Artículo Asociación unidireccional
subasta
Vendedor Artículo Asociación bidireccional

Asociación vs. Atributo
• Un atributo es equivalente a una asociación unidireccional
Punto Punto
posiciónX: Coordenada posiciónX
Coordenada
posiciónY: Coordenada
posiciónY
• Es incorrecto duplicar la representación
Punto
posiciónX
posiciónX: Coordenada Coordenada
posiciónY: Coordenada
posiciónY
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
arranca
Vehículo
conduce arrancar( )
Persona Vehículo Persona posee conducir( )
detener( )
detiene

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
«instance of»
Fluti Instancias directas e indirectas
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.

Jerarquías de clases
Bicicleta Representaciones alternativas:

- relaciones binarias
Terrestre Transporte - estructura en árbol
Automóvil
Aéreo
Ferrocarril Transporte
Avión Helicóptero
Terrestre Aéreo
Generalización:
- no-reflexiva
- transitiva Bicicleta Automóvil Ferrocarril Avión Helicóptero
- asimétrica
Dimensiones de especialización
• Una superclase puede ser especializada en distintos grupos de subclases
de acuerdo con criterios independientes: discriminadores.
CuentaCorriente
titular {disjoint, complete} moneda {disjoint, incomplete}
CuentaPersonal CuentaSocial CuentaEuro CuentaDólar
• 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.

Generalización múltiple vs. Clasificación múltiple
CuentaCorriente CuentaCorriente
CuentaPersonal CuentaEuro CuentaPersonal CuentaEuro
CuentaPersonalEuro «instance of» «instance of»
«instance of»
miCuenta miCuenta
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.
CuentaCorriente Coche
titular
color ¿Especialización
moneda
exagerada?
Alternativa a la doble
CocheAzul CocheVerde CocheRojo
especialización

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
Diagrama de clases vs. Diagrama de objetos
accionista
Sociedad Persona
empleado
Sociedad
accionista Ana : Persona

Anónima Limitada Acme : Sociedad
accionista Clara : Persona
Emca : Limitada empleado
Pedro : Persona
empleado

Legibilidad de los diagramas
Diagrama ilegible: letra

demasiado pequeña (Arial 9).
Tamaño mínimo en torno a 14.
Legibilidad de los diagramas
Usar “índice” en miniatura.

Restricciones y notas
Vendedor
nif {regla nif}
nombreDescriptivo
nombreUsuario
contraseña
falta determinar
las subclases
de Sociedad accionista
Sociedad Persona
empleado
{ningún accionista
puede ser empleado}
Restricciones en asociaciones
* 0..1
Persona
Cuenta {xor} or exclusivo entre asociaciones
* 0..1 Sociedad
* origen 1
Vuelo ordenación de los elementos

* destino 1 Aeropuerto
* 0..*
{ordered} escala
una asociación no puede

* *
Cliente Mesa contener tuplas repetidas
reserva
(desaparecerá en UML 2.0)

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.”
Registrar
artículo Vendedor subasta Artículo
nif descripciónBreve
nombreDescriptivo registra descripciónAmpliada
Modificar nombreUsuario fotografía
modifica
Vendedor datos de artículo contraseña precioSalida
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...
0..1 jefe 0..* amante
Empleado dirige Persona ama
0..* subalterno 0..* amado
dirige(Ana, Juan) ≠ dirige(Juan, Ana) ama(Pedro, Clara) ≠ ama(Clara, Pedro)

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
matriculada…
– 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.
{...}
1 0..*
Titulación Alumno
matriculado
1 0..*
matriculado
pertenece
1..* 0..*
Asignatura
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
0..*
0..* 1..*
Máquina Pieza
0..*
m1 : Máquina
p1 : Pieza p2 : Pieza
m2 : Máquina

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
0..3 1..* 0..* 0..2

Escuadrilla Avión Piloto
0..1
1 1 2
Cabina Fuselaje Ala
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
A
-C
+B

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, no puede contener tuplas
repetidas, aunque los valores de los atributos sean distintos:
sustituir clase-asociación por clase intermedia.
1..* trabaja-para 0..*
Persona Empresa
¿Representa el estado actual trabaja-para 0..*

pagar-en 1
o el registro histórico? sueldo Cuenta
pagar( )
Transformación de clase-asociación en clase intermedia

clase-asociación
• Sustituir la clase-asociación por 1..* trabaja-para 0..*
una clase simple, cuyas Persona Empresa
instancias representan enlaces.
trabaja-para
• Las multiplicidades originales se sueldo
cruzan, y aparecen otras nuevas. pagar( )
• Permite la existencia de tuplas

repetidas, cuando es necesario.
Persona Empresa
• Es una forma de implementar la
clase-asociación, pero hay que
1 1
añadir una restricción adicional 0..* trabaja-para 1..*
para no permitir tuplas repetidas. sueldo
pagar( )
clase intermedia
Asociación n-aria
• Asociación entre N clases: los enlaces conectan N instancias
– no permite: dirección del nombre, navegabilidad, agregación
– sí permite: 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
Un equipo enlazado con una
* * temporada siempre tiene un
Equipo Temporada entrenador asignado: no hay
“enlaces cojos”.
0..1
La multiplicidad mínima 1 implicaría la
Entrenador existencia de un enlace (o más) para toda
posible combinación de equipo y temporada.
Transformación de asociación n-aria en clase intermedia

asociación n-aria
• Sustituir la asociación n-aria por * *
Equipo Temporada
una clase simple, cuyas
instancias representan enlaces.
0..1
• Las multiplicidades originales se

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

repetidas, cuando es necesario. 1 * * 1
Equipo ETE Temporada
• Es una forma de implementar la *

asociación n-aria, pero hay que 1
añadir restricciones adicionales
para no permitir tuplas repetidas y Entrenador
para expresar las multiplicidades
originales perdidas. clase intermedia
Herramientas para IR: Requirements Studio
• Herramienta gratuita para la gestión de requisitos de usuario.
• Principales características:
– Herramienta multiproyecto y multiusuario.
– Gestión de usuarios y permisos de acceso por proyecto.
– Registro automático de sesiones de usuario.
– Control de versiones de cada requisito.
– Agrupación de requisitos en paquetes y subpaquetes.
– Relaciones entre requisitos: traza, subordinación jerárquica,
acoplamiento, conflicto, redundancia.
– Otros artefactos asociados a un requisito: escenarios, modelos...
– Glosario de términos.
– Visualización, navegación y edición de requisitos de modo amigable.
– Generación de informes: listado de requisitos en varios formatos,
estadísticas, matrices de trazabilidad y consistencia.
– Exportación e importación de proyectos.
Instalación
• 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 ofimáticas:
• Microsoft Office Word: para la generación de informes.
• Microsoft Office Excel: para la generación de tablas.
• Microsoft Office Access: para exportación/importación.
– Servidor: Microsoft SQL Server 2005 Express Edition.
• Posibilidad de bonificación en la calificación final.

Unidades Requisitos PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidades Requisitos PDF

Cargado por

Copyright:

Formatos disponibles

Ingeniería del Software I – 4°Ingeniería Informática

Procesos del Desarrollo de Software – 3º Grado en Ingeniería Informática

Proyecto Práctico de Ingeniería de Requisitos 1

• Procesos del Desarrollo de Software

• Aula Global 2 / Avisos / Web de la asignatura

• Un curso de análisis y diseño en dos asignaturas:

Proyecto Práctico de Ingeniería de Requisitos 2

Proyecto Práctico de Ingeniería de Requisitos 3

Programa de la asignatura: teoría

• Tema II. Requisitos del software (análisis de requisitos)

Proyecto Práctico de Ingeniería de Requisitos 4

Proyecto Práctico de Ingeniería de Requisitos 5

Proyecto Práctico de Ingeniería de Requisitos 6

Proyecto Práctico de Ingeniería de Requisitos 7

Formato de los documentos

Proyecto Práctico de Ingeniería de Requisitos 8

Nombre Ind. Eq. TOTAL Nombre Ind. Eq. TOTAL

Proyecto Práctico de Ingeniería de Requisitos 9

Proyecto Práctico de Ingeniería de Requisitos 10

* Asistencia obligatoria (0,5 penalización por falta no justificada)

Proyecto Práctico de Ingeniería de Requisitos 11

• Modelado con UML

• Más en la ficha de la asignatura (IS1, PDS)

Proyecto Práctico de Ingeniería de Requisitos 12

– Unidad 1. Estándares de documentación

Proyecto Práctico de Ingeniería de Requisitos 13

Flujos de trabajo vs. Documentos

Flujos de trabajo Documentos

USDP Clásica IEEE ESA

Software User Requirements

Diseño Architectural Design

+ Implementación, Pruebas, Mantenimiento...

GENERAL European Space Agency software engineering standards

Proyecto Práctico de Ingeniería de Requisitos 15

Los requisitos del usuario en el Estándar ESA

Proyecto Práctico de Ingeniería de Requisitos 16

Proyecto Práctico de Ingeniería de Requisitos 17

Introducción a la ingeniería de requisitos

Proyecto Práctico de Ingeniería de Requisitos 18

Proyecto Práctico de Ingeniería de Requisitos 19

The Chaos Report

1994 1996 1998 2000 2003

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

Proyecto Práctico de Ingeniería de Requisitos 20

Proyecto exitoso Proyecto completo pero deficiente

Proyecto Práctico de Ingeniería de Requisitos 21

Requisitos del Usuario vs. Requisitos del Software

Requisitos del usuario

Proyecto Práctico de Ingeniería de Requisitos 22

Proyecto Práctico de Ingeniería de Requisitos 23

Obtención y descripción de requisitos del usuario

Requisitos [no conforme]

• Cómo llevar adelante una entrevista

Proyecto Práctico de Ingeniería de Requisitos 24

Proyecto Práctico de Ingeniería de Requisitos 25

Beneficio de la inversión en prototipos

0% Gasto efectuado 100%

Proyecto Práctico de Ingeniería de Requisitos 26

Proyecto Práctico de Ingeniería de Requisitos 27

Ejemplo: Agencia de viajes por internet

Proyecto Práctico de Ingeniería de Requisitos 28

Mostrar vuelos disponibles

Proyecto Práctico de Ingeniería de Requisitos 29