introducción análisis y diseño
DESCRIPTION
Introducción análisis y diseñoTRANSCRIPT
Análisis y Diseño de Software
Departamento de Ingeniería de Sistemas Telemáticoshttp://moodle.dit.upm.es
IntroducciónAnálisis y Diseño
Carlos A. Iglesias <[email protected]>
Introducción. Diseño 2
Temario
● Ciclo de vida software● Análisis y Diseño Software● Técnicas OO de Diseño Descendente – Tarjetas CRC– Identificación de clases y métodos
● Técnicas de Diseño Ascendente– Refactorización y Patrones de Diseño
● Pruebas
Introducción. Diseño 3
Teoría
Ejercicio práctico en el ordenador
Ampliación de conocimientos
Lectura / Vídeo / Podcast
Práctica libre / Experimentación
Leyenda
Introducción. Diseño 4
Objetivos
● Entender el ciclo de vida del software● Conocer qué es el análisis y el diseño software● Aprender técnicas de diseño básicas● Aplicar estas técnicas en el desarrollo de un programa Java
Introducción. Diseño 5
Ciclo de vida sofware
● SDLC – Software Development Life Cycle● Fases de desarrollo software
Introducción. Diseño 6
Fases del ciclo de vida
Introducción. Diseño 7
Secuenciación SDLC
● Clásico o en cascada (waterfall): fases sucesivas● Iterativo o espiral: cascada sucesiva● Ágil: énfasis en código de calidad, e ir haciendo mejoras en el código
Introducción. Diseño 8
Análisis software
Introducción. Diseño 9
Diseño software y programación
Introducción. Diseño 10
Venta e Instalación en el cliente
Introducción. Diseño 11
Operación y facturación
Introducción. Diseño 12
Soporte
Introducción. Diseño 13
SDLC
● ¿Qué diferencias ves entre una secuencia en cascada o en espiral? ●¿Qué contratarías? ●¿Qué seguirías si montas una startup?
Introducción. Diseño 14
Análisis Software = QUÉ
● Determinar qué quiere realmente el usuario● Permitir valorar qué es importante y qué no de entre las cosas que pide
Introducción. Diseño 15
Análisis
●¿Piensas que es difícil entender qué quiere un usuario? ¿Por qué?● ¿Qué sucede si le entendemos mal?
Introducción. Diseño 16
Evaluación de alternativas● Viendo qué quiere el cliente, podemos:– Realizarlo nosotros (y
pasamos a diseño)– Subcontrarlo– Comprar un producto
(COTS, Commercial-Off-TheShelf Software)• Licencia o servicio en la
nube
Introducción. Diseño 17
Evaluar alternativas
● ¿Qué criterios seguirías para diseñar, subcontratar o comprar un producto?● ¿Qué opción es la más habitual?
Introducción. Diseño 18
Diseño Software = CÓMO
● Determinamos qué elementos SW (paquetes, clases, métodos, funciones, …) realizan las funcionalidades que deseamos
Introducción. Diseño 19
Diseño
● ¿Crees que hay un diseño que es 'el bueno'?● ¿Son todos los posibles diseños igual de buenos?● ¿Cómo sabes si un diseño es 'bueno'?
Introducción. Diseño 20
Desarrollo software...
Introducción. Diseño 21
Especificación de requisitos
● Lista de cosas que el proyecto debe cumplir– Normalmente priorizados (obligatorios,
opcionales, deseables)
– Distinguimos entre• Qué debe hacer = requisitos funcionales• Requisitos y preferencias que deseamos que
cumpla (requisitos no funcionales)– Seguridad, Almacenamiento, Compatibilidad con una
plataforma, Velocidad, Eficiencia, ...
Introducción. Diseño 22
Técnicas de especificación
● Casos de uso– Ver cómo el usuario
'usa el sistema'
– Distinguimos casos 'normales' y excepciones (qué pasa si hay un error)
Introducción. Diseño 23
Diseño
● Depende del paradigma de programación (objetos, funciones, …) ●… e incluso del framework (Android, ...)
Introducción. Diseño 24
Paradigmas y lenguajes de programación
Introducción. Diseño 25
Estrategias de Diseño
Diseño
Programación
Ascendente (bottom-up)
Técnicas: refactorización
Descendente (top-down)
Técnicas: especificación diseño
Introducción. Diseño 26
Especificación diseño OO● Identificamos clases principales, sus atributos y relaciones– Tarjetas CRC– Análisis del dominio
(nombres, ...)● Empleamos una notación gráfica– UML (Unified Modeling
Language)
Introducción. Diseño 27
Identificación Clases
● Identifica clases candidatas– Busca nombres y frases nominales (clases),
adjetivos (atributos) y verbos (métodos) en casos de uso o descripción del problema
– Técnica tarjetas CRC (Class-Resonsibility-Collaborator)
Introducción. Diseño 28
Tarjetas CRC
Introducción. Diseño 29
Calidad del diseño
● Acoplamiento– Cambios de código en una clase, implica
cambiar otra(s)● Cohesión– Variedad de funcionalidades
(responsabilidades) que debe realizar una clase
Introducción. Diseño 30
Ejemplo
Introducción. Diseño 31
Ejemplo
Introducción. Diseño 32
Refactorización
● Introducimos buenas prácticas en el código● Normalmente asistidos por el IDE● Ejemplos– Renombrar una variable
– Extraer una interfaz de una clase
– Extraer un método de un trozo de código
– Eliminar variables auxiliares
Introducción. Diseño 33
Ejemplo – Eliminar variables auxiliares
public boolean bisiesto(int año) { return (año % 4 == 0 && (!(año % 100 == 0))) || año % 400 == 0; }
public boolean bisiesto(int año) { boolean multiplo4 = año % 4 == 0; boolean multiplo100 = año % 100 == 0; boolean multiplo400 = año % 400 == 0; return (multiplo4 && (! multiplo100)) || multiplo400; }
Introducción. Diseño 34
Ejemplo. Extraer métodos
// cálculo de la diagonal mayor de un paralepípedo rectangular public double getDiagonalMayor(double a, double b, double c) { return Math.sqrt(Math.sqrt(a * a + b * b) * Math.sqrt(a * a + b * b) + c * c); }
// cáclulo de la diagonal mayor de un paralepípedo rectangular public double getDiagonalMayor(double a, double b, double c) { return hipotenusa(hipotenusa(a, b), c); } // teorema de Pitágoras private double hipotenusa(double x, double y) { return Math.sqrt(x * x + y * y); }
Introducción. Diseño 35
Ejemplo. Extraer métodos
public void testSimetria(String s) { boolean esSimetrica = true; for (int i = 0; i < s.length(); i++) { int j = s.length() - 1 - i; if (j < i) break; char c1 = s.charAt(i); char c2 = s.charAt(j); if (c1 != c2) { esSimetrica = false; break; } } System.out.println(esSimetrica); }
public void testSimetria2(String s) { System.out.println(isSimetrica(s)); } private boolean isSimetrica(String s) { for (int i = 0; i < s.length(); i++) { int j = s.length() - 1 - i; if (j < i) return true; char c1 = s.charAt(i); char c2 = s.charAt(j); if (c1 != c2) return false; } return true; }
Introducción. Diseño 36
Fallos típicos
http://jungla.dit.upm.es/~pepe/doc/adsw/apuntes/fallos.htm
Introducción. Diseño 37
Fallos típicos
Introducción. Diseño 38
Fallos típicos● No hacer "private" los campos de las clases.– Todos los campos deben ser privados, salvo que se indique explícitamente
lo contrario● Usar variables globales (de objeto) para cálculos locales (de método)– Las variables siempre deben tener el ámbito más estrecho posible. Una
variable global es fuente habitual de errores de difícil detección.● Hacer más cosas de las que se piden– No vamos a bajar la nota por hacer de más; pero es seguro que tampoco
vamos a subirla por hacer cosas que no se piden.
– De todas formas, lo frustrante es que el que hace más cosas introduce nuevas posibilidades de fallos, en lo obligatorio y en lo extra; y esos fallos si bajan la nota.
– Por tu interés: haz lo que se pide, ni más, ni menos.
Introducción. Diseño 39
Tufos 'Bad smells'● Campos públicos en una clase● Métodos largos● Malos nombres en clases / atributos / métodos● Clases (o métodos )fuertemente acopladas que hay modificar a la vez● Clases que parecen un cajón de sastre
Introducción. Diseño 40
Patrones de diseño
● Buenas prácticas● Ej. MVC (Model, View, Controller)– Separación de preocupaciones (concerns)– Definición de responsabilidades– Alta cohesión– Bajo acoplamiento
Introducción. Diseño 41
De un vistazo...
¿Qué era cada cosa?
Introducción. Diseño 42
Pruebas
Introducción. Diseño 43
Pruebas...
● Unitarias: de una funcionalidad● De Integración: con otros sistemas● De Usuario (end-to-end): usabilidad con el usuario● No funcionales: de estrés, de carga, ...● Aceptación: pruebas especificadas en los requisitos
Introducción. Diseño 44
Test Driven Development
Introducción. Diseño 45
Pensamientos
● “Probar programas puede ser una forma efectiva de mostrar la presencia de bugs, pero es totalmente inadecuado para mostrar su ausencia” - E. W. Dijkstra
Introducción. Diseño 46
Pensamientos
● “Si hubiese preguntado a mis clientes qué querían, me hubieran dicho que “caballos más rápidos”, Henry Ford
Introducción. Diseño 47
Pensamientos
● “No importa cómo de bueno es un diseño sino si el diseño mejora o empeora. Si mejora, día a día, puedo vivir con él para siempre. Si empeora, estoy muerto”, Kent Beck
Introducción. Diseño 48
Referencias
●Objects First with Java: A Practical Introduction Using BlueJ, D. Barnes and M. Kölling, Prentice Hall, 2011, capítulo 6
Introducción. Diseño 49
Referencias●Head First Object-Oriented Analysis and Design, Brett McLaughlin; Gary Pollice; David West, O'Reilly Media, Inc., 2006●http://proquest.safaribooksonline.com/book/software-engineering-and-development/object/0596008678
Introducción. Diseño 50
●Refactoring: Improving the Design of Existing Code, Martin Fowler; Kent Beck; John Brant; William Opdyke; Don Roberts, Addison-Wesley Professional, 1999●http://proquest.safaribooksonline.com/book/software-engineering-and-development/refactoring/0201485672
Referencias
Introducción. Diseño 51
Referencias
●Objects First with Java: A Practical Introduction Using BlueJ, D. Barnes and M. Kölling, Prentice Hall, 2011, capítulo 6
Introducción. Diseño 52
Enlaces● Glosario– http://www.lab.dit.upm.es/~fprg/curso/temario/glosario.htm
● Pruebas– http://www.dit.upm.es/~pepe/doc/adsw/apuntes/junit.pdf
● Vademécum– http://jungla.dit.upm.es/~pepe/libros/vademecum.pdf– http://jungla.dit.upm.es/~pepe/libros/vademecum/index.html
● Fallos típicos– http://jungla.dit.upm.es/~pepe/doc/adsw/apuntes/fallos.htm
Introducción. Diseño 53
Resumen
● El ciclo de vida software tiene diversas fases para concebir y diseñar el software● Hay varias técnicas, tarjetas CRC, reconocer nombres para realizar identificar clases durante el diseño.
Introducción. Diseño 54
¿Preguntas?