1. Análisis y Diseño
de Software
Introducción
Análisis y Diseño
Carlos A. Iglesias <cif@gsi.dit.upm.es>
Departamento de Ingeniería de Sistemas Telemáticos
http://moodle.dit.upm.es
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
2
3. Leyenda
Teoría
Ejercicio práctico en el ordenador
Ampliación de conocimientos
Lectura / Vídeo / Podcast
Práctica libre / Experimentación
Introducción. Diseño
3
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
4
5. Ciclo de vida sofware
SDLC – Software
Development Life
Cycle
●
Fases de desarrollo
software
●
Introducción. Diseño
5
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
7
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
13
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
14
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
15
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-TheSh
elf Software)
•
Licencia o servicio en la
nube
Introducción. Diseño
16
18. Diseño Software = CÓMO
Determinamos qué
elementos SW
(paquetes, clases,
métodos, funciones,
…) realizan las
funcionalidades que
deseamos
●
Introducción. Diseño
18
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
19
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
21
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
22
23. Diseño
Depende del paradigma de programación
(objetos, funciones, …)
●
… e incluso del framework (Android, ...)
●
Introducción. Diseño
23
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
26
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
27
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
29
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
32
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
34
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
35
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
38
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
39
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
40
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
43
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
45
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
46
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
47
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
48
49. Referencias
Head First
Object-Oriented Analysis
and Design, Brett
McLaughlin; Gary Pollice;
David West, O'Reilly
Media, Inc., 2006
●
http://proquest.safariboo
ksonline.com/book/softw
are-engineering-and-dev
elopment/object/0596008
678
●
Introducción. Diseño
49
50. Referencias
Refactoring: Improving
the Design of Existing
Code, Martin Fowler;
Kent Beck; John Brant;
William Opdyke; Don
Roberts, Addison-Wesley
Professional, 1999
●http://proquest.safariboo
ksonline.com/book/softw
are-engineering-and-dev
elopment/refactoring/020
1485672
●
Introducción. Diseño
50
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
51
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
53