Proyecto Práctico de Análisis y Diseño Orientado a … · 22-mar Semana Santa 23-mar 24-mar...

Proyecto Práctico de Análisis y Diseño Orientado a Objetos 1

Ingeniería del Software IIIngeniería Informática, 4°Curso

Proyecto Práctico de Análisis y Diseño Orientado a Objetos

Curso 2004-2005

Gonzalo Génova y Vicente Palacios


Presentación

• Profesores (despacho 2.1 B08)– Gonzalo Génova ([email protected])– Vicente Palacios ([email protected])– Omar Hurtado ([email protected])

• http://www.ie.inf.uc3m.es�Docencia, Reglada, Ingeniería del Software II

• Relación con otras asignaturas– Ing. Téc. Inf. Gestión: Ingeniería del Software II– Ing. Informática (1° y 2° Ciclo): Ingeniería del Software I

• Modelado OO (principios, lenguaje) � Proyecto AyD OO (práctica)


Objetivos de la asignatura

• Aplicar las técnicas del análisis y diseño orientado a objetos para mejorar el proceso de desarrollo de software– Conocimientos adquiridos en Ingeniería del Software I

• Aprender...– Redacción de un documento completo de requisitos, análisis y diseño– Desarrollo dirigido por modelos (MDA-MDD-MDE), evolución de USDP– Estándares de documentación de proyectos

• Desarrollar capacidades– Abstracción– Resolución de problemas– 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 – Presentación / Estándares de documentación en el SDP– Unidad 2 – Introducción a la ingeniería de requisitos– Unidad 3 – Obtención y descripción de requisitos de usuario

• Tema II – Requisitos del software (análisis de requisitos)– Unidad 4 – Tipos de requisitos– Unidad 5 – Propiedades deseables– Unidad 6 – Organización y calidad

• Tema III – Diseño arquitectónico (diseño de alto nivel)– Unidad 7 – Descomposición, marcos y patrones– Unidad 8 – Estilos arquitectónicos (1)– Unidad 9 – Estilos arquitectónicos (2)

• Tema IV – Diseño detallado (diseño de bajo nivel)– Unidad 10 – Técnicas generales– Unidad 11 – Patrones de diseño (1)– Unidad 12 – Patrones de diseño (2)


Programa de la asignatura: prácticas

• Grupos de 4 alumnos • Actividades

– Desarrollo y documentación del proyecto (4 fases)– Revisiones cruzadas (4 fases)– Exposiciones en público y defensa del proyecto (fase conclusiva)– Propuesta de preguntas teóricas para el examen de test

• Documentación entregada (9 documentos en total)– Documentos parciales: ej. URD-G05.doc [URD / SRD / ADD / DDD]

• envío por correo a profesores y miembros del grupo revisor– Documentos de revisión: ej. URD-G05-R07.doc

• envío por correo a profesores y miembros del grupo revisado– Documento final del proyecto con revisiones: ej. IS2-G05.doc

• envío por correo a profesores• ejemplar impreso, encuadernado en espiral, tapas duras


Descripción de la práctica

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

• No teléfonos, ni contactos... sólo organización de calendario.• Libertad para escoger plataforma e interacción con el usuario• Extensión de los documentos (orientativa):

– URD: 5 a 10 páginas.– SRD: 10 a 20 páginas.– ADD: 10 a 20 páginas.– DDD: 10 a 20 páginas.– TOTAL: 35 a 70 páginas

Calidad, no cantidad


Programa de la asignatura: calendario

• Formación de grupos: 28 febrero• Entrega de documentos parciales

– 14 marzo, 4 abril, 18 abril, 4 mayo

• Entrega de documentos de revisión– 28 marzo, 11 abril, 25 abril, 9 mayo

• Entrega de documentos finales– 16 mayo

• Exposiciones en público y defensa del proyecto– 17 mayo a 2 junio

Entregas 22-feb Presentación 23-feb 24-feb URD - TeoríaGrupos: 28-feb 1-mar URD - Teoría 2-mar 3-mar SRD - Teoría

8-mar SRD - Teoría 9-mar 10-mar SRD - TeoríaURD: 14-mar 15-mar ADD - Teoría 16-mar 17-mar ADD - Teoría

22-mar Semana Santa 23-mar 24-mar Semana SantarURD: 28-mar 29-mar URD - Revisión 30-mar 31-mar URD - RevisiónSRD: 4-abr 5-abr ADD - Teoría 6-abr 7-abr DDD - TeoríarSRD: 11-abr 12-abr SRD - Revisión 13-abr 14-abr SRD - RevisiónADD: 18-abr 19-abr DDD - Teoría 20-abr 21-abr DDD - TeoríarADD: 25-abr 26-abr ADD - Revisión 27-abr 28-abr ADD - RevisiónDDD: 4-may 3-may Fiesta 4-may 5-may Repaso - LibrerDDD: 9-may 10-may DDD - Revisión 11-may 12-may DDD - RevisiónFinal: 16-may 17-may Exposición 18-may 19-may Exposición

24-may Exposición 25-may 26-may Exposición31-may (Exposición) 1-jun 2-jun (Exposición)


Evaluación de la asignatura

• 70% Parte práctica de la calificación– A. 40% Evaluación de la documentación presentada

• corrección formal (estándar) y material (contenido)– B. 20% Evaluación de las presentaciones en público

• preparación y ejecución, respuesta a las preguntas del público

– C. 10% Evaluación de los informes de revisión• ayuda para el grupo revisado, no influye en su calificación

• 30% Parte teórica de la calificación– D. 10% Evaluación de la propuesta de preguntas de test (3 preguntas cada grupo)– E. 20% Calificación del examen final de test

• Calificaciones de grupo e individuales– 60% calificación global de grupo: A, C y D

– 40% calificación individual de cada alumno: B y E


Bibliografía

• Eric Braude. Software Engineering. An Object-OrientedPerspective. John Wiley & Sons, 2001.– Capítulos 3, 4, 5 y 6

• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns. Elements of reusable Object-Orientedsoftware. Addison-Wesley, 1994.

• ESA Board for Software Standardisation and Control (BSSC). ESA Software Engineering Standards. European Space Agency, February 1991.


Tema IRequisitos del Usuario

Unidad 1 –Estándares de documentación en el SDP

Unidad 2 – Introducción a la ingeniería de requisitosUnidad 3 –Obtención y descripción de requisitos de usuario


Flujos de trabajo vs. Documentos

+ Implementación, Pruebas, Mantenimiento...

Detailed DesignDocument

Diseño detallado

Software RequirementsDocument

DocumentosFlujos de trabajo

Architectural DesignDocument

User RequirementsDocument

ESA

Software DesignDocument

(IEEE 1016-1987)

IEEE

Software RequirementsSpecification

(IEEE 830-1993)

Diseño arquitectónico

Diseño

Análisis

Análisis de requisitos

Requisitos

ClásicaUSDP


El Estándar de la ESA

Guide to applying the ESA standards to small software projectsESA Lite

Guide to software quality assurance

Guide to software verification and validation

Guide to software configuration

Guide to software project management management

Guide to the software operations and maintenance phasePROCEDURES

Guide to the software transfer phase

Guide to the software detailed design and production phase

Guide to the software architectural design phase

Guide to the software requirements definition phase

Guide to the user requirements definition phasePRODUCTS

Guide to the software engineering standards

European Space Agency software engineering standardsGENERAL


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”

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

• Por qué es necesario escribir los requisitos– Sin requisitos escritos es imposible... – No hay ingeniería profesional sin requisitos escritos

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

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


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


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

Identificar

Entrevistar

(D)escribir

Revisar

[conforme]

[no conforme]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 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 100%

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

0%

Beneficio óptimo

Recursos malgastados

GUI simplificada


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


Introducción a los 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 funcionales

• Requisitos de información / Requisitos de operación• Modelo de análisis (PIM: Platform Independent Model)

– Modelo conceptual– Modelo de casos de uso

– Requisitos no funcionales

• Características distintivas• Ejemplos• Análisis y documentación

– Separación de incumbencias


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


Requisitos no funcionales

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

• Rendimiento– velocidad, tiempo de respuesta...

• Fiabilidad y disponibilidad– cuatificació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, arquitectura, estándares, plataformas...

• Seguridad– seguridad del sistema, seguridad de las personas


Propiedades deseables de los requisitos del software

• Propiedades globales– Completitud

• organización por tipos de requisitos– Consistencia

• tabla de referencias cruzadas• Propiedades individuales

– Claridad– Trazabilidad (funcionales / no funcionales)

• matrices de trazabilidad (hacia atrás, hacia adelante)– Necesidad

• esencial, deseable, opcional– Prioridad

• alta, baja– Riesgo

• alto, moderado, bajo– Comprobabilidad

• validación y verificación– Condiciones de error


Consistencia de requisitos: conflictos y solapamientos

• Solapamientos (+)– R1 y R3

– R3 y R4– R3 y R6

• Requisitos independientes– R2

+xR6

xxR5

x+R4

+++R3

R2

xx+R1

R6R5R4R3R2R1

• Conflictos (x)– R1 y R5

– R1 y R6– R4 y R5


Métodos para organizar los requisitos del software

• Técnicas ya mencionadas– Tablas de referencias cruzadas– Matrices de trazabilidad– Modularidad y anidamiento de requisitos

• Organizar los requistos funcionales según el modelo de análisis– Por caso de uso

• clases mencionadas• operaciones utilizadas

– Por clase• atributos• operaciones• existencia de objetos

– Por estado

• Uso de herramientas para analizar y organizar requisitos


Métricas de calidad en los requisitos del software

• Qué sentido tiene realizar medidas de calidad – personal– coste

• Métricas de calidad: cómo de bien están escritos los requisitos – propiedades globales– propiedades individuales

• 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


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


• 3.4. Modelo lógico = modelo de casos de uso + modelo conceptual

• 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, protopipado)• 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.6. Contenido


Introducción al diseño arquitectónico

• La transición del análisis al diseño– significados equívocos de “análisis”– niveles de abstracción en el diseño

• Arquitectura del software– analogía con la arquitectura civil: requisitos � diseño– madurez de la arquitectura del software

• Criterios para la selección de una arquitectura– extensibilidad– modificabilidad– simplicidad– eficiencia

• ¿Cómo lograr una descomposición modular eficaz?– cohesión y acoplamiento– diseñar para el mantenimiento


Cohesión y acoplamiento

1

2 3 4

5 6Alta cohesión Bajo acoplamientoPuente

componente

componente



Estilos arquitectónicos (Shaw & Garlan)

• Flujo de datos– Tuberías y filtros– Secuencial por lotes

• Componentes independientes– Sistemas cliente-servidor– Procesos paralelos – Sistemas de eventos

• Máquinas virtuales• Repositorios

– Bases de datos– Entornos de desarrollo– Editores– Sistemas hipertexto

• Arquitectura en capas


Arquitectura de flujo de datos: DFDs

account #& deposit

balancequery

account #& deposit

account #

User

Make

inquiry

account

database

deposittransaction

accountdata

Get

deposit

Get

inquiry

Validate

inquiry

Do

deposit

transaction

Create

account

summary

Validate

deposit

errorerror

Printer

member

banks

bank name

Display

account

account #

accountdata

accountdisplay



Arquitectura de tuberías y filtros

filter

filter

filter

filter filter

filter

pipe

< stream

stream >

pipe




Arquitectura de tuberías y filtros: clases y métodos

Modelo de clases

Arquitectura

Bank

datarecord Logtransaction

analyze

deposit

deposit data

withdraw

withdrawal

account data

bank address

transaction result

transaction result

transaction

account data

account data

Comm

account data

Transactionanalyze()record()

Accountwithdraw()deposit()*


Arquitectura de procesos paralelos

Customer:customer n

withdraw

Customer:customer n+1

Session:session k

Session:session m

deposit

create

Account:customer n+1 saving

Account:customer nchecking

create retrieve

retrieve



Arquitectura de máquina virtual

260Mhz & 64MB

400Mhz & 128MB

260Mhz & 32MB

assemble {{ 260MHz & 64MB }and{ { 400MHz & 128MB } and { 260MHz & 32MB } }

}



Arquitectura en capas

Definición de reglas

del juego

Jugador TurnoMovimiento

Lanzamiento

de Dado

Selección

de Ficha

Avance y Captura

Ejecución de movimientos

Representación

gráfica

«uses»

«uses»



El diseño arquitectónico en el Estándar ESA

• ESA software engineering standards (PSS-05-0)– Chapter 4. The architectural design phase

• 4.3. Actividades: modelo físico (estático y dinámico)


• 3.5. Modelo físico, reutilización, criterios de calidad del diseño

• Guide to the software architectural design phase (PSS-05-04)– Chapter 2. The architectural design phase

• 2.3. Construcción del modelo físico (descomposición, NFR, calidad...)• 2.4. Especificación del diseño arquitectónico (funciones – componentes)• 2.7. Revisión de los requisitos del software

– Chapter 5. The architectural design document


• 5.6. Contenido


Patrones Arquitectónicos: Arquitectura en Cuatro Capas


Patrones Arquitectónicos: Arquitectura en Tres Escalones


Patrones de Diseño

Creación Estructura Comportamiento

Abstract Factory Builder Factory Method

Prototype Singleton

Adapter Bridge Composite

Decorator Façade

Flyweight Proxy

Chain of Responsibility Command Interpreter

Iterator Mediator

Memento Observer State

Strategy Template Method

Visitor


Herencia vs. Delegación

c.x( ) c.x( )

A

x( )

B

x( )

C

x( )

1

c

1

c

Dos formas de reutilizar / refactorizar

A B

C

x( )


Patrones de Diseño: Abstract Factory


Patrones de Diseño: Decorator


Patrones de Diseño: Command


El diseño detallado en el Estándar ESA

• ESA software engineering standards (PSS-05-0)– Chapter 5. The detailed design and production phase

• 5.3. Actividades: diseño detallado / no producción– 5.3.1. Descomponer componentes arquitectónicos en módulos programables

• 5.4. Salidas: omitir código y manual de usuario


• 3.6. Conversión automática modelo ⇔ código (round-trip engineering)

• Guide to the software detailed design and production phase (PSS-05-05)– Chapter 2. The detailed design and production phase

• 2.3. Descomposición, diseño defensivo, optimización, etc.

– Chapter 5. The detailed design and production document


• 5.6. Contenido


Entrega final de documentación

• Estructura del documento único final del proyecto– Documento principal del proyecto (ej. IS2-G05.doc)

• Capítulos 1-4: URD + SRD + ADD + DDD (últimas versiones)• Anexo I: revisiones recibidas del equipo revisor y respuestas a las revisiones

– URD (r + rr) + SRD (r + rr) + ADD (r + rr) + DDD (r + rr)

• Anexo II: revisiones enviadas al equipo revisado– URD (r) + SRD (r) + ADD (r) + DDD (r)

• Anexo III: transparencias de la exposición pública (sólo impreso, 2xP)

– Exposición pública del proyecto (ej. IS2-G05.ppt): aprox. 15-16 transparencias– Recuento de horas del proyecto (ej. IS2-G05.xls)

• Fecha límite– 16 mayo: envío por correo a profesores

– 17 mayo: ejemplar impreso (doc+ppt), espiral, tapas duras

• Calendario de exposiciones


Examen final

• 30% Parte teórica de la calificación– 10% Evaluación de la propuesta de preguntas de test– 20% Calificación del examen final de test – ELIMINATORIO

• Cada equipo propone tres preguntas– Cada pregunta tiene cuatro posibles respuestas (a, b, c, d)– Sólo una respuesta acertada por cada pregunta– Las respuestas equivocadas no puntúan negativamente– Fecha límite para el envío: 6 junio

– Formato del envío

• Examen = selección definitiva de preguntas• ¿Por qué no conviene “filtrar” las preguntas?

Proyecto Práctico de Análisis y Diseño Orientado a … · 22-mar Semana Santa 23-mar 24-mar...

Documents

Transcript of Proyecto Práctico de Análisis y Diseño Orientado a … · 22-mar Semana Santa 23-mar 24-mar...