1.- Repaso Ingeniería del Software I

Slides:



Advertisements
Presentaciones similares
Ciclo de vida de desarrollo de software
Advertisements

Curso de Java Capitulo 7: Continuación Poo Profesor:
ANÁLISIS DE REQUERIMIENTOS
Guía metodológica para la gestión de proyectos de software en PyMEs que no son fábricas de software por medio de Metodologías ágiles.
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
Arquitectura CLARO-TECNOTREE
Introducción a la Orientación a Objetos
Introducción 1 Puntos Clave –La orientación a objetos representa un cambio radical en los métodos tradicionales de creación de software –Los métodos tradicionales.
Fundamentos de Ingeniería de Software
Modelos de Proceso del Software
UNIVERSIDAD LATINA (UNILA) ENCAPSULACION Y HERENCIA
Aplicación del paradigma orientado a objetos
Ingeniería del Software
DIAGRAMAS DE CLASES Completando los diagramas de interacción, es posible identificar la especificación de las clases que participarán en la solución indicando.
Ingeniería del Software
4.- Orientación a Objetos Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA.
Unified Modeling Language (Lenguaje de Modelamiento unificado)
Material Original de Microsoft para desarrolladores adaptado por Jorge Miguel PERALTA para clases de Informática Aplicada (Haga clic para adelantar/atrasar.
Introducción a la programación Orientada a objetos
DEPARTAMENTO DE INGENIERÍA INFORMÁTICA
DEPARTAMENTO DE INGENIERÍA INFORMÁTICA
DEPARTAMENTO DE INGENIERÍA INFORMÁTICA
(c) P. Gomez-Gil, INAOE DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP.
Introducción al Proceso de Desarrollo de Software Patricio Letelier Departamento de Sistemas Informáticos y Computación Universidad.
Ingeniería de Software
3.- Introducción al Proceso Unificado
Introducción a la POO • ¿Qué es la programación orientada a objets (POO)? – Un “paradigma” de programación – Una forma de pensar acerca de los problemas.
DISEÑO DE SOFTWARE 1ª. Parte
Fundamentos de programación
Contenido: 1- Que es el .Net Framework 2- Arquitectura en .Net
Ingeniería de Software: Metodologías Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de:
Rational Unified Process (RUP)
6. Componentes del Ciclo de Vida de un Proyecto SW
Gestión de Proyectos Informáticos Sesión N° 5 Ciclo de Vida de un Proyecto Roberto Jijena I.
1 Diseño Orientado a Objetos Agustín J. González ELO-329: Diseño y Programación Orientados a Objetos 1er. Sem
CS-432: Ingeniería Moderna de Software Semana 3
3.- Introducción a Patrones de Diseño
Ingeniería de Software: Metodologías Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de:
Rational Unified Process (RUP)
Ingeniería de Software: Parte 2 Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de:
2.- Planificación Básica DEPARTAMENTO DE INGENIERÍA INFORMÁTICA
Metodología de Programación Ayudantía 5 lelagos.ublog.cl 2009.
Introducción al Proceso de Desarrollo de Software Patricio Letelier Centro de Formación de Postgrado – Depto. Sistemas Informáticos y Computación Universidad.
Herencia. Introducción La idea básica es poder crear clases basadas en clases ya existentes. Cuando heredamos de una clase existente, estamos re-usando.
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
VISIÓN GENERAL DE LA IS Con independencia del modelo de proceso hay tres fases genéricas: Fase de definición Fase de desarrollo Fase de mantenimiento Cada.
INTRODUCCIÓN AL PROCESO UNIFICADO DE DESARROLLO DESOFTWARE
ANÁLISIS Y DISEÑO DE SISTEMAS II
Alexander Aristizabal Ángelo flores herrera
Introducción a UML Departamento de Informática Universidad de Rancagua
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
(Lenguaje Unificado de Modelado)
Unified Modeling Language (Lenguaje de Modelamiento unificado)
Estructurar tus ideas para hacerlas realidad
Ing. Johanna Macias Algoritmo, Estructura y Programación III.
Tipo de relación entre clases Es uno de los aspectos que distinguen el paradigma de orientación a objetos frente a otros paradigmas. Mecanismo que,
Proceso de desarrollo de Software
Programación Orientada a Objetos: CLASES Y OBJETOS
La Programación Orientado a Objetos
Introducción AOO. Contenido - Introducción - Repaso de Orientación a Objetos - UML - Casos de Uso.
Fundamentos de Ingeniería de Software
Herencias Conceptos básicos i
Modelado Orientado a Objetos Programación Orientada a Objetos Departamento de Sistemas Universidad del Cauca 2006.
Programación orientada a objetos La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa objetos.
1 Tema 2: Introducción al proceso unificado de desarrollo de software.
Programación Orientada a Objetos Unidad 5. Los objetos son entidades que combinan estado Contiene toda la información denominados atributos REPASO Cada.
2015-BM5A. Introducción Durante años, los programadores se han dedicado a construir aplicaciones muy parecidas que resolvían una y otra vez los mismos.
Modelado UML Diagrama de Clases
CURSO:PRACTICA INTEGRAL III ALUMNO: RARÁZ TINOCO, JORGE LUIS PROFESOR:DAVILA, JUAN CICLO:II CICLO.
Entregables del Proyecto
Transcripción de la presentación:

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

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

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. Gif: página 8 del UP (figure 1.2) Gif: página 9 del UP (figure 1.3)

Representaciones del Producto SW (y II): dependencias Figure 1.4 en página 10.

Visión global del ciclo de vida

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.

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.

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?

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?

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.

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

People

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

Orientación a Objetos

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

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

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

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.

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

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.

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.

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.

Encapsulamiento Implementación 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. Exterior Implementación Interfaz

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.

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

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: 

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

Delegación vs. 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.

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

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

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

Ejemplo Interfaces

Implementación de un Diseño

Bibliografía Artículos: Enlaces: 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