Lectura 1 - Paradigma OO

Mdulo 1
Unidad 1
Lectura 1
Materia: Paradigma OO, Introduccin a java y Software Patterns Profesor: Adriana Prez
1- Paradigma Orientado a Objetos

En esta Unidad se presentar el Paradigma Orientado a Objetos reconociendo sus elementos y definiciones cientficas para luego aplicarlo al modelado y a la programacin orientada a objetos en lenguaje JAVA.
El avance tecnolgico de las ltimas dcadas unido a la globalizacin y el dinamismo del mercado laboral provocaron que las empresas e instituciones necesitaran disear e informatizar sus procesos, tanto los administrativos, como los contables, de produccin, de servicio o cualquier otra tarea que se desarrollara en su interior. Era fundamental contar con la informacin lo antes posible para la toma de decisiones y ser competitivos. Requirieron de sistemas informticos cada vez ms complejos. Esta complejidad estaba dada por la cantidad de requerimientos que deban contemplar y solucionar de forma eficiente. Los proyectos de software no respondan a esta exigencia, ya que normalmente los proyectos se entregaban fuera de tiempo, lo que significaba que los requerimientos iniciales haban cambiado llevndolos a un doble problema: el cliente no contaba con la solucin en tiempo y forma y las empresas de software absorban las consecuencias de no cumplir con lo pactado con el cliente, lo que redundaba en costos excesivos en la produccin del producto. Esta situacin agravada deriv en la crisis del software". La industria del software tiene por objetivo crear programas y sistemas corporativos de forma eficiente, o sea en el menor tiempo y al menor costo, que den la solucin que el cliente espera, que sean confiables, estables, que manejen mayor complejidad y capaces de crecer, atendiendo los cambios de requerimientos. Para lograrlo hay que dejar el arte de programar para poner en prctica la Ingeniera de Software y el proceso de produccin del mismo, todo esto implica disear y crear un software de calidad. Atendiendo estos nuevos escenarios era necesario revisar la forma de trabajo, entre la que se encuentra la programacin como tarea central, lo que implic realizar una serie de preguntas buscando la respuesta que permita alcanzar el objetivo propuesto por las empresas de software. Qu tcnicas, qu herramientas, qu lenguajes, qu tipo de programacin se
Materia: Paradigma OO, Introduccin a java y Software Patterns Profesora: Adriana Prez | 2
estaba utilizando, qu paradigma? Estbamos frente a una Programacin estructurada" que no daba respuesta a las necesidades del momento. Era tiempo entonces de plantear un cambio de Paradigma". El concepto de paradigma procede del griego paradeigma, que significa ejemplo o modelo. A partir de los 60, comenz a utilizarse el trmino Paradigma para definir a un modelo o patrn en cualquier disciplina cientfica o contexto epistemolgico. El filsofo y cientfico estadounidense Thomas Kuhn fue quien actualiz el trmino y le dio el significado contemporneo, refirindose al conjunto de prcticas que definen una disciplina cientfica durante un periodo especfico de tiempo. Se dice que cuando un paradigma ya no puede satisfacer las necesidades de una ciencia, es sucedido por otro. Este cambio de paradigma no solo se da en la ciencia formal sino en la aplicacin de los conceptos y definiciones a la resolucin de problemas reales. Este es el caso de la industria del software con relacin al dinamismo de cambio observados en las empresas, ante la necesidad de informatizar sus procesos y que el sistema de informacin implementado sea capaz de actualizarse rpidamente respondiendo a las necesidades del negocio de manera ms eficiente, contemplando costo, tiempo y calidad del producto. Un cambio de paradigma implica un profundo cambio de mentalidad, de los valores que la conforman. Las variantes son: la velocidad y la profundidad del cambio. Con respecto a los paradigmas hay que tener en cuenta 3 caractersticas principales, como son: 1- El efecto Paradigma, es el fenmeno que se presenta como lo que es bueno para uno, puede no ser para otro, presentando conflictos en el yo pienso que es correcto. 2- El retorno a cero, cuando un paradigma cambia todo vuelve a cero para comenzar de nuevo. 3- La parlisis paradigmal, genera una desestructuracin que hace creer que es imposible crear cambios. En la historia de la construccin del software y los lenguajes de programacin encontramos distintos paradigmas. Recordemos que un paradigma de programacin representa un enfoque particular para la construccin del mismo. Cada uno presenta ventajas y desventajas, relacionadas con situaciones que tienen que abordar y as puede ser que un paradigma resulte ms apropiado que otro. Repasemos los ltimos Paradigmas en Programacin: Paradigma de Programacin Estructurada, se tienen en cuenta las estructuras lgicas de programacin, las estructuras de datos y las estructuras de los programas. En este paradigma se da auge a las "tcnicas de diseo de algoritmos", utilizando pseudocdigos,
diagramas de llaves, diagramas de flujo, entre otros. Todas estas tcnicas plantean que un algoritmo no se obtiene al primer intento, se deben hacer varias aproximaciones a travs del refinamiento del algoritmo. La mayora de los lenguajes son prosedurales, tales como C, VisualC, Basic, VisualBasic, Pascal y Cobol, entre otros. Paradigma de Programacin Orientada a Eventos, tanto la estructura como la ejecucin de los programas van determinados por los sucesos que ocurran en el sistema o que ellos mismos provoquen. Los sistemas pasan la mayor parte del tiempo esperando las acciones del usuario (eventos) y respondiendo a ellas. Los lenguajes visuales son los ms utilizados. Paradigma de Programacin Orientado a Objetos. Se centra en objetos, su estado, comportamientos y colaboraciones. Utiliza un lenguaje completamente orientado a objetos, como es Smalltalk. En la actualidad, Java y .Net son considerados orientados a objetos.
Si bien puede seleccionarse un paradigma y respetar la forma pura de programar, en la prctica es habitual que se mezclen, dando lugar a la programacin multiparadigma. No obstante, mezclar los paradigmas en la programacin no siempre es aconsejable, ya que puede hacer una mala prctica del paradigma.
Eventos
Simula Smalltalk
Componentes
1.980
1.1 Conceptos de OO
Ahora bien otro concepto importante que deberemos observar a lo largo del curso es el de OBJETO, un objeto es una representacin de una entidad del mundo real, la cual es modelada para ser usada en el mbito del negocio que trataremos de analizar y a posterior ofrecer una solucin a travs de la Ingeniera del Software. En base a estos dos conceptos fundamentales podemos decir que el Paradigma orientado a objetos presenta una serie de mtodos, herramientas y procedimientos para que al aplicarlos podamos modelar un problema del mundo real a travs de una serie de abstracciones o entidades de este que se comunicaran entre s para lograr el resultado ms ptimo del problema. Qu es el modelado? La Real Academia Espaola presenta varios conceptos de modelar, entre los que podemos destacar: Configurar o conformar algo no material, lo cual puede ser una abstraccin o una forma de ver o interpretar la realidad. Ajustarse a un modelo, lo que nos lleva a buscar la definicin de modelo. En la definicin de modelo encontramos una variedad interesante, donde cada una puede asociarse a una o ms disciplinas, entre las que podemos destacar: Esquema terico, generalmente en forma matemtica, de un sistema o de una realidad compleja, como la evolucin econmica de un pas, que se elabora para facilitar su comprensin y el estudio de su comportamiento. Representacin en pequeo de alguna cosa. Tratando de aplicar estas definiciones al concepto de Paradigma Orientado a Objetos y la relacin que encontramos con los sistemas de software, trataremos entonces realizar las interpretaciones con relacin a los negocios. Un modelo es un modo o forma inteligente de entender, organizar o explicar algo que sucede, o quizs creemos que puede suceder en el mundo. Son modos o pautas que adoptamos para relacionarnos con algo del todo en el que nosotros tambin estamos incluidos. Modelar entonces, es el proceso de crear modelos o modos para hacer o entender algo. Mnimamente este modelo se construye desde dos miradas, quien lo expresa y quien lo interpreta, ambos condicionados por sus propios modelos y esquemas, con lo cual llegar a un modelo que sea interpretado unvocamente por todos es una tarea ardua pero no imposible. El modelo de negocio de una empresa es una representacin simplificada de la lgica de negocio. Describe lo que un negocio ofrece a sus clientes, cmo llega a ellos, cmo se relaciona con ellos, cmo se relacionan internamente y cmo realizan sus tareas. En este punto se establece como
fundamental identificar la relacin de las personas con las tareas que realiza y cmo se agrupan dichas tareas para formar cada proceso de negocio. Visiones del Negocio Todo negocio debe tener una visin general que es necesario que conozcamos para poder orientarnos a ella, veamos algunos conceptos necesarios para modelar un negocio: Visin General. La visin general del negocio es una vista que describe la estructura de metas para la compaa y ensea los problemas que deben ser resueltos para alcanzar esas metas. Procesos. Representa las actividades y el valor creado por el negocio y muestra la interaccin entre los procesos y los recursos para alcanzar la meta de cada proceso. Esta vista tambin establece la interaccin existente entre diferentes procesos, algunos fundamentales y otros de apoyo. Estructura. La estructura entre los recursos del negocio, tal como la organizacin del negocio o la estructura de los productos creados. Comportamiento. El comportamiento individual de cada recurso y proceso importante en el modelo de negocio, lo que muestra cmo se comporta o acta el negocio ante distintas situaciones contempladas en sus procesos. Qu funciones realizan los modelos? Describen exactamente cules son las necesidades de negocio. Facilitan la discusin Evitan errores. Los modelos permiten especificar la estructura o el comportamiento de un sistema. Los modelos proporcionan plantillas que sirven de gua en la construccin de un programa.
1.1.1 Identificacin de los elementos de un modelo OO.

El modelado dentro del Paradigma Orientado a Objetos El Paradigma Orientado a Objetos es una nueva manera de ver y expresar el mundo, de pensar acerca de los problemas para encontrar una representacin adecuada y modelarlo. El modelo es organizado como una coleccin de unidades atmicas (los OBJETOS) constituidas por datos y funciones, que interactan entre s.
El Paradigma OO se basa en el concepto de objeto. Los Sistemas de Software realizan ciertas acciones sobre los objetos de cierto tipo. Para obtener un Sistema Reutilizable, es mejor basar su estructura en tipos de objetos y no en las acciones. [Construccin De Software Orientado A Objetos, de Bertrand Meyer - Prentice-Hall - 1998, pg. vi]
La Orientacin a Objetos describe o modela el Sistema como una cierta cantidad de Objetos relacionados que interactan.
1.1.2 Clase, objeto, atributos, mtodos

Qu son las clases y los objetos? A nivel de conceptual podemos definir: Una Clase: o Modela una abstraccin de los objetos. o Define los atributos y los comportamientos de los objetos. o Es el plano que define un objeto. Un Objeto: o Est moldeado en funcin de la clase. o Es una instancia nica de una clase. o Retiene la estructura y el comportamiento de una clase. Una clase es un modelo de abstraccin confeccionado a partir de objetos del mundo real. Una clase define las propiedades y el comportamiento de un conjunto de objetos. Una clase constituye una categora de objetos y acta como plano para la creacin de ese tipo de objeto.
Clase: es una especificacin de los atributos y operaciones para un tipo de objeto, es una plantilla para estos objetos definido.
Una clase es un conjunto de objetos que comparten una estructura y comportamiento comn. Las clases son definiciones estticas.
Un objeto es aquello que tiene estado (propiedades ms valores) y comportamiento (acciones y reacciones a mensajes). Es algo tangible, que se puede ver o tocar, o algo a lo que se puede aludir o sobre lo que se puede reflexionar. La estructura y comportamiento de objetos similares estn definidos en su clase comn; los trminos instancia y objeto son intercambiables. La diferencia entre un objeto y una clase radica fundamentalmente en que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstraccin, la esencia de un objeto, tal como son.
Los objetos son entidades dinmicas, se constituyen en instancias concretas de una clase.
Veamos un ejemplo de objetos y clases:
Animal
La Clase Animal contiene los objetos que son animales. Platero es un objeto concreto de la clase Animal.
Qu debemos saber sobre los objetos? Los atributos de un objeto mantienen su estado: Los objetos conocen su estado actual. Un atributo es un fragmento de informacin. o Los valores de los atributos indican el estado de los objetos
Por ejemplo: Objeto: Animal Atributo: cantidad de patas
Todos los datos necesarios para un sistema OO se deben ubicar en los atributos de los objetos existentes. La cantidad de atributos que tenga un objeto puede ser muchos, pocos o ninguno, depende por completo de las operaciones que vaya a realizar el objeto. Los atributos que se definen en un objeto determinan su estructura interna. En un momento del tiempo, los valores contenidos en los atributos representan el estado actual del objeto, el cual cambia en funcin del cambio de los valores de sus atributos. Normalmente, los atributos de un objeto se deducen despus de haber decidido las operaciones que va a realizar el objeto, o sea que cuando conozca lo que debe hacer el objeto estar en condiciones de definir los atributos necesarios para llevar a cabo esas acciones.
Los objetos tienen un comportamiento: Un objeto existe para proporcionar un comportamiento (funcionalidad) al sistema. Cada comportamiento distinto se denomina operacin.
Por ejemplo. Objeto: Animal Comportamiento: comer
El objetivo principal de los objetos es que realicen operaciones en el sistema en el que existen. Para cada objeto es necesario realizar una serie de preguntas: Qu es lo hace este objeto?, es decir, qu servicios proporciona este objeto a los dems objetos del sistema? Identificando solo las operaciones relevantes del objeto. Cmo se van a modificar los valores de los atributos del objeto? Con esta pregunta se podr definir operaciones para mantener los detalles internos del objeto. sta es una visin antropomrfica ya que se ve al objeto con cierta capacidad para hacer cosas, porque en el Paradigma de Objetos los que saben hacer algo son ellos. Cuando se trata de resolver una situacin, se deben identificar los objetos como si fueran cosas vivas. Al principio se piensa en cosas bastante concretas como un monitor, computadora, cajero automtico; pero luego se puede pensar en cosas ms abstractas, desde una regla de negocio hasta un algoritmo (pensar en el algoritmo como un objeto al que le puedo pedir que se active y haga algo).
La idea de ver a los objetos como entidades con comportamiento es la idea central del Paradigma de Objetos y la Programacin Orientada a Objetos.
El comportamiento est expresado por el conjunto de mensajes que el objeto es capaz de responder.
Los atributos o propiedades definen los datos o informacin del objeto, permitiendo modificar o consultar su estado, mientras que los mtodos son las rutinas que definen el comportamiento del objeto.
Los objetos se modelan como Abstracciones: Un objeto se modela como una representacin abstracta de un objeto del mundo real. Slo debe modelar los atributos y las operaciones que sean relevantes en el contexto del problema.
Veamos un ejemplo a continuacin: Objeto: Persona Atributos: DNI, nombre, apellido, sexo, fecha de nacimiento, (no se debe modelar el atributo color de ojos si no es relevante). Mtodos: comer, dormir, saltar, caminar, conversar, (no se debe modelar el mtodo servir comida) Objeto: Mesa Atributos: alto, tipo, material, color. Mtodo: sostener
Definicin de composicin de objetos: Los objetos pueden estar compuestos de otros objetos. Los objetos pueden formar parte de otros objetos. Esta relacin entre objetos que estn compuestos por otros objetos se conoce como agregacin. Cuando un objeto se divide en otros objetos de un nivel inferior es porque son necesarios para reutilizarlos.
Por ejemplo, el objeto PC est compuesto por otros objetos como son el teclado, el mouse, el monitor el gabinete. El gabinete est compuesto por la placa madre, el disco rgido, la lectora de CD/DVD, entre otros. A su vez cada uno de ellos es un objeto en s que puede estar compuesto por otros objetos.
Monitor
Gabinete Mouse Teclado
El objeto PC est compuesto por los objetos monitor, gabinete, mouse, teclado, donde cada uno es un objeto con sus atributos. Es necesario definir una clase para cada objeto y luego relacionarlas.
PC
Cmo colaboran los objetos entre s? Cuando se disean las clases se estn identificando los objetos que intervienen en el Sistema, en el Diagrama de clases no estn aisladas, sino que se relacionan de alguna forma. Algunos objetos funcionan juntos para realizar una tarea, son los objetos de colaboracin. Un mensaje es una solicitud para llevar a cabo una accin o tarea o parte de una funcionalidad. Veamos un ejemplo: Comnmente utilizamos el control remoto para prender el Televisor, para ello el objeto controlRemoto le enva un mensaje al objeto televisor para que encienda, si este no lo hace es porque no funciona el Televisor, ya que encender es un comportamiento del televisor, no del control remoto. - El emisor (control remoto) llama a un mtodo del receptor. - El receptor ejecuta el especificado. (televisor) mtodo
Agregacin: es una relacin formado por o compuesto por. Composicin: es un agregado fuertemente acoplado que responde a la relacin colabora con.
El Paradigma Orientado a Objetos separa estrictamente la nocin sobre qu se va a hacer, del cmo se va a hacer. El qu se describe como un conjunto de mtodos. Como el contrato entre el diseador de la clase y el programador que la usa, puesto que dice lo que ocurre cuando se invocan ciertos mtodos sobre el objeto. La colaboracin se da cuando los objetos se asocian y se comunican a travs del envo de mensajes desde un objeto a otro, o sea, el objeto emisor conoce al objeto receptor. El cmo de un objeto viene dado por su clase, que define la implementacin de los mtodos que soporta el objeto. Recuerde que cada objeto es una instancia de una clase".
Qu es un mensaje? Un mensaje es una solicitud para llevar a cabo una parte de la funcionalidad necesaria para realizar una tarea. La asociacin entre objetos se obtiene dinmicamente a travs de una referencia, dando lugar a un enlace o relacin entre objetos. Un mensaje es codificado en un lenguaje de programacin para que pueda realizar una tarea, si es convocado por otro objeto es porque necesita de su colaboracin que es parte del comportamiento del objeto convocado. Cuando se enva un mensaje, la parte especfica de cdigo que se ejecuta depende de la clase de objeto receptor.
1.1.3 Encapsulamiento, herencia, polimorfismo

Estado interno/Conocimiento Los objetos pueden tener un estado interno tal que cuando hablamos de implementacin nos podemos referir a que estn formados por variables (variables de estado), y que capturan lo que ese objeto conoce (el conocimiento del objeto), o sea sus atributos. En el enfoque OO las propiedades del objeto son claves. Los principios del modelo OO son: Abstraccin, Encapsulacin, Herencia Polimorfismo
Abstraccin. Es una descripcin simplificada o especificacin de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros. Encapsulacin. En el proceso de ocultar todos los detalles de un objeto, operaciones y la estructura interna que no contribuyen a sus caractersticas esenciales, detrs de una interfaz
Ocultacin de detalles Vistas: la modularidad y ocultamiento de
datos que permite deslindar los cambios de la representacin interna del mundo exterior se basan en dos vistas para una clase-objeto.
La interfaz del objeto (conjunto de mtodos) que se ubica en una clase es normalmente pblica.
Independencia: los atributos del objeto que se declaran en una clase son normalmente privados. Una de las principales ventajas de la Programacin OO es el concepto de encapsulacin, conocido tambin como proteccin de datos. Esto significa que slo se pueden modificar los datos de un objeto accediendo a travs de sus mtodos u operaciones (interfaz del objeto). Con la encapsulacin, el desarrollador de una aplicacin puede utilizar un objeto ignorando los detalles de nivel inferior de cmo est estructurado ni como funciona internamente. Nunca se permite modificar directamente desde la aplicacin principal. Como el objeto maneja datos, la funcionalidad est sujeta a ellos. Por ejemplo, en la vida cotidiana utilizamos objetos como microondas televisores o computadoras sin conocer ni entender el funcionamiento interno. En la programacin una ventaja de usar objetos es que podemos modificar su funcionalidad, aadir mejoras o corregir errores sin necesidad de cambiar su interfaz, convirtindose en una ventaja, ya que en caso contrario un proyecto estara sujeto a un mayor nmero de fallos y los cambios seran ms costosos. Por ejemplo, analicemos el objeto automvil. Sus atributos pueden ser: marca patente modelo Sus mtodos son: arrancar() frenar() doblar() parar() Los atributos son privados o protegidos, o sea, se pueden acceder desde adentro de la misma clase, mientras que los mtodos son pblicos, es decir, se pueden acceder desde otras clases. Para que pueda accederse a estos atributos desde otras clases, se definen mtodos pblicos para leer sus valores o para insertarlos. La clase Automovil debera contener adems los mtodos pblicos que permitan acceder a los atributos para manipular sus valores, estos mtodos bsicos deben permitir leer y asignar dichos valores.
La representacin de la clase Automovil sera:
Herencia de Clases: es una relacin entre clases que permite que se puedan definir nuevas clases basadas en otras existentes, lo cual facilita reutilizar cdigos previamente desarrollados. Puede haber aspectos comunes entre clases distintas, define las propiedades comunes de una superclase Si una clase deriva de otra, hereda todas sus variables y mtodos. La clase derivada puede aadir nuevas variables y mtodos, y/o redefinir las variables y mtodos heredados. Permite reusar cdigo-conocimiento-funcionalidad en una clase-padre que hereda sus atributos y mtodos a sus clases-hijas, subclases o clasestipos derivados. Por ejemplo, se puede redefinir la clase Automvil teniendo en cuenta que es un Vehculo, tal como es la moto y el camin, con lo cual es conveniente disear la relacin de jerarqua entre ellas.
Los atributos y mtodos comunes se ubican en la superclase Vehiculo, mientras que las subclases los heredan y agregan su propio estado y comportamiento.
Nota: la herencia responde a es un tipo de, en nuestro caso, Automovil es un Vehculo, Moto es un Vehiculo, Camin es un Vehiculo.
Si un objeto de la subclase no tiene todas las operaciones de la superclase, no debe ser una subclase. La clase Vehiculo se define como abstracta con lo cual no puede ser instanciada y si es necesario un vehculo de un tipo distinto es necesario declarar una nueva clase, con lo cual se mejora la productividad y el diseo.
Polimorfismo: es el grado mximo de excelencia de calidad en POO, permite mltiples implementaciones de mtodos, dependiendo del tipo de objeto que se indica al invocar el mtodo correspondiente, lo que posibilita, entonces, que el mismo mensaje enviado a diferentes objetos resulte en acciones dependientes del objeto que recibe el mensaje.
El polimorfismo hace referencia a: Muchas formas para una misma operacin, lo que significa que se puede definir la misma operacin para clases diferentes y que cada clase puede implementar la operacin de una forma diferente, o sea que tenga distinta forma de ejecutar la accin. Se puede solicitar una operacin con el mismo significado (nombre) a diferentes objetos, donde cada uno de ellos lo llevar a cabo de una manera distinta, siendo nica.
Podemos decir que facilita la adicin de capacidades nuevas a un sistema, como lo son el reuso y la extensin, que proporciona cdigo genrico compuesto por un mensaje polimrfico. Veamos un ejemplo. Supongamos que tenemos distintas clases con un mismo mtodo "encender ()", como son, Lmpara, PC y Microonda.
El mismo nombre de mtodo se encuentra en cada una de las clases pero, dependiendo del tipo de objeto que lo convoque, ser el mtodo que se ejecute. Cada uno tendr su funcionalidad. Veamos un ejemplo con herencia, encapsulamiento y polimorfismo. Las clases Lmpara, PC y Microonda pueden ser de tipo Artefacto elctrico, por lo que pueden heredar de la superclase. Grficamente los podemos representar de la siguiente forma:
Los mtodos polimrficos deben tener el mismo comportamiento lgico y la misma firma por lo que su nombre, atributos recibidos y el valor que devuelve deben ser consistentes.
El mtodo encender() es abstracto en la superclase y se redefine en cada subclase haciendo concreta su funcionalidad, o sea determinando el cmo.
1.2 Anlisis y Diseo OO repaso de conceptos e UML

Es muy posible que usted est utilizando UML en su desempeo diario laboral, lo est estudiando o ya lo haya estudiado en su momento, en este texto haremos referencia a aquellos conceptos que consideramos fundamentales para realizar el diseo orientado a objetos y entender las especificaciones que nos lleguen desde los analistas para su futura codificacin, sin profundizar en los conceptos propios del lenguaje. Recuerde que existen tres etapas fundamentales orientadas a objetos: - Anlisis orientado a objetos, comprende el dominio de aplicacin representado por un modelo orientado a objetos que reflejan las entidades y operaciones que se asocian con el problema a resolver. - Diseo orientado a objetos, implementa los requerimientos identificados en un modelo orientado a objetos relacionados con la solucin del problema agregando nuevos objetos para implementar la solucin. - Programacin orientada a objetos, implementa el diseo de software utilizando un lenguaje de programacin orientado a objetos, en nuestro caso Java.
1.2.1 Modelos. Conceptos.

Qu es un modelo y por qu modelamos? Los proyectos de software que se logran terminar con xito tienen algunos aspectos en comn, entre ellos se destaca el uso del modelado. El modelado es una tcnica de Ingeniera probada y bien aceptada en todas sus lneas. Se construyen modelos arquitectnicos de casas, edificios, diques o represas, entre otros, para ayudar a sus usuarios a visualizar el producto final antes que el mismo est construido, ya sea como plano o como maqueta. Tambin es posible elaborar modelos matemticos para analizar los efectos de vientos o terremotos sobre los edificios o represas. Un modelo es una simplificacin de la realidad, proporciona los planos de un sistema.
Estos planos pueden ser generales, que ofrecen una visin global del sistema, como planos detallados. Un buen modelo incluye los elementos que son significativos y omite los que no tienen relevancia. Todo sistema puede ser caracterizado desde diferentes perspectivas, utilizando diferentes modelos. Un modelo puede ser estructural resaltando la organizacin del sistema o puede ser de comportamiento, destacando su dinmica. Recordemos que se construyen modelos para comprender mejor el sistema que estamos desarrollando y obtener los siguientes objetivos: Los modelos ayudan a visualizar cmo es o queremos que sea un sistema. Los modelos permiten especificar la estructura o el comportamiento de un sistema. Los modelos proporcionan plantillas que sirven de gua en la construccin de un programa. Los modelos documentan las decisiones que se han adoptado. Es difcil comprender un sistema complejo en su totalidad, por ello es que construimos modelos, permitiendo poder enfocarnos en un aspecto a la vez logrando que el ser humano pueda entenderlo. Principios bsicos de modelado Como se plantea en el libro (El lenguaje Unificado de Modelado), la experiencia en el uso del modelado sugiere los siguientes cuatro principios bsicos: La eleccin de los modelos a crear tiene mucha influencia sobre cmo se aborda el problema y cmo de da forma a la solucin. (Booch G., 1999, pg. 7 y 8) Es necesario elegir bien los modelos, ya que los modelos adecuados pueden aclarar los problemas de desarrollo ms complejos, brindando una comprensin que difcilmente podramos obtener de otra manera. Tenga en cuenta que un modelo mal realizado no lo llevar al xito del problema. Todo modelo puede ser expresado a distintos niveles de precisin. (Booch G., 1999, pg. 7 y 8)
Los mejores tipos de modelos son aquellos que permiten elegir el grado de detalle teniendo en cuenta quin est viendo el sistema y por qu necesita verlo. Un analista o un usuario final se centrar en qu hace el sistema; un diseador/desarrollador se centrar en el cmo. Tanto unos como otros querrn visualizar un sistema a diferentes niveles de detalle en diferentes momentos. Los mejores modelos son los que estn ligados a la realidad. (Booch G., 1999, pg. 7 y 8)
Todos los modelos simplifican la realidad; lo importante es que esta simplificacin no enmascare ningn detalle importante. No es suficiente confeccionar un nico modelo. Todo sistema no trivial se aborda mejor a travs de un conjunto de modelos casi independientes. (Booch G., 1999, pg. 7 y 8)
Si por ejemplo, se estuviera realizando la construccin de una casa, no hay un nico conjunto de planos que indiquen todos sus detalles sino que se necesitarn planos de planta, de electricidad, de lozas, de agua, entre otros. Lo mismo se aplica para los sistemas de software. Para comprender la arquitectura de tales sistemas se necesitan varias vistas complementarias y entrelazadas. Cuando se habla de modelos casi independientes se refiere a tener modelos que podemos construir y estudiar separadamente pero que estn interrelacionados.
1.2.2 Caractersticas de los Modelos Orientados a Objetos

Los Modelos Orientados a Objetos estn basados en el Paradigma Orientado a Objetos, en ellos el sistema se puede ver (en trminos de percepcin) como una coleccin de objetos que colaboran entre s para obtener un objetivo comn. Las operaciones que modifican el estado de los objetos son sencillas; los objetos se construyen a partir de otros objetos lo que lleva a que los sistemas se puedan construir a partir de componentes probados. Por lo enunciado anteriormente, las tcnicas orientadas a objetos se pueden utilizar como medios para el diseo sencillo de sistemas complejos, esta hace que el diseo del sistema sea esencial para el xito futuro. La orientacin a objetos es muy poderosa cuando se combinan varias tecnologas, donde destacamos como principales las metodologas de Anlisis y Diseo Orientado a Objetos, herramientas CASE (Ingeniera de Software Asistida por Computadora), Generadores de Cdigo, entre otras. El anlisis y diseo orientado a objetos tiene algunas caractersticas importantes: Cambian nuestra forma de pensar sobre los sistemas. Para muchas personas la forma de pensar OO es ms natural. Comenzamos a aprender sobre ellos desde la infancia (por ejemplo, al jugar con una pelota donde reconoce el objeto con sus propiedades y funcionalidad), es as que desde una etapa muy temprana categorizamos los objetos y descubrimos su comportamiento. Los sistemas suelen construirse a partir de objetos ya existentes. Esto lleva a un alto grado de reutilizacin, un menor tiempo de desarrollo, a una disminucin de costos y una mayor confiabilidad del sistema.
La complejidad de los objetos que podemos utilizar sigue en aumento, puesto que nuevos objetos se construyen a partir de otros, que a su vez estn constituidos por otros objetos, y as sucesivamente. Ayuda a explotar la potencia expresiva de los lenguajes de programacin basados en objetos y orientados a objetos.
Elementos del Modelo de Objetos Hay cuatro elementos fundamentales en este modelo: Abstraccin Encapsulamiento Modularidad Jerarqua
Al decir fundamentales se quiere significar que cualquier modelo que carezca de alguno de estos elementos no se considera orientado a objetos. Veamos el concepto de cada uno de los elementos fundamentales desde la mirada del modelo Orientado a objetos.
Abstraccin Como la define Grady Booch, la abstraccin denota las caractersticas esenciales de un objeto distinguindolo de todos los dems tipos de objeto y proporcionando fronteras conceptuales ntidamente.
Como vimos anteriormente una abstraccin se centra en la visin externa de un objeto y sirve para separar el comportamiento esencial de un objeto de su forma de implementacin, tratando de construir abstracciones de entidades que imiten directamente el vocabulario de un determinado dominio de problema. Se puede caracterizar el comportamiento de un objeto considerando los servicios que presta a otros objetos, as como las operaciones que puede realizar sobre otros objetos. Este punto de vista nos lleva a concentrarnos en la visin exterior del objeto, lo que algunos llaman el modelo contractual; la vista exterior de cada objeto define un contrato del que pueden depender otros objetos y que a su vez es llevado a cabo por la vista interior del propio objeto (a menudo en colaboracin con otros objetos). Este contrato abarca las responsabilidades de un objeto, es decir el comportamiento del que se le considera responsable. Por ejemplo, en un banco uno de los servicios ofrecidos es el de Caja de Ahorro. Desde una vista externa una caja de ahorro en un objeto que sabe cul es su nmero de cuenta, a quin pertenece y cul es su saldo (de manera simplificada). Qu es su nmero de cuenta? Un valor numrico de ocho dgitos y su saldo ser un valor que represente el monto de dinero actualmente depositado en ella. Sus responsabilidades sern, entre otras: Conocer su saldo actual Conocer su nmero
Incrementar su saldo por un depsito Disminuir su saldo por una extraccin Conocer quin es su titular Mostrar sus dato Conocer su fecha de cierre
Encapsulamiento La abstraccin y el encapsulamiento son conceptos complementarios: la abstraccin se centra en el comportamiento observable de un objeto, mientras el encapsulamiento se centra en la implementacin que da lugar a este comportamiento. El encapsulamiento, tal como lo planteamos anteriormente, en el diseo consigue la ocultacin de informacin, por el cual se ocultan todos los aspectos de un objeto que no contribuyen a sus caractersticas esenciales. Normalmente lo que se oculta es la estructura de datos de un objeto as como la implementacin o codificacin de sus mtodos. Grady Booch define el encapsulamiento como el proceso de almacenar en un mismo compartimiento los elementos de una abstraccin que constituyen su estructura y su comportamiento; sirve para separar la interfaz contractual de una abstraccin y su implantacin. (Grady Boch, 1996, pg. 54,56) Por ejemplo: cuando a un objeto titular le llega una solicitud de servicio (mensaje) por el cual se le pide mostrar su nombre, ste retornar una cadena de caracteres en la que figuran su apellido, primer nombre y segundo nombre, si lo tuviera. El objeto que hizo la solicitud no sabe si el objeto titular tiene un atributo para nombre y apellido o dos, uno par el apellido y otro para el nombre. Modularidad Como afirma Booch citando a Liskov la modularizacin consiste en dividir un programa en mdulos que pueden compilarse separadamente, pero que tienen conexiones con otros mdulos. (Grady Boch, 1996, pg. 61) En algunos lenguajes las clases y objetos forman la estructura lgica de un sistema; estas abstracciones en mdulos producen la arquitectura fsica del sistema. Especialmente para aplicaciones grandes en las que puede haber varios cientos de clases el uso de mdulos es esencial para ayudar a manejar la complejidad poder abstraer y disear las clases que conforman los mdulos del mismo, es as que se logra ver por partes ms pequeas que interactan entre ellas. Para problemas muy pequeos el desarrollador podra decidir declarar todas las clases en el mismo paquete. Para cualquier situacin que se salga de lo trivial, es mejor solucin agrupar las clases que se relacionan lgicamente en el mismo mdulo.
Jerarqua La jerarqua es una forma de clasificar u ordenar las abstracciones. Frecuentemente un conjunto de abstracciones forma una jerarqua y la identificacin de estas jerarquas en el anlisis y diseo simplifica en gran medida la comprensin del problema. Las dos jerarquas ms importantes son: Su estructura de clases: la jerarqua de clases est dada por la herencia. Su estructura de objetos: la jerarqua de objetos est dada por la agregacin. No desarrollamos aqu estos conceptos porque se vern ms adelante en las secciones Relaciones entre Clases y Relaciones entre Objetos.
1.2.3 Anlisis de Sistemas

El anlisis de sistemas se emplea para analizar, disear e implementar mejoras en el funcionamiento de empresas a travs de sistemas de informacin computarizados. (Kendall Kenneth E. Kendall Julie E, 2005, pag. 7) El rol del analista es el de recabar los requerimientos funcionales y no funcionales del negocio y del sistemas, interpretar las realidades y necesidades de los clientes y usuarios, teniendo en cuenta que ser dinmico e incremental, por lo que no debe descuidar los requerimientos funcionales candidatos a ser implementados en el tiempo de vida del sistema. El anlisis y diseo de procesos de negocio ayuda a la mejora continua y la calidad de servicio al cliente, por lo que los desarrolladores deben tener en cuenta el anlisis y diseo realizado para lograr el objetivo de alcanzar un producto de calidad que cubra las expectativas y necesidades de la empresa. En el ciclo de vida del analista de sistemas es importante que se cumplan 3 etapas: 1- Identificacin de problemas, oportunidades y objetivos 2- Determinacin de los requerimientos de informacin 3- Anlisis de las necesidades del sistema. En este curso no trabajamos los temas de anlisis en profundidad, ya que no es nuestro objetivo, solo los mencionamos para centrarnos en el diseo.
Transicin del anlisis al diseo Las primeras entradas del diseo son las especificaciones del anlisis, tratando de que esta transicin sea lo ms fcil posible, para ello los modelos de requerimientos provistos por los analistas deben ser directamente representables en el diseo. Este primer paso se llama Diseo Preliminar, luego continuar el diseo con sus propios modelos y especificaciones con el fin de preparar el proceso de desarrollo o codificacin y construccin de Bases de datos. Estas etapas de transicin se pueden graficar de la siguiente manera:
Anlisis de Requerimientos
Modelos de Anlisis
Diseo preliminar
Adaptacin a Modelos de diseo
Diseo Detallado
Modelos Diseo de
Codificacin Esta transformacin del diseo preliminar al diseo detallado incluye normalmente las siguientes etapas: Diseo de datos Diseo arquitectnico Diseo procedimental Diseo de interfaz
Estas etapas y los modelos alcanzados tambin dependen de la metodologa que se aplique.
1.2.4 Diseo orientado a objetos

Un diseo orientado a objetos est compuesto de objeto que interactan, manteniendo su estado local dado por sus atributos y poseen un comportamiento que proviene de sus operaciones o mtodos. Recuerde que la presentacin del estado es privada no pudiendo acceder desde afuera del El Diseo detallado es el proceso que realiza el refinamiento obteniendo la documentacin y modelos que entregarn a los desarrolladores de cdigo y a los Administradores de Base de datos.
objeto, contando con mtodos pblicos que permitan acceder a ellos. Las clases es su forma de disear y representar los objetos, por lo que en un sistema orientado a objetos es necesario disear la arquitectura de clase que intervienen estableciendo las comunicaciones de cooperacin que existen entre ellos. En el proceso de diseo orientado a objetos se reconocen varias etapas, estas son: 1- Comprender y definir el contexto y los modos de utilizacin del sistema. 2- Disear la arquitectura del sistema 3- Identificar los objetos principales en el sistema. 4- Desarrollar los modelos de diseo. 5- Especificar las interfaces de los objetos.
Recuerde que el Paradigma orientado a objetos se centra en los objetos y su representacin: Un objeto es una entidad que tiene un estado y un conjunto de operaciones definidas que operan sobre ese estado. El estado se representa como un conjunto de atributos del objeto. Las operaciones asociadas al objeto proveen servicios a otros objetos (clientes) que solicitan estos servicios cuando se requiere llevar a cabo algn clculo. Los objetos se crean conforme a una definicin de clases de objetos. Una definicin de clases sirve como una plantilla para crear objetos. Esta incluye las declaraciones de todos los atributos y operaciones asociados con un objeto de esa clase. (Sommerville, 2005) UML es el lenguaje que se utiliza como estndar para modelar y representar los objetos a travs de clases con sus relaciones. En los sistemas basados en servicios, las comunicaciones de los objetos se implementan directamente como mensajes de texto que intercambian los objetos, identificando el objeto receptor que analiza el mensaje identificando el servicio y sus datos asociados ejecutndolo. Este tipo de comunicacin entre objetos es sncrona, donde el objeto invocador espera a que la peticin del servicio se complete. La comunicacin es asncrona cuando los objetos se implementan como procesos concurrentes o hilos, donde el objeto invocador contina activo mientras se ejecuta el servicio solicitado.
Los objetos concurrentes se pueden implementar de dos formas: 1- Servidores en los cuales el objeto se implementa como un proceso paralelo con mtodos que corresponden a las operaciones definidas de los objetos, donde los mtodos inician su actividad en respuesta a un mensaje externo y se ejecutan en paralelo con los mtodos asociados a otros objetos. Cuando se ha completado la operacin, se suspende el objeto por s mismo y queda a la espera de otras peticiones de servicios. 2- Objetos activos en los cuales el estado de los objetos cambia debido a la ejecucin de operaciones internas, por lo que no se suspende por s mismo. Los servidores son ms tiles en entornos distribuidos donde los objetos invocadores y los invocados se encuentran ubicados en diferentes computadoras, donde el tiempo de respuesta es un factor importante y el diseo del sistema debe contemplar que los objetos que solicitan el servicio no deban esperar demasiado tiempo. En los diferentes modelos de objetos posibles, las clases se pueden organizar mediante la generalizacin o jerarqua de herencias que establece la relacin entre las clases ms generales y las ms especficas, donde stas ltimas concuerdan completamente son la clase general, pero adiciona informacin. Recordemos entonces los tipos de modelos que pueden crearse durante el proceso de anlisis: Modelo de flujo de datos. Modelo de composicin. Modelo arquitectnico. Modelo de clasificacin. Modelo de estmulo-respuesta.
Para el diseo orientado a objetos es necesario tambin tener claro algunos puntos clave sobre el concepto de modelo, estos son: Un modelo es una vista abstracta de un sistema que prescinde de algunos detalles del mismo. Los modelos de contexto muestran cmo el sistema que se est modelando se ubica en un entorno con otros procesos y sistemas. Como modelo de contexto se pueden utilizar los modelos arquitectnicos, los de proceso y los modelos de flujo de datos. Los modelos de flujo de datos pueden utilizarse para modelar el procesamiento de los datos llevado a cabo por un sistema. Los modelos de mquina de estados se utilizan para modelar el comportamiento del sistema en respuesta a eventos internos o externos. Los modelos semnticos de datos describen la estructura de los datos importados y exportados por el sistema. Los modelos de objetos describen las entidades lgicas del sistema y su clasificacin y agregacin, entre los posibles modelos de objetos que pueden desarrollarse se incluyen el modelo de herencia, el de
agregacin y el de comportamiento. Los modelos de secuencia que muestran las interacciones entre actores y objetos en un sistema se utilizan para modelar el comportamiento dinmico. Los mtodos estructurados proporcionan un marco para soportar el desarrollo de modelos del sistema.
Adems se puede implementar el diseo orientado a objetos con los modelos de capas, donde la comunicacin se presenta entre objetos de una misma capa o entre objetos de distintas capas, por ejemplo un objeto de la capa vista (cliente) se comunica con un objeto de la capa web (controlador), el objeto invocado de esta capa se comunica con un objeto de la capa de negocio (capa negocio) o con un objeto del modelo (capa modelo) o con un objeto de base de datos (capa datos). Tambin es posible disear la comunicacin entre objetos de distintos mdulos o subsistemas. Contexto del sistema y modelos utilizados La primera etapa del proceso de diseo de software es comprender las relaciones entre el software que se est diseando y el entorno externo, lo que ayuda a decidir cmo se suministra los requerimientos funcionales del sistema y cul es la estructura para que la comunicacin en su entorno sea efectiva. La representacin del contexto del sistema y el modelo de utilizacin del mismo est dada por dos modelos complementarios, que son: 1- El contexto del sistema es un modelo esttico que describe a los otros sistemas de su entorno. 2- El modelo de utilizacin del sistema es un modelo dinmico que describe cmo el sistema interacta con su entorno. Este modelo de contexto se representa en UML por el diagrama de paquetes. Una representacin a modo de ejemplo es la siguiente:
Sistema E-Commerce
Sistema de Pedidos
Sistema de Administracion
Sistema de Facturacion
En el diagrama se presenta una organizacin en paquetes, donde Sistema E-Commerce contiene tres susbsistemas, sistema de Pedidos, Sistema de Administracin y Sistema de Facturacin. Entre ellos se comunican de acuerdo a la estructura que se plantee. Tenga en cuenta que cada uno de los paquetes de los subsistemas puede contener otros paquetes con componentes en su interior. Otra forma de visualizar esta organizacin es la siguiente:
Esta estructura con las interiores estarn realizando en conjunto el Diseo arquitectnico, en el cual se tendrn en cuenta los modelos de capas, de sistemas distribuidos, de servicios o de eventos segn el comportamiento del sistema. Es importante en el proceso de diseo decidir qu modelos de diseo son necesarios y su nivel de detalle, lo cual depende del tipo de sistema que se est diseando. Fundamentalmente existen dos tipos de modelos de diseo para describir un diseo orientado a objetos: 1- Modelos estticos, que describen solo la estructura esttica del sistema dado por las clases del sistema y sus relaciones. 2- Modelos dinmicos, que describen las interacciones entre los objetos del sistema de forma dinmica, o sea en el tiempo.
Recuerde que UML provee de 12 modelos entre esttico s y dinmicos y que no es necesario utilizar todos, sino solo los necesarios, los que aporten informacin al sistema y al equipo que interviene en el proceso de desarrollo del software. Uno de los modelos ms convenientes de utilizar hoy en da es el Modelo de mquina de estado donde se muestra cmo los objetos del sistema cambian de estado de acuerdo a algn evento y el comportamiento que asumen en cada estado. Tenga en cuenta que para que los objetos puedan comunicarse es necesario facilitar esta tarea, para lo cual se disean las Interfaces entre los distintos componentes. El diseo de interfaces de objetos comprende la especificacin del detalle de la interfaz para un objeto o para un grupo de objetos, en UML se representa con el estereotipo <<interfaz>> y en Java se identifica la clase interfaz con la palabra reservada <<interfaz>>. Otro factor importante a tener en cuenta es que el diseo no es esttico, si bien es la arquitectura que sustenta al sistema, con la llegada de nuevos requerimientos durante el proceso de desarrollo y en la etapa de Mantenimiento, seguramente el diseo evolucionar pero no debe dejar de ser una estructura slida que permita con cada iteracin crecer de forma robusta y confiable. Relaciones entre Objetos Un objeto por s mismo no es demasiado interesante, contribuyen al comportamiento de un sistema colaborando con otros. Se identifican dos tipos de relaciones que se pueden dar entre objetos: enlaces y agregacin. Enlaces:
Un enlace es una conexin fsica o conceptual entre objetos, o sea que un objeto colabora con otros a travs de sus enlaces denotando la asociacin especfica por la cual un objeto (el cliente) utiliza los servicios de otro objeto (el servidor) o a travs de la cual un objeto puede comunicarse con otro. Un concepto esencial en el paradigma orientado a objetos, es el hecho de que los objetos colaboran entre s para llevar a cabo un comportamiento superior. Los objetos de una clase pueden cumplir una responsabilidad por s solos o pueden requerir la asistencia de otros objetos (de otras clases), estableciendo la comunicacin entre ellos.
Se dice que un objeto S colabora con otro objeto C, si el objeto C para cumplir con una responsabilidad, necesita enviar algn mensaje a S solicitndole un servicio. Desde el punto de vista del cliente, C, cada una de sus colaboraciones estn asociadas con una responsabilidad particular implementada por el servidor, S. Los mensajes se muestran con lneas dirigidas, o sea con direccin y una etiqueta que nombra al propio mensaje. Si hubiese mensajes en ambas direcciones estara significando que ambos objetos son cliente y servidor. Segn la direccin del mensaje se identifica: del cliente al servidor: parmetros del servidor al cliente: respuesta
Supongamos que el objeto Factura, que conoce quin es el cliente, como parte de su responsabilidad de mostrar sus datos completos debe mostrar el nombre del mismo, le enviar un mensaje indicndole tal solicitud. El objeto Cliente responder retornndole su nombre. Esto puede representarse grficamente en el siguiente Diagrama de colaboraciones:
Agregacin:
La agregacin denota una jerarqua todo/parte, en la cual un objeto del todo tiene o contiene objetos de la parte. La agregacin puede o no denotar contencin fsica. Por ejemplo, un auto se compone de motor, ruedas, tren delantero, chasis, entre otros siendo un caso de contencin fsica. En otro ejemplo, un cliente de un banco tiene cuentas, pero las cuentas no son de ninguna manera parte fsica del cliente. Esta ltima relacin todo/parte es ms conceptual y por lo tanto menos directa que la agregacin fsica de las partes que forman un auto. Se desarrolla este tema con ms detalle en el punto siguiente, Relaciones entre Clases.
Relaciones entre Clases Las clases, al igual que los objetos, no existen aisladamente. Existen tres tipos bsicos de relaciones entre clases, en UML: Generalizacin/Especializacin, que denota una relacin del tipo es un, padre/hijo, conocida como herencia y representada por:
Asociacin, que denota alguna dependencia semntica entre clases de otro modo independientes, como en nuestro ejemplo de Factura Cliente, representada por:
Dependencia, es una relacin de uso, se quiere indicar que un elemento utiliza a otro. Uno de los usos ms frecuentes de la dependencia es para modelar una visibilidad temporal desde los objetos de una clase hacia los objetos de otra.
Herencia: La herencia es un concepto ya desarrollado desde el Paradigma, por lo que se plantea desde el diseo como una implantacin de la generalizacin. La generalizacin establece que las propiedades de un tipo se aplican a sus subtipos. La herencia hace que la estructura de datos y operaciones de una clase (padre) estn disponibles para su reutilizacin por parte de sus subclases (hijos). La herencia de estructura de datos permite la reutilizacin de la estructura.
La herencia es una relacin entre clases en la que una clase comparte la estructura y/o el comportamiento definidos en una (herencia simple) o ms clases (herencia mltiple). La clase de la que otras heredan se denomina superclase o clase padre y la clase que hereda de otra o ms clases se denomina subclase o clase hija, que puede adicionar su propio estado y/o comportamiento.
Una clase puede tener uno o ms padres o bien no tener ninguno. Una clase sin padres y uno o ms hijos se denomina raz o clase base. Una clase sin hijos se denomina clase hoja. Las clases hojas son de las que se espera que existan instancias, es decir objetos, por ello se las denomina tambin clases concretas. Las clases sin instancias se llaman clases abstractas, son las subclases las que aaden elementos a su estructura y comportamiento, usualmente completando la implementacin de sus mtodos. De modo que nunca existirn objetos de una clase abstracta. Una clase con un nico padre se dice que utiliza herencia simple; una clase con ms de un padre se dice que utiliza herencia mltiple. Veamos grficamente un ejemplo:
Asociacin: Una asociacin es una relacin estructural que especifica que los objetos de una clase estn conectados con los objetos de otra, denotando una dependencia semntica entre dos clases sin establecer la forma exacta en que una clase se relaciona con la otra; slo puede denotarse esa semntica nombrando el papel que desempea cada clase en relacin con la otra. Dada una asociacin entre dos clases se puede navegar desde un objeto de una clase hasta un objeto de la otra. Grficamente, una asociacin se representa como una lnea continua que conecta la misma o diferentes clases:
Asociacin
Cuando un objeto conoce a otro objeto la asociacin se dice que tiene direccin, aunque algunos modeladores de UML no lo permiten, siendo una lnea sin sentido.
Asociacin unidireccional
Puede ocurrir que en algunos casos la asociacin necesite ser navegable en ambos sentidos. Por ejemplo: Para mostrar los datos completos de una factura es necesario que factura conozca al cliente al que corresponde. Para mostrar un resumen de cuenta de un cliente es necesario que cliente conozca las facturas que le corresponden. Esta situacin se modela de la siguiente manera:
Asociacin bidireccional con multiplicidad
Puede establecerse tambin la relacin de asociacin entre objetos de la misma clase, como por ejemplo miembros de una familia, son todas personas, la relacin grficamente es la siguiente:
Agregacin: La agregacin es un tipo especial de asociacin, tienen un paralelismo directo con las relaciones de agregacin entre los objetos correspondientes a esas clases. La agregacin es una relacin todo/parte en la cual una clase representa una cosa grande (el todo), que consta de elementos ms pequeos (las partes).
Representa una relacin del tipo tiene un, o sea, un objeto del todo tiene objetos de la parte.
Todo
Parte
Agregacin
Como planteamos anteriormente, la agregacin puede o no denotar contencin fsica, se definen entonces dos posibilidades en cuanto a la relacin de agregacin: Agregacin por Valor: Es un tipo de relacin, en la que el tiempo de vida del objeto incluido est condicionado por el tiempo de vida del que lo incluye. Este tipo de relacin es tambin llamada Composicin (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo").
En este tipo de relacin el objeto parte no existe independientemente del objeto todo que lo contiene. El tiempo de vida de ambos objetos est ntimamente relacionado: cuando se crea una instancia del todo, se crea tambin por lo menos una instancia de la parte; cuando se destruye el objeto todo esto implica la destruccin de todos los objetos parte relacionados a l.
En el ejemplo, cuando se crea una instancia de Pedido (un objeto pedido) es porque existe al menos una instancia (objeto) de la clase DetallePedido.
Agregacin por valor
Agregacin por Referencia: Es un tipo de relacin, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relacin es comnmente llamada Agregacin (el objeto base utiliza al incluido para su funcionamiento). Algunos autores llaman tambin a esta forma de agregacin compartida porque es posible que un objeto parte o contenido corresponda a ms de un objeto todo o contenedor.
Por ejemplo: Una Universidad tiene como parte a los docentes, pero los objetos pueden existir independientes de la Universidad, se grafica de la siguiente forma:
Agregacin
por
referencia
Esta forma de graficar la agregacin es opcional. No es obligatorio determinar el tipo de agregacin sobre todo durante el modelado de requerimientos o anlisis, pero es til comprender el significado de ambas y es ms til determinar concretamente el tipo de agregacin en la actividad de diseo.
Dependencia: Segn lo expresa Booch G., Rumbaugh J. y Jacobson I. en su libro El Lenguaje Unificado de Modelado, (1999), este tipo de relacin se define como una relacin de uso que declara que un cambio en la especificacin de un elemento puede afectar a otro elemento que la utiliza, representando la dependencia que tiene una clase de otra.
La clase dependiente obtiene visibilidad de la otra clase porque recibe un objeto como parmetro de alguna operacin. Esto es claramente una relacin de uso: si la clase utilizada cambia, la operacin de la otra clase puede verse tambin afectada, porque la clase utilizada puede presentar ahora una interfaz o comportamientos diferentes. Grficamente estas relaciones se representan con una lnea discontinua dirigida hacia la clase de la cual se depende, como se muestra a continuacin:
Dependencia
La dependencia se utiliza para representar la visibilidad de parmetro. En nuestro ejemplo calcularRecargo se hace visible para CondicionPago porque un objeto de esta ltima clase recibir como parmetro de entrada para su operacin calcularRecargo(obj CondicionPago), un objeto de la clase CondicionPago. Diagrama de Clases Los diagramas de clases son los ms utilizados en el modelado de sistemas orientados a objetos y necesario para el diseo, ya que ser el diagrama que guiar la codificacin. Un diagrama de clases muestra un conjunto de clases as como sus relaciones. Los diagramas de clases se utilizan para modelar la vista de diseo esttica de un sistema. En este caso se usa el diagrama de clases para modelar el dominio del problema pero tambin se utiliza para mostrar las clases de implementacin, que son las cosas con las que trabajan los programadores. Este enfoque se aplica a partir de la actividad de Diseo de un sistema. En un diagrama de clases podemos encontrar: Clases Relaciones: herencia, asociacin (su variante: agregacin), dependencia.
Indicadores de multiplicidad y navegabilidad Nombre de Rol
A continuacin se muestra un fragmento de un diagrama de clases uniendo algunos de los ejemplos individuales ya vistos:
Bibliografa Lectura 1
Corts Morales Roberto, Introduccin al Anlisis de Sistemas y a la Ingeniera de Software, 1998. Booch Grady, Anlisis y diseo orientado a objetos, con aplicaciones, EE.UU, Editorial Addison-Wesley Iberoamericana S.A. , (1996).
Booch Grady, Rumbaugh James, Jacobson Ivar, (1999), El lenguaje de Modelado Unificado, Espaa, Editorial Addison Wesley Iberoamericana.
Evans Gary, Getting from Use.Case to code Part 1: Use Case Analysis, artculo publicado en el sitio IBM Rational en Julio/2004. Jacobson Ivar, Booch Grady, Rumbaugh James, (2000), El Proceso Unificado de Desarrollo de Software, Espaa, Editorial Addison Wesley.
Piattini Mario, Calvo-Manzano, Cervera, Fernndez, (2004), Anlisis y Diseo de aplicaciones informticas de gestin. Una perspectiva de Ingeniera de Software, Alfaomega Grupo Editor.
KENDALL KENNETH E. KENDALL JULIE E, (2005), ANALISIS Y DISEO DE SISTEMAS 6ta. edicin, Ed. PEARSON ADDISON-WESLEY
www.uesiglo21.edu.ar

Lectura 1 - Paradigma OO

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Lectura 1 - Paradigma OO

Загружено:

Авторское право:

Доступные форматы

Mdulo 1

1- Paradigma Orientado a Objetos

1.1.1 Identificacin de los elementos de un modelo OO.

1.1.2 Clase, objeto, atributos, mtodos

Veamos un ejemplo de objetos y clases:

Por ejemplo: Objeto: Animal Atributo: cantidad de patas

Por ejemplo. Objeto: Animal Comportamiento: comer

Gabinete Mouse Teclado

1.1.3 Encapsulamiento, herencia, polimorfismo

La representacin de la clase Automovil sera:

1.2 Anlisis y Diseo OO repaso de conceptos e UML

1.2.1 Modelos. Conceptos.

1.2.2 Caractersticas de los Modelos Orientados a Objetos

1.2.3 Anlisis de Sistemas

Adaptacin a Modelos de diseo

1.2.4 Diseo orientado a objetos

Asociacin bidireccional con multiplicidad

Agregacin por valor

Indicadores de multiplicidad y navegabilidad Nombre de Rol

Вам также может понравиться