Diseño de Componentes. Dra. Marcela Capobianco

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Diseño de Componentes. Dra. Marcela Capobianco"

Transcripción

1 Tecnicas avanzadas en Diseño de Software Diseño de Componentes Dra. Marcela Capobianco 1

2 Diseño orientado a objetos Es difícil crear SW reusable Indentificar los objetos Factorearlos en clases con la granularidad adecuada Ser específicos y generales al mismo tiempo Es casi imposible hacerlo bien la primera vez

3 El arte de programar Los programadores experimentados no resuelven las cosas desde cero. Reutilizan soluciones previamente encontradas, testeadas y aprobadas. Lo hacen en el código con facilidad al identificar el procedimiento a implementar. Lo hacen en el diseño con facilidad al identificar la aplicación particular. Básicamente, identifican patrones y aplican soluciones.

4 El arte de programar Nos centraremos principalmente en la etapa de diseño (tal vez la más difícil) y analizaremos diferentes soluciones que pueden servirnos en el futuro para desarrollar buenas aplicaciones. Los patrones de diseño nombran, explican y evalúan un diseño importante y recurrente en los sistemas orientados a objetos.

5 Patrones de diseño En general, poseen estos cuatro elementos: Nombre del patrón, para poder identificarlo fácilmente y tratarlo de manera abstracta cuando sea necesario. El problema, que describe cuándo utilizar este patrón de forma tal que sea la solución. La solución que describe los elementos que componen el diseño, sus relaciones, sus responsabilidades, etc. Se describe en forma abstracta, pues un patrón es un template que se aplica en diferentes situaciones. Las consecuencias, que son los resultados y el balance final de aplicar el patrón (impacto en el sistema, detalles de lenguajes,etc)

6 Patrones de diseño Los patrones de diseño son básicamente descripciones de objetos que se comunican y clases que son personalizadas para resolver un problema de diseño general en un contexto particular [GoF] Los patrones se describen gráficamente, lo que facilita su comprensión, pero no es suficiente. Algunos aspectos no pueden ser aclarados o especificados por medio de diagramas. Se adopta entonces una convención para la descripción de patrones. Es un formato generalmente aceptado que incluye todos los items necesarios a destacar.

7 Patrones de diseño Los patrones GoF se describen todos de esta forma. Por lo general, otros patrones también seguirán la misma estructura a la hora de describirlos

8 Descripción Intención: qué hace? qué problema ataca? Alias: algunos patrones son conocidos por nombres diferentes. Motivación: un escenario que describe el problema de diseño y que muestra como el patrón resuelve el problema. Aplicabilidad: cuáles son las situaciones en las cuales se aplica el patrón. Estructura: representación gráfica de las clases del patrón (diagramas de clases, diagramas de interacción) Nombre del patrón y clasificación

9 Descripción Participantes: clases y objetos que participan del patrón. Colaboraciones: cómo los participantes colaboran para realizar alguna tarea. Consecuencias: beneficios, balance pros y contras, etc. Implementación: hints, técnicas y detalles a tener en cuenta al implementar el patrón Código ejemplo: fragmentos de código que ejemplifican la implementación Usos conocidos: ejemplos de patrones en sistemas reales. Patrones relacionados: qué otros patrones de diseño están relacionados o pueden combinarse para resolver problemas mayores.

10 Problemas de diseño Los patrones de diseño procuran ayudar a resolver problemas de diseño en el desarrollo de aplicaciones. Veremos algunos de estos problemas, y mencionaremos los patrones que nos ayudarán en este aspecto. Luego en detalle veremos los patrones más populares (conocidos como patrones GoF Gang of Four) y analizaremos las soluciones que proponen. Mas adelante exploraremos otros patrones basados en tecnologías específicas.

11 Problemas de diseño Problema: encontrar los objetos apropiados Una parte difícil del diseño orientado a objetos (DOO) es descomponer el sistema en objetos. Muchos factores entran en juego: encapsulamiento, granularidad, dependencia, flexibilidad, performance, reusabilidad, etc. Existen metodologías para esto, que aunque nos ayudan bastante, no son completas ni infalibles.

12 Problemas de diseño Algunos objetos incluso no corresponden a objetos del mundo real (por ejemplo, arreglos) y es difícil derivarlos de la especificación inicial. Los patrones nos ayudan a identificar abstracciones menos obvias. Por ejemplo, objetos que representan procesos o algoritmos. Esto no surge de forma natural, pero es esencial para el diseño flexible y reutilizable.

13 Problemas de diseño Problema: determinar la granularidad de los objetos Los objetos varían en número y tamaño. Pueden representar aplicaciones completas o simples datos. Qué debería ser un objeto y que no? Algunos patrones nos ayudan en este problema

14 Algunos patrones Facade describe cómo representar subsistemas completos como objetos. Flyweight describe cómo soportar un gran número de objetos a la más fina granularidad. Abstract Factory y Builder permiten derivar objetos cuya responsabilidad es generar otros objetos.

15 Problemas de diseño Problema: especificar las interfaces de los objetos La interfaz es el conjunto de todos los signatures definidos por un objeto. La interfaz de cada objeto determina el conjunto de mensajes o pedidos (request) que se les puede enviar. Es un concepto fundamental en OO. Los objetos son conocidos por sus interfaces y éstas no dicen nada de su implementación. El polimorfismo y la vinculación dinámica de código es posible gracias a este concepto.

16 Problemas de diseño Los patrones ayudan a definir interfaces e incluso nos indican que no poner en la interfaz. Por ejemplo, el patrón Memento indica cómo encapsular y guardar el estado interno de un objeto para ser restaurado más tarde. Este patrón requiere dos interfaces, una semipública y la otra restringida.

17 Problemas de diseño Problema: herencia de clases vs. herencia de interfaces. La clase define el tipo de los objetos. Sin embargo, es posible cierta separación entre estos dos conceptos. En nuestro caso, los dos conceptos están relacionados, pero existen lenguajes que marcan una diferencia.

18 Problemas de diseño La herencia de clase define un objeto en términos de la implementación de otros objetos. La herencia de interfaz (subtipo) indica cuándo un objeto puede ser utilizado en lugar de otro. Por ejemplo, en Smalltalk la herencia es sólo herencia de implementación. Uno puede asignar objetos de otra clase, siempre y cuando implementen las mismas interfaces. Java implementa una aproximación a este concepto

19 Problemas de diseño public interface inter1{ public void f(); public void g(); } class Uno implements inter1 { public void f() { System.out.println("f() de clase Unointer1"); } public void g() { System.out.println("g() de clase Unointer1"); } class Dos implements } inter1 { public void f() { System.out.println("f() de clase Dos-inter1"); } public void g() { System.out.println("g() de clase Dos-inter1"); } } Uno u = new Uno(); Dos d = new Dos(); inter1 i1; i1 = u; i1.f(); i1 = d; i1.f();

20 Problemas de diseño Problema: herencia de clases vs. herencia de interfaces. Algunos patrones dependen de estas distinciones entre los dos tipos de herencia. Por ejemplo, el patrón Chain of Responsability define objetos con un tipo común, pero no necesariamente con una implementación común. Muchos otros patrones (Command, Observer, Strategy) se implementan vía clases abstractas que son simplemente interfaces.

21 Problemas de diseño Lema: Programar para la interface, no la implementación. Este es una máxima a seguir en el diseño orientado a objetos. La herencia permite definir objetos con interfaces idénticas. Es importante pues el polimorfismo depende de esto. Si la herencia se utiliza propiamente, todas las clases derivadas de una clase abstracta comparten la misma interfaz, por lo que todos pueden responder a los mismos mensajes.

22 Problemas de diseño Los beneficios de manipular los objetos en términos de la interface son principalmente: Los clientes desconocen el tipo específico de los objetos que utilizan. Los clientes desconocen las clases que implementan estos objetos. Conocen las clases abstractas que definen sus interfaces.

23 Problemas de diseño Lema: Programar para la interface, no la implementación. Este lema nos sugiere que no declaremos variables como instancias de una clase concreta particular. En lugar de esto, utilizamos la interfaz definida por una clase abstracta particular. Esta buena práctica de diseño OO es recurrente en muchos patrones. Los patrones creacionales (Abstract Factory, Builder, Factory Method, Prototype, Singleton) hacen uso de estas técnicas

24 Problemas de diseño Problema: Reutilización del software. Conocemos los elementos de la OO y las bondades de la reutilización del software. Usualmente la herencia es vista como el mecanismo de reutilización en la orientación a objetos, pero existe otra técnica alternativa denominada composición de objetos. En esta técnica se obtiene nueva funcionalidad ensamblando o componiendo objetos. Para esto es necesario que los objetos posean interfaces bien definidas. Las dos técnicas tienen sus ventajas y desventajas.

25 Problemas de diseño Problema: Reutilización del software. Ventajas de la herencia: definida en tiempo de compilación, sustentada por el lenguaje, facilidad de modificar la implementación reutilizada. Desventajas de la herencia: No puede cambiarse la implementación de lo heredado en tiempo de ejecución. Como la clase padre implementa parte de la estructura de la clase hija, esta expone detalles de implementación a sus herederos. Usualmente se dice que la herencia quiebra el encapsulamiento. La clase padre y la clase hija están íntimamente relacionadas. Un cambio en la clase padre provoca un cambio en la clase hija.

26 Problemas de diseño Problema: Reutilización del software. La composición de los objetos se define en tiempo de ejecución, por medio de objetos que adquieren referencias a otros objetos. Cada objeto debe respetar la interfaz de cada uno. Como los objetos se acceden por medio de las interfaces, no se quiebra el encapsulamiento. Los objetos pueden ser reemplazados en tiempo de ejecución, siempre y cuando posean la misma interfaz. Favorece el encapsulamiento, y el comportamiento del sistema depende de la interrelación entre objetos y no está definido en las clases. Esto permite enunciar el segundo lema de diseño OO: Favorecer la composición de objetos por sobre la herencia

27 Problemas de diseño Problema: Reutilización del software. En realidad la herencia y la composición trabajan juntas. Una buena combinación de las dos permite buenos diseños. La delegación es la técnica que le da poder a la composición de objetos. En delegación, dos objetos están involucrados en atender un mensaje o pedido: un objeto que recibe en el mensaje y lo deriva en el objeto delegado. (análogo al super en herencia!)

28 Problemas de diseño

29 Problemas de diseño Problema: Reutilización del software. La principal ventaja de la delegación es que es fácil determinar el comportamiento en tiempo de ejecución y cambiar el modo en que este comportamiento se define. Muestra que siempre podemos reemplazar herencia por composición de objetos como mecanismo de reutilización de código. La delegación es una buena opción únicamente cuando realmente simplifica más de lo que complica. Varios patrones de diseño utilizan delegación. Strategy, por ejemplo, depende totalmente de esta técnica.

30 Problemas de diseño Problema: Relacionar estructuras de tiempo de ejecución con estructuras de tiempo de compilación Vimos básicamente dos tipos de relaciones entre clases: Asociación: informalmente, modelando la relación conoce a Agregación: informalmente, modelando la relación tiene un

31 Problemas de diseño Hay que tener en cuenta las posibilidades del lenguaje utilizado a la hora de implementar estas relaciones. La asociación entre clases corresponde a referencias entre objetos y la agregación a objetos expandidos o subobjetos. Algunos lenguajes no admiten objetos expandidos. Tiene sentido hablar de la relación de agregación? Por supuesto! Puede implementarse con referencias + restricciones

32 Problemas de diseño Problema: Diseñar para el cambio La clave para maximizar la reutilización es anticipar los nuevos requerimientos y cambios a los actuales y diseñar el sistema para que evolucione adecuadamente. Los patrones de diseño nos ayudan a alcanzar este objetivo y evitar así las consecuencias del mal diseño. Presentan soluciones generales a casos puntuales. Muchos de ellos favorecen directamente el rediseño, evitando situaciones que provocan demasiado acoplamiento entre clases, abstrayendo propiedades comunes, dando flexibilidad al comportamiento de objetos, etc.

33 Patrones de diseño Recordemos Los patrones de diseño son básicamente descripciones de objetos que se comunican y clases que son personalizadas para resolver un problema de diseño general en un contexto particular [GoF]

34 Patrones de diseño GoF PROPÓSITO CREACIONAL ESTRUCTURAL COMPORTAMIENTO CLASE Factory Method Adapter Interpreter Template Method SCOPE OBJETO Abstract Factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Proxy Chain of Responsibility Command Iterator Mediator Memento Flyweight Observer State Strategy Visitor

35 Patrones Creacionales Creational Patterns

36 Patrones GoF - creacionales Los patrones creacionales son patrones que abstraen el proceso de instanciación. Procuran independizar el sistema de cómo sus objetos son creados, compuestos y representados. Cobran especial importancia al tender los sistemas a utilizar mas composición de objetos que herencia. En lugar de codificar un conjunto de comportamientos complejos, se definen varios comportamientos simples, los cuales son ensamblados para modelar comportamientos complejos.

37 Patrones GoF - creacionales Crear objetos con un comportamiento especial requiere más que simplemente instanciar una clase. Estos patrones encapsulan el conocimiento acerca de las clases que el sistema usa y ocultan cómo se crean instancias de estas clases. Seguiremos el ejemplo que Gamma et al. proponen para estudiar estos patrones: la creación de un laberinto para juegos. Un laberinto (maze) es un conjunto de habitaciones (rooms). Una habitación conoce a sus vecinos, los cuales pueden ser otra habitación, un muro o una puerta a otra habitación.

38 Patrones GoF - creacionales *

39 Patrones GoF - creacionales * Cada habitación tiene cuatro lados. En C++ podemos declarar un enumerado: enum Direction {North, South, East, West}; La clase MapSite es una clase abstracta para todos los componentes del laberinto. Posee una sola operación Enter() para simplificar. El significado de Enter() depende del componente. Si es una habitación, cambiamos de locación, si es una puerta y está abierta, pasamos a la siguiente habitación.

40 Room es una clase concreta que define las relaciones entre los otros elementos del laberinto. El número identifica la habitación. Wall y Door son clases concretas que representan las paredes o puertas en cada lado de la habitación. Patrones GoF - creacionales *

41 class Room : public MapSite { public: Room(int roomno); MapSite* GetSide(Direction) const; void SetSide(Direction, MapSite*); virtual void Enter(); private: MapSite* _sides[4]; int _roomnumber; }; class Wall : public MapSite { public: Wall(); virtual void Enter(); }; class Door : public MapSite { public: Door(Room* = 0, Room* = 0); virtual void Enter(); Room* OtherSideFrom(Room*); private: Room* _room1; Room* _room2; bool _isopen; }; class Maze { public: Maze(); void AddRoom(Room*); Room* RoomNo(int) const; private: //... };

42 Patrones GoF - creacionales Maze* MazeGame::CreateMaze () { Maze* amaze = new Maze; Room* r1 = new Room(1); Room* r2 = new Room(2); Door* thedoor = new Door(r1, r2); } amaze->addroom(r1); amaze->addroom(r2); r1->setside(north, new Wall); r1->setside(east, thedoor); r1->setside(south, new Wall); r1->setside(west, new Wall); r2->setside(north, new Wall); r2->setside(east, new Wall); r2->setside(south, new Wall); r2->setside(west, thedoor); return amaze; Esta operación crea un laberinto con dos habitaciones Puede simplificarse. Por ejemplo, las habitaciones podrían crear las paredes. Pero esto sólo mueve código de un lugar a otro Además Qué pasa si queremos agregar otro elemento al laberinto o modificar uno existente? Los patrones creacionales procuran hacer este diseño más flexible, quitando las referencias explícitas a clases concretas.

43 Patrones GoF - creacionales Si CreateMaze invoca funciones virtuales (abstractas) en lugar de los constructores, podemos agregar con facilidad elementos al laberinto, puesto que no se referencia explícitamente las clases intervinientes. Esto lo propone el patrón Factory Method Si CreateMaze recibe un objeto como parámetro para crear habitaciones, paredes y puertas, podemos cambiar los elementos del laberinto pasando diferentes parámetros. Esto lo propone el patrón Abstract Factory.

44 Patrones GoF - creacionales Si CreateMaze recibe un objeto que puede crear un nuevo laberinto completo usando operaciones para agregar habitaciones, paredes y puertas, podemos usar herencia para cambiar partes del laberinto o crearlo de otra forma. Esto lo propone el patrón Builder Si CreateMaze se parametriza con varias habitaciones, paredes y puertas prototípicas, las cuales se copian al laberinto, podemos cambiar la composición del laberinto reemplazando los prototipos por otros. Esto lo propone el patrón Prototype.

45 Patrón Abstract Factory Intención: Proveer una interfaz para crear familias de objetos dependientes o relacionados sin especificar sus clases concretas. Alias: Kit (como sufijo usualmente). Aplicabilidad: Usamos este patrón cuando Un sistema debe independizarse de cómo sus productos son creados, compuestos y representados. Un sistema debe ser configurado con una de múltiples familias de productos. Una familia de objetos debe ser usada en conjunto, y debe reforzarse este hecho. Queremos proveer una librería de productos, pero sólo publicitar las interfaces, no las implementaciones.

46 Cliente AbstractFactory * CreateProductA() * CreateProductB() * AbstractProductA * ProductA2 ProductA1 ConcretFactory1 CreateProductA() + CreateProductB() + ConcretFactory2 CreateProductA() + CreateProductB() + AbstractProductB * ProductB2 ProductB1

47 Participantes AbstractFactory: declara una interfaz para operaciones que crean objetos producto (abstractos) ConcreteFactory: implementa las operaciones para crear objetos producto concretos AbstractProduct: declara una interfaz para un tipo de producto ConcreteProduct: define un objeto producto que será creado por la correspondiente clase factory concreta. Implementa la interfaz AbstractProduct. Cliente: usa sólo interfaces declaradas por AbstractFactory y AbstractProduct.

48 Patrón Abstract Factory - laberintos Apliquemos el patrón Abstract Factory a los laberintos class MazeFactory { public: MazeFactory(); virtual Maze* MakeMaze() const { return new Maze; } virtual Wall* MakeWall() const { return new Wall; } virtual Room* MakeRoom(int n) const { return new Room(n); } virtual Door* MakeDoor(Room* r1, Room* r2) const { return new Door(r1, r2); } }; La clase MazeFactory crea componentes de laberinto.

49 Patrón Abstract Factory - laberintos Maze* MazeGame::CreateMaze (MazeFactory& factory) { Maze* amaze = factory.makemaze(); Room* r1 = factory.makeroom(1); Room* r2 = factory.makeroom(2); Door* adoor = factory.makedoor(r1, r2); amaze->addroom(r1); amaze->addroom(r2); r1->setside(north, factory.makewall()); r1->setside(east, adoor); r1->setside(south, factory.makewall()); r1->setside(west, factory.makewall()); r2->setside(north, factory.makewall()); r2->setside(east, factory.makewall()); r2->setside(south, factory.makewall()); r2->setside(west, adoor); return amaze; }

50 Patrón Abstract Factory - laberintos Podemos crear otros tipos de laberintos simplemente utilizando herencia e invocando la operación anterior con el factory correspondiente. class EnchantedMazeFactory : public MazeFactory { public: EnchantedMazeFactory(); virtual Room* MakeRoom(int n) const { return new EnchantedRoom(n, CastSpell()); } virtual Door* MakeDoor(Room* r1, Room* r2) const { return new DoorNeedingSpell(r1, r2); } protected: Spell* CastSpell() const; };

51 Patrón Builder Intención: Separar la construcción de un objeto complejo de su representación de forma tal que el mismo proceso de construcción pueda crear diferentes representaciones. Aplicabilidad: Usamos este patrón cuando El algoritmo para crear un objeto complejo debe ser independiente de las partes que crean los objetos y de cómo son ensamblados El proceso de construcción debe permitir diferentes representaciones para el objeto que es construído.

52 Patrón Builder - Estructura

53 Patrón Builder Participantes Builder especifica una interfaz abstracta para crear partes del objeto producto. ConcreteBuilder Construye y ensambla partes del producto implementando la interface Builder. Define y lleva un registro de las representaciones que crea. Provee una interfaz para recuperar el producto. Director construye un objeto usando la interfaz Builder Product Representa el objeto complejo en construcción. ConcreteBuilder construye la representación interna del producto y define el proceso por el cual es ensamblado. Incluye clases que definen las partes constituyentes, incluyendo interfaces para ensamblar las partes en el producto final

54 Patrón Builder El cliente crea el objeto Director y lo configura con el objeto Builder deseado. Director notifica al Builder cuando una parte del objecto producto deba ser creada Builder administra pedidos del director y agrega partes al producto El cliente recupera el producto del Builder.

55 Patrón Builder - Colaboraciones

56 Patrón Builder (en los laberintos) class MazeBuilder { public: virtual void BuildMaze() { } virtual void BuildRoom(int room) { } virtual void BuildDoor(int roomfrom, int roomto) { } virtual Maze* GetMaze() { return 0; } protected: MazeBuilder(); }; Maze* MazeGame::CreateMaze (MazeBuilder& builder) { builder.buildmaze(); builder.buildroom(1); builder.buildroom(2); builder.builddoor(1, 2); return builder.getmaze(); }

57 Maze* StandardMazeBuilder::GetMaze () { return _currentmaze; } Patrón Builder - laberintos class StandardMazeBuilder : public MazeBuilder { public: StandardMazeBuilder(); virtual void BuildMaze(); virtual void BuildRoom(int); virtual void BuildDoor(int, int); virtual Maze* GetMaze(); private: Direction CommonWall(Room*, Room*); Maze* _currentmaze; }; StandardMazeBuilder::StandardMazeBuilder () { _currentmaze = 0 void StandardMazeBuilder::BuildMaze () { _currentmaze = new Maze; }

58 Patrón Builder - laberintos void StandardMazeBuilder::BuildRoom (int n) { if (!_currentmaze->roomno(n)) { } } Room* room = new Room(n); _currentmaze->addroom(room); room->setside(north, new Wall); room->setside(south, new Wall); room->setside(east, new Wall); room->setside(west, new Wall); void StandardMazeBuilder::BuildDoor (int n1, int n2) { Room* r1 = _currentmaze->roomno(n1); Room* r2 = _currentmaze->roomno(n2); Door* d = new Door(r1, r2); r1->setside(commonwall(r1,r2), d); r2->setside(commonwall(r2,r1), d); } Maze* maze; MazeGame game; StandardMazeBuilder bld game.createmaze(bldr); maze = bldr.getmaze();

59 Patrón Factory Method Intención: Define una interfaz para crear un objeto, pero deja que las subclases decidan qué clase instanciar. Permite a una clase relegar la instanciación a sus subclases. Alias: Virtual Constructor Aplicabilidad: Usamos este patrón cuando Una clase no puede anticipar qué objetos va a crear. Una clase quiere que sus subclases indiquen qué objetos crea.

60 Patrón Factory Method - Estructura

61 Patrón Factory Method Product define la interfaz de los objetos que el método factoryt va a crear. ConcreteProduct implementa la interfaz Product. Creator Declara el método factory, el cual retorna un objeto del tipo Product. Creator puede también definir una implementación default del método factory y retornar un objeto por defecto. Puede invocar al método factory para crear un objeto de tipo Product. ConcreteCreator Redefine el método factory que retorna una instancia de ConcreteProduct.

62 Patrón Factory Method class MazeGame { public: Maze* CreateMaze(); // factory methods: virtual Maze* MakeMaze() const { return new Maze; } virtual Room* MakeRoom(int n) const { return new Room(n); } virtual Wall* MakeWall() const { return new Wall; } virtual Door* MakeDoor(Room* r1, Room* r2) const { return new Door(r1, r2); } }; Podemos implementar CreateMaze en función de estos factory methods. Diferentes juegos pueden heredar de MazeGame y redefinir partes específicas del laberinto.

63 Patrón Prototype Intención: especifica los tipos de objetos a crear utilizando una instancia prototipo, y crea nuevos objetos copiando esta instancia. Aplicabilidad: Usamos este patrón cuando Cuando las clases a instanciar son especificadas en tiempo de ejecución, por ejemplo, por carga dinámica. Evitar construir una jerarquía de factories paralela a una jerarquía de clases de products Cuando instancias de una clase pueden tener sólo uno de muchas combinaciones de estados, lo que puede obtenerse clonando prototipos en lugar de hacerlo manualmente.

64 Patrón Prototype - Estructura

65 Patrón Prototype - Participantes Prototype declara una interface para la autoclonación. ConcretePrototype implementa una operación para clonarse a sí mismo. Client crea un nuevo objeto solicitándole al prototipo que se clone a sí mismo.

66 Patrón Prototype - laberintos class MazePrototypeFactory : public MazeFactory { public: MazePrototypeFactory(Maze*, Wall*, Room*, Door*); virtual Maze* MakeMaze() const; virtual Room* MakeRoom(int) const; virtual Wall* MakeWall() const; virtual Door* MakeDoor(Room*, Room*) const; private: Maze* _prototypemaze; Room* _prototyperoom; Wall* _prototypewall; Door* _prototypedoor; }; El constructor inicializa los prototipos con los parámetros.

67 Patrón Prototype Las funciones miembro para crear habitaciones, puertas paredes simplemente solicitan clones a los prototipos. Wall* MazePrototypeFactory::MakeWall () const { } Door* MazePrototypeFactory::MakeDoor (Room* r1, Room *r2) const { Door* door = _prototypedoor->clone(); door->initialize(r1, r2); return door; Wall* } MazePrototypeFactory::MakeWall () const { return _prototypewall->clone(); } Door* MazePrototypeFactory::MakeDoor (Room* r1, Room *r2) const { Door* door = _prototypedoor->clone(); door->initialize(r1, r2); return door; }

68 Patrón Prototype Para crear laberintos utilizamos la operación MakeMaze() Para crear laberintos con otras características (por ejemplo, habitaciones con ciertas propiedades adicionales), simplemente inicializamos MazePrototypeFactory con otros prototipos.

69 Patrón Singleton Intención: Asegura que una clase posea sólo una instancia y provee un punto global de acceso a ella. Aplicabilidad: Usamos este patrón cuando Debe existir exactamente una instancia de una clase y debe ser accedida por los clientes a través de un punto de acceso conocido. Cuando la única instancia debe ser extensible por herencia y los clientes pueden usar esta nueva versión sin modificar sus códigos.

70 Estructura: Participantes: Singleton Define una operación Instance que permite a los clientes acceder su instancia única. Es una operación de la clase (static). Es responsable por crear su propia instancia única.

71 Patrón Singleton Si necesitamos que exista una única instancia de la clase MazeFactory que produce el laberinto, debemos contemplar la siguiente estructura: class MazeFactory { public: static MazeFactory* Instance(); // la interfaz completa va acá protected: MazeFactory(); private: static MazeFactory* _instance; };

72 Bibliografía Design Patterns: elements of reusable OO SW. Gamma, Helm, Johnson, Vlissides.

73 Patrones de diseño Recordemos Los patrones de diseño son básicamente descripciones de objetos que se comunican y clases que son personalizadas para resolver un problema de diseño general en un contexto particular [GoF]

74 Patrones de diseño GoF PROPÓSITO CREACIONAL ESTRUCTURAL COMPORTAMIENTO CLASE Factory Method Adapter Interpreter Template Method SCOPE OBJETO Abstract Factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Proxy Chain of Responsibility Command Iterator Mediator Memento Flyweight Observer State Strategy Visitor

75 Patrones Estructurales Structural Patterns

76 Patrones GoF - estructurales Los patrones estructurales se refieren a cómo las clases y los objetos son organizados para conformar estructuras más grandes. La mayor variedad se encuentra en los patrones estructurales de objetos, en donde los objetos se componen para obtener nuevas funcionalidades. Tener en cuenta la importancia del concepto de interfaz. Los objetos interactúan entre ellos por medio de sus interfaces. Pueden ser patrones de clases, basados en la utilización de herencia, o patrones de objetos, basados en la técnica de composición.

77 Patrón Adapter Intención: Convertir la interfaz de una clase en otra interfaz que el cliente espera. Alias: Wrapper. Aplicabilidad: Usaremos este patrón cuando: Deseamos usar una clase existente, pero su interfaz no es la que necesitamos. Queremos crear una clase reutilizable que coopera con otras clases no relacionadas, probablemente con interfaces incompatibles. Necesitamos usar varias subclases, pero no es práctico adaptar sus interfaces heredando de ellas, por lo que apelamos a un objeto adaptador. En este caso se utiliza la versión Object Adapter

78 Patrón Adapter Se realiza una encapsulación de los métodos y una traducción directa. Lo usaremos cuando querramos ver clases de una forma determinada, y la apariencia de esas clases en origen no correspondan con nuestras necesidades.

79 Patrón Adapter Motivación: Aplicación para gráficos.

80 Patrón Adapter Estructura: (versión Class-Adapter)

81 Patrón Adapter Estructura: (versión Object-Adapter)

82 Patrón Adapter Participantes: Target: define la interfase específica del dominio que usa el cliente Client: Colabora con los objetos que se ajustan a la interfaz de target Adaptee: Define una interfaz que se necesita adaptar Adapter: Adapta la interfaz de adaptee a target

83 class Shape { public: Shape(); virtual void BoundingBox(Point& bttmlft, Point& tpright) const; virtual Manipulator* CreateManipulator() const; }; class TextView { public: TextView(); void GetOrigin(Coord& x, Coord& y) const; void GetExtent(Coord& width, Coord& height) const; virtual bool IsEmpty() const; }; class TextShape : public Shape, private TextView { public: TextShape(); virtual void BoundingBox(Point& bttmlft, Point& tprght) const; virtual bool IsEmpty() const; virtual Manipulator* CreateManipulator() const; }; Interfaz esperada en nuestra aplicación Clase que queremos usar, pero la interfaz es incompatible. Clase que adapta TextView con la interfaz Shape

84 Patrón Adapter El object-adapter utiliza composición de objetos en lugar de herencia múltiple. class TextShape : public Shape { public: TextShape(TextView*); virtual void BoundingBox(Point& bttmlft, Point& topright) const; virtual bool IsEmpty() const; virtual Manipulator* CreateManipulator() const; private: TextView* _text; }; Cada operación del adapter debe derivar ( adaptar ) las consultas de la interfaz Shape en función de la interfaz de TextView (interfaz adaptada).

85 Consecuencias Un adapter a nivel clase: Adapta comprmetiendose a una clase adaptee concreta (no sirve si queremos adaptar una clase y sus subclases) Permite override parte del comportamiento de adaptee Un adapter a nivel objeto Permite que un solo adapter trabaje con muchos adaptee (todas sus subclases!) Hace más difícil override el comportamiento del adaptee (subclassing y referirse a la subclase en vez de al adaptee)

86 Bridge: motivación De esta forma comienzan a mezclarse abstracciones de windows con clases concretas de implementaciones para diversas aplicaciones. Lo mejor es separar las jerarquías de abstracciones de las de implementaciones. Esto permite extender ambos conceptos.

87 Bridge: motivación

88 Patrón Bridge Intención: Desacopla una abstracción de su implementación de forma tal que las dos puedan variar o evolucionar en forma independiente. Alias: Handle/Body. Aplicabilidad: Usaremos este patrón cuando: Queremos evitar un ligamiento constante entre la abstracción y la implementación Tanto la implementación como la abstracción deben ser extensibles por herencia. Los cambios en la implementación de una abstracción no deben tener impacto en los clientes. Queremos ocultar completamente la implementación a los clientes.

89 Patrón Bridge Estructura: Bridge

90 Patrón Bridge Participantes: Abstraction: define la interfaz de la abstracción y mantiene una referencia a un objeto de tipo Implementor. RefinedAbstraction: extiende la interfaz definida por Abstraction. Implementor: define la interfaz para clases de implementación. No necesariamente debe corresponder a la interfaz Abstraction. ConcreteImplementor: implementa la interfaz Implementor y define su implementación concreta. Leer ejemplo de implementación (abstracción Window) del libro de Gamma et al.

91 Patrón Bridge Leer ejemplo de implementación (abstracción Window) del libro de Gamma et al. Un abstract factory resulta adecuado para crear y configurar un tipo particular de bridge

92 Estructuras compuestas de objetos Algunas aplicaciones necesitan manipular objetos básicos y agrupaciones de estos objetos de manera indistinta. Por ejemplo, una aplicación gráfica necesita manipular líneas, círculos y rectángulos tanto como figuras compuestas por estos elementos, o por otras figuras compuestas. Para la aplicación gráfica, el tratamiento es distinto, aún cuando para el usuario es el mismo. La aplicación necesita distinguir estos objetos, lo cual complica un poco el escenario general. La clave en este caso es abstraerse de los dos elementos, y trabajar con una clase abstracta que represente tanto los objetos primitivos como los objetos compuestos.

93 Estructuras compuestas de objetos En este caso la organización puede ser: Esta composición recursiva de objetos es la propuesta del patrón de diseño Composite.

94 Patrón Composite Intención: Compone objetos en estructuras de árbol para representar jerarquías de relación es-partede. Aplicabilidad: Usaremos este patrón cuando: Queremos representar jerarquías de objetos modelando la relación es-parte-de (part-whole hierarchies) Queremos que el cliente ignore la distinción entre objetos compuestos y objetos individuales. El cliente tratará todos los objetos de la estructura compuesta de manera uniforme.

95 Patrón Composite

96 Patrón Composite Component: declara la interfaz para los objetos en la composición. Implementa el comportamiento por defecto para todos los objetos. Declara la interfaz para acceder y manipular los componentes hijos. Opcionalmente implementa una interfaz para acceder al padre.

97 Patrón Composite Leaf: representa los objetos simples en la composición. Define el comportamiento de tipos primitivos. Composite: define el comportamiento para componentes compuestos. Almacena estos componentes e implementa operaciones relacionadas a su administración. Client: Manipula los objetos en la composición por medio de la interfaz Component. Este patrón simplifica la implementación del cliente

98 Patrón Composite Usualmente las clases que conforman este patrón incluyen, de ser posible, cada una su propio destructor. Es factible agregar referencias a los padres, lo cual facilita el recorrido de la estructura. Sin embargo, es importante no perder la consistencia (el padre debe apuntar al hijo y viceversa) Se pueden utilizar varias estructuras de datos para que Composite matenga referencias a sus hijos (listas enlazadas, tablas hash, etc). En algunos casos es importante el orden de los hijos (por ejemplo, un parse-tree de un proceso de compilación). En este caso es factible combinar este patrón con el patrón de diseño Iterator, que veremos

99 Objetos, clases y responsabilidades A veces es deseable agregar responsabilidades a objetos individuales, y no a toda la clase a la que pertenece. Una conjunto de herramientas para desarrollar interfaces gráficas debería permitir agregar bordes o comportamientos como el scrolling a cualquier componente gráfica.

100 Objetos, clases y responsabilidades Una forma de agregar responsabilidades es por medio de la herencia. Heredar un borde significa agregarlo a todas las subclases. Pero la elección del borde se resuelve en forma estática. El cliente no controla cómo y cuándo decorar el componente con un borde. Una aproximación más flexible es encerrar el componente a decorar en otro objeto que agrega el borde. Este último se denomina el objeto decorador.

101 Decorando objetos

102 Patrón Decorator Intención: Agrega responsabilidades a un objeto de manera dinámica. Provee una alternativa a la herencia cuando deseamos agregar funcionalidad. Alias: Wrapper Aplicabilidad: Usaremos este patrón cuando: Queremos agregar responsabilidades a objetos individuales de manera dinámica y transparente, sin afectar otros objetos. Deseamos implementar responsabilidades que pueden removerse. Cuando la extensión utilizando herencia es impracticable, por ejemplo, pues provocaría demasiadas variaciones y un gran número de clases.

103 Patrón Decorator

104 Patrón Decorator Participantes: Component: define la interfaz para los objetos que pueden tener responsabilidades agregadas dinámicamente. ConcreteComponent: define un objeto al cual se le pueden agregar responsabilidades dinámicamente. Decorator: mantiene una referencia a un objeto Component y define la interfaz que conforma la interfaz de Component. ConcreteDecorator: agrega responsabilidades al componente. Leer las secciones Consecuencias e Implementación del libro de Gamma et. al.

105 Patrón Decorator - ejemplo class VisualComponent { public: VisualComponent(); virtual void Draw(); virtual void Resize(); //... }; class Decorator : public VisualComponent { public: Decorator(VisualComponent*); virtual void Draw(); virtual void Resize(); //... private: VisualComponent* _component; }; Decorador Concreto class BorderDecorator : public Decorator { public: BorderDecorator(VisualComponent*, int borderwidth); virtual void Draw(); private: void DrawBorder(int); private: int _width; }; { Decorator::Draw (); DrawBorder(_wid th); }

106 Patrón Decorator - ejemplo Supongamos que tenemos esta operación en Window, para agregar componentes visuales void Window::SetContents (VisualComponent* contents) { //... } Creamos un objeto TextView y una ventana en la cual ubicarlo. Window* window = new Window; TextView* textview = new TextView; window->setcontents(textview); Pero como queremos un TextView con borde y con barra de desplazamiento (scroll bar), lo decoramos acordemente antes de ubicarlo en la ventana. window->setcontents( new BorderDecorator( new ScrollDecorator(textView), 1) ); Como Window accede a sus componentes por medio de la interfaz VisualComponent, no tiene conciencia de la decoración de TextView.

107 Objetos y subsistemas Estructurar un sistema en subsistemas reduce la complejidad. Una de las premisas de diseño es la minimización de las comunicaciones entre subsistemas, para evitar la excesiva dependencia. Una forma de lograr esto es centralizar los accesos al subsistema por medio de puntos de acceso generalizados, lo que se suele denominar facade (fachada).

108 Patrón Facade El patrón de diseño Facade provee una interfaz unificada para acceder a un conjunto de interfaces en un subsistema. Define una interfaz de alto nivel que facilita la utilización del subsistema como un todo. Dado que existe usualmente un solo objeto Facade, puede combinarse con el patrón Singleton.

109 Patrón Facade El patrón oculta a los clientes los componentes del subsistema, reduciendo el número de objetos que los clientes deben manipular. Disminuye el acoplamiento entre un subsistema y sus clientes, al proveer puntos de acceso específicos, que permiten manejar un cierto número de objetos. Reduce las dependencias de compilación. Es un patrón muy simple. Leer el ejemplo de la implementación de un subsistema de un compilador.

110 Administrando muchos objetos Las aplicaciones se benefician por el uso de objetos, aunque ciertas implementaciones se tornan demasiado costosas. La identificación de los objetos con la granularidad adecuada forma parte de los desafíos del DOO En un editor de texto no será eficiente crear un objeto por cada letra del documento, con toda la información pertinente a las letras. El problema es el costo. Tener tantos objetos requiere memoria y puede incurrir en un incremento del tiempo de ejecución de la aplicación.

111 Administrando muchos objetos Un objeto flyweight puede ser utilizado en diferentes contextos en forma simultánea. El objeto flyweight es compartido por diferentes contextos, pero en cada uno de ellos este hecho es imperceptible. Esto es posible distinguiendo dos tipos de estados para el objeto modelado: estado intrínseco y estado extrínseco. El estado intrínseco se mantiene en el objeto flyweight propiamente dicho, y consiste de la información independiente del contexto en el cual el flyweight es utilizado.

112 Administrando muchos objetos El estado extrínseco depende y varía del contexto en el cual es utilizado. Los objetos clientes son responsables por otorgar el estado extrínseco al flyweight si lo necesita. Por ejemplo, en el caso de los caracteres, la posición en el documento forma parte del estado extrínseco de ese objeto, y el código UNICODE o ASCII es parte del estado intrínseco.

113 Patrón Flyweight Intención: Permitir manipular un gran número de objetos con granularidad fina, compartiendo objetos. Alias: Wrapper Aplicabilidad: Usaremos este patrón cuando: Una aplicación usa una gran cantidad de objetos. Los costos de almacenamiento son altos precisamente por esa cantidad de objetos. La mayor parte del estado de un objeto es extrínsico. Muchos grupos de objetos se reducen a pocos al eliminar el estado extrínsico. La aplicación no depende de la identidad de los objetos (la igualdad de dos objetos flyweight es verdadera!)

114 Patrón Flyweight

115 Patrón Flyweight Estructura dinámica:

116 Patrón Flyweight Participantes: Flyweight: declara una interfaz por medio de la cual los objetos flyweight pueden actuar sobre el estado extrínseco. ConcreteFlyweight: implementa la interfaz Flyweight y agrega almacenamiento para el estado intrínseco. UnsharedConcreteFlyweight: objeto flyweight no compartible.

117 Patrón Flyweight FlyweightFactory: crea y administra objetos flyweight. Se asegura que los objetos sean compartidos correctamente. Cuando el cliente solicita un objeto flyweight, retorna una instancia existente o crea una nueva en caso contrario. Client: mantiene una referencia a los objetos flyweight que solicitó. Es el responsable de computar y/o almacenar el estado extrínseco de cada objeto. Leer sección Implementación del patrón en el libro de Gamma et. al.

118 Rapidez y eficiencia En algunos casos es deseable que la creación de los objetos sea controlada en pos de la eficiencia en el escenario general. Pensemos en un documento con imágenes complejas. Algunas de estas imágenes pueden ser costosas de crear. Sin embargo, la apertura y manipulación del documento debe ser rápida, por lo que deberíamos postergar la creación de las imágenes hasta tanto realmente se necesiten La solución es crear objetos en demanda, y en su lugar, mientras tanto, ubicamos objetos proxy que representan los originales

119 Patrón Proxy Intención: Proveer un objeto subrogante o reemplazante de otro objeto, para controlar el acceso a éste. Aplicabilidad: Este patrón es aplicable siempre que necesitemos una referencia más detallada a un objeto que el simple puntero: Un proxy remoto que provee representación para un objeto en un espacio de direcciones diferente. Un proxy virtual que crea objetos costosos en demanda (como el de las imágenes del documento). Un proxy de protección, que controla el acceso al objeto original. Una referencia inteligente (smart reference) como reemplazo de un simple puntero, que realiza acciones adicionales cuando el objeto es accedido (eg. conteo de ref., locks para escritura)

120 Patrón Proxy

121 Patrón Proxy Estructura dinámica:

122 Patrón Proxy Participantes: Proxy: mantiene una referencia que le permite al proxy acceder al objeto real. Provee una interfaz idéntica a Subject de forma tal que el proxy puede sustituir al objeto real. Controla el acceso al objeto real. Subject: define la interfaz común para RealSubject y Proxy de forma tal que Proxy pueda ser usada en cualquier lugar en el que se espere usar RealSubject. RealSubject: define el objeto real que el proxy representa.

123 class Graphic { public: virtual ~Graphic(); virtual void Draw(const Point& at) = 0; virtual void HandleMouse(Event& event) = 0; virtual const Point& GetExtent() = 0; virtual void Load(istream& from) = 0; virtual void Save(ostream& to) = 0; protected: Graphic(); }; class Image : public Graphic { public: Image(const char* file); // carga imagen de archivo virtual ~Image(); virtual void Draw(const Point& at); virtual void HandleMouse(Event& event); virtual const Point& GetExtent(); virtual void Load(istream& from); virtual void Save(ostream& to);... }; Interfaz para los objetos gráficos. Clase para mostrar archivos de imágenes.

124 class ImageProxy : public Graphic { public: ImageProxy(const char* imagefile); virtual ~ImageProxy(); virtual void Draw(const Point& at); virtual void HandleMouse(Event& event); virtual const Point& GetExtent(); virtual void Load(istream& from); virtual void Save(ostream& to); protected: Image* GetImage(); private: Image* _image; Point _extent; char* _filename; }; Proxy para las imágenes. Tiene la misma interfaz que Image ImageProxy::ImageProxy (const char* filename) { _filename = strdup(filename); _extent = Point::Zero; _image = 0; } Image* ImageProxy::GetImage() { if (_image == 0) { _image = new Image(_fileName); } return _image; }

125 Patrón Proxy GetExtent del proxy retorna el tamaño almacenado, si no es posible se lo consulta a la imagen real. const Point& ImageProxy::GetExtent () { if (_extent == Point::Zero) { _extent = GetImage()->GetExtent(); } return _extent; } void ImageProxy::Draw (const Point& at) { GetImage()->Draw(at); } void ImageProxy::HandleMouse (Event& event) { GetImage()->HandleMouse(event); }

126 Patrón Proxy Podemos agregar una imagen al documento de la siguiente manera: TextDocument* text = new TextDocument;... text->insert(new ImageProxy( Nombre_de_Archivo_de_Imagen"));

127 Patrones estructurales Adapter y Bridge parecen similares pero se diferencian en su intención: Adapter resuelve incompatibilidades entre interfaces Bridge separa una abstracción de su implementación Composite y Decorator tienen diagramas similares Decorator agrega responsabilidades sin subclassing Composite estructura las clases de forma que objetos relacionados puedan ser tratados uniformemente Algo similar sucede con Proxy y Decorator

128 Patrones de diseño Recordemos Los patrones de diseño son básicamente descripciones de objetos que se comunican y clases que son personalizadas para resolver un problema de diseño general en un contexto particular [GoF]

129 Patrones de diseño GoF PROPÓSITO CREACIONAL ESTRUCTURAL COMPORTAMIENTO CLASE Factory Method Adapter Interpreter Template Method SCOPE OBJETO Abstract Factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Proxy Chain of Responsibility Command Iterator Mediator Memento Flyweight Observer State Strategy Visitor

130 Patrones de Comportamiento Behavioral Patterns

131 Patrones GoF - comportamiento Los patrones de comportamiento se centran en los algoritmos y la asignación de responsabilidades entre los objetos. Son patrones tanto de clases y objetos (similares a los anteriores) como de comunicación entre ellos. Caracterizan flujo de control complejo. Estos patrones también se clasifican en patrones de clases y patrones de objetos.

132 Patrones GoF - comportamiento Los patrones de comportamiento de clases (behavioral class patterns) utilizan herencia para distribuir el comportamiento entre las clases. Los patrones de comportamiento de objetos (behavioral object patterns) utilizan composición de objetos en lugar de herencia. Algunos describen cómo los objetos cooperan entre sí para realizar una tarea compleja, imposible para sólo uno de ellos.

133 Atención de pedidos En algunos casos es factible que se necesario realizar una consulta sobre algún objeto específico, aún sabiendo que tal vez no sea ese el objeto que resolverá realmente el pedido. Ejemplo: ayuda contextual de ventanas El objeto sobre el cual se hace click no necesariamente es el objeto que provee la ayuda (que puede no existir) En ese caso se provee una ayuda más general

134 Atención de pedidos La idea es organizar los objetos de forma tal que pueda desacoplarse el objeto que origina la ayuda del que la provee. El requerimiento atraviesa una cadena de objetos hasta que alguno de ellos pueda atender propiamente este pedido.

135 Atención de pedidos El primer objeto en la cadena recibe el pedido (request) y lo atiende o lo deriva a otros objetos. El objeto que hizo el pedido no tiene conocimiento de quién lo atiende. Decimos en este caso que el pedido tiene un receptor implícito.

136 Atención de pedidos Tal es la propuesta del patrón Chain of Responsability

137 Patrón Chain of Responsability Intención: Evitar acoplar el emisor de un pedido con el receptor, permitiendo que más de un objeto pueda manejar el pedido. Encadena los objetos receptores, los cuales se pasan el pedido hasta que alguno pueda atenderlo. Aplicabilidad: Usaremos este patrón cuando: Más de un objeto puede atender un pedido, y el receptor no es conocido a priori. Queremos realizar un pedido a uno de varios objetos especificando el receptor explícitamente. El conjunto de objetos que atiende un pedido es determinado dinámicamente.

138 Patrón Chain of Responsability - Estructura

139 Patrón Chain of Responsability Participantes: Handler: define una interfaz para atender pedidos. Implementa opcionalmente el link sucesor. ConcreteHandler: atiende los pedidos por los cuales es responsable. Puede acceder a sus sucesor. Client: inicia el pedido a un objeto ConcreteHandler de la cadena. Ver los ejemplos de GoF y de Applied Java Patterns

140 Requerimientos sobre objetos desconocidos A veces es necesario solicitar servicios que desconocemos sobre objetos que ignoramos. Por ejemplo, por medio de herramientas (toolkits) para implementar menús de usuario, con botones, listas, etc. Obviamente, una opción del menú no implementa explícitamente la tarea. Sólo la aplicación que usa el toolkit sabe qué debe hacerse en qué objeto.

141 Requerimientos sobre objetos desconocidos La idea es que el pedido mismo sea un objeto. Podemos declarar una clase Command que declara una interfaz para ejecutar operaciones. Las clases Command concretas (descendientes) especifican el receptor de la operación, vinculando el requerimiento con el objeto en cuestión.

142

143 Patrón Command Intención: Encapsular el pedido (mensaje, solicitud) como un objeto, permitiendo parametrizar los clientes con diferentes pedidos, encolar o registrar los pedidos y proveer operaciones para deshacer pedidos previos. Alias: Action, Transaction.

144 Patrón Command Aplicabilidad: Usaremos este patrón cuando: Parametrizar objetos para una acción a realizar. Especificar, encolar y ejecutar pedidos en momentos diferentes. Proveer la posibilidad de deshacer acciones. Proveer registros de auditoría y salvaguarda. Estructurar un sistema en función de operaciones de alto nivel construidas en base a operaciones primitivas.

145 Patrón Command - Estructura

146 Patrón Command Diagrama de interacción

147 Patrón Command Participantes Command: declara una interfaz para ejecutar operaciones. ConcreteCommand: define el vínculo entre el objeto Receiver y una acción. Implementa Execute() invocando las operaciones correspondientes sobre el Receiver. Client: crea un objeto ConcreteCommand y setea el receptor. Invoker: solicita al comando realizar su tarea. Receiver: conoce cómo realizar operaciones asociadas al llevar a cabo un pedido. Cualquier clase puede actuar como Receiver.

148 Interpretación de lenguajes Es una tarea frecuente en la computación. Nuestras aplicaciones pueden requerir lenguajes simples, con gramáticas simples, que permitirán construir sentencias representando información específica. La representación de las gramáticas del lenguaje puede hacerse de forma tal de favorecer el procesamiento de las sentencias. El patrón Interpreter procura solucionar este problema de diseño. En él podremos representar símbolos terminales y no terminales de la gramática, junto con las reglas de producción.

149 Interpretación de lenguajes Esta estructura representa la expresión regular raining {dogs,cats}*

150 Patrón Interpreter Intención: Dado un lenguaje, define una representación para su gramática junto con un intérprete que usa la representación para interpretar las sentencias del lenguaje. Aplicabilidad: Usaremos este patrón cuando existe un lenguaje que es necesario interpretar, y podemos representar sentencias en el lenguaje como árboles sintácticos abstractos. La gramática debe ser simple. Para gramáticas complejas los árboles se vuelven intratables. La eficiencia no es un factor crítico en el desarrollo.

151 Patrón Interpreter

152 Patrón Interpreter - Participantes AbstractExpression: declara una operación abstracta Interpret que es común a todos los nodos en el árbol sintáctico. TerminalExpression: implementa Interpret asociada a símbolos terminales de la gramática. Se requiere una instancia por cada símbolo terminal. NonterminalExpression: requerida para cada regla de la gramática. Mantiene instancias de tipo AbstractExpression para cada símbolo no terminal. Implementa Interpret para estos símbolos.

153 Patrón Interpreter - Participantes Context: contiene información global al intérprete. Client: Construye el árbol sintáctico de la sentencia particular de la gramática. Invoca la operación Interpret.

154 Conscuencias Es fácil cambiar la gramática Es fácil implementar la gramática No sirve para gramáticas complejas

155 Recorriendo estructuras de objetos Un objeto que contenga otro objeto agregado (como listas) debería permitir el acceso a sus elementos, pero revelando lo menos posible la estructura interna del objeto agregado. La idea es proveer una forma de recorrer una estructura de objetos y de obtener sus componentes independientemente de la estructura específica.

156 Recorriendo estructuras de objetos Cada estructura puede definir sus propia forma de recorrerse, pero la metodología es la misma. Los lenguajes modernos incorporan esta técnica para todos sus tipos estructurados predefinidos. Se denominan iteradores. El patrón Iterator nos indica cómo construir esto para nuestras propias estructuras complejas. Esto nos permite definir iteradores para diferentes políticas de recorridos sin enumerarlas en la interfase de lista

157 Patrón Iterator Intención: Provee un modo de acceder a los elementos de un objeto agregado en forma secuencial, sin exponer su representación interna. Alias: Cursor Aplicabilidad: Usaremos este patrón cuando: Queremos acceder al contenido de los objetos sin exponer su representación interna. Queremos proveer múltiples recorridos de objetos agregados. Queremos proveer una interfaz uniforme para acceder diferentes estructuras agregadas (iteración polimórfica)

158 Patrón Iterator - Estructura Observemos que se usa Factory Method

159 Patrón Iterator Participantes: Iterator: define una interfaz para acceder y recorrer elementos. ConcreteIterator: implementa la interfaz Iterator. Mantiene registro de la posición actual del recorrido. Aggregate: define una interfaz para crear un objeto Iterator. ConcreteAggregate: implementa la interfaz de creación Iterator y devuelve una instancia de ConcreteIterator.

160 Ordenando la marea de objetos La construcción de un sistema orientado a objetos puede derivar en la definición de un gran número de objetos que cooperativamente resuelven una tarea. En muchos casos se determina una estructura de objetos con muchas conexiones entre ellos. Una alternativa es incluir un objeto que controle y coordine la interacción de un grupo de objetos. Este objeto evita que los otros se referencien explícitamente unos a otros para realizar ciertas operaciones. Este objeto se denomina mediador. Los objetos solo conocen al mediador, y por medio (!) de él se interrelacionan con los otros objetos del grupo.

161 Patrón Mediator Intención: Define un objeto que encapsula cómo un conjunto de objetos interactúa. Promueve el bajo acoplamiento y es posible variar la interacción independientemente. Aplicabilidad: Usaremos este patrón cuando: Un conjunto de objetos se comunica en una forma bien definida, pero compleja y difícil de entender. La reutilización de un objeto es dificultosa pues se comunica con varios objetos en el sistema. Un comportamiento distribuido en varias clases debe ser personalizado sin agregar muchas subclases.

162 Patrón Mediator

163 Patrón Mediator Participantes: Mediator: define una interfaz para que se comuniquen los objetos Colleague. ConcreteMediator: implementa el comportamiento cooperativo coordinando objetos Colleague. Conoce y mantiene a sus colegas. Clases Colleague: cada clase conoce a su objeto Mediator. Siempre se comunica con otros objetos por medio del objeto Mediator.

164 Estados del objeto En muchos casos es necesario registrar el estado interno de un objeto, por ejemplo, al permitir deshacer ciertas acciones en nuestra aplicación. El objetivo es recordar el estado interno del objeto, para poder eventualmente restaurarlo más tarde. No debería exponerse el estado interno del objeto, pues viola el encapsulado.

165 Estados del objeto Una forma de realizar esta tarea es crear un objeto que almacene un recuerdo (snapshot) del estado interno del objeto. El primero se denomina memento, y el segundo el objeto originador del memento. El mecanismo para deshacer acciones solicitará un memento del originador para restaurarlo al estado recordado. Estos detalles se especifican en el patrón de diseño Memento.

166 Patrón Memento Intención: Sin violar el encapsulamiento, captura y externaliza el estado interno de un objeto de forma tal que el objeto puede ser restaurado a ese mismo estado más tarde. Aplicabilidad: Usaremos este patrón cuando: Un registro (snapshot) del estado de un objeto debe ser guardado para restaurarlo más tarde, y Una interfaz directa para obtener el estado expondría detalles de implementación y quiebraría el encapsulado del objeto.

167 Patrón Memento

168 Patrón Memento Estructura de colaboración acaretaker solicita un memento del originador, lo retiene durante un tiempo, y luego se lo devuelve al originador para restauración.

169 Patrón Memento - Participantes Memento: almacena el estado interno del objeto Originator. Almacena tanto como sea necesario o requerido. Protege contra accesos que no provean de su originador. Originator: crea un memento registrando su estado actual. Usa el memento para restaurar el estado interno. Caretaker: responsable por la salvaguarda del memento. Nunca opera o examina el contenido del memento. Leer la implementación ejemplo de Memento en Applied Java Patterns (pag.63)

170 Objetos y consistencia Un problema recurrente en la programación orientada a objetos es el mantenimiento de la consistencia entre objetos relacionados y cooperativos, sin alto acoplamiento. Este problema cobra también importancia en la representación visual de objetos complejos. Cuando el objeto cambia, su representación visual (que también es un objeto) debe cambiar acordemente (ejemplo: gráficos en Excel) Una forma de lograr esto es organizar los objetos en observadores de un aspecto particular (observerssubject) La propuesta de organización se refleja en el patrón Observer.

171 Patrón Observer Intención: Define una dependencia entre objetos de uno-a-muchos de forma tal que cuando un objeto cambia de estado, todos sus dependientes son notificados y actualizados acordemente. Alias: Dependents, Publish-Suscribe Aplicabilidad: Usaremos este patrón cuando: Cuando una abstracción tiene dos aspectos, uno independiente del otro. Cuando un cambio a un objeto requiere cambios en otros, y no sabemos cuántos objetos necesitan ser cambiados. Cuando un objeto debería notificar a otros objetos sin realizar suposiciones de quiénes son esos objetos (evitar el acoplamiento)

172 Patrón Observer

173 Patrón Observer Estructura de colaboración

174 Patrón Observer - Participantes Subject: conoce a sus observadores. Cualquier número de objetos Observer puede observar un subject. Provee una interfaz para vincular y desvincular objetos Observer. Observer: define una interfaz de actualización para objetos, que debe ser notificada de los cambios en el subject. ConcreteSubject: Almacena el estado de interés de objetos ConcreteObserver. Notifica a sus observadores cuando el estado cambia. ConcreteObserver: mantiene una referencia a un objeto ConcreteSubject. Almacena estado que debe mantenerse consistente con el subject. Implementa la interfaz Observer.

175 Actuar en función del estado Muchas veces diferentes alternativas del flujo procesamiento del objeto se deciden en función de su estado interno. Esto genera a veces muchos condicionales en donde se examina el estado y se determina la acción a realizar. Ante los cambios las modificaciones son bastante tediosas. Podemos encapsular el estado del objeto en otro objeto que determine la secuencia de acciones a realizar en ese estado en particular. El objeto delega todos los pedidos relacionados con el estado al objeto mismo que representa el estado actual, el cual resuelve el pedido finalmente.

176 Patrón State Intención: Permite a un objeto alterar su comportamiento cuando cambia su estado interno. Alias: Objects for States Aplicabilidad: Usaremos este patrón cuando: El comportamiento de un objeto depende de su estado, y debe cambiar en tiempo de ejecución según el estado. Las operaciones tienen muchas sentencias condicionales dependientes del estado del objeto.

177 Patrón State La clase Context delega pedidos dependientes del estado al objeto State asociado (concreto)

178 Patrón State Participantes: Context: define una interfaz de interés para los clientes. Mantiene una instancia de ConcreteState que define el estado actual State: define una interfaz para encapsular el comportamiento asociado con un estado particular del Contexto. Subclases ConcreteState: cada subclase implementa un comportamiento específico asociado con un estado del objeto Context. Leer el ejemplo correspondiente en el libro Applied Java Patterns

179 Algoritmos, comportamiento y variaciones Así como es posible encapsular el estado de un objeto en pos de la flexibilidad, también es posible encapsular operaciones, de forma tal que estas también puedan variar libremente. Algoritmos diferentes pueden utilizarse en situaciones diferentes y podemos perfeccionar el algoritmo sin modificar las clases que lo utilizan. La idea básica es alojar un algoritmo en un objeto con una interfaz definida, de forma tal que al cambiar el objeto cambia la implementación del algoritmo. Esta es la situación que captura el patrón Strategy.

180 Patrón Strategy Intención: Define una familia de algoritmos, encapsula cada uno convirtiéndolos en intercambiables. Permite variar un algoritmo independientemente de los clientes que lo utilizan. Alias: Policy Aplicabilidad: Usaremos este patrón cuando: Muchas clases relacionadas difieren únicamente en el comportamiento. Necesitamos diferentes variantes de un algoritmo. Un algoritmo utiliza datos que el cliente no debe conocer. Una clase define múltiples comportamientos, y éstos figuran como sentencias condicionales múltiples en sus operaciones.

181 Patrón Strategy - Estructura

182 Patrón Strategy Participantes: Strategy: declara una interfaz común a todos los algoritmos soportados. ConcreteStrategy: implementa un algoritmo utilizando la interfaz Strategy. Context: está configurado con un objeto de tipo ConcreteStrategy. Mantiene una referencia a un objeto Strategy. Puede definir, si es necesario, una interfaz para que Strategy acceda a sus datos.

183 Algoritmos en términos abstractos Es posible que se conozca la estructura general de un algoritmo, pero que ciertos detalles deban resolverse en situaciones específicas. Podemos implementar el algoritmo en función de ciertas primitivas abstractas, las cuales serán redefinidas por los herederos correspondientes. Esta operación se denomina template method. Las subclases proveen de esta forma el comportamiento concreto de la operación antes especificada, implementando los pasos que son abstractos en el template method.

184 Patrón Template Method Intención: Define el esqueleto de un algoritmo en una operación, postergando la implementación de algunos pasos a las subclases. Las subclases redefinen ciertos pasos del algoritmo sin cambiar su estructura general. Aplicabilidad: Usaremos este patrón cuando: Es conveniente implementar la parte invariante de un algoritmo sólo una vez y dejar que las subclases implementen el comportamiento variante. El comportamiento común de varias subclases puede ser factorizado y ubicado en una clase común para evitar la duplicación de código. Para controlar las extensiones por subclases. La extensión se permite en ciertos puntos de un algoritmo.

185 Patrón Template Method Participantes AbstractClass: define operaciones primitivas abstractas. ConcreteClass: implementa las operaciones primitivas específicas.

186 Repartiendo tareas.. Supongamos que tenemos una estructura de objetos medianamente compleja, por ejemplo un árbol, en la cual debemos realizar una operación que requiere operar con cada objeto de la estructura.

Capítulo 4 Patrones y Patrones de Diseño (ii)

Capítulo 4 Patrones y Patrones de Diseño (ii) Capítulo 4 Patrones y Patrones de Diseño (ii) Orientado a Objetos Ingeniería Informática Ingeniería Técnica de Informática de Sistemas y Gestión Optativa (6 créditos) http://www.info-ab.uclm.es/asignaturas/42579

Más detalles

Patrones Creacionales Builder. Patrones Creacionales Abstract Factory. Patrones Creacionales Singleton. Patrones Creacionales Prototype

Patrones Creacionales Builder. Patrones Creacionales Abstract Factory. Patrones Creacionales Singleton. Patrones Creacionales Prototype Temario Patrones de Diseño de Software Fundamentos de Ingeniería de SW Jocelyn Simmonds GOF: Patrones Creacionales Patrones Estructurales ILI-236 (JS) Patrones II 1 / 31 ILI-236 (JS) Patrones II 2 / 31

Más detalles

Tecnología de Programación

Tecnología de Programación Tecnología de Programación Diego C. Martínez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Reutilización La reutilización es un ingrediente fundamental en la ingeniería

Más detalles

Patrones de Diseño Orientados a Objetos 2 Parte

Patrones de Diseño Orientados a Objetos 2 Parte Patrones de Diseño Orientados a Objetos 2 Parte Patrón Observador Observer (Patrón de Comportamiento) Patrón Observador Observer Observador (en inglés: Observer) es un patrón de diseño que define una dependencia

Más detalles

Patrones de Diseño. Patrones de creación. Técnicas de Programación - Curso 2007/08

Patrones de Diseño. Patrones de creación. Técnicas de Programación - Curso 2007/08 Patrones de Diseño Patrones de creación Técnicas de Programación - Curso 2007/08 Patrones de creación Introducción Abstraen el proceso de instanciación Encapsulan conocimiento sobre qué clases concretas

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura

Más detalles

CLASE 10: MÁS PATRONES. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette C. Martínez

CLASE 10: MÁS PATRONES. Universidad Simón Bolívar. Ing. de Software. Prof. Ivette C. Martínez CLASE 10: MÁS PATRONES Universidad Simón Bolívar. Ing. de Software. Prof. Ivette C. Martínez Polimorfismo Problema: Cómo manejar las alternativas basadas en el tipo? Cómo crear componentes conectables?

Más detalles

PATRONES DE DISEÑO. FAVA - Formación en Ambientes Virtuales de Aprendizaje. SENA - Servicio Nacional de Aprendizaje

PATRONES DE DISEÑO. FAVA - Formación en Ambientes Virtuales de Aprendizaje. SENA - Servicio Nacional de Aprendizaje PATRONES DE DISEÑO 1. Generalidades 2. Patrones Gof 2.1. Patrones Creacionales 2.1.1.Fábrica Abstracta 2.1.2.Constructor 2.1.3.Método de Factoría 2.1.4.Prototipo 2.1.5.Singleton 2.2. Patrones Estructurales

Más detalles

Factory method (Gamma et al.)

Factory method (Gamma et al.) Factory method (Gamma et al.) Define una interfaz para crear un objeto pero deja a las subclases decidir que clase instanciar Motivación: Consideremos un framework que presenta múltiples documentos al

Más detalles

Patrones de Diseño. Patrón estructural Decorator. Técnicas de Programación - Curso 2008/09 (Esther Guerra Sánchez)

Patrones de Diseño. Patrón estructural Decorator. Técnicas de Programación - Curso 2008/09 (Esther Guerra Sánchez) Patrones de Diseño Patrón estructural Decorator Técnicas de Programación - Curso 2008/09 (Esther Guerra Sánchez) Propósito Permite añadir responsabilidades extra a objetos concretos de manera dinámica

Más detalles

Patrones de Diseño. Ezequiel Postan. 1 Libro e índice. 2 Introducción

Patrones de Diseño. Ezequiel Postan. 1 Libro e índice. 2 Introducción Patrones de Diseño Ezequiel Postan 1 Libro e índice Gamma, E., Helm, R., Johnson, R., Vlissides, J., Patrones de diseño, Addison-Wesley, 2003. Páginas 2-69: Introducción. Composite. Strategy. Decorator.

Más detalles

2.2.- Paradigmas de la POO

2.2.- Paradigmas de la POO 2.2.- Paradigmas de la POO Los principios propios de la orientación a objetos son: 2.2.1.- Abstracción de Datos 2.2.2.- Encapsulamiento 2.2.3.- Ocultamiento 2.2.4.- Herencia 2.2.5.- Polimorfismo Cualquier

Más detalles

GUIA PROGRAMACIÓN ORIENTADA A OBJETOS

GUIA PROGRAMACIÓN ORIENTADA A OBJETOS GUIA PROGRAMACIÓN ORIENTADA A OBJETOS 1. Por qué la P.O.O? R= A medida que se van desarrollando los lenguajes, se va desarrollando también la posibilidad de resolver problemas más complejos. En la evolución

Más detalles

Tema: Patrones de Diseño.

Tema: Patrones de Diseño. Programación II. Guía 13 1 Facultad: Ingeniería Escuela: Computación Asignatura: Programación II Tema: Patrones de Diseño. Objetivos Específicos Implementar la aplicación de patrones de diseño como herramientas

Más detalles

Programación Orientada a Objetos en Java

Programación Orientada a Objetos en Java Programación Orientada a Objetos en Java Curso 2006-2007 Tema 4 Herencia y Polimorfismo Gonzalo Méndez Pozo Dpto. de Ingeniería de Software e Inteligencia Artificial Universidad Complutense de Madrid Herencia

Más detalles

2. Conceptos básicos Abstracción La abstracción como un proceso mental natural La abstracción en el desarrollo de software

2. Conceptos básicos Abstracción La abstracción como un proceso mental natural La abstracción en el desarrollo de software 2. Conceptos básicos Hoy en día las aplicaciones son demasiado voluminosas y complejas para ser manejadas por una sola persona. Las aplicaciones de software son complejas porque modelan la complejidad

Más detalles

Curso de Java POO: Programación orientada a objetos

Curso de Java POO: Programación orientada a objetos Curso de Java POO: Programación orientada a objetos Luis Guerra Velasco Curso INEM 02830. Programación en Java Marzo 2010 Índice 1 Introducción a la POO 2 Herencia y polimorfismo 3 Empaquetado de proyectos

Más detalles

Patrones de diseño: Test 1

Patrones de diseño: Test 1 Patrones de diseño: Test 1 1. Cuál es el objetivo del patrón Strategy? a) Definir el esqueleto de un algoritmo dejando la implementación de algunos de los pasos del esqueleto a las subclases. b) Permite

Más detalles

La ventana de Microsoft Excel

La ventana de Microsoft Excel Actividad N 1 Conceptos básicos de Planilla de Cálculo La ventana del Microsoft Excel y sus partes. Movimiento del cursor. Tipos de datos. Metodología de trabajo con planillas. La ventana de Microsoft

Más detalles

Modulo 1 El lenguaje Java

Modulo 1 El lenguaje Java Modulo 1 El lenguaje Java 13 - Codificación en Java Una de las grandes diferencias entre Java y Pascal en cuando a la codificación es que Java se trata de un lenguaje de los llamados case sensitive Esto

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Conceptos. ELO329: Diseño y Programación Orientados a Objetos. ELO 329: Diseño y Programación Orientados a Objetos

Conceptos. ELO329: Diseño y Programación Orientados a Objetos. ELO 329: Diseño y Programación Orientados a Objetos Conceptos ELO329: Diseño y Programación Orientados a Objetos 1 Paradigmas de Programación Historia: Los computadores parten cableados por hardware, Luego se introduce la programación en binario, Se desarrolla

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS

PROGRAMACIÓN ORIENTADA A OBJETOS PROGRAMACIÓN ORIENTADA A OBJETOS Clase 1. Introducción Profesor: Diego Sánchez Gómez Introducción a la programación orientada a objetos 1. Introducción a la programación orientada a objetos 2. Las clases

Más detalles

Tutorial de UML. Introducción: Objetivos: Audiencia: Contenidos:

Tutorial de UML. Introducción: Objetivos: Audiencia: Contenidos: Tutorial de UML Introducción: El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende

Más detalles

DIAGRAMA DE CLASES EN UML

DIAGRAMA DE CLASES EN UML DIAGRAMA DE CLASES EN UML Mg. Juan José Flores Cueto jflores@usmp.edu.pe Ing. Carmen Bertolotti Zuñiga cbertolotti@usmp.edu.pe INTRODUCCIÓN UML (Unified Modeling Language) es un lenguaje que permite modelar,

Más detalles

Programación Orientada a Objetos con Java

Programación Orientada a Objetos con Java Programación Orientada a Objetos con Java M.C. Jorge Eduardo Ibarra Esquer jorgeeie@uabc.mx Sobrecarga de métodos Java permite la definición de dos o más métodos que tengan el mismo nombre, dentro de la

Más detalles

Patrones de diseño en Java Los 23 modelos de diseño: descripción y soluciones ilustradas en UML 2 y Java

Patrones de diseño en Java Los 23 modelos de diseño: descripción y soluciones ilustradas en UML 2 y Java Introducción a los patrones de diseño 1. Design patterns o patrones de diseño 15 2. Descripción de los patrones de diseño 17 3. Catálogo de patrones de diseño 18 4. Cómo escoger y utilizar un patrón de

Más detalles

Notación UML para modelado Orientado a Objetos

Notación UML para modelado Orientado a Objetos 1 Notación UML para modelado Orientado a Objetos 2 Notación UML para modelado Orientado a Objetos Índice 1.1. Qué es UML?.. 3 1.2. Por qué interesa UML en la asignatura de Programación Orientada a Objetos?3

Más detalles

Figura 4.1 Clasificación de los lenguajes de bases de datos

Figura 4.1 Clasificación de los lenguajes de bases de datos 1 Colección de Tesis Digitales Universidad de las Américas Puebla Romero Martínez, Modesto Este capítulo describen los distintos lenguajes para bases de datos, la forma en que se puede escribir un lenguaje

Más detalles

Patrones de diseño en PHP Los 23 modelos de diseño: descripciones y soluciones ilustradas en UML2 y PHP

Patrones de diseño en PHP Los 23 modelos de diseño: descripciones y soluciones ilustradas en UML2 y PHP Introducción a los patrones de diseño 1. Design patterns o patrones de diseño 15 2. Descripción de los patrones de diseño 17 3. Catálogo de patrones de diseño 18 4. Cómo escoger y utilizar un patrón de

Más detalles

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual Introducción Algunas de las personas que trabajan con SGBD relacionales parecen preguntarse porqué deberían preocuparse del diseño de las bases de datos que utilizan. Después de todo, la mayoría de los

Más detalles

Universidad de Cantabria corcuerp@unican.es

Universidad de Cantabria corcuerp@unican.es Herencia Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Aprender los conceptos de herencia Comprender la forma de derivar una

Más detalles

Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech

Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech Correspondencias entre taxonomías XBRL y ontologías en OWL Unai Aguilera, Joseba Abaitua Universidad de Deusto, EmergiaTech Resumen Todo documento XBRL contiene cierta información semántica que se representa

Más detalles

Instructivo para la elaboración de un Manual Técnico

Instructivo para la elaboración de un Manual Técnico Instructivo para la elaboración de un Manual Técnico Autora: Ing. Alena González Reyes. (agonzalez@ceis.cujae.edu.cu) Ciudad de la Habana, Cuba Marzo, 2010 Índice 1. Introducción... 3 2. Confección...

Más detalles

Introducción a la programación orientada a objetos

Introducción a la programación orientada a objetos Introducción a la programación orientada a objetos 1. Introducción a la programación orientada a objetos 2. Las clases 3. El tipo Struct 4. Diferencias entre Class y Struct 5. Pilares de la Programación

Más detalles

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de los

Más detalles

Tema 3: Herencia en C++ Programación Orientada a Objetos Curso 2008/2009 Begoña Moros Valle

Tema 3: Herencia en C++ Programación Orientada a Objetos Curso 2008/2009 Begoña Moros Valle Tema 3: Herencia en C++ Programación Orientada a Objetos Curso 2008/2009 Begoña Moros Valle Contenido Tipos de herencia Herencia y niveles de visibilidad Herencia y creación Redefinición de métodos Conversión

Más detalles

Curso de Doctorado: Tecnologías de Objetos

Curso de Doctorado: Tecnologías de Objetos Curso de Doctorado: Tecnologías de Objetos Grupo IMO Área de Lenguajes y Sistemas Informáticos Departamento de Informática J. Baltasar García Perez-Schofield http://webs.uvigo.es/jbgarcia/ Implementación

Más detalles

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

Más detalles

Centro de Capacitación en Informática

Centro de Capacitación en Informática Fórmulas y Funciones Las fórmulas constituyen el núcleo de cualquier hoja de cálculo, y por tanto de Excel. Mediante fórmulas, se llevan a cabo todos los cálculos que se necesitan en una hoja de cálculo.

Más detalles

En cualquier caso, tampoco es demasiado importante el significado de la "B", si es que lo tiene, lo interesante realmente es el algoritmo.

En cualquier caso, tampoco es demasiado importante el significado de la B, si es que lo tiene, lo interesante realmente es el algoritmo. Arboles-B Características Los árboles-b son árboles de búsqueda. La "B" probablemente se debe a que el algoritmo fue desarrollado por "Rudolf Bayer" y "Eduard M. McCreight", que trabajan para la empresa

Más detalles

ARQUITECTURA DE DISTRIBUCIÓN DE DATOS

ARQUITECTURA DE DISTRIBUCIÓN DE DATOS 4 ARQUITECTURA DE DISTRIBUCIÓN DE DATOS Contenido: Arquitectura de Distribución de Datos 4.1. Transparencia 4.1.1 Transparencia de Localización 4.1.2 Transparencia de Fragmentación 4.1.3 Transparencia

Más detalles

FASES DEL PROCESO DE RESOLUCIÓN DE PROBLEMAS

FASES DEL PROCESO DE RESOLUCIÓN DE PROBLEMAS FASES DEL PROCESO DE RESOLUCIÓN DE PROBLEMAS Varios autores han tratado de identificar y describir las distintas fases en el proceso de resolución de problemas. Polya (1945), en su modelo descriptivo,

Más detalles

5.1. Organizar los roles

5.1. Organizar los roles Marco de intervención con personas en grave situación de exclusión social 5 Organización de la acción 5.1. Organizar los roles Parece que el modelo que vamos perfilando hace emerger un rol central de acompañamiento

Más detalles

Patrones de software y refactorización de código

Patrones de software y refactorización de código Patrones de software y refactorización de código Introducción y antecedentes de los patrones de software Los patrones permiten construir sobre la experiencia colectiva de ingenieros de software habilidosos.

Más detalles

CAPÍTULO 3 Servidor de Modelo de Usuario

CAPÍTULO 3 Servidor de Modelo de Usuario CAPÍTULO 3 Servidor de Modelo de Usuario Para el desarrollo del modelado del estudiante se utilizó el servidor de modelo de usuario desarrollado en la Universidad de las Américas Puebla por Rosa G. Paredes

Más detalles

LABORATORIO Nº 2 GUÍA PARA REALIZAR FORMULAS EN EXCEL

LABORATORIO Nº 2 GUÍA PARA REALIZAR FORMULAS EN EXCEL OBJETIVO Mejorar el nivel de comprensión y el manejo de las destrezas del estudiante para utilizar formulas en Microsoft Excel 2010. 1) DEFINICIÓN Una fórmula de Excel es un código especial que introducimos

Más detalles

Diseño orientado a los objetos

Diseño orientado a los objetos Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia

Más detalles

Clases y Objetos. Informática II Ingeniería Electrónica

Clases y Objetos. Informática II Ingeniería Electrónica Clases y Objetos Informática II Ingeniería Electrónica Los Tipos de Datos Hasta ahora, en un programa podemos usar para representar variables a: Tipos fundamentales : enteros (int), caracteres (char),

Más detalles

Tema 6. Reutilización de código. Programación 2015-2016. Programación - Tema 6: Reutilización de código

Tema 6. Reutilización de código. Programación 2015-2016. Programación - Tema 6: Reutilización de código Tema 6 Reutilización de código Programación 2015-2016 Programación - Tema 6: Reutilización de código 1 Tema 6. Reutilización de código Modularidad. Implementación de métodos. Uso de métodos. Programación

Más detalles

Los números racionales

Los números racionales Los números racionales Los números racionales Los números fraccionarios o fracciones permiten representar aquellas situaciones en las que se obtiene o se debe una parte de un objeto. Todas las fracciones

Más detalles

GUÍA RÁPIDA DE TRABAJOS CON ARCHIVOS.

GUÍA RÁPIDA DE TRABAJOS CON ARCHIVOS. GUÍA RÁPIDA DE TRABAJOS CON ARCHIVOS. 1 Direcciones o Ubicaciones, Carpetas y Archivos Botones de navegación. El botón Atrás permite volver a carpetas que hemos examinado anteriormente. El botón Arriba

Más detalles

Repetir el proceso para cada abstracción identificada hasta que el diseño este expresado en términos sencillos

Repetir el proceso para cada abstracción identificada hasta que el diseño este expresado en términos sencillos I. INTRODUCCIÓN El reciente aumento de aplicaciones en donde se utiliza la computadora ha sido posible debido a un hardware de bajo costo, por lo cual la demanda de software ha crecido de forma exponencial.

Más detalles

Base de datos en la Enseñanza. Open Office

Base de datos en la Enseñanza. Open Office 1 Ministerio de Educación Base de datos en la Enseñanza. Open Office Módulo 1: Introducción Instituto de Tecnologías Educativas 2011 Introducción Pero qué es una base de datos? Simplificando mucho, podemos

Más detalles

MODELOS DE RECUPERACION

MODELOS DE RECUPERACION RECUPERACIÓN Y ORGANIZACIÓN DE LA INFORMACIÓN INGENIERÍA INFORMÁTICA RECUPERACIÓN Y ACCESO A LA INFORMACIÓN MODELOS DE RECUPERACION AUTOR: Rubén García Broncano NIA 100065530 grupo 81 1 INDICE 1- INTRODUCCIÓN

Más detalles

TALLER No. 1 Capitulo 1: Conceptos Básicos de Bases de datos

TALLER No. 1 Capitulo 1: Conceptos Básicos de Bases de datos TALLER No. 1 Capitulo 1: Conceptos Básicos de Bases de datos 1. La base de datos se puede considerar como una unificación de varios archivos de datos independientes, cuyo propósito básico es evitar la

Más detalles

Para ingresar a la aplicación Microsoft PowerPoint 97, los pasos que se deben seguir pueden ser los siguientes:

Para ingresar a la aplicación Microsoft PowerPoint 97, los pasos que se deben seguir pueden ser los siguientes: Descripción del ambiente de trabajo Entrar y salir de la aplicación Para ingresar a la aplicación Microsoft PowerPoint 97, los pasos que se deben seguir pueden ser los siguientes: A través del botón :

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

Criterios para seleccionar tecnología de Modelos de Toma de Decisiones

Criterios para seleccionar tecnología de Modelos de Toma de Decisiones Estado del Arte Por Eduardo Cantú y Stephen Sellers Criterios para seleccionar tecnología de Modelos de Toma de Decisiones Seleccionar la herramienta apropiada para desarrollar sus Modelos de Cadena de

Más detalles

Introducción a Visual Studio.Net

Introducción a Visual Studio.Net Introducción a Visual Studio.Net Visual Studio es un conjunto completo de herramientas de desarrollo para la generación de aplicaciones Web ASP.NET, Servicios Web XML, aplicaciones de escritorio y aplicaciones

Más detalles

BASE DE DATOS RELACIONALES

BASE DE DATOS RELACIONALES BASE DE DATOS RELACIONALES Una base de datos relacional es una base de datos que cumple con el modelo relacional, el cual es el modelo más utilizado en la actualidad para implementar bases de datos ya

Más detalles

TIPOS DE PATRONES. PATRONES DE DISEÑO: Las soluciones probadas para el diseño de software. En estas nos vamos a centrar.

TIPOS DE PATRONES. PATRONES DE DISEÑO: Las soluciones probadas para el diseño de software. En estas nos vamos a centrar. TIPOS DE PATRONES Hoy, podemos encontrar literalmente miles de patrones definidos. Resulta imposible para un programador conocerlos todos, ni mucho menos probarlos o valorarlos. Así que necesitamos una

Más detalles

Sistema de Mensajería Empresarial para generación Masiva de DTE

Sistema de Mensajería Empresarial para generación Masiva de DTE Sistema de Mensajería Empresarial para generación Masiva de DTE TIPO DE DOCUMENTO: OFERTA TÉCNICA Y COMERCIAL VERSIÓN 1.0, 7 de Mayo de 2008 CONTENIDO 1 INTRODUCCIÓN 4 2 DESCRIPCIÓN DE ARQUITECTURA DE

Más detalles

Instructivo Asesoría Básica Comunidad Virtual SharePoint 2010

Instructivo Asesoría Básica Comunidad Virtual SharePoint 2010 Instructivo Asesoría Básica Comunidad Virtual SharePoint 2010 CONTENIDO 1. Qué es? 2. Cómo crear y acceder a la Comunidad Virtual en Microsoft SharePoint 2010? Ejemplo. 3. Qué tengo en la página de inicio

Más detalles

CAPÍTULO 4. EL EXPLORADOR DE WINDOWS XP

CAPÍTULO 4. EL EXPLORADOR DE WINDOWS XP CAPÍTULO 4. EL EXPLORADOR DE WINDOWS XP Características del Explorador de Windows El Explorador de Windows es una de las aplicaciones más importantes con las que cuenta Windows. Es una herramienta indispensable

Más detalles

ASIGNATURA: Ingeniería de software II DOCENTE: Licda.Carla Milagro López Vásquez RESPONSABLE: Rodolfo Alberto Palma Ramos CARRERA:

ASIGNATURA: Ingeniería de software II DOCENTE: Licda.Carla Milagro López Vásquez RESPONSABLE: Rodolfo Alberto Palma Ramos CARRERA: UNIDAD 04: PATRONES DE DISEÑO WEB. ASIGNATURA: Ingeniería de software II DOCENTE: Licda.Carla Milagro López Vásquez RESPONSABLE: Rodolfo Alberto Palma Ramos CARRERA: Técnico en Ingeniería en Sistemas y

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Diagramas de Actividad 2 Cuatrimestre 1998 1. INTRODUCCIÓN 1 2. DIAGRAMA DE ACTIVIDAD 1 2.1. SEMÁNTICA 1 2.2. NOTACIÓN 1 2.3. EJEMPLO 2 3. ACCIÓN 3 3.1. SEMÁNTICA 3 3.2. NOTACIÓN

Más detalles

Manual Impress Impress Impress Impress Impress Draw Impress Impress

Manual Impress Impress Impress Impress Impress Draw Impress Impress Manual Impress Se puede definir Impress como una aplicación dirigida fundamentalmente a servir de apoyo en presentaciones o exposiciones de los más diversos temas, proyectando una serie de diapositivas

Más detalles

POLIMORFISMO "una interfaz, múltiples métodos".

POLIMORFISMO una interfaz, múltiples métodos. "una interfaz, múltiples métodos". 20/02/2007 Polimorfismo 2 Indice Definición y caracteristicas Objetivos. SOBRRESCRITURA-SOBRECARGA SOBRECARGA Clases y métodos abstractos INTERFACES (herencia múltiple)

Más detalles

UTILIZACIÓN DE UNA CUENTA DE CORREO ELECTRÓNICO (NUEVO) Acceso al correo electrónico

UTILIZACIÓN DE UNA CUENTA DE CORREO ELECTRÓNICO (NUEVO) Acceso al correo electrónico Acceso al correo electrónico Pasamos ahora a lo que sería usar la cuenta de correo que nos hicimos en la clase anterior. Lo primero que hacemos es entrar en la página web de Yahoo y localizar el icono

Más detalles

Introducción a la Programación de Videojuegos y Gráficos

Introducción a la Programación de Videojuegos y Gráficos Introducción a la Programación de Videojuegos y Gráficos GRADO EN INGENIERÍA INFORMÁTICA CURSO 2012/2013 T2: ARQUITECTURA Y LÓGICA DE VIDEOJUEGO 2.1. Ingeniería del software aplicada a videojuegos (paradigmas

Más detalles

Patrones de diseño. Patrón básico Handler. Técnicas de Programación - Curso 2008/09 (Esther Guerra Sánchez)

Patrones de diseño. Patrón básico Handler. Técnicas de Programación - Curso 2008/09 (Esther Guerra Sánchez) Patrones de diseño Patrón básico Handler Técnicas de Programación - Curso 2008/09 (Esther Guerra Sánchez) Patrones de diseño Introducción Objetivos: Diseño específico para el problema, pero general para

Más detalles

Microsoft Excel 2003. Unidad 6. La Hoja de Cálculo

Microsoft Excel 2003. Unidad 6. La Hoja de Cálculo Microsoft Excel 2003 Unidad 6. La Hoja de Cálculo Las hojas de cálculo son aplicaciones informáticas que se suelen incluir con frecuencia dentro de conjuntos de programas más amplios destinados normalmente

Más detalles

Curso: FT433 - Introducción a la virtualización con VirtualBox

Curso: FT433 - Introducción a la virtualización con VirtualBox forumtecnico.com Curso: FT433 - Introducción a la virtualización con VirtualBox Configuración de red Uno de los aspectos de la virtualización con más número de opciones es la configuración de red. Recordemos

Más detalles

Organización como función administrativa Resumen para Administración y Gestión Profesor: Gonzalo V.

Organización como función administrativa Resumen para Administración y Gestión Profesor: Gonzalo V. Organización como función administrativa Introducción: Organización rganización como función administrativa En las organizaciones que se caracterizan por estar orientadas al éxito, a la eficiencia y al

Más detalles

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño El proceso de diseño para una base de datos consta básicamente de 7 pasos, los cuáles se describen en la siguiente imagen.

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para

Más detalles

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3

Más detalles

1 Vista de Casos de Uso

1 Vista de Casos de Uso Vista de Casos de Uso Esta vista describe el proceso de negocio más significativo y el modelo del dominio. Presenta los actores y los casos de uso para el sistema. Es decir que esta vista presenta la percepción

Más detalles

Manual de usuario para Android de la aplicación PORTAFIRMAS MÓVIL

Manual de usuario para Android de la aplicación PORTAFIRMAS MÓVIL Manual de usuario para Android de la aplicación PORTAFIRMAS MÓVIL Índice 1 Introducción... 5 1.1 Perfil de la aplicación... 5 1.2 Requisitos técnicos... 5 2 Manual de usuario... 7 2.1 Instalación del certificado...

Más detalles

Haciendolo realidad ENTRENAMIENTO DE PADRES EN EL MANEJO

Haciendolo realidad ENTRENAMIENTO DE PADRES EN EL MANEJO Haciendolo realidad ENTRENAMIENTO DE PADRES EN EL MANEJO DE LA CONDUCTA SECCIÓN 1 Introducción...1 El Resultado Esperado por el Entrenamiento...2 SECCIÓN 2 Que Es Lo Que Hay en El Programa?...4 SECCIÓN

Más detalles

Introducción a los Tipos Abstractos de Datos

Introducción a los Tipos Abstractos de Datos Página 1 de 8 Introducción a los Tipos Abstractos de Datos Introducción: Concepto de abstracción Abstracción funcional y abstracción de datos Construcción de tipos abstractos de datos Especificación de

Más detalles

Base de datos relacional

Base de datos relacional Base de datos relacional Una base de datos relacional es una base de datos que cumple con el modelo relacional, el cual es el modelo más utilizado en la actualidad para modelar problemas reales y administrar

Más detalles

Patrones de diseño. Programación III.I.T.I. de Sistemas. Contenidos. Información sobre patrones de diseño. Motivación.

Patrones de diseño. Programación III.I.T.I. de Sistemas. Contenidos. Información sobre patrones de diseño. Motivación. Departamento de Informática Universidad de Valladolid Programación III.I.T.I. de Sistemas Patrones 1 Contenidos Programación III.I.T.I. de Sistemas Patrones de diseño Patrones de diseño Introducción Conceptos

Más detalles

A. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo OCW 2013

A. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo OCW 2013 3.3: Realización de diagramas de secuencia: capas software y patrones GRASP A. Goñi, J. Ibáñez, J. Iturrioz, J.A. Vadillo OCW 2013 3.3.- Cómo realizar los diagramas de 30 secuencia a partir de los flujos

Más detalles

Decorador y Prototype

Decorador y Prototype Ampliación de Programación Orientada a Objetos Decorador y Prototype Javier Abrines Vives Juan Romero Benítez Patrón decorador Qu Qué es? Es un patrón estructural Describe como los objetos y las clases

Más detalles

MANUAL COPIAS DE SEGURIDAD

MANUAL COPIAS DE SEGURIDAD MANUAL COPIAS DE SEGURIDAD Índice de contenido Ventajas del nuevo sistema de copia de seguridad...2 Actualización de la configuración...2 Pantalla de configuración...3 Configuración de las rutas...4 Carpeta

Más detalles

Pilares de la Orientación a Objetos

Pilares de la Orientación a Objetos Pilares de la Orientación a Objetos Pilares de la Orientación a Objetos Abstracción Relaciones Herencia Encapsulamiento Abstracción La Abstracción es la propiedad que permite seleccionar las características

Más detalles

Yalù Galicia Hernàndez. Yalú Galicia Hdez. (FCC/BUAP)

Yalù Galicia Hernàndez. Yalú Galicia Hdez. (FCC/BUAP) Yalù Galicia Hernàndez Yalú Galicia Hdez. (FCC/BUAP) 1 Introducción Qué es la Programación Orientada a Objetos? Conceptos básicos Abstracción Jerarquía Encapsulación Objeto Clase Herencia Polimorfismo

Más detalles

Universidad Católica del Maule. Fundamentos de Computación Especificación de tipos de datos ESPECIFICACIÓN ALGEBRAICA DE TIPOS DE DATOS

Universidad Católica del Maule. Fundamentos de Computación Especificación de tipos de datos ESPECIFICACIÓN ALGEBRAICA DE TIPOS DE DATOS Especificación algebraica ESPECIFICACIÓN ALGEBRAICA DE TIPOS DE DATOS Un tipo abstracto de datos se determina por las operaciones asociadas, incluyendo constantes que se consideran como operaciones sin

Más detalles

Estilos de Arquitectura y. Patrones de Diseño Arquitectónico. Patrones de Arquitectura

Estilos de Arquitectura y. Patrones de Diseño Arquitectónico. Patrones de Arquitectura Estilos de Arquitectura y Patrones de Diseño Arquitectónico Gastón Mousqués - AR 1 Patrones de Arquitectura Gastón Mousqués - AR 2 Principales Categorías de Patrones (Software) Patrones de Análisis Expresan

Más detalles

INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA UNIDAD CULHUACÁN INTEGRANTES

INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA UNIDAD CULHUACÁN INTEGRANTES INSTITUTO POLITÉCNICO NACIONAL ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA UNIDAD CULHUACÁN INTEGRANTES CÁRDENAS ESPINOSA CÉSAR OCTAVIO racsec_05@hotmail.com Boleta: 2009350122 CASTILLO GUTIÉRREZ

Más detalles

INTRODUCCIÓN A LOS SISTEMAS GESTORES DE BASE DE DATOS

INTRODUCCIÓN A LOS SISTEMAS GESTORES DE BASE DE DATOS INTRODUCCIÓN A LOS SISTEMAS GESTORES DE BASE DE DATOS AUTORÍA JOSEFA PÉREZ DOMÍNGUEZ TEMÁTICA NUEVAS TECNOLOGIAS ETAPA CICLOS FORMATIVOS DE GRADO SUPERIOR DE INFORMÁTICA Resumen En esta publicación se

Más detalles

CAPÍTULO I. Sistemas de Control Distribuido (SCD).

CAPÍTULO I. Sistemas de Control Distribuido (SCD). 1.1 Sistemas de Control. Un sistema es un ente cuya función es la de recibir acciones externas llamadas variables de entrada que a su vez provocan una o varias reacciones como respuesta llamadas variables

Más detalles

Trabajo Semanal Alternativo

Trabajo Semanal Alternativo Trabajo Semanal Alternativo 1. Qué es trabajo semanal alternativo? SUS DERECHOS LEGALES En una semana laboral normal, si usted trabaja más de ocho horas diarias, su empleador está obligado a pagarle tiempo

Más detalles

Depto de Cs e Ing. de la Computación Universidad Nacional del Sur

Depto de Cs e Ing. de la Computación Universidad Nacional del Sur Click to add title Mejorando los tiempos de desarrollo Frameworks Diego C. Martínez - DCIC-UNS 2 Patrones de Diseño, según GoF Los patrones de diseño son básicamente descripciones de objetos que se comunican

Más detalles

SOLUCION PARCIAL TASK SCHEDULER. Task Scheduler

SOLUCION PARCIAL TASK SCHEDULER. Task Scheduler Task Scheduler Se necesita modelar una aplicación que permita definir tareas y ejecutarlas en forma programada. Las tareas pueden ser: La ejecución de programa cualquiera o comando del sistema operativo,

Más detalles

Introduccion al Lenguaje C. Omar Andrés Zapata Mesa Grupo de Fenomenología de Interacciones Fundamentales, (Gfif) Universidad de Antioquia

Introduccion al Lenguaje C. Omar Andrés Zapata Mesa Grupo de Fenomenología de Interacciones Fundamentales, (Gfif) Universidad de Antioquia Introduccion al Lenguaje C Omar Andrés Zapata Mesa Grupo de Fenomenología de Interacciones Fundamentales, (Gfif) Universidad de Antioquia Introducción C es un lenguaje de programación creado en 1972 por

Más detalles

Colección de Tesis Digitales Universidad de las Américas Puebla. Morales Salcedo, Raúl

Colección de Tesis Digitales Universidad de las Américas Puebla. Morales Salcedo, Raúl 1 Colección de Tesis Digitales Universidad de las Américas Puebla Morales Salcedo, Raúl En este último capitulo se hace un recuento de los logros alcanzados durante la elaboración de este proyecto de tesis,

Más detalles

MATERIAL 2 EXCEL 2007

MATERIAL 2 EXCEL 2007 INTRODUCCIÓN A EXCEL 2007 MATERIAL 2 EXCEL 2007 Excel 2007 es una planilla de cálculo, un programa que permite manejar datos de diferente tipo, realizar cálculos, hacer gráficos y tablas; una herramienta

Más detalles