1.- repaso ingeniería del software i justo n. hidalgo sanz departamento de ingenierÍa informÁtica
DESCRIPTION
1.- Repaso Ingeniería del Software I Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA. Índice. Repaso al Proceso Unificado Repaso a Conceptos de Orientación a Objetos. Proceso Unificado. Qué es el Proceso Unificado. Unified Software Development Process - PowerPoint PPT PresentationTRANSCRIPT
1.- Repaso Ingeniería del 1.- Repaso Ingeniería del Software ISoftware IJusto N. Hidalgo SanzJusto N. Hidalgo Sanz
DEPARTAMENTO DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA INFORMÁTICAINFORMÁTICA
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Índice
Repaso al Proceso Unificado Repaso a Conceptos de Orientación a Objetos
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Proceso Unificado
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Características
Es guiado por casos de uso (use-case driven) Se centra en la arquitectura (architecture-
centric) Es iterativo (iterative) Es incremental (incremental)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Representaciones del Producto SW (y II): dependencias
Catedral
Modelo de Casos de Uso
Modelo de Pruebas
Modelo de DiseñoModelo de Despliegue
Modelo de Análisis
Modelo de Implementación
especificado porrealizado por
implementado por
distribuido por
verificado por
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Visión global del ciclo de vida
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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?
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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?
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Relaciones de las Cuatro Ps
Process
Product
ProjectTools
People Participantes
AutomatizaciónPlantilla
Resultado
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
People
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.• ...
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Orientación a Objetos
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Índice
La abstracción de los hechos La interfaz: esa gran desconocida Encapsulamiento Herencia Reutilización Tipos de relaciones Polimorfismo
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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).
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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”.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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::Grundig TV::Thomson
TV
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Interfaz: esa gran desconocida (IV)
Así que la interfaz ofrece al exterior el la interfaz ofrece al exterior el comportamiento del objetocomportamiento 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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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ónInterfazExterior
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Herencia (y II)
•Opciones de utilización de la herencia
1. <= Añadir funcionalidad
2. Modificación de comportamiento =>
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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:
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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”.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Polimorfismo (I)
“Early binding”. Linker => dirección absoluta. En OOP eso no se puede hacer hasta run-time:
late-binding.
Controlador de pájaros.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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);
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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 signaturessignatures (¿nos suena de algo?)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Ejemplo Interfaces
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Implementación de un Diseño
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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