Introducción Análisis y Diseño

580 views

Published on

Introducción análisis y diseño

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
580
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Introducción Análisis y Diseño

  1. 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. 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. 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. 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. 5. Ciclo de vida sofware SDLC – Software Development Life Cycle ● Fases de desarrollo software ● Introducción. Diseño 5
  6. 6. Fases del ciclo de vida Introducción. Diseño 6
  7. 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
  8. 8. Análisis software Introducción. Diseño 8
  9. 9. Diseño software y programación Introducción. Diseño 9
  10. 10. Venta e Instalación en el cliente Introducción. Diseño 10
  11. 11. Operación y facturación Introducción. Diseño 11
  12. 12. Soporte Introducción. Diseño 12
  13. 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. 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. 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. 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
  17. 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 17
  18. 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. 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
  20. 20. Desarrollo software... Introducción. Diseño 20
  21. 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. 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. 23. Diseño Depende del paradigma de programación (objetos, funciones, …) ● … e incluso del framework (Android, ...) ● Introducción. Diseño 23
  24. 24. Paradigmas y lenguajes de programación Introducción. Diseño 24
  25. 25. Estrategias de Diseño Diseño Descendente (top-down) Ascendente (bottom-up) Técnicas: especificación diseño Técnicas: refactorización Programación Introducción. Diseño 25
  26. 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. 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
  28. 28. Tarjetas CRC Introducción. Diseño 28
  29. 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
  30. 30. Ejemplo Introducción. Diseño 30
  31. 31. Ejemplo Introducción. Diseño 31
  32. 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
  33. 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 33
  34. 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. 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
  36. 36. Fallos típicos http://jungla.dit.upm.es/~pepe/doc/adsw/apuntes/fallos.htm Introducción. Diseño 36
  37. 37. Fallos típicos Introducción. Diseño 37
  38. 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. 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. 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
  41. 41. De un vistazo... ¿Qué era cada cosa? Introducción. Diseño 41
  42. 42. Pruebas Introducción. Diseño 42
  43. 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
  44. 44. Test Driven Development Introducción. Diseño 44
  45. 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. 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. 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. 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. 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. 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. 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
  52. 52. Enlaces ● Glosario – ● Pruebas – ● http://www.lab.dit.upm.es/~fprg/curso/temario/glosario.htm 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 52
  53. 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
  54. 54. ¿Preguntas? Introducción. Diseño 54

×