Introducción Análisis y Diseño

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


Teoría

Ejercicio práctico en el ordenador

Ampliación de conocimientos

Lectura / Vídeo / Podcast

Práctica libre / Experimentación

Leyenda


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


Ciclo de vida sofware

● SDLC – Software Development Life Cycle● Fases de desarrollo software


Fases del ciclo de vida


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


Análisis software


Diseño software y programación


Venta e Instalación en el cliente


Operación y facturación


Soporte


SDLC

● ¿Qué diferencias ves entre una secuencia en cascada o en espiral? ●¿Qué contratarías? ●¿Qué seguirías si montas una startup?


Análisis Software = QUÉ

● Determinar qué quiere realmente el usuario● Permitir valorar qué es importante y qué no de entre las cosas que pide


Análisis

●¿Piensas que es difícil entender qué quiere un usuario? ¿Por qué?● ¿Qué sucede si le entendemos mal?


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


Evaluar alternativas

● ¿Qué criterios seguirías para diseñar, subcontratar o comprar un producto?● ¿Qué opción es la más habitual?


Diseño Software = CÓMO

● Determinamos qué elementos SW (paquetes, clases, métodos, funciones, …) realizan las funcionalidades que deseamos


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


Desarrollo software...


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


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)


Diseño

● Depende del paradigma de programación (objetos, funciones, …) ●… e incluso del framework (Android, ...)


Paradigmas y lenguajes de programación


Estrategias de Diseño

Diseño

Programación

Ascendente (bottom-up)

Técnicas: refactorización

Descendente (top-down)

Técnicas: especificación diseño


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)


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)


Tarjetas CRC


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


Ejemplo


Ejemplo


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


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


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); }


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


Fallos típicos

http://jungla.dit.upm.es/~pepe/doc/adsw/apuntes/fallos.htm


Fallos típicos


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.


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


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


De un vistazo...

¿Qué era cada cosa?


Pruebas


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


Test Driven Development


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


Pensamientos

● “Si hubiese preguntado a mis clientes qué querían, me hubieran dicho que “caballos más rápidos”, Henry Ford


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


Referencias

●Objects First with Java: A Practical Introduction Using BlueJ, D. Barnes and M. Kölling, Prentice Hall, 2011, capítulo 6


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


●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


Referencias

●Objects First with Java: A Practical Introduction Using BlueJ, D. Barnes and M. Kölling, Prentice Hall, 2011, capítulo 6


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


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.


¿Preguntas?

Technology

Introducción Análisis y Diseño