Ing. 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
Presentacin
Ingeniera del Software I
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
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

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
Proyecto Prctico de Ingeniera de Requisitos 3
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 12. Modelado conceptual con UML (2) 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.
Buscar en internet... Elegir un portal y ceirse a l.
Describir brevemente el alcance total de la funcionalidad ofrecida por el portal.

Incluir tambin los requisitos de restriccin/no funcionales.
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.
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.
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 Ana Garca Juan Gmez Isabel Lpez Pedro Fernndez
Ind. Eq. TOTAL 25 25 25 25 35 35 35 35 60 60 60 60 240
Nombre Ana Garca Juan Gmez Isabel Lpez Pedro Fernndez
Ind. Eq. TOTAL 40 43 47 50 15 11 16 18 60 55 54 63 68 240
TOTAL 100 140 MAL
TOTAL 180 BIEN
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
Aprendizaje de herramientas.
Tutoras por equipo

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.
Evaluacin de la asignatura
Individual Tutoras* Prctica Exp/Ejecucin Exp/Respuestas Teora Equipo 00% Exp/Preparacin 05% Documentacin 05% Revisiones 10% 25% 05% 10% 50% 50% 100% 50%
Exmenes parciales 10% Propuesta de Examen final 30% preguntas 50%
* 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)

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
Documentos IEEE
Software Requirements Specification (IEEE 830-1993) Software Design Document (IEEE 1016-1987)
Clsica
Anlisis de requisitos
ESA
User Requirements Document Software Requirements Document Architectural Design Document Detailed Design Document
Diseo
Diseo arquitectnico Diseo detallado
+ Implementacin, Pruebas, Mantenimiento...

El Estndar de la ESA
GENERAL PRODUCTS
European Space Agency software engineering standards Guide to the software engineering standards 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 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
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
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...
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
x x x x x
Da
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 Proyecto exitoso Proyecto completo pero deficiente Proyecto cancelado 16% 53% 31%
1996 27% 33% 40%
1998 26% 46% 28%
2000 28% 49% 23%
2003 34% 51% 15%
20
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 Aos Proyecto exitoso Proyecto cancelado
Porcentaje
2000
2003
Proyecto completo pero deficiente
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
Lo que tengo que hacer es...
Cliente
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
Identificar
Entrevistar [no conforme] Escribir
Revisar [conforme]
Cmo llevar adelante una entrevista

Antes, durante, despus...
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
Beneficio de la inversin en prototipos

Beneficio obtenido (% ahorro/gasto) GUI simplificada Recursos malgastados
Beneficio ptimo
0%
Gasto efectuado (% prototipo/total)
100%
Adaptado de E. Braude, Software Engineering: An Object-Oriented Perspective Proyecto Prctico de Ingeniera de Requisitos 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

Diagramas de actividad
Casos de uso y procesos de negocio

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
Vaga descripcin inicial
agencia de viajes por internet
Acceder a la pgina web
Seleccionar ciudad origen y destino, nmero de pasajeros y fechas de ida y vuelta
Patrn de comportamiento
Mostrar vuelos disponibles y precio de los billetes
[no conforme]
[alternativas]
Mostrar alternativas ms baratas en fechas parecidas
Objetivo
comprar billetes de avin por internet facilitando la bsqueda de tarifas baratas
[conforme] 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.
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.
Diagrama de casos de uso

Asociaciones
Feria de subastas
Registrar artculo
Modificar datos de artculo
Consultar lista de artculos Vendedor
Casos de uso Actores

Observador Pujar por artculo Comprador
Registrar usuario
Frontera del sistema
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.
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).
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.
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 Extensin
Base
Editar documento extend Ayuda
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.
Especificacin textual de casos de uso

Nombre Actores Objetivo Precondiciones Postcondiciones Frase verbal descriptiva Actores que interaccionan con el sistema participando en este caso de uso Finalidad o servicio requerido (qu, no cmo) Descripcin del estado del sistema antes de la ejecucin del caso de uso (aspecto relevante) Descripcin del estado del sistema despus de la ejecucin del caso de uso (diferencia) Secuencia de acciones principales de la interaccin en el escenario bsico, detallando la informacin intercambiada, y los cambios observados en el sistema
Escenario bsico
Ejemplo: Registrar artculo

Nombre Actores Objetivo Precondiciones Postcondiciones Registrar artculo Vendedor Registrar los datos de un artculo para que salga a subasta Usuario registrado como Vendedor Artculo registrado Insertar tarjeta magntica Abrir sesin como Vendedor Introducir datos del artculo Confirmar datos introducidos Terminar
Escenario bsico
38
Escenarios alternativos
Nombre Registrar artculo 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
Escenario bsico
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 Registrar usuario Registrar artculo Pujar Usuario registrado como Vendedor Precondiciones Postcondiciones Usuario registrado Artculo registrado Usuario registrado como Comprador Si no hay ms pujas, artculo adjudicado Artculo registrado y no adjudicado
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 Validacin Cambio de estado Respuesta sacar dinero comprobar que hay saldo suficiente alterar el saldo de la cuenta entregar el dinero
Especificacin de operaciones mediante contratos.

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
Diagramas de actividad
Acciones y transiciones Estados inicial y final Decisiones y ramas alternativas Sincronizacin de ramas concurrentes
Abrir boca Tomar alimento Cerrar boca [slido] Masticar [lquido] [else] [terminado] Preparar desayuno
Cortar pan Leer peridico
Beber caf
Comer pan
Tragar
Limpiar cocina
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]
Abrir sesin como Observador [error] [ok] Mostrar lista de artculos con datos de vendedores [fin] [mostrar pujas] Seleccionar artculo
Mostrar lista de pujas con datos de compradores
44
Consultar lista de artculos

Abrir sesin [ok]
Subactividades
[error]
Abrir sesin
Mostrar lista de artculos con datos de vendedores [fin] [mostrar pujas] Seleccionar artculo
[sesin abierta]
Abrir sesin como Observador
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 Obtener una hipoteca Formalizar la compra Vendedor, Comprador, Web inmobiliaria Comprador, Representante del banco, SI del banco 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 Vendedor, Comprador, Representante del banco, Notario, SI del registro de la propiedad Vendedor, Comprador, Representante del banco, SI del banco, Notario
46
Obtener una hipoteca Comprador, Representante del banco SI del banco Formalizar la compra
SI del registro de Formalizar la compra la propiedad
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
Los tres pilares de la tica

interioriza insensibilidad caballero autodominio VIRTUD (Sneca) NORMA (Kant) racionalidad 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.
Ejemplos de clusulas del cdigo tico

Pblico Cliente y empleador
1.03 certificar software: seguridad, especificaciones, pruebas, riesgos... 1.04 revelar peligros reales o potenciales 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 3.08 buena documentacin 3.09 estimaciones cuantitativas realistas (= 5.05) 3.10 pruebas, depuraciones y revisiones adecuadas 4.02 aprobar documentos supervisados 4.04 objetividad profesional 5.07 justa remuneracin 5.08 no impedir el acceso a puestos al personal cualificado 6.04 apoyar a otros ingenieros que intenten seguir este cdigo 6.07 veracidad y exactitud de las caractersticas del software 7.04 revisar el trabajo de otros 7.06 ayudar a los colegas a mejorar su prctica profesional 8.05 conocer estndares relevantes y leyes aplicables
Producto Juicio Gestin Profesin Colegas Personal
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 11. Modelado conceptual con UML (1) Unidad 12. Modelado conceptual con UML (2) 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

Diferencias RU-RS
Requisitos del Usuario objetivo fuente responsable audiencia planteamiento del problema captura de requisitos usuario/cliente usuario/cliente usuario/cliente (y desarrollador) perspectiva del producto caractersticas de los usuarios entorno operacional captura mediante prototipos (modelo de dominio) necesidad nombre, actores objetivo y escenario bsico Requisitos del Software refinamiento del problema anlisis de requisitos usuario/cliente y analista analista desarrollador (y usuario/cliente) conocimiento de expertos modelado, mtodos formales organizacin, no dejar cabos sueltos consistencia y completitud modelo de casos de uso modelo conceptual (prioridad, estabilidad) escenarios alternativos pre- y postcondiciones
53
nfasis
modelos atributos casos de uso
Nomenclatura de los modelos
Adaptacin ESA URD / SRD SRD
Modelo lgico
Modelo de requisitos Modelo del dominio Modelo de anlisis
Modelo de casos de uso 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)
Matrices de trazabilidad
RU 0..* 1..* RS 1..* 1..* Imp
URD/SRD Matriz de doble entrada dispersa
ADD/DDD Matrices de tres columnas (una o las dos)
RU1 RU2 RU3 RS1 RS2 RS3 RS4 RS5 X X X X X X
RU 1 2 3
RS 1,2 3 2,4,5
Descripcin
RS 1 2 3 4 5
RU 1 1,3 2 3 3
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
Consistencia: conflictos, acoplamientos y redundancias

R1 R1 R2 R3 R4 R5 R6 R7 Conflicto (x) R1 y R5 R1 y R6 R4 y R5 Acoplamiento (+) R1 y R3 R3 y R4 R3 y R6 x x + o Redundancia (o) R4 y R7 ( R7xR5, R7+R3) Independencia R2 + + x + x + o R2 R3 + R4 R5 x R6 x R7
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
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. Agrupacin en paquetes y subpaquetes. Atributos: automticos, obligatorios, opcionales. Relaciones entre requisitos: navegabilidad y asimetra. Requisitos sospechosos. Otros artefactos asociados: escenarios, modelos...
Propiedades de los requisitos

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.
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
Propiedades e indicadores de calidad

CLIENTE Validabilidad DESARROLLADOR Verificabilidad Modificabilidad
Completitud
Consistencia
Comprensibilidad
Inambigedad
Trazabilidad Abstraccin
Precisin Morfolgicos Lxicos Analticos Relacionales
Atomicidad
Tamao, Legibilidad, Puntuacin, Acrnimos, Abreviaturas Trminos negativos, conectivos, de flujo, anafricos, ambiguos, incompletos, especulativos, de diseo Ortografa, gramtica, verbos imperativos, verbos condicionales, voz pasiva, trminos del dominio Nmero de versiones, grado de anidamiento, dependencias, solapamientos
Modelado conceptual con UML

Qu significa modelo conceptual
Es una vista grfica de la informacin contenida en los requisitos.
Objetos y clases
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
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.
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}
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 representa la estructura y el comportamiento del sistema
Estatuilla : Artculo Juan : Vendedor Cuadro : Artculo Ana : Vendedor Espejo : Artculo
71
Vendedor
Artculo
Enlace: conexin entre objetos determina una tupla de objetos instancia de una asociacin estado de los objetos enlazados estado del sistema
hecho + posibilidad de comunicacin

Nombre de asociacin y nombre de rol

Nombre de asociacin
subasta
Direccin del nombre
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
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
1..1 vendedor 0..* artculo
Artculo participa obligatoriamente
Persona
Artculo
Persona participa opcionalmente
Valores tpicos:
0..1 1..1 0..* 1..*
Persona depende funcionalmente de Artculo
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.
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 Artculo Artculo
Navegabilidad no especificada Asociacin unidireccional Asociacin bidireccional

74
Asociacin vs. Atributo Un atributo es equivalente a una asociacin unidireccional

Punto posicinX: Coordenada posicinY: Coordenada
Punto
posicinX posicinY
Coordenada
Es incorrecto duplicar la representacin

Punto posicinX: Coordenada posicinY: Coordenada
posicinX posicinY
Coordenada
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 conduce detiene
Vehculo Vehculo Persona arrancar( ) conducir( ) detener( )
Persona
posee
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 instance of Fluti
Mamfero
Animal
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.
Jerarquas de clases
Bicicleta Terrestre Automvil Areo Transporte
Representaciones alternativas: - relaciones binarias - estructura en rbol
Ferrocarril
Transporte
Avin
Helicptero Terrestre Areo
Generalizacin: - no-reflexiva - transitiva - asimtrica
Bicicleta
Automvil
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} moneda {disjoint, incomplete}
CuentaPersonal
CuentaSocial
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.
Generalizacin mltiple vs. Clasificacin mltiple
CuentaCorriente
CuentaCorriente
CuentaPersonal
CuentaEuro
CuentaPersonal
CuentaEuro
CuentaPersonalEuro
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 Coche color
Especializacin exagerada?
CocheVerde CocheRojo
Alternativa a la doble especializacin
CocheAzul
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
Diagrama de clases vs. Diagrama de objetos
Sociedad
accionista empleado
Persona
Sociedad
accionista Ana : Persona

Annima Limitada
Acme : Sociedad accionista Clara : Persona Emca : Limitada empleado Pedro : Persona empleado
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 empleado
Persona
{ningn accionista puede ser empleado}

Restricciones en asociaciones
* 0..1 Persona Cuenta * {xor} 0..1 origen 1 destino 1 Aeropuerto 0..* {ordered} escala * * reserva Sociedad
or exclusivo entre asociaciones
* Vuelo * *
ordenacin de los elementos
Cliente
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 Modificar datos de artculo
Vendedor
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
Empleado
jefe dirige
Persona
0..* amante ama 0..* amado
0..*
subalterno
dirige(Ana, Juan) dirige(Juan, Ana)
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 1
0..*
matriculado
Alumno 0..*
pertenece
1..* Asignatura 0..*
matriculado
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 m2 : Mquina p2 : Pieza
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

0..3 1..* 0..* 0..2
Escuadrilla
Avin 0..1
Piloto
1 Cabina
1 Fuselaje 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..*
trabaja-para
0..*
Empresa
Representa el estado actual o el registro histrico?
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 1
0..* trabaja-para 1..* sueldo pagar( )
clase intermedia
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. Las multiplicidades originales se pierden, y aparecen otras nuevas. Permite la existencia de tuplas repetidas, cuando es necesario.
Equipo
Temporada
0..1
Entrenador
?
Equipo 1 * ETE * 1 Entrenador * 1 Temporada
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.
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.
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

Ing. de Requisitos

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ing. de Requisitos

Transféré par

Droits d'auteur :

Formats disponibles

Ingeniera del Software I 4Ingeniera Informtica Procesos del Desarrollo de Software 3 Grado en Ingeniera Informtica

Proyecto Prctico de Ingeniera de Requisitos

Proyecto Prctico de Ingeniera de Requisitos

Procesos del Desarrollo de Software

Aula Global 2 / Avisos / Web de la asignatura

Un curso de anlisis y diseo en dos asignaturas:

Proyecto Prctico de Ingeniera de Requisitos

Programa de la asignatura: teora

Tema II. Requisitos del software (anlisis de requisitos)

Programa de la asignatura: prcticas

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

Proyecto final revisado (normas):

Propuesta de preguntas tericas para el examen de test

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

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

Realizar una evaluacin del portal (la parte seleccionada):

Formato de los documentos

Extensin (porque queremos calidad, no cantidad):

Trabajo en equipo y dedicacin a la prctica

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

Nombre Ana Garca Juan Gmez Isabel Lpez Pedro Fernndez

Ind. Eq. TOTAL 25 25 25 25 35 35 35 35 60 60 60 60 240

Nombre Ana Garca Juan Gmez Isabel Lpez Pedro Fernndez

Ind. Eq. TOTAL 40 43 47 50 15 11 16 18 60 55 54 63 68 240

TOTAL 100 140 MAL

TOTAL 180 BIEN

Proyecto Prctico de Ingeniera de Requisitos

Tutoras por equipo

Calendario completo (IS1, PDS)

Exmenes parciales 10% Propuesta de Examen final 30% preguntas 50%

Proyecto Prctico de Ingeniera de Requisitos

Modelado con UML

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

Tema I Requisitos del Usuario

Proyecto Prctico de Ingeniera de Requisitos

Flujos de trabajo vs. Documentos Flujos de trabajo USDP

Diseo arquitectnico Diseo detallado

+ Implementacin, Pruebas, Mantenimiento...

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

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

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

Guide to the software requirements definition phase (PSS-05-03)

Introduccin a la ingeniera de requisitos Qu es la Ingeniera de Requisitos

Necesidad de la Ingeniera de Requisitos

Por qu es necesario escribir los requisitos

Dos niveles en los requisitos

Dificultades de la Ingeniera de Requisitos

La Ingeniera de Requisitos en el contexto del proyecto

Proyecto Prctico de Ingeniera de Requisitos

The Chaos Report

1996 27% 33% 40%

1998 26% 46% 28%

2000 28% 49% 23%

2003 34% 51% 15%

Proyecto Prctico de Ingeniera de Requisitos

The Chaos Report

Proyecto completo pero deficiente

Requisitos del Usuario vs. Requisitos del Software

Proyecto Prctico de Ingeniera de Requisitos

Diferentes puntos de vista Diferentes documentos