proyecto práctico de ingeniería de · pdf file• realizar un proyecto de...

1Proyecto Práctico de Ingeniería de Requisitos

Ingeniería del Software I – 4°Ingeniería InformáticaProcesos 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


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 12. Modelado conceptual con UML (2)

– 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.

60 120 páginas

1

00

penalización

1-(p-60)/60


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

Ana García 25 35 60

Juan Gómez 25 35 60

Isabel López 25 35 60

Pedro Fernández 25 35 60

TOTAL 100 140 240

Nombre Ind. Eq. TOTAL

Ana García 40 15 55

Juan Gómez 43 11 54

Isabel López 47 16 63

Pedro Fernández 50 18 68

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

Práctica

Tutorías* 00% Exp/Preparación 10%

50%Exp/Ejecución 05% Documentación 25%

Exp/Respuestas 05% Revisiones 05%

TeoríaExámenes parciales 10% Propuesta de

preguntas10% 50%

Examen final 30%

50% 50% 100%

Más detalles

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

Igualmente se penaliza la falta no justificada a las exposiciones ajenas.


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.• Capítulos 6 y 7

– Roger Pressman. Ingeniería del software: un enfoque práctico, 6ª ed. McGraw-Hill.

• Capítulos 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 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 IRequisitos 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

+ Implementación, Pruebas, Mantenimiento...

Flujos de trabajo Documentos

USDP Clásica IEEE ESA

RequisitosAnálisis de requisitos

Software RequirementsSpecification

(IEEE 830-1993)

User RequirementsDocument

AnálisisSoftware Requirements

Document

Diseño

Diseño arquitectónico Software Design

Document(IEEE 1016-1987)

Architectural DesignDocument

Diseño detalladoDetailed Design

Document


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.”

Día

Compromiso

Compromiso

Compromiso

…

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

MES


The Chaos Report

• The Standish Group International: realiza estudios desde 1994• 2003: datos de 13.522 proyectos de tecnologías de la información

1994 1996 1998 2000 2003

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

Proyecto completo pero deficiente

53% 33% 46% 49% 51%

Proyecto cancelado

31% 40% 28% 23% 15%


The Chaos Report

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

100,00%

1994 1996 1998 2000 2003

Años

Po

rcen

taje

Proyecto exitoso Proyecto completo pero deficiente

Proyecto cancelado


Requisitos del Usuario vs. Requisitos del Software

Requisitos del usuario

Diseño detallado

Diseño arquitectónico

Requisitos del software

IMPLEMENTACIÓN

ANÁLISIS

DISEÑO


Diferentes puntos de vista – Diferentes documentos

Lo que yo necesito es...

Lo que él necesita es... Lo que tienes

que hacer es...

Lo que tengo que hacer es...

Cliente

Analista Arquitecto

Diseñador


Identificar

Entrevistar

Escribir

Revisar

[conforme]

[no conforme]

Obtención y descripción de requisitos del usuario

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

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

contradictorios– Negociar el equilibrio

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

Requisitos Calidad

Presupuesto Recursos

Planificación Tiempo


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)

Gasto efectuado(% prototipo/total)

100%

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

0%

Beneficio óptimo

Recursos malgastados

GUI simplificada


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.


Acceder a la página web

Seleccionar ciudad origen y destino, número de pasajeros y fechas de ida y vuelta

Mostrar vuelos disponibles y precio de los billetes

Mostrar alternativas más baratas en fechas parecidas

Introducir nombres de los pasajeros y datos de la tarjeta de crédito

Seleccionar un vuelo

[alternativas]

[conforme]

[conforme]

[no conforme]

[no conforme]

• Vaga descripción inicial– “agencia de viajes

por internet”

• Patrón de comportamiento

• Objetivo– “comprar billetes de avión por

internet facilitando la búsqueda de tarifas baratas”

Descubrir el objetivo


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.


Feria de subastas

Vendedor

Observador

Comprador

Registrarartículo Modificar

datos de artículo

Consultarlista de artículos

Pujar por

Registrarusuario

Diagrama de casos de uso

Actores

Casos de uso

Asociaciones

Frontera del sistemaartículo


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.

• Incorrecto: pretender que es “el mismo caso de uso” para distintos actores, que lo ejecutan de modo independiente.

Piloto Entrenador

Simular vuelo


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.

• 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.

BaseInclusión

Extensión

Sacar dineroValidartarjeta

Editardocumento

Ayuda

«include»

«extend»


Especificación textual de casos de uso

Nombre Frase verbal descriptiva

ActoresActores que interaccionan con el sistema participando en este caso de uso

Objetivo Finalidad o servicio requerido (qué, no cómo)

PrecondicionesDescripción del estado del sistema antes de la ejecución del caso de uso (aspecto relevante)

PostcondicionesDescripción del estado del sistema despuésde la ejecución del caso de uso (diferencia)

Escenario básico

Secuencia de acciones principales de la interacción en el escenario básico, detallando la información intercambiada, y los cambios observados en el sistema


Ejemplo: Registrar artículo

Nombre Registrar artículo

Actores Vendedor

ObjetivoRegistrar los datos de un artículo para que salga a subasta

Precondiciones Usuario registrado como Vendedor

Postcondiciones Artículo registrado

Escenario básico

Insertar tarjeta magnéticaAbrir sesión como VendedorIntroducir datos del artículoConfirmar datos introducidosTerminar


Escenarios alternativos

Nombre Registrar artículo

Escenario básico

1. Insertar tarjeta magnética2. Abrir sesión como Vendedor3. Introducir datos del artículo4. Confirmar datos introducidos5. Terminar

Escenarios alternativos

2-5a. Tarjeta inválida1. Devolver tarjeta2. Terminar

2-5a. Apertura de sesión incorrecta1. Devolver tarjeta2. Terminar

5a. Desea registrar otros artículos1. 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

PujarUsuario registrado como CompradorArtículo registrado y no adjudicado

Si no hay más pujas, 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.

• Especificación de operaciones mediante contratos.

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 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

Abrir boca

Tomar alimento

Masticar

Cerrar boca

Tragar

[sólido] [líquido]

Preparar desayuno

Leerperiódico

Cortarpan

Bebercafé

Comer pan

Limpiar cocina

[else]

[terminado]

• Acciones y transiciones• Estados inicial y final• Decisiones y ramas alternativas• Sincronización de ramas concurrentes


Seleccionar artículo

Mostrar lista de artículos con datos de vendedores

Mostrar lista de pujas con datos de compradores

Abrir sesión como Observador

[mostrar pujas]

[fin]

[error]

[ok]

[sesión abierta]

Correspondencia entre las especificaciones textual y gráfica

• Nombre: Consultar lista de artículos• Actores: Observador• Objetivo: Obtener lista de artículos con

datos de vendedores, y lista de pujas de un artículo con datos de compradores

• Precondiciones: • Postcondiciones: • Escenario básico:

– Abrir sesión como Observador– Mostrar la lista de artículos con los datos

de los vendedores– Opcionalmente:

• Seleccionar un artículo• Mostrar la lista de pujas del artículo

con los datos de los compradores


Subactividades

Seleccionar artículo

Mostrar lista de artículos con datos de vendedores

Mostrar lista de pujas con datos de compradores

Abrir sesión

[mostrar pujas]

[fin]

[ok]

[error]

Abrir sesión como Observador

[sesión abierta]

Abrir sesión

Consultar lista de artículos


Casos de uso y procesos de negocio

Procesos de negocio: acciones y agentes

Localizar la casa Vendedor, Comprador, Web inmobiliaria

Obtener una hipoteca Comprador, Representante del banco, SI del banco

Formalizar la compraVendedor, 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

SI del banco

Obtener una hipoteca Comprador, Representante del banco

Formalizar la compraVendedor, Comprador, Representante del banco, Notario, SI del registro de la propiedad

SI del registro de la propiedad

Formalizar la compraVendedor, Comprador, Representante del banco, SI del banco, 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

NORMA(Kant)

VIRTUD(Séneca)

BIEN(Epicuro)

autodominio

felicidad

racionalidadinterioriza

disciplina

da sentido

caballero

militar

vividor

insensibilidad

rigorismo

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

Público1.03 certificar software: seguridad, especificaciones, pruebas, riesgos...1.04 revelar peligros reales o potenciales

Cliente y empleador

2.01 respetar el propio nivel de competencia2.05 información confidencial obtenida en el trabajo profesional2.06 informar al cliente si es probable que un proyecto fracase

Producto3.08 buena documentación3.09 estimaciones cuantitativas realistas (= 5.05)3.10 pruebas, depuraciones y revisiones adecuadas

Juicio4.02 aprobar documentos supervisados4.04 objetividad profesional

Gestión5.07 justa remuneración5.08 no impedir el acceso a puestos al personal cualificado

Profesión6.04 apoyar a otros ingenieros que intenten seguir este código6.07 veracidad y exactitud de las características del software

Colegas7.04 revisar el trabajo de otros7.06 ayudar a los colegas a mejorar su práctica profesional

Personal 8.05 conocer estándares relevantes y leyes aplicables


Tema IIRequisitos 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 11. Modelado conceptual con UML (1)– Unidad 12. Modelado conceptual con UML (2)– 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-RSRequisitos del Usuario Requisitos del Software

objetivoplanteamiento del problema

captura de requisitosrefinamiento del problema

análisis de requisitos

fuente usuario/cliente usuario/cliente y analista

responsable usuario/cliente analista

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

énfasis

perspectiva del productocaracterísticas de los usuarios

entorno operacional

captura mediante prototipos

conocimiento de expertosmodelado, métodos formales

organización, no dejar cabos sueltos

consistencia y completitud

modelos (modelo de dominio)modelo de casos de uso

modelo conceptual

atributos necesidad (prioridad, estabilidad)

casos de uso

nombre, actores

objetivo y escenario básico

escenarios alternativos

pre- y postcondiciones


Nomenclatura de los modelos

ESA

Adaptación

URD / SRD SRD

Modelo lógico

Modelo de requisitos

Modelo del dominio

Modelo de casos de uso

Modelo del sistema

Modelo de análisis

Modelo 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

RU1 RU2 RU3

RS1 X

RS2 X X

RS3 X

RS4 X

RS5 X

RU RS Descripción

1 1,2

2 3

3 2,4,5

RS RU Título

1 1

2 1,3

3 2

4 3

5 3

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

URD/SRD ADD/DDD

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


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 R5R1 y R6R4 y R5

R1 y R3R3 y R4R3 y R6

R4 y R7(�R7xR5, R7+R3)

R2


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

60

Ciclo de vida de los requisitos

Propuesto

Implementado VerificadoValidado

Cancelado

creado eliminado


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

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

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

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

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

Validabilidad Verificabilidad Modificabilidad

Completitud Consistencia Comprensibilidad Inambigüedad Trazabilidad

Precisión Atomicidad

DESARROLLADORCLIENTE

Abstracción


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 plataformade implementación y no tienen por qué corresponder a conceptos del dominio


Notación básica de objetos y clases

PuntoposiciónXposiciónYsituar( )mover( )

p1 : Punto

posiciónX = 3posiciónY = -5

p2 : Punto

posiciónX = 0posiciónY = 2

«instance of»«instance of»

p1 : Punto

p1

: Punto

PuntoposiciónXposiciónY

Punto

situar( )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

ArtículoVendedor

Juan : Vendedor

Ana : Vendedor

Estatuilla : Artículo

Cuadro : Artículo

Espejo : Artículo

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

representa la estructura y el comportamiento del sistema

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

estado de los objetos enlazadosestado del sistema

hecho + posibilidad de comunicación


Nombre de asociación y nombre de rol

ArtículoVendedorsubasta

ArtículoPersonavendedor artículo

Nombre de asociación Dirección del nombre

Nombres de rol

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

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


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

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

Multiplicidad de la asociación

• En una asociación binaria, la multiplicidad de un extremo de asociaciónespecifica el número de instancias destino que pueden estar enlazadas con una única instancia origen a través de la asociación

ArtículoPersonavendedor artículo

1..1 0..*Artículo participaobligatoriamente

Persona “depende funcionalmente” de Artículo

Persona participaopcionalmente


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




Navegabilidad no especificada

Asociación unidireccional

Asociación bidireccional


• Un atributo es equivalente a una asociación unidireccional

• Es incorrecto duplicar la representación

PuntoposiciónX: CoordenadaposiciónY: Coordenada

PuntoposiciónX: CoordenadaposiciónY: Coordenada

Coordenada

posiciónY

posiciónX

Asociación vs. Atributo

PuntoCoordenada

posiciónY

posiciónX


Persona

Vehículo

arrancar( )conducir( )detener( )

poseePersona Vehículo

arranca

conduce

detiene

Asociación vs. Operación

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

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

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

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

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


Generalización y clasificación

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

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

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

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

Gato Mamífero Animal

Fluti

«instance of»

Instancias directas e indirectas


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.


Transporte

AéreoTerrestre

Avión HelicópteroBicicleta Automóvil Ferrocarril

Jerarquías de clases

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

Transporte

Aéreo

Terrestre

Avión Helicóptero

Bicicleta

Automóvil

Ferrocarril

Representaciones alternativas:- relaciones binarias- estructura en árbol


CuentaCorriente

CuentaPersonal CuentaSocial CuentaEuro CuentaDólar

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

Dimensiones de especialización

• Una superclase puede ser especializada en distintos grupos de subclases de acuerdo con criterios independientes: discriminadores.

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

• Valor por defecto: disjoint, incomplete.• Partición propiamente dicha: disjoint, complete.


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

CuentaCorriente

CuentaPersonal CuentaEuro

CuentaPersonalEuro

miCuenta

«instance of»

CuentaCorriente

CuentaPersonal CuentaEuro

miCuenta

«instance of» «instance of»


Subclase vs. Atributo

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

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

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

• Criterio final de especialización: comportamiento.

CuentaCorrientetitularmoneda

Coche

CocheRojoCocheVerdeCocheAzul

color

Alternativa a la doble especialización

¿Especialización exagerada?


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

Sociedad

Anónima Limitada

Sociedad Personaaccionista

empleado

Acme : Sociedad

Emca : Limitada

Ana : Persona

Clara : Persona

Pedro : Persona

accionista

empleado

empleado

accionista


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

{ningún accionista puede ser empleado}

falta determinar las subclasesde Sociedad

Sociedad Personaaccionista

empleado

Vendedornif {regla nif}nombreDescriptivonombreUsuariocontraseña


Restricciones en asociaciones

Vuelo Aeropuerto

{ordered} escala

* 0..*

* 1origen

* 1destino

Cliente Mesa* *

reserva

Cuenta

Sociedad

Persona

* 0..1

* 0..1

{xor} or exclusivo entre asociaciones

ordenación de los elementos

una asociación no puede contener tuplas repetidas (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.”

Vendedor

Registrarartículo

Modificardatos de artículo

ArtículodescripciónBrevedescripciónAmpliadafotografíaprecioSalida

VendedornifnombreDescriptivonombreUsuariocontraseña

subasta

registra

modifica


Asociaciones reflexivas

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

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

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

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

Empleado Personadirige

0..1

0..*

jefe

subalterno

ama

0..*

0..*

amante

amado

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


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.

{...}

Alumno

Asignatura

Titulaciónmatriculado

1 0..*

pertenece

1

1..*

matriculado0..*

0..*


Agregación

• Es un tipo especial de asociación que representa una relación todo-parte, transitiva y asimétrica– no impone ninguna restricción especial sobre la multiplicidad– puede ser reflexiva para las clases, pero no para las instancias

PiezaMáquina0..* 1..*

0..*

0..*

m1 : Máquina

m2 : Máquina

p1 : Pieza p2 : Pieza


Composición

• Es un tipo especial de agregación no compartida– la multiplicidad sólo puede ser 0..1 ó 1..1

– el todo es responsable de la existencia y almacenamiento de las partes– propagación de las operaciones de copiado y borrado

• Composición no significa encapsulamiento ni acceso restringido

AviónEscuadrilla

Cabina Fuselaje Ala

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

1

0..1

1 2


Anidamiento – Clase interna

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

• La relación de anidamiento no es una asociación• No tiene nada que ver con la agregación o la composición

– la composición abstrae enlaces todo-parte entre objetos– el anidamiento es una pura relación de inclusión entre clases

+B

A

-C


Persona Empresa

trabaja-parasueldopagar( )

Cuenta

trabaja-para1..* 0..*

pagar-en0..* 1

Clase-asociación

• Tiene todas las propiedades de una clase y de una asociación:– atributos, operaciones y asociaciones con otras clases.– conexión entre clases que especifica enlaces entre ellas.– multiplicidad, navegabilidad, agregación...

• Es un único elemento, por tanto tiene un nombre único.• Como cualquier otra asociación, no puede contener tuplas

repetidas, aunque los valores de los atributos sean distintos: sustituir clase-asociación por clase intermedia.

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


Persona Empresa


trabaja-para1..* 0..*

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

• Sustituir la clase-asociación por una clase simple, cuyas instancias representan enlaces.

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

• Permite la existencia de tuplasrepetidas, cuando es necesario.

• Es una forma de implementar la clase-asociación, pero hay que añadir una restricción adicional para no permitir tuplas repetidas.

Persona Empresa


10..*

11..*

clase intermedia

clase-asociación


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

Equipo

Entrenador

Temporada* *

0..1La multiplicidad mínima 1 implicaría la existencia de un enlace (o más) para toda posible combinación de equipo y temporada.

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


Equipo

Entrenador

TemporadaETE1 * 1*

1*

Equipo

Entrenador

Temporada* *

0..1

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

?

clase intermedia

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

una clase simple, cuyas instancias representan enlaces.

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

• Permite la existencia de tuplasrepetidas, cuando es necesario.

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


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.

proyecto práctico de ingeniería de · pdf file• realizar un proyecto de...

Documents