1.- Repaso Ingeniería del Software I Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

1. 1.- Repaso Ingeniería del Software I Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

2. Índice • Repaso al Proceso Unificado • Repaso a Conceptos de Orientación a Objetos

3. Proceso Unificado

4. Qué es el Proceso Unificado • Unified Software Development Process • Definido por Ivar Jacobson, James Rumbaugh y Grady Booch. • Un proceso define QUIÉN está haciendo QUÉ, CUÁNDO y CÓMO para llegar a un objetivo. • En la ingeniería de sw el objetivo es construir un producto sw o mejorar uno ya existente dentro de un esquema temporal, económico y de calidad. • Un proceso de desarrollo es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. • El proceso unificado no es un único proceso, sino un framework genérico.

5. Características • Es guiado por casos de uso (use-case driven) • Se centra en la arquitectura (architecture-centric) • Es iterativo (iterative) • Es incremental (incremental)

6. Vida del Proceso Unificado • El proceso se repite sobre una serie de CICLOS, cada uno de los cuáles termina con una release: versión entregable del producto. • Cada versión de una herramienta comercial que se “vende en las tiendas” es una release -entrega-. • Cada ciclo consta de cuatro FASES: • Concepción • Elaboración • Construcción • Transición • Cada fase se puede subdividir en iteraciones, tal y como vimos anteriormente.

7. Representaciones del Producto SW (y II): dependencias

8. Visión global del ciclo de vida

9. Fases del Proceso Unificado (I) • Como hemos dicho antes, cada ciclo se divide en cuatro fases: concepción, elaboración, construcción y transición. • Una fase acaba de un hito -milestone-: • Un hito ocurre cuando se encuentran disponibles un conjunto de “artefactos”, es decir, modelos o documentos en un estado prescrito determinado. • ¿Por qué? • Decisiones a tomar antes de pasar a la siguiente fase. • Monitorización del trabajo por parte de desarrolladores y gestores. • Categorización de los datos obtenidos: análisis.

10. Fases del Proceso Unificado (II) • Concepción -inception- • A partir de la idea se desarrolla la “visión” del producto final y se elabora el caso de negocio. • Esta fase responde a las siguientes cuestiones: • Qué va a realizar el sistema principalmente. • Cómo sería un esqueleto de arquitectura del sistema. • Cuál es el plan de proyecto y cuánto costaría.

11. Fases del Proceso Unificado (III) • Elaboración -elaboration- • Se diseña la arquitectura del sistema • desde todos los puntos de vista -modelos del sistema-. • Se definen todos los casos de uso. • Los casos de uso más críticos se desarrollan: • ARCHITECTURE BASELINE: la línea base de la arquitectura. • Al final de esta fase, el gestor ya es capaz de planificar las actividades y recursos necesarios para completar el proyecto: • ¿Hemos logrado la estabilidad suficiente en casos de uso, arquitectura y planificación como para asegurar el éxito del proyecto?

12. Fases del Proceso Unificado (IV) • Construcción -construction- • El producto se construye. • Ahora se añade el “músculo” al “esqueleto”. • La línea base crece hasta convertirse en el sw completo. • Se supone que la arquitectura del sistema es estable, a pesar de que puede haber modificaciones menores. • Al final de la fase el producto está terminado -todos los casos de uso implementados-, aunque todavía nos podemos encontrar con “bugs”: • ¿Satisface el producto las necesidades del usuario?

13. Fases del Proceso Unificado (y V) • Transición -transition- • Período durante el cuál el SW está en “beta release”. • Otras tareas: • Manufactura. • Formación, ayuda en línea, … • Corrección de defectos.

14. Relaciones de las Cuatro Ps Process Automatización Plantilla Tools People Project Participantes Resultado Product

15. People

16. Producto • Un producto es algo más que código… os lo juro! • Artefacto -artifact-: cualquier tipo de información creada, producida, cambiada o utilizada por “workers” para desarrollar el sistema. Tipos: • Engineering artifacts • Texto. • Interfaces de usuario, prototipos. • Documentación técnica. • Código. • MODELO: abstracción del sistema, que especifica el sistema modelado desde un punto de vista y un cierto grado de abstracción -impuesto por los workflows-. • Management artifacts • Planificaciones. • Plan de proyecto. • Gestión de recursos. • ...

17. Orientación a Objetos

18. Índice • La abstracción de los hechos • La interfaz: esa gran desconocida • Encapsulamiento • Herencia • Reutilización • Tipos de relaciones • Polimorfismo

19. La abstracción de los hechos • El programador ha de establecer una relación entre la máquina en la cual se está resolviendo el problema y el modelo de conocimiento del cual procede; es decir, entre el espacio de soluciones y el espacio de problemas. • La orientación a objetos provee al desarrollador la capacidad de representar elementos en el espacio de problemas. Estos elementos se denominan “objetos”. • Smalltalk, C++, Java, ... son tipos más o menos puristas de OOL (Object-oriented languages).

20. Características de OOLs • Todo es un objeto • La comunicación entre objetos se realiza mediante paso de mensajes. • Todo objeto está construido por otros objetos internamente. • Todo objeto tiene un tipo • O, utilizando otra manera de hablar, toda instancia proviene de una clase. • Todo objeto del mismo tipo puede recibir los mismos mensajes. • Si un objeto del tipo “pastor aleman” es también del tipo “perro”, ambos podrán aceptar mensajes del tipo “ladra”.

21. Interfaz: esa gran desconocida (I) • Desde la filosofía antigua se viene hablando de “tipos” o “clases” –tipo de pájaro, clase de pez-. • Todos los objetos, aunque son únicos, comparten características comunes.

22. Interfaz: esa gran desconocida (II) • En la programación OO, es vital la obtención de “clases”: definición de características y comportamientos. • A partir de esas clases se pueden obtener “instancias”. • Se comunican mediante el paso de mensajes. • Cada instancia es idéntica a su hermana, pero cada una mantiene su propio estado (valores de los atributos). TV TV::Grundig TV::Thomson

23. Interfaz: esa gran desconocida (III) • Pero, ¿cómo conseguimos que los objetos trabajen? • Cada objeto ha de satisfacer un conjunto de peticiones que se le puedan realizar. • P.e. Un objeto “bombilla” (“light” en el dibujo): • El conjunto de peticiones que se pueden realizar sobre el objeto se encuentra definido por su INTERFAZ. • El tipo (o clase) es lo que determina la interfaz.

24. Interfaz: esa gran desconocida (IV) • Así que la interfaz ofrece al exterior el comportamiento del objeto. • Por otra parte, el código que satisface esa petición, así como datos u operaciones internas, conforman la IMPLEMENTACIÓN del objeto. • Del ejemplo anterior: Light lt = new Light(); lt.on(); • Así que, importante para el futuro: • Un objeto de un tipo (clase) determinado comprende: • Interfaz: qué se ofrece. • Implementación: cómo se ofrece.

25. Interfaz: esa gran desconocida (y V) • C++: clase abstracta virtual pura • Java: palabra clave interface. public interface Isort { void sort(Collection vElements); } • Habrá de tener al menos una clase que implemente el método “sort”: public class QuickSort implements Isort { public void sort (Collection vElements) { //Implementación del algoritmo QuickSort //… } } • Se permite implementación múltiple.

26. Encapsulamiento • Una de las características de los sistemas distribuidos –pero que es aplicable a cualquier otro sistema- es la Apertura: • Permite a un SO expandirse en múltiples direcciones. • Las interfaces de las clases que conforman el API se hacen públicas • Para ello hay que exponer al usuario sólo aquellas operaciones que se establezcan como públicas. • Facilidad de utilización. • Posibilidad de errores por programadores inexpertos. • Java utiliza tres palabras clave: public, protected, private – aparte, existe otro estado por defecto-. Se explicará más adelante. • Las interfaces cumplen esta función, ya que esconden al exterior la implementación interna. Implementación Exterior Interfaz

27. Herencia (I) • Sería un inconveniente tener que crear nuevas clases muy parecidas a otras que ya existían. • El concepto de Herencia nos permite crear “clones” o “hijos” de clases, de tal forma que heredan su estado. • A esta clase hija se le puede añadir o modificar funcionalidad con respecto a la del padre.

28. Herencia (y II) • Opciones de utilización de la herencia • <= Añadir funcionalidad 2. Modificación de comportamiento =>

29. Reutilización • La reutilización de código es una de las grandes ventajas de la OO. • No es fácil de obtener –parece fácil al principio...- • Técnicas de reutilización: • Utilización directa. La misma clase vale. • Subclassing: heredar una clase (frameworks). • Modificación de una clase existente: 

30. Tipo de relaciones • 1. Ya conocido: Herencia • 2. Agregación • Dentro de una objeto puede albergarse un conjunto de instancias de diferentes clases que conformen parte del estado del primero. • Composición: especialización de la agregación. • “Has-a”.

31. Delegación vs. Herencia • Herencia: • Se realiza en tiempo de compilación. • Fácilmente entendible y utilizable. • La subclase es dependiente de la implementación del padre (“la herencia rompe el encapsulamiento”). • La implementación heredada no puede cambiarse en tiempo de ejecución. • Delegación (agregación, composición) • La implementación puede cambiarse en tiempo de ejecución -objetos accedidos a través de sus interfaces-. • El comportamiento es más complicado de entender. • Se favorece la delegación sobre la herencia. • Los patrones utilizan más la delegación.

32. Polimorfismo (I) • “Early binding”. • Linker => dirección absoluta. • En OOP eso no se puede hacer hasta run-time: late-binding. • Controlador de pájaros.

33. Polimorfismo (II) • Operación del BirdController: • hazAlgo(Bird b) { • b.move(); • } • Y en otra parte del código: • Goose g = new Goose(); • Penguin p = new Penguin(); • hazAlgo(g); • hazAlgo(p); • ¿Y si ahora añadimos un tipo “Tweety” descendiente de Bird sin método “move” sobrecargado? • Tweety t = new Tweety(); • hazAlgo(t);

34. Polimorfismo (y III) • Si “Bird” o “Shape” nunca van a ser instanciables, es mejor declararlas como clases abstractas o virtuales puras. • También las operaciones –métodos- pueden ser abstractas: • Sólo dentro de clases abstractas. • Obliga a las subclases a implementar ese método. • Otra opción es definir directamente “interfaces”: se pueden entender como clases abstractas sin implementación alguna, sólo signatures (¿nos suena de algo?)

35. Ejemplo Interfaces

36. Implementación de un Diseño

37. Bibliografía • Artículos: • Rational Unified Process. Best practices for Software Development Teams. Rational Software. • Using the Rational Unified Process for Small Projects: Expanding upon eXtreme Programming. G. Pollice, Rational Software. • Introduction to UML: Structural and Use Case Modeling. C. Kobryn. Co-chair UML Revision Task Force OMG. www.omg.org. • Enlaces: • Rational: www.rational.com