Análisis y Diseño Orientado a ObjetosTexto Preparado para los Alumnos del CFT Simón BolívarRevisado - 2012Diseño Orientado a Objetos

Introducción a Orientación Objetual.La tecnología de Objetos data de los años 60, cuando surge la necesidad de describir y simular fenómenos como sistemas de comunicación, redes neurales, sistemas administrativos, etc.En 1961 Krystin Nygaard con la idea de desarrollar un lenguaje de doble propósito (descripción de sistema y simulación programable), crea SIMULA I. Los usuarios descubrieron que también proveía de nuevas y poderosas facilidades cuando era usado para otros propósitos, aparte de la simulación, tales como el prototipeo y aplicaciones.En 1967 se creó SIMULA 67, y en él se implementaron por primera vez los conceptos de clase, objeto y herencia, que en adelante serían elementos centrales en los Lenguajes Orientados A Objetos. SIMULA 67 es una extensión del lenguaje ALGOL 60 y diseñado en 1967 por Ole - Johan Dahl y Krystin Nygaard, de la Universidad de Oslo y del Centro de Computación Noruego (Norsk Regasentral). Sin embargo Simula, así como se le conoce actualmente, es un lenguaje de programación de propósito general, que no es ampliamente utilizado.En 1970 se crea el SMALLTALK, éste fue el mayor desarrollo de los lenguajes orientado a objetos. El proyecto de investigación se realizó en la Corporación Xerox, Centro de Investigación de Palo Alto (PARC - Palo Alto Research Center) y fue dirigido por Alian Kay. Empezó en los 70's y tuvo como meta, más que el lenguaje de programación, una completa interfacez gráfica y herramienta de desarrollo integradas.Xerox PARC fue la pionera en el desarrollo y utilización de los componentes estándar de las modernas interfaces gráficas, como ventanas, iconos, mouse, etc.Smalltalk fue el primer lenguaje orientado a objetos, ya que trató exclusivamente con ellos; los subsecuentes, se ha basado en los conceptos utilizados por él. Smalltalk fue importante no sólo por su lenguaje, sino por las herramientas de desarrollo disponibles en su ambiente, éstas incluyen visualizadores de clases (class browsers) e inspeccionadores de objetos (object inspectors) .Un visualizador de clases es una poderosa herramienta, que permite editar el código del programa, en una manera mucho más conveniente y estructurada que utilizando editores convencionales. Por la estructura, inherente, bien definida por los programas orientados a objetos, el visualizador de clases es capaz de mostrar, en forma gráfica , el árbol de una clase dada, permitiendo al usuario "apuntar y disparar" método en particular (proceso) a ser editado. Otras ventajas del visualizador es que muchas tareas de programación se realizan sólo por menúes, por ejemplo la creación de una nueva clase modificación de la estructura del árbol de herencia, modificación de una estructura de una clase etc. Estas operaciones son mucho más complejas cuando se realizan en un ambiente de edición tradicional.Herramientas como éstas, son una parte integral de la " promesa" de la Tecnología Orientada a Objetos, ya que puede simplificar la vida del programador, reduciendo el costo y el tiempo de desarrollo.En los años 80 evoluciona el SMALLTALK y se crea ADA, lo que hizo crecer el interés en el Diseño Orientado a Objetos.En estos lenguajes la abstracción de los datos tienen gran importancia. Los problemas del mundo real se representan mediante objetos a los cuales se le agrega operaciones cuando es necesarioLa TOO se fundamenta en el proceso de construcción y utilización de conocimientos, por lo tanto, objetos y clases son los pasos más importantes en la búsqueda de una nueva revolución que reemplace , esta vez, parte del esfuerzo que implica la organización y utilización del conocimiento , del mismo modo que en la primera, las máquinas reemplazaron el esfuerzo físico del hombre y de los animales, permitiendo el vertiginoso avance del mundo.Los "Chips de Software" (Objetos y clases altamente reutilizables) serán el motor de la revolución que ya se ha iniciado. Participar en ella garantizará nuestra competitividad en el futuro y solo nos exige todo el esfuerzo de nuestra capacidad creativa, y de la perseverancia de construir productos de alta calidad. La materia más importante del software es la inteligencia.El Desarrollo de la Estructura del Pensamiento y la Construcción del ConocimientoDesde muy temprana edad, aproximadamente hasta los siete años, en los denominados períodos Senso-motriz y Preparatorio de la inteligencia, en los que se afirma el esquema del objeto permanente, los seres humanos, a partir de la experiencia de la observación y captación de cosas y hechos del mundo que nos rodea, construimos conceptos "concretos". Estos nos permiten ser consistentes y razonar. Por ejemplo: Fido es un elemento del mundo real que es conceptualizado como Fido. En él almacenamos sus características (DATOS), por ejemplo: tiene pelos, cuatro patas, dos orejas , dos años de edad, es de color blanco, otros. Junto con los datos también almacenamos sus acciones (COMPORTAMIENTO), es decir, lo que puede o no hacer (ladrar, correr, saltar, comer, etc.). Como consecuencia de este hecho (almacenamiento de los datos y comportamiento en una sola unidad conceptual), entre las muchas operaciones de nuestra mente, podemos razonar que Fido no tiene alas, ni plumas, ni puede volar.A las acciones que, cualquier elemento del mundo real, realiza como reacción frente a un estímulo las denominaremos Operaciones. Algunos comportamientos complejos son el resultado de la interacción o sucesión de varias operaciones, a éstos los denominaremos Procesos. Sin embargo en nuestro enfoque, en la mayoría de los casos y de manera genérica utilizaremos el término OPERACION.Los conceptos se construyen modelando los aspectos y características de cualquier objeto real, extrayendo los detalles (datos y comportamiento) necesarios y descartando lo menos útil. Este proceso, natural en los seres humanos, compuesto por diversas operaciones tales como observar, captar, fijar, comparar, conceptualizar y otros es denominado abstracción.Prof.: Oscar Núñez M.1Diseño Orientado a ObjetosCuando pensamos en un auto, no visualizamos cada mínimo detalle que lo describa, lo más probable es que tengamos en mente sólo las principales características físicas y, dependiendo de nuestra experiencia, algunos de los subsistemas importantes como la caja de cambios, o los sistemas de dirección y frenos.

En Tecnología Orientado a Objetos (TO) a los conceptos se les llama objetos, en consecuencia, los OBJETOS son MODELOS de entes del mundo real. Los percibimos porque tienen límites que los esperan de su medio ambiente y de los demás (IDENTIDAD). Se encuentran en un ESTADO específico en el mundo.Un objeto puede ser concreto (material)o abstracto (inmaterial), simple o complejo; pero siempre estará compuesto deDATOS y OPERACIONES.Continuando con el desarrollo de la estructura del pensamiento, encontraremos que aproximadamente a partir de los siete años, en la denominada etapa de las operaciones concretas, el ser humano aprende a CLASIFICAR (separar y agrupar objetos de acuerdo a características y comportamientos comunes) y ORDENAR (establecer criterios de jerarquía que permitan la organización).La clasificación es un medio por el cual organizamos el conocimiento.Clasificar y ordenar es una consecuencia de la capacidad de interiorizar esquemas representativos (MODELOS), los cuales permiten: por un lado, reconocer si un concepto (OBJETO) tiene o no las características de dicho esquema; y por otro, incorporarlo o no en el conjunto de los que comparten ese mismo esquema (CLASE). Posteriormente organizamos jerárquicamente en clases y superclases, construyendo en forma progresiva las grandes CLASIFICACIONES y las OPERACIONES DE ORDEN.Después de los doce años, en la etapa de las Operaciones combinatorias de la inteligencia (Pensamiento formal), el hombre construye SISTEMAS y aún TEORIAS como producto del raciocinio de Hipótesis (propuestas de solución a interrogantes o problemas), y de la representación en dimensiones simultáneas.Un Sistema es un conjunto de componentes (conceptos y modelos, y aún de otros sistemas) que interactúan, en distintos planos, entre sí para alcanzar objetivos específicos. Cada Sistema construido es una manera de solucionar los diferentes problemas que enfrenta el hombre a lo largo de su existencia, por ejemplo el Lenguaje, uno de los sistemas más elaborados, permite satisfacer la necesidad vital de la comunicación.En síntesis, construimos CONCEPTOS, MODELOS y SISTEMAS. Esta es la forma en que los seres humanos captamos el mundo real y operamos en él. La tecnología de Objetos intenta simular este hecho y sus fundamentos se sostienen en él.Fundamentos de la Tecnología de Objetos.1. Simulación. Representación directa de elementos que "maneja" el usuario en el mundo real.Consiste en recrear el mundo real. No se trata de construir "modelos ideales", sino de representarlo directamente. Por ello, en este enfoque, primero se identifican las características de los elementos del mundo real, los que se organizan en las denominadas ESTRUCTURAS DE DATOS. Luego se captan los comportamientos u operaciones, los cuales se imitan o simulan mediante pequeños programas (procedimientos) a los que en adelante denominaremos METODOS. Y así como en la vida real conceptualizamos en una sola unidad (datos y comportamiento), en TO simulamos este hecho colocando en una especie de "cápsula" las estructuras de datos y los métodos, a esta unidad denominamos OBJETO.También se simula la manera en que los entes del mundo real se comunican entre sí, enviándose señales o "mensajes" a los que responden con una conducta o comportamiento específico, de la misma manera se simulan las clasificaciones, ordenamiento, organización, e incluso la herencia de los seres vivos.En síntesis, se trata de actuar de la misma manera en que los humanos, a los que en informática, en general, se nos denomina usuarios, " manejamos" y operamos el mundo real.2. Encapsulamiento. Utilización del concepto de "Caja Negra" a una potencia mucho mayor. Empaquetar datos y operacionesen forma conjunta se llama ENCAPSULACION.La encapsulación es el resultado (o acto) de ocultar, al usuario, los detalles de la implementación de un objeto. El objeto oculta sus datos a otros objetos y sólo permite accesar a sus datos vía sus propios métodos mediante mensajes específicos, es decir, se crea una " Caja Negra" que solo el constructor del objeto conoce. A esto se llama ocultamiento de información. La encapsulación protege los datos de un objeto de la corrupción. Si todos los programas pudieran accesar a los datos (como actualmente sucede con la tecnología estructurada), fácilmente puede corromperse o perderse. La encapsulación protege los datos del objeto del uso arbitrario y no intencionado. Así la creación está protegida y la competencia garantizada.La encapsulación tiene dos beneficios primordiales:1. Modularidad. El código de un objeto puede ser escrito y se puede mantener independiente del código de otros objetos. Un objeto se puede mover de sistema en sistema, se puede quitar, modificar y volver a colocar sin alterar el s is tema general.2. Esconder la información ( Information Hiding ). Un objeto tiene una interfaz con la que otros objetos se pueden comunicar, pero puede mantener información privada para sí misma que puede cambiar en cualquier momento, sin afectar a los objetos que dependen de ésta.3. Reutilización. Capacidad de reutilizar código sin alterarlo, programando solo lo adicional o diferente. Base de la HerenciaDurante la vida de un sistema, las estructuras de datos se mantienen relativamente estables, mientras que las operaciones sobre dichas estructuras cambian, dependiendo de situaciones. Por ello en el Análisis y Diseño Orientado a Objetos, se da énfasis primordial a los DATOS y al COMPORTAMIENTO de los objetos y tipos de objetos (modelos).Los datos, como son relativamente estables, pueden ser utilizados muchas veces, modificando únicamente aquello que sea necesario para tal o cualProf.: Oscar Núñez M.2Diseño Orientado a Objetossituación, en la misma forma se procede con los comportamientos. En cambio, en el Análisis y Diseño Estructurado, se da énfasis a la descomposición funcional orientada al proceso, en consecuencia, cualquier modificación requiere de una reconstrucción, normalmente, a partir de cero.Principios Fundamentales.Los objetos son las cosas físicas y conceptuales que encontramos en el universo alrededor de nosotros. Hardware, software, documentos, seres humanos, los conceptos son todos los ejemplos de los objetos.Un objeto es algo real o abstracto acerca del cual almacenamos datos y métodos que manipulan dichos datos.Es una persona, lugar o cosa. Ejemplo: Una manzana. Todos los objetos tienen un estado y un comportamiento. Esto es muy importante. Para el ejemplo de la manzana, la manzana (hablando de una manzana normal de color rojo) recién bajada de un árbo l, está completa, es dura y de color rojo. Este es su estado. Uno sabe que si se muerde la manzana va a sonar un "crunch", y esto se puede interpretar como un comportamiento. Después de haberla mordido la manzana cambió de estado. Los objetos pueden tener más de un comportamiento y más de un estado.

Una clase es un grupo de objetos con propiedades (atributos) similares, comportamiento común (operaciones), relaciones comunes entre objetos, y semántica común.Un grupo de objetos con las mismas características. Una clase contiene:• Una descripción de las variables internas de los objetos de la clase.• Las operaciones que se pueden aplicar al objeto de la clase.En este ejemplo vamos a analizar la clase Música de Colombia es la clase padre de las clases hija Vallenato y Salsa. En otras palabras las clases Vallenato y Salsa son derivadas de la clase Música de Colombia. Ellas heredan todas las propiedades de su padre. Las clases derivadas pueden adicionar, cambiar u ocultar los miembros públicos de la clase padre usando las reglas de la herencia. Cuidado... los miembros privados no pueden ser accesados por otras clases.Clase padre Música de ColombiaAtributos: Tipo de ritmo, tipo de instrumentos, músicos. Métodos: bailada, cantada, tomada.Clase hija Vallenato (hereda las propiedades de la clase padre) Atributos: Tipo de ritmo, tipo de instrumentos, músicos.Métodos: bailada, cantada. El nuevo método incluye el tocar un instrumento tomada.Clase hija Salsa (hereda las propiedades de las clase padre) Atributos: Tipo de ritmo, tipo de instrumentos, músicos. Métodos: Bailada, cantada, tomada.Prof.: Oscar Núñez M. 31) Objeto.

2) ClasesEjemplo.Diseño Orientado a Objetos

3) Estructura de Objetos.El modelo orientado a objetos se basa en encapsular código y datos en una única unidad, llamada objeto. La interfaz entre un objeto y el resto del sistema se define mediante un conjunto de mensajes.El motivo de este enfoque puede ilustrarse considerando una base de datos de documentos en la que los documentos se preparan usando uno entre varios paquetes software con formateador de texto. Para imprimir un documento debe ejecutarse el formateador correcto en el documento. Bajo un enfoque orientado a objetos, cada documento es un objeto que contiene el texto de un documento y el código que opera sobre el objeto. Todos los objetos del tipo documento responden al mensaje Imprimir, pero lo hacen de forma diferente. Cada documento responde ejecutando el código formateador adecuado. Encapsulando dentro del objeto documento la información acerca de cómo imprimirlo, se puede tener todos los documentos con la misma interfaz externa al us uario (aplicación).En general, un objeto tiene asociado:• Un conjunto de atributos que contienen datos acerca del objeto. A su vez, cada valor de un atributo es un objeto.• Un conjunto de mensajes a los que el objeto responde.• Un conjunto (puede ser unitario) de métodos, que es un procedimiento o trozo de código para implementar la respuesta a cada mensaje. Un método devuelve un valor (otro objeto) como respuesta al mensaje.Puesto que la única interfaz externa de un objeto es el conjunto de mensajes al que responde, es posible modificar la definición de métodos y atributos sin afectar a otros objetos.También es posible sustituir un atributo por un método que calcule un valor.Ejemplo:Un objeto documento puede contener un atributo de tamaño que contenga el número de bytes de texto en el documento, o bien un método de tamaño que calcule el tamaño del documento leyéndolo y contando el número de bytes."La capacidad de modificar la definición de un objeto, sin afectar a l resto del sistema, está considerada como una de las mayores ventajas del Modelo de Programación Orientada a Objetos".4) Jerarquía de Clases.Normalmente en la realidad a modelar existen muchos objetos similares. Por similar se quiere decir que tienen una naturaleza parecida, por lo que son candidatos a poseer atributos, métodos y responder a mensajes comunes en un contexto orientado a objetos (VIC).Para el caso de los objetos similares, sería un trabajo inútil definir cada uno de ellos por separado. Por t anto, se agrupan para que conformen una clase. A cada uno de estos objetos se le llama instancia de clase. Todos los objetos de una clase comparten una definición común, aunque difieran en los valores asignados a los atributos.Ejemplo:En un banco, son objetos los clientes, las cuentas y los préstamos. Una clase incluye:• Un atributo con valores en un conjunto cuyo valor es el conjunto de todos los objetos que son instancias de la clase.• Implementación de un método para el mensaje nuevo, el cual crea una nueva instancia de la clase.

Un esquema orientado a los objetos, normalmente requiere un gran número de clases. Sin embargo, a menudo se da el caso que varias clases son similares. Para permitir la representación directa de similitudes entre clases, se utiliza una jerarquía de especialización, como aquella utilizada por el modelo MER extendido.Prof.: Oscar Núñez M.4Diseño Orientado a ObjetosEjemplo:En un banco, es de esperarse que los Empleados y los Clientes tengan ciertos atributos comunes como RUC, nombre, dirección y teléfono, sin embargo los Empleados podrían tener un atributo exclusivo, como salario, mientras que los Clientes tendrán atributos como tasa de crédito. Aquí los empleados y clientes pueden ser representados por especializaciones de una clase Persona. Los atributos y los métodos específicos para Empleado se asocian a la clase Empleado, en forma análoga, se actúa para los clientes. Los atributos y métodos comunes para empleados y clientes se asocian a la clase Persona.

Obs.:Denotaremos las clases por medio de rectángulos con línea doble, mientras que las instancias de las mismas u objetos, se representarán por rectángulos. El semicírculo denota la relación ES_UN, o ESPECIA LIZACION de, que se utiliza para construir la jerarquía de clases (VIC).5) Operaciones.Una acción que es afectada por, o requerida por un objeto. Las operaciones pueden ser selectoras, constructivas, o iterativas . Una operación es contenida en la interfaz del objeto y tiene sus detalles descritos en un método correspondiente. Las operaciones pueden ser compuestas, es decir, integrada por otras operaciones. Sin embargo no es alentada, la encapsulación de operaciones compuestas dentro de la interfaz a un objeto.6) Mens aje.Los objetos se comunican unos con otros mediante mensajes. El mensaje es enviado por un objeto emisor y recibido por un objeto destino o receptor. Un mensaje invoca una o más operaciones en el objeto receptor.7) Herencia.Principio por el cual una clase se puede derivar de otra clase ya existente, heredando las características del padre.Relación entre clases de objetos que permite incluir (re-usar) los atributos y operaciones definidas en otra clase más general de la cual se hereda o deriva. Es compartir atributos y operaciones entre clases tomando como base una relación jerárquica. En términos generales se puede definir una clase que después se irá refinando sucesivamente para producir subclases. Todas las subclases poseen o heredan, todas y cada una de las propiedades de su superclase y añaden, además, sus propiedades exclusivas. No es necesario repetir las propiedades de las superclases en cada subclase.Ejemplo:Tengo el objeto fruta, con algunas propiedades inherentes a la fruta. Luego tengo el objeto manzana, que es hijo de fruta y por lo tanto hereda las propiedades de la fruta, pero puede tener otras propiedades propias de la manzana. Este es un ejemplo sencillo pero más o menos ilustra lo que se trata de explicar. El hijo hereda las características del padre, pero tiene otras propias y mejora o empeora, algunas características del papá.Ejemplo:Retornando al caso del banco, podemos observar que como atributos para la clase persona se tiene ruc, nombre, dirección y teléfono. A su vez los empleados tienen un sueldo, y los clientes una tasa de crédito.Prof.: Oscar Núñez M.4Diseño Orientado a Objetos

En este caso, un objeto de la clase persona tiene como atributos RUC, Nombre, Dirección y Teléfono, un Empleado, hereda todos los anteriores y agrega el atributo Sueldo, mientras que el Cliente agrega el atributo Tasa Crédito.Obs.:1. El triángulo del diagrama denota la relación COMPUESTO_DE o INTEGRADO_POR, para indicar que los atributos de una clase pertenecen a las clases que se indican. En algunos formalismos para modelar clases y objetos existe la cardinalidad, para indicar el número de veces que un atributo puede aparecer en una clase.2. En este caso no se han incluido los métodos pertenecientes a cada clase ni los mensajes a los que responde cada método. Esto se ha obviado por quedar fuera del ámbito de nuestro interés.8) Polimorfismo.Principio en el cual objetos de diferentes clases pueden entender el mismo mensaje pero responder de manera distinta.Una vez que se tienen bien claros estos conceptos se puede entender mejor la filosofía de objetos. Ahora tratamos de encapsular los estados de los programas por medio de objetos, que pueden ser accesados solamente por medio de operaciones definidas dentro de ellos mismos.Los programas están compuestos por varios objetos. Cada objeto tiene sus variables internas así como sus métodos bien definidos. Un método es el equivalente a un procedimiento.La misma operación es resuelta de diferente forma, según el objeto que recibe el mensaje. Significa que una misma operación puede comportarse de modos distintos en distintas clases. La operación mover, por ejemplo, se puede comportar de modo distinto en las clases Ventana y Pieza de ajedrez. Una operación es una acción o una transformación que se lleva a cabo o que se aplica a un objeto. Justificar a la derecha, visualizar y mover son ejemplos de operaciones. Una implementación específica de una operación por parte de una cierta clase es lo que se denomina método. Dado que los operadores orientados a objetos son polimórficos es posible que haya más de un método que lo implemente.En el mundo real una operación es simplemente, una abstracción de comportamiento análogo entre distintas clases de objetos. Cada objeto "sabe" llevar a cabo sus propias operaciones. Sin embargo, en un lenguaje orientado a objetos es este el que selecciona automáticamente el método correcto para implementar una operación basándose en el nombre de la operación y en la clase del objeto que esta siendo afectado. El usuario de una operación no necesita ser consciente del número de métodos que existen para implementar una cierta operación polimórfica. Se pueden añadir nuevas clases sin modificar el código existente, siempre y cuando se proporcionen métodos para todas las operaciones aplicables a las nuevas clases.Objeto

9) Identidad.Los datos están cuantificados en entidades discretas y distinguibles denominadas objetos (PE. una televisión, una bicicleta, un árbol). Los objetos pueden ser concretos, como un archivo en un sistema de archivos, o bien conceptuales como la política de planificación en un sistema operativo con multiprocesos. Cada objeto posee su propia identidad inherente. En otras palabras: dos objetos serán distintos aun cuando los valores de todos sus atributos (tales como el nombre y el tamaño) sean idénticos.Prof.: Oscar Núñez M.5Diseño Orientado a ObjetosEn este modelo no necesitamos detectar los atributos que constituirán el identificador de un objeto. Aquí cada objeto conserva su identidad independientemente de su estado.El estado de un objeto está dado por los valores que en un momento tengan sus atributos. En el caso de las otras técnicas, habíamos identificado un elemento de la realidad en base al valor de algún conjunto de sus atributos, por ejemplo el nombre de una persona o la patente de un auto. Aquí podemos utilizar el mismo criterio para fines de búsqueda de información, pero a diferencia de los sistemas como los relaciónales, aunque modifiquemos el nombre de un objeto persona, éste seguirá siendo el mismo objeto.10) Clasificación.Significa que los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se reúnen para formar una clase. La selección de clases es arbitraria y depende de la aplicación.Ejemplo.Objetos: Bicicleta de montaña, Bicicleta de carreras, Bicicleta de niños. Clase: Bicicleta.Atributos: Tamaño del cuadro, tamaño de rueda, material, marca, velocidad Operaciones: mover, reparar, cambiar velocidadObjetos: Triangulo, Cuadrado, Octágono. Clase: Polígonos.Atributos: vértices, color del borde, color del interior Operaciones: dibujar, borrar, mover11) Abs tracción.Consiste en representar las características esenciales de un objeto, sin preocuparse de las restantes características (no esenciales). Una abstracción se centra en la vista externa de un objeto, de modo que sirva para separar el comportamiento esencial de un objeto, de su implementación. Definir una abstracción significa describir una entidad del mundo real, no importa lo compleja que pueda ser, y a continuación utilizar esta descripción en un programa. Una clase se puede definir como una descripción abstracta de un grupo de objetos, cada uno de los cuales se diferencia por su estado específico y por la posibilidad de realizar una serie de operaciones.12) Encapsulamiento.

Mecanismo que permite ocultar los detalles de implementación de un objeto. Permite empaquetar en una unidad los datos y las funciones que operan sobre dichos datos.Consiste en la combinación de datos e instrucciones en un nuevo tipo de datos denominado clase. Facilita la descomposición modular. En la práctica, una clase estará formada por dos partes: Una interfaz mediante la cual se accederá a la funcionalidad de los objetos y Una representación de la abstracción utilizando las facilidades del lenguaje. Es una buena norma el realizar el acceso a los datos del objeto utilizando los métodos de la interfaz. Los lenguajes OO permiten especificar en el objeto elementos que no serán visibles desde el exterior del mismo pero que son necesarios para su representación. A esta caracterís tica se le conoce con el nombre de Ocultamiento de Información.Acceso ..-—

Métodos,1 y 1 \ I-¡ Datos13) Agregación.Composición de un objeto por otros. Es una relación más débil que la que existe entre el atributo y el objeto al cual pertenece, y más fuerte que una asociación.14) Concurrencia.Propiedad que distingue un objeto activo de otro inactivo.Prof.: Oscar Núñez M.6Diseño Orientado a Objetos15) Persistencia.Es la propiedad de un objeto cuya existencia trasciende el tiempo y/o el espacio (PE. El objeto continúa existiendo luego de que su creador deja de existir; la ubicación de un objeto se mueve a un espacio de direcciones diferente de aquella donde fue creada).16) Visibilidad.Capacidad de restringir el acceso a atributos y servicios de un objeto. Particularmente importante en el diseño e implementación (PE. En C++ existen: público, protegido, privado).Beneficios de la Tecnología O.O.¿Por qué usar el paradigma Orientado a Objeto?• Proximidad de los conceptos de modelado respecto de las entidades del mundo real■ Mejora captura y validación de requisitos■ Acerca el "espacio del problema" y el "espacio de la solución"• Modelado integrado de propiedades estáticas y dinámicas del ámbito del problema■ Facilita construcción, mantenimiento y reutilización• Conceptos comunes de modelado durante el análisis, diseño e implementación■ Facilita la transición entre distintas fases■ Favorece el desarrollo iterativo del sistema■ Disipa la barrera entre el "qué" y el "cómo""...Los conceptos básicos de la OO se conocen desde hace dos décadas, pero su aceptación todavía no está tan extendidacomo los beneficios que esta tecnología puede sugerir"."...La mayoría de los usuarios de la OO no utilizan los conceptos de la OO de forma purista, como inicialmente se pretendía. Esta práctica ha sido promovida por muchas herramientas y lenguajes que intentan utilizar los conceptos en diverso sgrados ". Wolfgang StrigelBeneficios de las técnicas OO.Muchos de los beneficios son alcanzados únicamente cuando el Análisis y Diseño son utilizados con herramientas CASE OO, basados en repositorios que generan códigos, entre ellos:• Reus abilidadLas clases son diseñadas de tal manera que ellas puedan ser reutilizadas en muchos sistemas. Para maximizar el reuso las clases deben ser construidas de manera que puedan ser personalizadas. Un repositorio debería ser cargado con una colección de clases reusables.Un objetivo permanente de las técnicas OO, es conseguir reusabilidad masiva en la construcción de software.• Es tabilidadLas clases diseñadas para el reuso repetido, llegan a ser estables de la misma manera que los microprocesadores y otros chips que son bastante estables. Las aplicaciones serán construidas utilizando chips de software.• El Diseñador piensa de Comportamiento de Objeto, no en Niveles de DetalleEl encapsulamiento oculta los detalles y hace fácil el uso de clases complejas. Las clases son semejantes a las cajas negras. El desarrollador utiliza la caja negra sin mirar su interior. El tiene un entendimiento del comportamiento de la caja negra y cómo comunicarse con ella.• Cons trucción de Objetos de complejidad CrecienteLos objetos se construyen fuera de los objetos. Una buena manera de fabricar es construir tomando una lista de materiales de partes y subpartes existentes. Esto posibilita construir componentes de software complejos y los mismos se utilizarán para construir otros bloques de software más complejos.• ConfiabilidadEL software construido a partir de una librería de clases estables, es probable que se encuentre libre de errores, respecto a construir software desde el inicio. Cada método en una clase es en sí mismo simple y diseñado para ser confiable.Prof.: Oscar Núñez M.6Diseño Orientado a Objetos• Verificación de CorreccionesEl Diseño OO con técnica formal para la creación de métodos, puede generar potencialmente software de alta confiabilidad. Técnicas para verificar y garantizar la operación correcta de una clase, probablemente estén disponibles en nuevas generaciones de herramientas CASE OO.• Diseño RápidoLas aplicaciones son creadas tomando componentes pre-existentes. Muchos componentes son construidos de tal forma que, puedan ser observados, personalizados, para un diseño particular. Los componentes pueden ser vistos, customizados y enlazados en la pantalla de la herramienta CASE.

• Nuevos Mercados de SoftwareLas compañías de software, deberían proporcionar librerías de clases para áreas específicas, fácilmente adaptables a las necesidades de la organización. La era de los paquetes monolíticos esta siendo reemplazada por software que incorpora clases y encapsula paquetes de diferentes vendedores.• Dis eño de Alta CalidadLos diseños son a menudo de alta calidad, ya que ellos se construyen a partir de componentes que han sido aprobados y refinados repetidamente.• IntegridadLas estructuras de Datos pueden ser utilizadas solamente con métodos específicos. Esto es particularmente importante en sistemas distribuidos y sistemas CLIENTE/SERVIDOR, donde usuarios desconocidos pueden tratar de accesar al sistema.• Facilidad de ProgramaciónLos programas son construidos utilizando pequeñas plazas de software las cuales son generalmente fáciles de crear.• Fácil MantenimientoLos programas de mantenimiento generalmente cambiarán los métodos correspondientes a una clase. Cada clase realiza sus operaciones independientemente de otras clases.• CreatividadImplementadores hábiles en poderosas herramientas CASE OO laborando sobre estaciones de trabajo, encuentran que puede generar rápidamente muchas ideas. Las herramientas estimulan la creación e implementan las invenciones. La genialidad individual puede ser más creativa.• Ciclo de Vida DinámicoLos objetivos de desarrollo de un sistema, a menudo cambian durante la implementación. Las herramientas CASE OO, hacen los cambios durante el ciclo de vida rápidamente.Esto permite a los diseñadores de sistemas satisfacer mejor a los usuarios finales, adaptarse a los cambios, refinar los objetivos y mejorar constantemente el diseño durante la implementación.• Refinamiento durante la ConstrucciónLas personas creativas cambian constantemente el diseño de su trabajo mientras se está implementando. Esto conduce a más y mejores resultados. Los trabajos creativos objetivos, son una y otra vez refinados,. Las herramientas CASE OO (Orientado a Objetos) proporcionan a los constructores de software la capacidad para refinar el diseño durante la implementación.• Modelamiento más realísticoEl AOO modela la empresa o área de negocio de una manera más coherente y minuciosa que los métodos tradicionales de análisis. El análisis se traslada directamente al diseño e implementacion. En técnicas convencionales, el entorno del problema cambia cuando vamos del análisis al diseño y del diseño a la programación. Con técnicas de OO Análisis, Diseño e implementación, utiliza el mismo paradigma y lo refinan sucesivamente.• Mejor Comunicación entre Profesionales de Informática y los usuarios finalesLos usuarios finales entienden mejor el paradigma OO. Ellos piensan en términos de eventos, objetos y políticas de negocios que describen el comportamiento de los objetos. Las metodologías OO estimulan el mejor entendimiento, cuando el usuario final y los desarrolladores comparten un modelo común.• Modelos Inteligentes de la EmpresaLos modelos de la empresa debería escribir las reglas del negocio con las cuales el ejecutivo desearlas administrarla. Esto debería ser expresado en términos de eventos y de cómo éstos cambian el estado de los objetos del negocio. El diseño de la aplicación debería ser derivando automáticamente como sea posible, el modelo del negocio.• Especificaciones y Diseños DeclarativosLa especificación y el diseño, construido con la formalidad de las herramientas CASE, deberían ser declarativas tanto como sea posible, fijando explícitamente lo que es solicitado. Esto permite al diseñador pensar en el usuario antes que en el computador.• Interface Gráfica Seductiva al UsuarioSe debería utilizar interfaces gráficas para usuarios, tal que ésta apunte al icono que relacione al objeto.Prof.: Oscar Núñez M.7Diseño Orientado a Objetos• Independencia de DiseñoLas clases son diseñadas independientemente de plataforma de operación, hardware o software.Las clases emplean requerimientos y respuestas de forma. Esto permite que ellos sean utilizados con múltiples sistemas operativos, DBMS, manejadores de redes, interfaces gráficas para usuarios, etc.• InteroperatividadSoftware de diferentes vendedores pueden trabajar juntos. Un vendedor puede utilizar clase de otros vendedores. La interoperatividad de software de diferentes vendedores es uno de los objetivos más importantes de los estándares de la OO. Software desarrollados independientemente en lugares separados, deberían ser capaces de trabajar juntos y presentarse como una unidad simple al usuario.• Computaci ón Cliente / S ervidorEn el sistema Cliente / Servidor, las clases en el software cliente deberían enviar sus requerimientos a las clases de software servidor y recibir respuestas. Una clase servidor puede ser utilizada por muchos clientes. Esto puede accesar al software únicamente a través de los métodos (así los datos se protegen de corrupciones).• Computación masivamente DistribuidaRedes alrededor del mundo emplearán directorios de software de objetos accesibles. El diseño orientado al objeto, es la clave para la computación masivamente distribuída. Las clases en una máquina interactuarán con cualquier otra, sin necesidad de saber dónde residen. Ellas envían y reciben mensajes en formatos estándares.• Computaci ón ParalelaLa velocidad de las maquinas., pueden ser ampliamente mejoradas mediante la instalación de computadoras en paralelo. Se pueden tener procesamientos simultáneos y concurrentes en múltiples chips de procesadores (eventualmente, un chip puede tener muchos procesadores). Objetos en diferentes procesadores se ejecutarán simultáneamente, cada uno de ellos actuando independientemente.• Alto Nivel de Automatización de Bases de datosLas estructuras en Base de Datos OO, están ligadas a métodos que toman acciones automáticas. Una Base de Datos OO, tiene su inteligencia construida en la forma de métodos, mientras que otras bases de datos no.

• Performance de MáquinasLa Bases de Datos Orientada a Objetos han demostrado una mayor performance que las bases de datos relacionales para ciertas aplicaciones con estructuras de datos más complejas. Las bases de datos OO, la computacion concurrente y el diseño OO prometen mayores saltos en la performance de las máquinas LAN'S basadas en sistemas Cliente/Servidor. Emplearán servidores de Base de Datos concurrentes y orientadas al objeto.• MigraciónExistiendo o no aplicaciones orientadas a objetos, ellos pueden ser preservados convenientemente con una cobertura OO, comunicándose entre ellos mediante mensajes estándares OO.• Mejores herramientas CAS ELas herramientas Case utilizarán técnicas gráficas para diseñar las clases y sus interacciones, y para utilizar objetos existentes adaptados en nuevas aplicaciones. Las herramientas deberían facilitar el modelamiento en términos de eventos, trig gers (iniciadores), estado de los objetos, etc. Las herramientas de los CASE OO generan códigos tan pronto como una clase sea definida y permitirá al diseñador probar y utilizar el método creado. Las herramientas deberán ser diseñadas para estimular la máxima creatividad y continuo refinamiento del diseño durante la construcción.• Industriales de Librerías de ClasesLas compañías de software comercializarán librerías para diferentes áreas de aplicación. Las librerías de clases independientes de las aplicaciones, serán también importantes y éstas serán proporcionadas como facilidades de herramientasCASE (VIC).• Librerías de Clases CorporativasLas corporaciones, crearán sus propias librerías de clases que reflejen sus estándares internos y requirimientos de aplicación. La identificación TOP-DOWN de los OBJETOS del negocio, es un aspecto importante de la ingeniería de la Información.Prof.: Oscar Núñez M.8Diseño Orientado a ObjetosUML, (Unified Modeling Language). Seguramente habrá observado sistemas de información computarizados y no computarizados, y en un porcentaje mínimo tenemos a los usuarios que están conforme con los programas desarrollados, o tal vez hemos conversado con usuarios que han deseado modificar un sistema integrado y dicho cambio le ha producido el desequilibrio de otras unidades del sistema incorporado, o ha encontrado desarrolladores que sin conocer correctamente los procesos empiezan construyendo formulario tras formulario y desarrollan la aplicación, todo esto conlleva a poder analizar las causas que generan este desequilibrio es el incorrecto análisis de los procesos para la construcción de software de aplicaciones comerciales.Para ello el UML, (Unified Modeling Language), Lenguaje Unificado de Modelado esta compuesto por una gama de diagramas o artefactos, que permiten graficar o tomar una radiografía a los procesos para una interpretación de los mismos desde el punto de vista de usuario como de los desarrolladores de Software. UML es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estándar de facto de la industria, debido a que ha sido impulsado por los autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Estos autores fueron contratados por la empresa Rational Software Co. para crear una notación unificada en la que basar la construcción de sus herramientas CASE. En el proceso de creación de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, así como grupos de analistas y desarrolladores.Esta notación ha sido ampliamente aceptada debido al prestigio de sus creadores y debido a que incorpora las principales ventajas de cada uno de los métodos particulares en los que se basa (principalmente Booch, OMT y OOSE). UML ha puesto fin a las llamadas "guerras de métodos" que se han mantenido a lo largo de los 90, en las que los principales métodos sacaban nuevas versiones que incorporaban las técnicas de los demás. Con UML se fusiona la notación de estas técnicas para formar una herramienta compartida entre todos los ingenieros software que trabajan en el desarrollo orientado a objetos.

Uno de los objetivos principales de la creación de UML era posibilitar el intercambio de modelos entre las distintas herramientas CASE orientadas a objetos del mercado. Para ello era necesario definir una notación y semántica común. En la Figura 2 se puede ver cuál ha sido la evolución de UML hasta la creación de UML 1.3, en el que se basa este documento. Hay que tener en cuenta que el estándar UML no define un proceso de desarrollo específico, tan solo se trata de una notación.Desde principios de los 90, los artículos publicados en el Journal of Object Oriented Programming (JOOP) por James Odell, James Rumbaugh, Grady Booch, Desmond d'Souza, Bertrand Meyer, Steve Cook, John Daniels, Sally Shlaer y Stephen J. Mellor entre otros, han sido una constante fuente de conocimiento. Publicaciones pioneras como el Object Oriented Technology, A Manager's Guide de David A. Taylor, en su primera edición de 1990 y en la segunda

ampliada de 1998, han tenido una gran influencia en como abordar la presentación didáctica. También los libros de Peter Coad et al, Object Oriented Analysis, Design and Programming, Object Models y Java Modeling Color with UML, han sido de una ayuda extraordinaria. La obra enciclopédica The Unified Modeling Language: Reference Manual de Rumbaugh & Jacobson & Booch, es un punto de referencia constante. Sin duda, uno de los autores más influyentes ha sido Martin Fowler. Su primer libro Analysis Patterns continua siendo una referencia clave. Posteriormente, la primera edición de UML Distilled en 1997 y su última edición ampliada en 2000, se ha convertido en el libro de cabecera de UML. Otro clásico por la excelencia de su trabajo es Applying UML and Patterns de Craig Larman que en su segunda edición aparecida en verano de 2001 se ha superado a si mismo. También recientes y con muy buen material que ha sido incorporado a la guía, tenemos los libros de Wendy & Michael Boggs, Mastering UML with Rational Rose, de Alistair Cockburn, Writing Effective Use Cases; de Scott W. Ambler, The Object Primer segunda edición; y de John Chessman & John Daniels, UML Components, una de las novedades más interesantes de 2001.MAINSTREAM OBJECTSCombina una síntesis de las principales técnicas y enfoques OO.Prof.: Oscar Núñez M.9Diseño Orientado a ObjetosRumbaugh / Coad / Yourdon:• Estructura de Objetos• Ciclo de VidaJacobson:Enfoque Use Case (Casos de Usos; secuencia de transformación, para capturar requerimientos del sistemas)R.Wirfs - Brock:Responsability-Driven model (como estructurara la funcionalidad de un sistema OO.)La tecnología orientada a objetos persigue el antiguo principio del divide y vencerás. Su objetivo es descomponer la complejidad en partes más manejables y comprensibles. No parece que esto sea algo novedoso con respecto a la tradicional descomposición funcional de los métodos estructurados. Sin embargo, la gran diferencia reside en aplicar la dualidad estructura-función en pequeñas unidades capaces de comunicarse y reaccionar en base a la aparición de una serie de eventos. El esquema dominante de la separación de estructuras de datos y funciones (bases de datos y programas) está amenazado pero aún se resiste a desaparecer.Problemas en OO.Un objeto contiene datos y operaciones que operan sobre los datos, pero ...• Podemos distinguir dos tipos de objetos degenerados:■ Un objeto sin datos (que sería lo mismo que una biblioteca de funciones)■ Un objeto sin "operaciones", con sólo operaciones del tipo crear, recuperar, actualizar y borrar (que se correspondería con las estructuras de datos tradicionales)• Un sistema construido con objetos degenerados no es un sistema verdaderamente orientado a objetos ."Las aplicaciones de gestión están constituidas mayoritariamente por objetos degenerados".MODELOS UTILIZADOS POR ADOO. Modelo de Estructura de Objetos (OSM).El OSM es el modelo central. Contiene las clases de objetos requeridas para construir la aplicación y las relaciones entre ellas. Se construye a través de un proceso aditivo durante todo el ciclo de desarrollo del sistema.Modelo de Procesos de Negocios (BPM).El BPM describe los procesos que se llevan a cabo en la organización. Se lo utiliza para analizar la organización y comprender sus procesos, parte de los cuales (o todos), serán soportados por el sistema a desarrollar.Modelo de Secuencias de Transacciones (TSM).El TSM parte de la especificación de alto nivel del BPM y lo traslada en requerimientos para la aplicación (el TSM corresponde conceptualmente con los USE CASE - casos de uso - de Jacobson).Diagrama de Interacción de Objetos (OID).Los OID's muestran las interacciones entre objetos requeridas para proveer al usuario los servicios descritos en el TSM. Diagramas de Flujo de Actividad (AFD).Los AFD's son utilizados para analizar y presentar flujos de actividad complejos en los procesos de negocio y en las secuencias de transacciones (secuencias, iteraciones y decisiones).Diagrama de ciclo e vida de objetos (OLD).El OLD es utilizado para describir como un objeto cambia de estados en el tiempo y que eventos producen dichos cambios de estado.Modelo global del sistema (SGM).El SGM es utilizado para dividir el sistema en unidades de diseño manejables. Es una herramienta para manejar la complejidad de desarrollo de grandes sistemas. Especifica las interfaces entre las unidades de diseño.

Prof.: Oscar Núñez M.9Diseño Orientado a ObjetosModelo Estructural Modelo de Estructura de

(Estático) Objetos (OSM)

Modelo de Comportamiento (Dinámico)

Diagrama de Ciclo de Vida de Objetos (OLD)Diagrama de Interacción de Objetos (OID)Modelo Funcional

Modelo de Procesos de Negocios (BPM)Modelo de Secuencia de Transacciones (TSM)Prof.: Oscar Núñez M.10Diseño Orientado a ObjetosCOMPONENTES DEL OSM. 1. Clases de Objetos. Objetos Entidad.Representan algo real o abstracto sobre el cual el sistema necesita almacenar datos. Representa la memoria esencial del negocio. Los objetos del negocio (business objects) son normalmente objetos entidad. Se representan en el OSM con el siguiente s ímbolo:Membre Class

Objetos Interface.Representan los objetos técnicos requeridos para vincular la aplicación con el entorno. Representan el vínculo a través del cual el sistema recibe o suministra datos e información al entorno. Típicamente incluyen interfaces con el usuario (pantallas, reportes, etc.) e interfaces con otras aplicaciones. Se representan en el diagrama de estructura de objetos con el siguiente símbolo:«Interface» Nombre Clase

Objetos de Control.Contienen comportamiento que no pertenece naturalmente ni a Objetos Entidad ni de Interfaz. Son normalmente objetos transitorios, como ser un controlador de reportes. Se representan en el diagrama de estructura de objetos con el siguiente símbolo:Nombre Clase

Clases abstractas y concretas.Una clase de la cual pueden generarse instancias particulares (objetos), se denominan clase concreta.Una clase abstracta es aquella que no tiene instancias (objetos) propias. Las clases abstractas son un poderoso mecanismo conceptual para definir estructuras comunes de atributos, operaciones y restricciones, reutilizadas a través de la herencia por múltiples clases concretas.En el diagrama de estructura de objetos una clase abstracta se representa con un rectángulo punteado.Prof.: Oscar Núñez M.10Modelo de Estructura de Objetos (OSM) UML: Diagrama de Clases (Class Diagram)El OSM es el modelo fundamental que provee un medio uniforme par modelar el sistema desde la captura de requerimientos en la etapa inicial del análisis hasta la implementación, atravesando todo el ciclo de desarrollo del sistema.Es te modelo identifica:• Las clases de objetos en la aplicación.• Como las clases de objetos se asocian unas con otras.• Como se comunican los objetos.• Los detalles de cada clase de objetos, incluyendo atributos y operaciones.Durante el proceso de análisis y diseño, el OSM es definido en sucesivos niveles incrementales de detalle, hasta que el nivel necesario para la implementación es alcanzado.Todos los demás modelos capturan detalles que alimentan este modelo.El desarrollo de OSM es un proceso aditivo, diferenciándose del enfoque transformacional característico de otros métodos como el estructurado, donde los DFD son transformados en diagramas de estructura, con los consiguientes problemas que esto acarrea.Diseño Orientado a Objetos2. Características de las Clases de Objetos.Operaciones.Una operación define un servicio ofrecido por un objeto junto con la información que debe suministrarse cuando es invocado (nombre, argumentos de entrada y/o salida). También puede contener una especificación de método, el cual especifica una implementación para la operación.Durante la etapa de Análisis o Diseño Lógico pueden utilizarse típicamente texto libre o pseudocódigo. Durante el Diseño Físico dichas especificaciones son trasladadas a un lenguaje de programación específico, como por ejemplo: C++, Java, Visual Basic, etc.Algunas operaciones pueden asumirse que existen para cada clase de objetos sin identificarlas formalmente. Estas son llamadas operaciones implícitas. Las operaciones implícitas más importantes son: Crear, Destruir, Leer y Actualizar. Una operación implícita debe ser formalmente definida cuando sus pre y post condiciones no sean triviales.La identificación y especificación de operaciones es una tarea clave durante el Diseño Lógico.Atributos.Son valores de datos asociados a los objetos de una clase a la cual describen. Están fuertemente asociados con la clase de objetos que los contienen, de tal forma que no tienen existencia independiente o identidad de objeto. La decisión de cuando un ítem debe considerarse como atributo o como clase varía de sistema en sistema, dependiendo de su semántica

en el dominio del problema, es decir, lo que en un sistema se modela como atributo en otro puede modelarse como una clase.Cada atributo identificado debe ser atómico en el sentido de que debe ser tratado como una unidad, es decir, puede ser un valor simple o un grupo de valores tratados siempre como una unidad (PE. Dirección). Debe notarse que las clases no se modelan en formas normales. La decisión sobre la estructura de datos a utilizar se difiere hasta el Diseño Físico.Los atributos pueden basarse en definiciones de tipos de atributos, lo cual provee una definición estándar sobre formato, longitud y dominio de valores para atributos del mismo tipo.Restricciones.Las restricciones pueden especificarse sobre los valores que un atributo puede tomar. La implementación de las restricciones puede realizarse de diferentes formas:• Reglas de validación durante los procesos de entrada de datos (user inputs).• Database-level triggers• Lógica de control contenida en una o más operaciones.3. Asociaciones entre Objetos.a) Relaciones Estáticas.Las relaciones estáticas describen como los objetos se asocian unos con otros en la misma forma que en el modelo Entidad-Relación. Identifican así mismo dependencias entre objetos, cuando un objeto requiere de la existencia de otro ya sea de la misma clase o de otra. Las relaciones estáticas se establecen usualmente entre objetos de tipo entidad.Al igual que los atributos, las relaciones modelan información sobre un objeto (cosas que un objeto debe conocer sobre sí mismo). Estas son propiedades de un objeto. Los atributos son valores de datos. Las relaciones son valores que se referencian otros objetos.Una relación estática se representa en el diagrama de estructura de objetos como una línea sólida entre las clases de objetos , con símbolos de cardinalidad en sus extremos. Las relaciones pueden etiquetarse para identificar el propósito de la asociación. El diseñador puede optar por:■ Un nombre para cada dirección de la relación.■ Un nombre para una dirección de la relación.■ Un solo nombre que representa ambas direcciones de la relación.■ Sin nombre.Por cuestiones de simplicidad, las relaciones son modeladas como binarias, es decir, solo dos clases de objetos, no necesariamente distintas, participan en relación. Es posible que entre el mismo par de clases exista más de una relación.La cardinalidad identifica el número máximo y mínimo de instancias de una clase (objetos) que participan en una relación dada, en el mismo sentido que lo hacen en el modelo Entidad-Relación. En el diagrama de estructura de objetos utilizaremos la notación de "pata de gallo" para especificar cardinalidades, aunque puede utilizarse otras como ser pares ordenados, flechas (Bachmann), etc.Prof.: Oscar Núñez M.11Diseño Orientado a ObjetosPueden observarse las siguientes cardinalidades:

Mínimo 0 - Máximo 1Mínimo 1 - Máximo 1Nombre Clase Nombre Clase

a,* U*

Mínimo 0 - Máximo N Mínimo 1 - Máximo Nb) Herencia.La herencia es el mecanismo a través del cual los atributos, operaciones y restricciones definidas para una clase, denominada superclase, pueden ser heredados (reutilizados) por otra clase denominadas subclases. La herencia utiliza el principio "es un tipo de Una subclase puede redefinir operaciones heredadas. Adicionalmente, una subclase puede definir nuevos atributos y operaciones.Se distingue entre herencia simple y múltiple. La herencia simple se da cuando una subclase hereda de una única superclase. En el caso de la herencia múltiple, una subclase puede heredar de varias superclases.En el OSM, la relación de herencia se representa de la siguiente manera:

PE.:

c) Agregación.La agregación es un tipo de asociación fuerte, donde los objetos de una clase se componen de objetos de otra(s) clase (s). Se diferencia de de las relaciones estáticas en la fuerza semántica del vínculo. En una relación de agregación un objeto compone otro. En la relación estática existe un vínculo pero no una compo sición. La agregación es la aplicación del principio " el todo y sus partesEn el OSM, la relación de agregación se representa de la siguiente manera:Prof.: Oscar Núñez M.12Diseño Orientado a Objetos

PE.

d) Comunicación por Mensajes.Las asociaciones por comunicación pueden utilizarse para mostrar que objetos de una clase se comunican con objetos de otra clase o de la misma. Una asociación por comunicación corresponde al conjunto de mensajes que son enviados por los objeto s de una clase a los objetos de otra clase o de la misma. Típicamente, la asociación por comunicación es la única asociación existente entre objetos de los tres diferentes tipos.En el OSM, la asociación por comunicación se representa de la siguiente manera:Emisor Riicr-ptor

7

4. Consideraciones: Técnicas avanzadas de OSM.Visibilidad Define que objetos puede acceder y utilizar los atributos y operaciones de un objeto dado. Público: todos.Protegido: Sólo desde el objeto mismo y operaciones definidas en subclases.Privado: Sólo desde el objeto mismo.Atributos identificadores. Son atributos o grupos de atributos que identifican unívocamente un objeto de una clase, se corresponde con el concepto de Clave del modelo E-R.Atributos Derivados. Son atributos cuyo valor puede obtenerse a partir de los valores de otros atributos.Relaciones Derivadas. Relaciones transitivas que se derivan de otras relaciones estáticas. En el OSM las relaciones derivadas se representan de la siguiente manera:Relaciones Ordenadas. Los objetos del extremo "muchos" de una relación se presentan en forma ordenada. Es particularmente útil para especificar que los objetos componentes de un agregado están ordenados. Por ordenado, entendemos queProf.: Oscar Núñez M.

13Diseño Orientado a Objetoslos objetos componentes serán accedidos en una secuencia específica predefinida. En el OSM las relaciones ordenadas se representan de la siguiente manera:Atributos y Operaciones de Clase. Definen el comportamiento de la clase misma más allá del comportamiento de sus instancias. Los atributos de la clase son utilizados para registrar datos comunes a todos los objetos (instancias) de una misma clase. Las operaciones de clase actúan sobre la clase misma como un objeto. El caso típico son las operaciones Crear y Destruir.Modelo de Datos vs Modelo de Objetos• Una BD se desarrolla mediante un Modelo de Datos.1) Se construye el Modelo de Datos sobre el dominio de la aplicación.2) Se transforma del Modelo de Datos en un Diseño de la BD mediante la aplicación de una serie de transformaciones estándar (normalización).• Un Sistema de Objetos se construye modelando mediante técnicas diferentes, pues las técnicas del Modelo de Datos son bastante limitadas para soportar el Modelo de Objetos.Consejos prácticos• No comenzar construyendo diagramas de clases; primero, es necesario comprender el problema.• Intentar mantener el Modelo sencillo.• Seleccionar con cuidado los nombres.• No introducir punteros o referencias a otros objetos como atributos.• Intentar evitar asociaciones n-arias.• No intentar establecer el grado de multiplicidad perfecto al principio.• No introducir atributos de enlace dentro de la clase.• Utilizar as ociaciones cualificadas donde sea posible.• Intentar evitar generalizaciones profundamente anidadas.• Intentar asociaciones uno a uno.• No se sorprenda si su modelo requiere una revisión.• Documentar siempre los Modelos de Objetos.Prof.: Oscar Núñez M.13Diseño Orientado a ObjetosModelo de Clases (UML)Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.Un diagrama de clases esta compuesto por los siguientes elementos:• Clase: atributos, métodos y visibilidad.• Relaciones: Herencia, Composición, Agregación, Asociación y Uso. Elementos:CLASEEs la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).En UML, una clase es representada por un rectángulo que posee tres divisiones:<Nombie Clase :><A(ributos><0p« aciones o Métodos>

En donde:o Superior: Contiene el nombre de la Claseo Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public).o Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).Ejemplo:Una Cuenta Corriente que posee como característica:o Balance Puede realizar las operaciones de:o Depositaro Giraro y Balance El diseño asociado es:Cuenta ^balance: ¡nt*ciepos¡tar(monto : ¡nt): void *g¡rar(monto : int): boolean ♦balanceo : ír|tATRIBUTOS Y MÉTODOS:1. Atributos:Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son:■ public (+, ^)'■ Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.■ private (-, ^Nr/ Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar).■ protected (#, ^ y. Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).2. Métodos:Prof.: Oscar Núñez M.13Diseño Orientado a ObjetosLos métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:■ public (+, ~): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.i: Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden accesar).

protected (#, v ): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia).3. Relaciones entre Clases:Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes).Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:o uno o muchos: 1..* (1..n)o 0 o muchos: 0..* (0..n)o número fijo: m (m denota el número).HERENCIA (Especialización/Generalización):Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected).Ejemplo:

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir, Auto posee las Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es Descapotable, en cambio Camión también hereda las características de Vehiculo (Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.Cabe destacar que fuera de este entorno, lo único "visible" es el método Características aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición publica, en cambio atributos como Descapotable no son visibles por ser privado s.■■

AGREGACIÓN:Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades:• Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comunmente llamada Composición (el Objeto base se contruye a partir del objeto incluido, es decir, es "parte/todo").■

Prof.: Oscar Núñez M.14Diseño Orientado a ObjetosPor Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).Ejemplo:

En donde se destaca que:• Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).• Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.• La composición (por Valor) se destaca por un rombo relleno.• La agregación (por Referencia) se destaca por un rombo transparente.La flecha en este tipo de relación indica la navegabilidad del objeto referenciado. Cuando no existe este tipo de particularidad la flecha se elimina.ASOCIACIÓN:

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado uncliente.■

■ DEPENDENCIA O INSTANCIACIÓN (uso):

---------->Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el objeto Aplicación):Aplicación .....------> Ventana

Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicación).CASOS PARTICULARES:■ Clas e Abs tracta:Empleado

2^Operario Gerente

Prof.: Oscar Núñez M.15Diseño Orientado a ObjetosUna clase abstracta se denota con el nombre de la clase y de los métodos con letra "itálica". Esto indica que la clase definida no puede ser instanciada pues posee métodos abstractos (aún no han sido definidos, es decir, sin implementación). La única forma de utilizarla es definiendo subclases, que implementan los métodos abstractos definidos.■ Clas e parametrizada:KEY, ÍTEMDiccionario♦Definir(key : KEY, item : ÍTEM) »Consultar(key : KEY) : ÍTEMUna clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los parámetros que deben ser pasados a la clase para que esta pueda ser instanciada. El ejemplo más típico es el caso de un Diccionario en donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden ser genéricos. La genericidad puede venir dada de un Template (como en el caso de C++) o bien de alguna estructura predefinida (especialización a través de clases).En el ejemplo no se especificaron los atributos del Diccionario, pues ellos dependerán exclusivamente de la implementación que se le quiera dar.Prof.: Oscar Núñez M.15Diseño Orientado a ObjetosModelo de Procesos de Negocios (BPM) y Secuencia de Transacciones (TSM) UML: Casos de Usos (Uses Case)Los requerimientos para una aplicación de negocios deben basarse en las actuales actividades del negocio, que la aplicación deberá soportar.El Modelo de Procesos de Negocios (BPM) es usado durante el análisis del negocio (análisis del sistema actual) y provee un medio para describir el negocio.El Modelo de Secuencia de Transacciones (TSM) es usado durante el análisis de requerimientos del negocio y provee un medio para describir la funcionalidad requerida de la aplicación para soportar los procesos de negocios.El enfoque en los procesos de negocio durante el análisis del negocio provee el punto de partida para determinar qué se requiere de la aplicación. Durante el análisis de requerimientos decidimos qué parte de los procesos de negocio deben computarizarse y describimos dichos requerimientos usando una o más secuencias de transacción (determinación de las fronteras de automatización).Las secuencias de transacciones modelan qué es lo que el usuario requiere de la aplicación (su contenido funcional); proveen la navegabilidad desde los requerimientos del usuario a los objetos y operaciones que implementan dicha funcionalidad; proveen también un medio adecuado para comunicarse con el usuario, en un lenguaje y nivel de abstracción que él pueda comprender con facilidad.Como parte del proceso de Diseño Lógico, las secuencias de transacciones son analizadas para identificar como los objetos y sus operaciones proveen la funcionalidad requerida. Posteriormente, durante el proceso de testeo de la aplicación, sirven de base para definir casos de testeos.Proceso de Negocio (PN).

Un proceso de negocios es una colección de actividades que toman uno o más tipos de entrada y crea una salida de valor para el cliente.Un proceso de negocios describe desde el comienzo al fin, la secuencia de eventos requeridos para producir un resultado de negocio significativo. El cliente puede ser externo o interno a la organización.Los procesos de negocios típicamente atraviesan los límites de la organización y de sus departamentos internos, evitando la clásica visión de departamentos estáticos (organigrama jerárquico). Por este motivo, cualquier modificación drástica a un pro ceso de negocios implica un cambio en la estructura organizacional.Entradas y/o EventosEventoProceso de Negocio

ProductoT T T

Salidas Menores¿Cómo identificar y definir PN?.1. Se identifican los productos y/o servicios significativos, de los que es responsable el negocio y se asocia cada uno de ellos a uno o más procesos de negocios.2. Se identifican las entradas y eventos disparadores que inician cada proceso de negocio y se da un nombre a cada PN.3. Cada PN se describe especificando las actividades de alto nivel que se requieren para producir los productos y/o servicios.Secuencia de Transacciones (ST).El concepto de secuencia de transacciones es muy similar al concepto de "Casos de Uso" (UML), introducido por Jacobson en su metodología OOSE y de amplia difusión actualmente.Una secuencia de transacciones es conceptualmente similar a un proceso de negocios, la diferencia radica en su alcance. El proceso de negocio se utiliza para comprender y modelar el funcionamiento de la empresa (negocio). Las secuencias de transacciones se utilizan para modelar los requerimientos funcionales de la aplicación que soportará determinados procesos de negocios.Los procesos de negocio son trasladados en secuencias de transacciones durante el análisis de requerimientos. El alcance de una secuencia de transacciones es el mismo de un proceso de negocios o de un subproceso muy significativo. Una secuencia de transacciones puede implicar más de un usuario y función y puede extenderse en el tiempo, esto es no tener resolución inmediata.Prof.: Oscar Núñez M.16Diseño Orientado a ObjetosActores nombre

Secuencia de Transacción o Proceso de Negocio. (^^ombre^^

Evento C / - Evento -----

-*Q CasoUsol j

\

Comunicación entre Actor y ST's. -►Borde del Sistema

1 1

Descripción Textual.1. Abs tracto. Breve descripción del proceso de negocios o secuencia de transacciones.2. Contexto del Negocio. Especifica:a) el resultado de la ST o PN (productos y/o servicios)b) el cliente de la ST o PNc) el valor que gana el cliente con la ST o PNd) el evento que inicia la ST o PNe) entradas requeridas por la ST o PNf) descripción de alto nivel de la ST o PNg) requerimientos especiales que controlan la ejecución de la ST o PN 2) Camino estándar y alternativo.El camino estándar es una descripción secuencial de todas las actividades que deben realizarse para alcanzar el resultado. Par una ST describe las actividades de los actores y que debe hacer la aplicación en orden de servir dichas actividades. Para un PN describe las actividades de alto nivel del proceso y quién las realizaProf.: Oscar Núñez M.16El proceso de identificar requerimientos del usuario y secuencias de transacciones puede asistirse con la prototipación de interfaces.¿Cómo identificar y definir ST?1. Identificación a través de actores.Identificar los actores que se comunicarán con el sistema, luego para cada actor considerar:

a) ¿Cuáles son las principales tareas del actor?b) ¿Qué accesos (lectura o escritura) requiere el actor del sistema?c) ¿Cuándo el actor informará al sistema acerca de cambios fuera del sistema?d) ¿Cuándo el actor será informado de cambios a través del sistema?2. Identificación a través de eventos.Consiste en identificar a qué eventos externos o temporales, debe ser capaz de responder el sistema, para ello:a) Confeccionar la lista de eventosb) Asociar una secuencia de transacciones para cada evento identificadoComponentes y Herramientas de Modelado de Procesos de Negocios y Secuencias de Transacciones.Para modelar y documentar procesos de negocios y secuencias de transacciones se utilizan los mismos diagramas y documentos, los cuales son:1) Diagrama de Secuencia de Transacciones (TSD)Diseño Orientado a ObjetosLos caminos alternativos se describen separadamente pero pertenecen a la misma ST o PN. Describen casos inusuales de procesamiento y manejos de excepciones o errores. Esta separación se realiza para facilitar el modelado y lectura de los caminos estándar.Para modelar y diagramar los caminos estándar y alternativos, respectivamente, se utilizan los Diagramas de Interacción de Objetos (OID) y los Diagramas de Flujo de Actividad (AFD).3) Actores.En el BPM representan los profesionales del negocio y sistemas de computación involucrados en producir un producto o s ervicio.En el TSM representan agentes externos que interactúan con la aplicación. Pueden representar usuarios humanos o interfaces con otros sistemas.Cada actor es usado para modelar un rol, el cual puede ser desempeñado por un usuario individual o grupo de usuarios.4) Observación.Subdivis ión de procesos de negocios.Los PN pueden ser subdivididos en subprocesos. Las dos formas principales para realizar esto son:• Especialización. Es la especialización del PN en distintos tipos que producen el mismo resultado pero tienen diferentes conjuntos de actividades.• Particionamiento. Es el particionamiento del PN a lo largo del eje de tiempo en una secuencia de subprocesos.Casos de Uso (Use Case)El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).Un diagrama de casos de uso consta de los siguientes elementos:• Actor.• Casos de Uso.• Relaciones de Uso, Herencia y Comunicación. ElementosACTOR:

Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.CASO DE USO:

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.RELACIONES:• As ociación

->Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.Prof.: Oscar Núñez M.17Diseño Orientado a Objetos• Dependencia o Ins tanciación

.........->Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.• GeneralizaciónEste tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).ExtendsSe recomienda utilizar cuando un caso de uso es similar a otro (características).Us es

Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.Prof.: Oscar Núñez M.18Diseño Orientado a ObjetosModelo de Interacción de Objetos.El modelo de interacción de objetos modela la manera en que colaboran los objetos de un sistema para proveer la funcionalidad descrita en una secuencia de transacciones. Su utilidad primaria se da durante la etapa de diseño lógico.La Interacción de Objetos se produce cuando un objeto envía un mensaje a otro con el objetivo de utilizar o requerir la funcionalidad de la operación invocada de parte del receptor del mensaje.El modelo de interacción de objetos provee el enlace entre las descripciones de las secuencias de transacciones y las especificaciones de operaciones elementales a nivel de objetos.Asisten en la identificación de clases de objetos y operaciones requeridas, considerando como una determinada funcionalidad debe distribuirse en operaciones de diferentes clases de objetos (responsabilidades de objetos), y como los objetos deben colaborar para proveer la funcionalidad descrita en las secuencias de transacciones.La herramienta de modelado fundamental para el modelo de interacción de objetos es el diagrama de interacción de objetos (OID). Normalmente se usa un OID para cada secuencia de transacciones concentrándose en el camino estándar.Utilización del modelado de interacción de objetos.• Modelado de procesos de negocios: es una técnica adicional que puede utilizarse para comprender un proceso de negocios en particular. Se considera al sistema como una "caja negra" y se lo representa como actor (interfaz de máquina).• Análisis de requerimientos: no es muy utilizado ya que el propósito de esta etapa es definir requerimientos, no diseñar.• Diseño lógico: se utiliza un OID para cada secuencia de transacciones definida en el análisis de requerimientos, para determinar con claridad que clases, operaciones y responsabilidades se necesitan. Se mira dentro de la caja negra (tal como se la ve en el modelo de proceso de negocio) y se determina que objetos participan para implementar la funcionalidad requerida del sistema.Diagrama de interacción de objetos (OID) para un proceso de negocios (PN).Actor 1Actor 2 Actor 3 Sistem a 1Evento 1

-HEvento 5

H-H-Evento 2

-HEvento 4Evento 3

-HElementos:1. Actores en la parte superior del diagrama. Pueden ser humanos o sistemas vistos como cajas negras2. Una línea vertical asociada a cada actor3. Requerimientos o eventos enviados por un actor a otro. Se representan por flechas. Se utiliza una sola flecha para representar el estímulo y la respuesta implícita.4. Etiquetas en el margen izquierdo representando links a actividades de un diagrama de flujo de actividades.12Prof.: Oscar Núñez M.18Diseño Orientado a ObjetosDiagrama de interacción de objetos (OID) para una secuencia de transacciones (ST).

|— Obj.1 |— Obj.2 |—| Obj.3Obj.4Obj.5Descripción narrativa de la ST.

-HK--HH--H-H-H23Elementos:1. Barra vertical a la izquierda representa el límite del sistema.2. Se acompaña con la descripción narrativa de la secuencia de transacciones a la izquierda de esta.3. Una flecha proveniente desde el límite representa un requerimiento externo generado por un actor. Es conveniente que los requerimientos/respuestas de este tipo se representen por flechas individuales.

4. Operaciones: se representan por rectángulos alargados sobre los ejes correspondientes a los objetos que las realizan. Permite visualizar que mensajes dispara una operación. La longitud de la barra no representa duración.5. Actividades: bloques de eventos que siempre ocurren en una determinada secuencia. Dichas actividades que pueden ocurrir en paralelo, condicional o iterativamente, pueden modelarse con un diagrama de flujo de actividad asociado.Cas os es peciales .1. Invocación de operaciones "in-self". A menudo una operación de un objeto invoca a otra operación de la misma clase. Esto puede representarse de la siguiente forma:-H

J2. Múltiples objetos de una misma clase. Se representa la clase más de una vez.Prof.: Oscar Núñez M.19Diseño Orientado a Objetos3. Secuencias comunes.Usualmente se dibujan diagramas por separado para las secuencias comunes y su invocación se representa con una flecha punteada.-H---►

Diagrama de Interacción.El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en petición a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades claramente.Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o el de Casos de Uso (son diferentes).Los componentes de un diágrama de interacción son:• Un Objeto o Actor.• Mensaje de un objeto a otro objeto.• Mens aje de un objeto a si mismo.Elementos• OBJETO/ACTOR:

El rectángulo representa una instancia de un Objeto en particular, y la línea punteada representa las llamadas a métodos del objeto.• MENSAJE A OTRO OBJETO:

Se representa por una flecha entre un objeto y otro, representa la llamada de un método (operación) de un objeto en particular.• MENSAJE AL MISMO OBJETO:

No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a métodos desde el mismo objeto en estudio.Prof.: Oscar Núñez M.19Diseño Orientado a ObjetosDiagrama de Flujo de Actividad ( A I D )Los OID no muestran decisiones, interacciones, o la posibilidad de que partes del procesamiento puedan realizarse en secuencias aleatorias o concurrentemente. Una manera de describir esto es con descripciones textuales en el margen izquierdo del OID, o utilizando diagramas de flujo de actividad (AFD). Los AFD son un tipo particular de los clásicos "flowcharts".Actividad: es una secuencia de interacciones entre objetos.El alcance de una actividad queda normalmente definido por el hecho de que una secuencia de interacciones dada es condicional, iterativa, o puede ocurrir antes o después de otras secuencias de interacciones.Simbología de los AFD.Actividad.

Flujo entre una actividad y la siguiente. InicioTerminación.Decisión: división del flujo de actividades según la condición.

Sincronización.

7Obs ervación.• Un AFD puede incluir actividades que no estén en un camino estándar pero que aparezcan en un camino alternativo.• Pueden existir actividades sin interacciones asociadas que se utilizan para clarificar la lógica del flujo.• Puede utilizarse un AFD sin OID asociado simplemente para describir la lógica del flujo en un camino estándar/alternativo.• Generalmente, un OID es utilizado para modelar cada secuencia de transacciones. Es posible más de un OID por secuencia de transacciones y se describen a continuación dos enfoques alternativos.o Usando AFD para modelar operaciones.Los AFD pueden ser utilizados en combinación con los OID. En un AFD cada bloque normalmente representa un grupo de eventos que ocurren siempre en la misma secuencia. Otra opción es mostrar un bloque en un AFD para representar cada posible estímulo externo para una secuencia de transacciones. Tal estímulo externo (u operación del sistema) puede ocurrir a menudo en secuencias aleatorias o en secuencias alternativas. Un OID puede desarrollarse para cada uno de tales bloques u operaciones del sistema.Sin embargo, se recomienda utilizar un OID simple para toda la secuencia de transacciones siempre que sea posible, debido a que esto brinda una visión general para todo el proceso requerido.o OID's, ST's y Escenarios.Generalmente se desarrolla un solo OID por cada secuencia de transacciones. Este diagrama muestra un caso general omitiendo caminos alternativos inusuales. No muestra un escenario de ejecución que pueda ocurrir en una ocasión específica. En casos complicados, puede ser útil desarrollar OID's alternativos representando los caminos alternativos.Prof.: Oscar Núñez M.20Diseño Orientado a ObjetosModelo de Ciclo de Vida de Desarrollo de ObjetosConceptos y propósito del modelo de ciclo de vida de objetos.El modelo de ciclo de vida de objetos se utiliza para describir los aspectos dinámicos de los objetos. Modela lo que ocurre dentro de los objetos de una clase: estados, cambios de estado, y eventos que producen dichos cambios de estado.El estado de un objeto de una clase está dado por el conjunto de valores de sus atributos en un instante dado de tiempo.Durante su ciclo de vida, desde que son creados hasta que son destruidos, los objetos atraviesan por diferentes estados. La importancia de estudiar el ciclo de vida de los objetos y de sus estados, se debe a que muchos objetos exhiben comportamiento s estado-dependientes.Es especialmente importante reconocer comportamientos de objetos que son dependientes del tiempo y del estado previo, ya que pueden agregar una complejidad considerable a la aplicación. Ciertas operaciones y/o atributos pueden ser válidos sólo en ciertos estados. Sólo deben modelarse los estados de un objeto que son relevantes al dominio del problema que se está modelando.Las transiciones de estados de un objeto son causadas por la recepción de un evento interno o externo al sistema. El estado que asume un objeto luego de recibir un evento depende del estado actual, del evento recibido, y opcionalmente del valor de una condición de guarda. Cuando un objeto recibe un evento ejecuta una acción (que corresponde con una operación) asociada con un a transición. Al fin o durante la ejecución de dicha acción, el objeto produce el cambio de estado. Puede d arse que el estado final sea el mismo que el inicial.Utilización del modelo de ciclo de vida de objetos.Siempre que se agrega una nueva clase al OSM es importante examinar si se presentan estados significativos para los objetos de la misma. Si es asi puede utilizarse el modelo de ciclo de vida en orden de comprender correctamente el ciclo de vida de dichos objetos. El modelo de ciclo de vida es útil en las etapas de análisis del negocio y de requerimientos, para obtener una clara comprensión de los objetos claves descubiertas y de los caminos estándar y alternativos involucrados.Herramientas de modelado. Diagrama de ciclo de vida de objetos.La herramienta que se utiliza para modelar el ciclo de vida de objetos es el diagrama de ciclo de vida de objetos (OLD). Un OLD se aplica sólo a una clase de objetos.El OLD representa:• Cómo los objetos son creados.• Cómo los objetos son destruidos.• Cómo los objetos cambian a través del tiempo.• Qué estados típicamente asume un objeto.• Qué eventos causan cambios de estado.• Qué acciones realiza un objeto cuando recibe un evento que produce un cambio de estado.Componentes del OLD.Punto de entrada. Instante previo a la creación de un objeto. Punto de salida. Momento en el que deja de existir un objeto.

Estado. Conjunto de valores de los atributos de un objeto en un instante de tiempo. LTransición o cambio de estado.IEvento [condición de guarda! AcciónProf.: Oscar Núñez M.20

Diseño Orientado a ObjetosModelo Global del SistemaConceptos y propósito del modelo del modelo global del sistema.El modelo global del sistema posibilita tener una visión general del modelo de estructura de objetos del sistema, asistiendo en el manejo de la complejidad.Las principales razones para utilizar un modelo global del sistema son:• Posibilita el particionamiento de una tarea de análisis o desarrollo. Para grandes sistemas, subsistemas pueden ser asignados a diferentes equipos o subproyectos.• Puede utilizarse para definir unidades de entrega, PE: unidades funcionales (módulos) que deban entregarse al usuario en sucesivas fechas de liberación, o componentes de producto.• Puede utilizarse para definir unidades distribuíbles.• Puede utilizarse para validar el diseño de un sistema y asegurar que está bien diseñado para soportar el cambio.• Incluye un diagrama (el diagrama de visión general del sistema) que puede utilizarse para producir una visión general de un modelo del análisis o de un subsistema, asistiendo con la presentación de un modelo o subsistema a un nivel de visión general.Una característica importante del modelo global es que permite el modelado de interfaces entre subsistemas. Esto se logra modelando los servicios que un subsistema ofrece para ser utilizados por otro subsistema.ConceptosEl modelo global implica la subdivisión del espacio de problema en componentes. En un enfoque de desarrollo orientado a objetos, esto se alcanza agrupando clases de objetos. El modelado orientado a objetos difiere aquí de las técnicas estructuradas, en que en estas, los subsistemas usualmente agrupan funciones, no objetos.Las secuencias de transacciones no necesariamente residen en un único subsistema. Pueden requerir el soporte de objetos pertenecientes a más de un subsistema o componente.El espacio del problema y sus componentes.Durante la etapa de análisis del negocio, el espacio del problema es el dominio del negocio, y podemos optar por dividir dicho dominio en áreas sujetos. Cada área sujeto contiene clases de objetos semánticamente relacionadas unas a otras, vinculadas con el mismo sujeto.Durante el desarrollo, el espacio del problema es el sistema o subsistema que se construye. Esto también puede ser subdividido en submodelos o subsistemas. Los submodelos son utilizados principalmente con propósitos de presentación. Los subsistemas son definidos por razones técnicas como ser: definición de unidades de distribución, y definición de módulos, importante para validar y preservar la mantenibilidad del sistema.Otro uso del particionamiento es la subdivisión arquitectural, la cual es particularmente importante durante el diseño físico. Se recomienda la división de todo sistema en seis subsistemas arquitecturales:• El componente dominio de problema: es el más importante y en el cual nos concentramos durante el análisis de requerimientos y el diseño lógico.• El componente de Interfaz humana: introducido en el diseño lógico.• El componente de interfaz externa: introducido durante el diseño lógico.• El componente de administración de datos: introducido durante el diseño físico.• El componente de administración de tareas: introducido durante el diseño físico.• El componente de servicio de utilidades: introducido durante el diseño físico.Prof.: Oscar Núñez M.21Diseño Orientado a ObjetosDefinición del alcance de un subsistemaBásicamente, las clases de objetos que tienen un alto grado de interdependencia y sirven a un propósito común, deben asignarse al mismo subsistema. Usualmente, jerarquías de herencia y agregación, deben ser asignadas completamente a un subsistema.Debe notarse que si existen objetos que son requeridos por diferentes subsistemas, entonces dichos objetos no deben asignarse a un subsistema.ServiciosUn subsistema provee sus servicios vía una interface, la cual es un conjunto de operaciones que los clientes de un subsistema pueden utilizar. Son útiles estas operaciones en servicios. Cada servicio agrupa operaciones relacionadas que tienen un propósito común.Los servicios provistos por un subsistema a otro, o a actores, pueden identificarse determinando que comunicaciones son posibles entre subsistemas, y agrupar estas en servicios. Es conveniente que esto se realice durante ci diseño lógico, cuando las operaciones han sido definidas.Los subsistemas pueden vincularse en relaciones cliente-servidor o partner to partner (compañero a compañero). En este último caso, un subsistema puede ser cliente y servidor a la vez.Particiones verticales y horizontalesUn sistema puede ser particionado horizontalmente (en capas) o verticalmente. Las particiones verticales son usadas para subdividir la funcionalidad de la aplicación, mientras que las particiones horizontales son particularmente útiles para aislar las aplicaciones de capas de software de menor nivel como ser sistemas operativos, bases de datos o hardware. Este enfoque por capas (layers) asegura la portabilidad de una aplicación.En el siguiente ejemplo el dominio de problema se divide en cuatro particiones verticales. El componente de administración de datos es una partición horizontal, la cual existe para aislar a la aplicación del software de base de datos utilizada.Subsistema de reportes

Subsistema de seminario

Subsistema de registración

Subsistema de memos

Componente de Administración de Datos

Prof.: Oscar Núñez M.21Diseño Orientado a Objetos

Diagrama de Modelo Global del Sistema Componentes del diagramaActor: personas que interactúan con el subsistema o interfaces con otros subsistemas.OBordes del sistema: se representan con un rectángulo en línea gruesa. Los actores se dibujan fuera del rectángulo, y los s ubs is temas dentro.nombre

Subsistema: se representan con un rectángulo redondeado.

Servicios: se representan como semicírculos dentro del rectángulo correspondiente al subsistema.Actor usando un servicio: se representa como una flecha que vincula al actor con el servicio que usa. Obs.Uso de Clases de Objetos para encapsular subsistemas.Es posible encapsular la funcionalidad de un sistema utilizando object wrapper (envoltura). Esto puede ser muy útil para permitir la utilización de un sistema no orientado a objetos desde un sistema orientado a objetos. Esto se realiza definiendo un objeto interface el cual puede llamarse para invocar las funciones provistas por el sistema encapsulado. Solo dicho objeto interface necesita conocer el funcionamiento interno del sistema que encapsula.También es posible utilizar una clase de objetos para encapsular el acceso a un sistema orientado a objetos. Si no se utiliza esto, todos los mensajes provenientes del exterior del subsistema, deben dirigirse directamente a la clase de objetos correspondiente dentro del mismo, lo que implica que los actores que necesiten utilizar la funcionalidad del subsistema, deban conocer la estructura interna del mismo.Utilizando un objeto interfaz, se oculta la complejidad interna del subsistema y es posible definir una interfaz sencilla para los clientes externos.Prof.: Oscar Núñez M.22Diseño Orientado a ObjetosCiclo de Desarrollo Orientado a ObjetosEn los capítulos anteriores se introdujeron los conceptos fundamentales del paradigma de orientación a objetos, como así también los modelos fundamentales que se utilizarán en la metodología de OOAD.Se examinará el proceso de desarrollo orientado a objetos, es decir que actividades deben llevarse a cabo, que tareas deben realizarse, y que deben producirse en cada etapa.En esta unidad se realiza una presentación a nivel general que se desarrolla en detalle en las unidades siguientes.Fases del ciclo de desarrollo OO.En este enfoque un ciclo de vida tradicional está compuesto por las siguientes etapas:1. Definición del proyecto y planificación.Aquí es donde se define el alcance y límites del proyecto. Se realizan los estudios de factibilidad y se determinan las relaciones costo/beneficio.2. Análisis• Análisis del Negocio: aquí es donde se modela el negocio o parte del mismo en orden de comprender la naturaleza del mismo, como se realizan actualmente las actividades, y como los usuarios desean que se realicen en el futuro. Provee una comprensión preliminar de áreas específicas del negocio a ser informatizadas. Esta etapa también es conocida como estudio del sistema actual en otras metodologías.• Análisis de requerimientos del sistema: aquí es donde se establece con claridad las capacidades requeridas para el nuevo sistema a ser desarrollado. Estas capacidades son documentadas de modo tal que los desarrolladores tengan una especificación clara sobre la que trabajar y para validar los resultados obtenidos.3. Diseño• Diseño Lógico: aquí es donde los desarrolladores del sistema identifican los componentes de software y hardware necesarios para satisfacer los requerimientos, como así también especifican las relaciones arquitecturales entre dichos componentes. El diseño lógico debe evitar detalles técnicos específicos requeridos para mapear el diseño en un entorno de implementación específico.• Diseño Físico: aquí es donde se toman decisiones técnicas considerando arquitecturas de hardware especificas, sistemas de bases de datos, lenguajes de programación, utilización de paquetes de middleware o herramientas Case, etc. Aquí también se toman decisiones con respecto a características de implementación como ser arquitectura cliente/servidor, distribución de objetos, etc.4. Construcción• Desarrollo: aquí es donde un diseño físico es implementado en un lenguaje de programación, o entorno especifico de desarrollo.• Prueba: se realizan test del software para validar su correcto funcionamiento y detectar fallas que deban ser depuradas.• Documentación: desarrollo de: documentación técnica sobre la aplicación, manuales de usuario, manuales de procedimiento, etc.5. Aprobación (Implantación)6. Operación y MantenimientoProf.: Oscar Núñez M.22Diseño Orientado a ObjetosUso de los distintos modelos.A continuación se resume el uso de los distintos modelos en las diferentes etapas del ciclo de desarrollo: Análisis del Negocio• Modelo de Estructura de Objetos: es utilizado para identificar y modelar los objetos del dominio del negocio (objetos entidad). Preguntas fundamentales son: "¿Qué objetos necesitamos en orden de realizar los procesos de negocio identificados?", "¿Qué deben conocer estos objetos, y que deben ser capaces de realizar?", "¿Cómo interactúan estos objetos entre sí?'.• Modelo de procesos de negocios y secuencias de transacciones: pueden utilizarse para describir los procesos del negocio en una forma compatible con la descripción de secuencias de transacciones de la siguiente fase de análisis de requerimientos.

• Modelo de Ciclo de Vida de Objetos: pueden proveer una mayor comprensión sobre el comportamiento dinámico de los objetos del negocio, durante su vida. Su utilización dependerá de la complejidad de los objetos del negocio en estudio, y en algunos casos puede ser Innecesaria su utilización.Análisis de Requerimientos• Modelo de estructura de Objetos: contiene únicamente objetos entidad, y se agrega mayor detalle al modelo describiendo relaciones, herencia, agregación, atributos y restricciones aplicables a las clases de objeto entidad, identificados.• Secuencias de Transacción: son utilizadas para describir la funcionalidad esperada del sistema.• Modelo de Ciclo de Vida de Objetos: se utiliza para aquellos objetos con ciclos de vida complejos.• Modelo Global del Sistema: es utilizado para sistemas grandes cuando se necesite particionar en subsistemas. Diseño Lógico• Secuencias de Transacciones: definidas en la etapa anterior, son examinadas aquí para determinar objetos interfaz y de control donde es apropiado.• Diagramas de Interacción de Objetos: se dibuja uno por cada secuencia de transacción describiendo eventos e interacciones entre objetos necesarios para soportar la secuencia de transacción.• Operaciones: son definidas con descripciones informales de su comportamiento.• Diagramas de Ciclo de Vida: son creados y extendidos donde sean necesarios.• Modelo Global: se definen subsistemas y se dibujan diagramas globales donde sea requerido con propósitos organizacionales, manejo de complejidad, y presentación.Diseño FísicoDurante la etapa de diseño físico se llevan a cabo las siguientes actividades:• El entorno para el sistema debe ser determinado, y las decisiones tomadas inicialmente deben finalizarse. Esto incluye determinación de lenguaje de programación, sistema operativo, DBMS, S.O. de red, hardware, tipo de interface de usuario, librerías de clases, frameworks, y patrones de diseño.• La administración de tareas y distribución de objetos/funciones debe finalizarse.• La definición de tipos de atributos debe finalizarse.• Se implementan las relaciones (p.e. en forma de punteros)• Decisiones relativas a implementación de restricciones debe finalizar, dependiendo del lenguaje de programación, DBMS utilizados, etc.• Debe finalizarse la interfaz de usuario.• Deben tomarse decisiones sobre el manejo de persistencia de objetos, involucrando posiblemente un mapeo entre objetos y DBMS relacionales. Esto puede implicar la implementación de una "capa de acceso" en el sistema, o bien puede manejarse con un producto comercial.• Se desarrollan objects wrappers para todos los componentes no orientados a objetos que serán utilizados por la aplicación.• Se realiza la codificación de todas las operaciones que deban realizarse.El rol de las versiones en un proceso de desarrollo aditivoEl proceso de OOAD descripto aquí es aditivo, esto significa que los resultados de cada fase son utilizados como entrada para la siguiente fase, donde se realizan actualizaciones y extensiones. Esto contrasta con otros enfoques como el estructurado que es carácter transformacional, donde los DFD del análisis son transformados en Diagramas de Estructura durante el diseño.Debido a esta naturaleza aditiva del proceso, es técnicamente innecesario retener versiones de resultados de las primeras fases del desarrollo. Sin embargo muchas veces por cuestiones contractuales u organizacionales se retienen copias de los modelos del análisis de requerimientos. A menudo, este modelo representa un contrato entre los usuarios y los desarrolladores. El modelo se retiene en orden de proveer un mecanismo para validar que el sistema entregado cumple con las especificaciones iniciales.Arquitectura de Seis ComponentesComo se ha mencionado, es útil y común dividir sistemas grandes y complejos en subsistemas para facilitar su desarrollo. Pero además es útil dividir un sistema de cualquier tamaño en subsistemas basados en consideraciones arquitecturales que son específicamente relevantes durante la fase de diseño físico de la aplicación.• Componente Dominio de Problema (PDC)• Componente de Interacción Humana (HIC)• Componente de Interfaces Externas (EIC)• Componente de Administración de Datos (DMC)• Componente de Administración de Tareas (TMC)• Componente de Servicio de Utilidades (USC)Análisis del Negocio.El análisis del negocio es utilizado para modelar parte o toda la empresa, en orden de comprender la naturaleza del negocio y como se llevan a cabo sus procesos.El análisis del negocio se concentra en dos aspectos:• Modelado de los Objetos que soportan el Negocio (Business Objects)• Modelado de los Procesos del Negocio (Business Processes)

Actividades del Análisis del Negocio.Las siguientes actividades son llevadas a cabo durante el análisis del negocio:• Identificación de los Objetos del Negocio. Son los objetos más importantes del tipo entidad. Otros objetos entidad adicionales son agregados durante el análisis de requerimientos y durante el diseño lógico.• Modelado del ciclo de vida para cada objeto del negocio que tenga un ciclo de vida complejo relevante al problema a manejar.• Modelado de los procesos de negocio. Implica la identificación de los procesos de negocio y la obtención de una comprensión de alto nivel de los flujos de trabajo (workflows: secuencias de actividades y eventos) de dichos procesos, y de los agentes (humanos o máquinas) que interactúan para alcanzar un resultado significativo.• Chequeo de consistencia y validación del modelo producido.El alcance del análisis del negocio (dominio del negocio o dominio del problema) normalmente se determina durante la fase de definición del proyecto.1. Modelado de Objetos del Negocio.

El modelado de objetos del negocio es la primera definición del modelo de estructura de objetos para la aplicación. El modelado de objetos puede realizarse en simultáneo con el modelado de procesos de negocios. Sin embargo, se recomienda comenzar modelando los objetos ya que son la escencia de este enfoque.El modelo de estructura de objetos producido en esta fase será extendido en fases subsiguientes. Sin embargo, es muy similar al de la fase de análisis de requerimientos.Las principales diferencias residen en:1. El alcance de los objetos del negocio suele ser mayor, pues puede involucrar objetos de negocio que no son relevante al sistema computarizado.2. El modelo de objetos del negocio suele ser menos detallado. Usualmente sólo objetos de la realidad son modelados. Durante el análisis de requerimientos, objetos menos obvios son identificados (p.e. clases que representan eventos).3. En el análisis del negocio, el modelo contiene los objetos del negocio, sus principales atributos y relaciones estáticas relevantes. Durante el análisis de requerimientos, pueden agregarse objetos entidad, adicionales, con un conjunto de atributos más detallado y las operaciones básicas para los objetos del modelo.4. La definición de jerarquías de herencia y estructuras de agregación se difieren hasta el análisis de requerimientos. Pas os en el modelado de objetos de negocio.1. El modelado de objetos de negocio incluye los siguientes pasos:2. Determinar objetos del negocio candidatos.Prof.: Oscar Núñez M.24Diseño Orientado a Objetos3. Abstraer los objetos candidatos en clases y definir el propósito de cada clase de objetos.4. Determinar las relaciones estáticas entre los objetos del negocio.5. Nominar dichas relaciones y asignar cardinalidades.¿Qué modelar?Los objetos pueden ser identificados respondiendo la pregunta "¿qué cosas (reales o abstractas) considera la empresa y sobre la que guarda datos?". El énfasis en esta etapa es identificar objetos de la realidad (personas, lugares, cosas o eventos que están dentro del dominio.2. Modelado de Ciclo de Vida de Objetos.El principal propósito del modelado de ciclo de vida de objetos es asistir en la comprensión de objetos con ciclos de vida complejos.Es importante reconocer cualquier comportamiento del objeto que sea dependiente del tiempo y del estado del mismo, ya que esto agrega complejidad a la aplicación.El uso de diagramas de ciclo de vida facilita la comprensión y comunicación con los usuarios.¿Cuándo modelar ciclos de vida?Debe dibujarse diagramas de ciclo de vida solo para objetos que poseen comportamientos dependientes del tiempo y de su estado interno. Para determinar esto, debe tomarse cada clase de objetos y analizarla por separado. Deben identificarse los eventos que pueden afectar a un objeto de la clase y determinar si la reacción a dichos eventos puede variar según el estado interno del objeto.¿Cómo modelar ciclos de vida de objetos?El modelado de ciclos de vida incluye los siguientes pasos:Determinar cuando debe modelarse el ciclo de vida para una clase de objetos, según lo expuesto anteriormente.1. Identificar el primer estado del objeto.2. Identificar que evento lleva a un objeto a su estado inicial (usualmente la creación del mismo).3. Identificar los eventos que pueden causar transiciones de estado desde el primer estado, y a que estados puede cambiar el objeto.4. Identificar que actividades se llevan acabo durante la transición de estado.5. Identificar el estado final del objeto.Básicamente el alcance del modelado de ciclo de vida de objetos es el mismo para la actividad de análisis del negocio como para el análisis de requerimientos.3. Modelado de Procesos de Negocio.El modelado de procesos de negocio es usado para comprender y documentar las actividades de alto nivel realizadas por los profesionales del negocio para alcanzar los objetivos del dominio del negocio.Esta comprensión de alto nivel de cómo trabaja la empresa es necesaria como un paso preliminar para asegurar que las partes del negocio afectadas por la aplicación en desarrollo es comprendida antes de que el análisis de requerimientos sea llevada a cabo.Pas os del modelado de Proces os de Negocio.1. Identificar los procesos de negocio.2. Subdivisión de los procesos de negocio. Los procesos de negocio pueden subdividirse identificando especializaciones o particionándolos a lo largo del tiempo en subprocesos.3. Descripción de los procesos de negocio. La descripción de un proceso de negocio implica la descripción de la naturaleza del mismo como de las actividades que lo constituyen.Identificación de procesos de negocio.Los procesos de negocio pueden identificarse de dos maneras:Considerar quién es el cliente, y qué productos o servicios requiere. Verificar que dichos productos/servicios sean de valor para el cliente. La producción de dichos productos/servicios implicará uno o más procesos de negocio.Considerar que eventos la empresa debe ser capaz de tratar, y que procesos implican el tratamiento de dichos eventos.¿Cómo describir procesos de negocio?Los siguientes mecanismos pueden utilizarse para describir procesos de negocio:1. Una identificación del evento inicial y del producto(s) o servicio(s) del proceso de negocios.Prof.: Oscar Núñez M.24Diseño Orientado a Objetos2. Una descripción textual de las actividades involucradas en el proceso de negocio.3. Una descripción de la secuencia de interacciones entre agentes (humanos o máquinas) que es requerida para producir el producto/servicio requerido. Para esta descripción pueden utilizarse diagramas de interacción de objetos.

4. Una descripción de los cambios de ejecución de los caminos de ejecución involucrados en el proceso, mostrando los puntos en los cuales se inician dichos caminos: alternativos, actividades paralelas, e iteraciones. Para esta se pueden utilizar diagramas de flujo de actividad (AFD).Análisis de Requerimientos.El proceso de análisis de requerimientos debe producir una definición clara de los requerimientos para el nuevo sistema desde la cual puedan trabajar los desarrolladores y contra la cual puedan validarse los resultados.Durante el análisis del negocio se producen un modelo de la forma en que actualmente funciona la empresa. Durante el análisis de requerimientos, se modela cómo la empresa operará utilizando el nuevo sistema.Un objetivo adicional del análisis de requerimientos es proveer a los profesionales del negocio de la oportunidad de cambiar la manera en que actualmente funciona la empresa.El punto de partida del análisis de requerimientos depende del contexto en el cual una aplicación es desarrollada. Cuando el dominio del negocio para la aplicación es pequeño y bien comprendido, entonces la fase de análisis del negocio es muy breve. El análisis de requerimientos parte de los modelos del análisis del negocio que contienen muy poco detalle. En este caso es casi como partir desde cero.Cuando se ha realizado un análisis del negocio extenso, entonces los modelos obtenidos constituyen la base sobre la cual, se continúa trabajando realizando los agregados y extensiones pertinentes.Actividades del Análisis de Requerimientos.Durante el análisis de requerimientos se llevan a cabo las siguientes actividades:1. Definición de secuencias de transacciones basadas en los procesos de negocio.2. Expansión o definición del modelo de estructura de objetos para objetos entidad.3. Dibujo de diagramas de ciclo de vida para objetos entidad.4. Particionamiento del espacio del problema.El proceso de producción de la especificación de requerimientos comprende dos corrientes principales:El análisis de la funcionalidad requerida del nuevo sistema. Esto se documenta utilizando secuencias de transacción.El análisis de la estructura de objetos entidad para soportar dicha funcionalidad. Esto es documentado utilizando el modelo de objetos.Estas dos actividades pueden realizarse en paralelo, y no existe un criterio estricto sobre que modelo debe desarrollarseantes.Para sistemas "intensivos en datos", el modelado de las relaciones de objetos y atributos es particularmente importante.Para sistemas "algorítmicamente intensivos" o en proyectos de "reingeniería de negocios", el modelado de la funcionalidad, representado por secuencias de transacción en combinación con un modelo de objetos, puede ser más importante.a) Definición de Secuencia de Transacciones.El modelado de secuencia de transacciones incluye los siguientes pasos:1. Identificación de las secuencias de transacciones requeridas.2. Definición del contexto del negocio.3. Descripción del camino estándar.4. Descripción de caminos alternativos. Identificación de s ecuencias de trans acciones. Identificación a través de actores.• Identificar los actores que se comunicarán con el sistema. Los actores pueden ser personas humanas o interfaces con otros sistemas.• Para cada actor identificado considerar que es lo que el actor realizará con el sistema, utilizando secuencias de transacciones para describir esto. Es útil considerar:o Cuales son las principales tareas del actor.o Qué accesos (lectura o escritura) requiere el actor del sistema.Prof.: Oscar Núñez M.25Diseño Orientado a Objetoso Cuándo el actor informará al sistema acerca de cambios fuera del sistema. o Cuándo el actor será informado de cambios a través del sistema. Identificación a través de eventos.Consiste en identificar a que eventos externos o temporales debe ser capaz de responder el sistema. Para ello se siguen los siguientes pasos:• Confeccionar la lista de eventos. Cada evento externo al cual el sistema debe responder, es listado, incluyendo eventos temporales.• Asociar una secuencia de transacciones para cada evento identificado. Inicialmente se asocia una secuencia de transacción por cada evento. Puede haber más de una respuesta para un evento. En tal caso se requiere una secuencia de transacciones para cada respuesta.Relación entre actores y eventos externos.El enfoque de particionamiento por eventos describe eventos del negocio los cuales se originan a menudo fuera de la compañía. El generador de dichos eventos, a menudo no se comunica en forma directa con el sistema, sino que lo hace a través de un actor que hace de agente o intermediario. Por lo tanto, el actor que inicia una secuencia de transacciones lo hace en resp uesta a un evento, no es él quién lo origina. Sin embargo, hay casos, como los cajeros automáticos, en los cuales el actor es quién origina el evento.Uso de diagramas de secuencias de transacciones.Los actores y secuencias de transacciones identificados pueden documentarse utilizando diagramas de secuencias de transacciones. Estos diagramas muestran el actor que inicia la interacción con el sistema.Alcance de una s ecuencia de trans acciones .Una secuencia de transacciones debe cubrir una secuencia de eventos lógica y cohesiva. Es posible que dicho flujo de eventos s extienda en el tiempo por varios días.Para decidir el alcance de una secuencia de transacciones pueden seguirse los siguientes criterios:1. La secuencia de transacciones debe tener el alcance tan grande como sea posible manejarla (en orden de asegurarnos de que la secuencia de procesamiento completa es manejada satisfactoriamente). El proceso de negocios completo es el alcance por defecto para la secuencia de transacciones.2. Cuando se necesite subdividir la secuencia de transacciones para poder tener unidades razonables para manejar, debemos elegir unidades que el usuario acepte y perciba como realizando un objetivo de interés desde el punto de vista del

negocio. Estas unidades pueden corresponderse con las opciones mayores del menú de la aplicación o comandos del sistema.El alcance de una secuencia de transacciones debe realizar una tarea la cual el profesional del negocio la reconozca como una unidad cohesiva. Esto difiere de la perspectiva funcional donde las acciones son empaquetadas en comandos del sistema u opciones de menú pero sin referenciar la secuencia en la que deben utilizarse dichas opciones.Una secuencia de transacciones describe acciones en la secuencia en que se usan, sin especificar si estas acciones deben empaquetarse en una única función del sistema o en varias.Des cripción de Caminos Es tándar y Alternativos .Los caminos estándar y alternativos son descritos utilizando las descripciones textuales explicadas en el capítulo dedicado al modelado de procesos de negocios y secuencias de transacciones.En la secuencia de transacciones se describe que es lo que el sistema debe hacer, como interactuará con los actores, y cual e s el contexto del negocio para dicha interacción. La secuencia de transacciones muestra como se logra esto. Esto es descrito en el modelo de estructura de objetos donde se especifican operaciones elementales a nivel de objeto.Los caminos alternativos son descritos separadamente por un número de razones. Una razón es que esto permite que se lea el camino estándar sin distracciones por los detalles de casos inusuales o manejo de errores. Otra razón es que la separación del camino estándar de los alternativos ayuda al desarrollador a concentrarse en los tratamientos principales del procesamiento normal de las transacciones.Ejemplos de funcionalidad que puede ser descrita como caminos alternativos son:• Partes opcionales de la secuencia de transacciones.• Curs os alternativos de eventos que rara vez ocurren.• Sub-cursos separados que solo se ejecutan en ciertos casos.• Manejo de errores.Identificación y definición de s ecuencias comunes.Secuencias que son comunes a varias secuencias de transacciones pueden ser identificadas y descritas como secuencias de transacciones separadas. Tanto las secuencias de transacciones y las secuencias comunes se pueden utilizar para describir caminos estándar como alternativos.Prof.: Oscar Núñez M.26Diseño Orientado a ObjetosA menudo las secuencias comunes se asocian con jerarquías de herencia, tanto de clases de objetos como de actores. A menudo las secuencias de transacciones individuales describen la lógica que se aplica a las subclases de objetos mientras que la secuencia común describe la lógica que se aplica al nivel de superclase y por lo tanto es común a todas las subclases.Jerarquías de actores.Los actores representan roles de usuarios. En casos donde diferentes tipos de actores comparten capacidades comunes, puede ser útil definir jerarquías de actores. (p.e., un administrador y un usuario normal de l sistema pueden tener ciertas capacidades comunes las que pueden modelarse utilizando una superclase de actor). Cada actor hereda de la superclase actor.Las jerarquías de actores son necesarias cuando se encuentra lógica común en dos secuencias de transacciones distintas que se comunican con dos actores diferentes. Cuando se separa esta lógica común en una secuencia común, ésta necesita comunicarse con los dos diferentes actores. Dichos actores juegan un rol idéntico con respecto a la secuencia común. En este caso es conveniente definir una superclase actor desde la que los dos actores originales heredan y con quienes la secuencia común se comunica.Modelando interfaces de usuario e interfaces externas.En los puntos donde los actores inician o se comunican son secuencias de transacciones, existe a menudo intercambio de datos. El actor suministra datos al sistema, o el sistema brinda datos al actor.Es importante identificar que datos son pasados. Estos datos pueden ser descritos utilizando clases de objetos interface (que se corresponde con pantallas, ventanas, reportes). Es necesario identificar clase de objetos interfaces cuyos datos son suministrados a los actores o recibidos desde ellos.El proceso de definición de interfaces puede asistirse con el modelado de prototipos. Sin embargo, debe aclararse que el modelado final de los objetos interfaces debe posponerse hasta la etapa de diseño lógico.b) Expandiendo el Modelo de Estructura de Objetos.El principal objetivo del modelado de estructura de objetos en esta fase es producir un modelo completo de objetos entidad. Dependiendo en cuan detallado fue el análisis del negocio, puede que solo sea necesario expandir y refinar el modelo de estructura de objetos.Pasos en el modelado de estructura de objetos para el análisis de requerimientos.1. Determinar los objetos entidad candidatos y agregarlos al modelo.2. Agregar relaciones estáticas entre objetos entidad.3. Completar la definición básica para cada objeto entidad:• Definiendo el conjunto básico de atributos.• Definiendo atributos de identificación.• Definiendo restricciones.• Identificando operaciones donde se requieran.4. Agregar estructuras de herencia para los objetos entidad.5. Agregar estructuras de agregación para los objetos entidad.6. Refinar las relaciones estáticas tomando en cuenta las estructuras de herencia y agregación.c) Definición de ciclos de vida de Objetos.Cada vez que se agrega una nueva clase al modelo de estructura de objetos, debe examinarse si no es necesario dibujar un diagrama de ciclo de vida para dicha clase.d) Uso de Diagramas de Modelo Global.Los diagramas de modelado global tienen dos usos durante el análisis de requerimientos, ambos vinculados con el manejo de la complejidad:• Particionamiento del espacio del problema para sistemas muy grandes.• Representación de requerimientos del sistema a un nivel general (como el diagrama de contexto).Prof.: Oscar Núñez M.26

Diseño Orientado a ObjetosDiseño Lógico.El propósito del diseño lógico es producir un modelo de diseño completo para el sistema, relativamente libre de restricciones detalladas de implementación.Relaciones entre el diseño lógico y el físico.El objetivo del diseño lógico es producir un diseño que requiera pequeños cambios durante el diseño físico para ser implementado. El objetivo de esto es obtener un modelo de implementación "portable" a diferentes escenarios de implementaci ón (estilos de interfaces, lenguajes, dbms, sistemas operativos, hardware, etc.).Sin embargo, se recomienda que antes de empezar el diseño lógico se tomen ciertas decisiones estratégicas incluyendo:• Sistemas de computación a utilizar.• Bases de datos.• Interface de usuario.• Lenguaje de programación.• Librería de clases a utilizar.• Trabajos planeados para ejecutar en modo batch.• Criterios de performance.• Estrategias con respecto al manejo de errores, administración de memoria (garbage collection).• Requerimientos de distribución esperados.Actividades realizadas durante el diseño lógico.Las siguientes actividades se llevan a cabo durante el diseño lógico:• Identificación de objetos interface y de control.• Identificación de operaciones.• Uso de diagramas de interacción de objetos para validar el diseño.• Refinado del modelo de estructura de objetos.• Refinado del modelo de ciclo de vida de objetos.• Definición de subsistemas.Muchas actividades del diseño lógico toman las secuencias de transacciones como punto de partida. El análisis de las secuencias de transacciones es utilizado para identificar que objetos de interfaz y de control deben agregarse al modelo de objetos. Dibujando diagramas de interacción de objetos individuales para cada secuencia de transacciones se asiste en la identificación de operaciones de las clases de objetos.Identificación de Objetos de Interface y de Control.Cómo identificar objetos interfaz.Los objetos interfaz pueden identificarse siguiendo los siguientes pasos:1. Asignar un objeto interfaz central por cada combinación secuencia de transacción / actor / dispositivo. P.E. un supervisor de bodega puede utilizar una interface GUI (Graphical User Interface, interface gráfica de usuario) de pantalla para controlar movimientos de stock y una impresora para imprimir detalles de movimientos. Para estas actividades se pueden identificar dos objetos interfaz.2. Para una interfaz GUI, asignar un objeto interfaz por ventana. Los objetos interface se comunican con el objeto interface central identificado en el punto anterior. No es conveniente identificar objetos interfaz para cada componente individual de la ventana (botones, listas, etc.), ya que esto es manejado normalmente por los constructores de interfaces (p.e. Visual Basic).3. Para otro tipo de dispositivos, puede ser útil identificar un objeto interface central, el cual maneja el tipo particular de salida, y definir objetos interfaz adicionales para variantes específicas. P.E. puede definirse un objeto interfaz central para manejar los requerimientos de impresión, con objetos interfaz asociados para tipos individuales de impresoras (de matriz de puntos, de inyección o láser, etc.)4. Objetos interfaz pueden modelar protocolos de comunicación por capas como el modelo ISO. Un objeto interfaz se define por cada capa, el cual se comunica solo con objetos de la capa superior e inferior inmediata.Prof.: Oscar Núñez M.27Diseño Orientado a Objetos5. La agregación puede utilizarse con los objetos interfaz. P.E. algunos dispositivos son mejor considerados como compuestos. Un ejemplo es un cajero automático compuesto de una lectora de tarjeta magnética, una pantalla, un dispensador de dinero, y una impresora.6. Puede definirse herencia para objetos interfaz. Esto puede ser útil en casos donde un actor tiene un conjunto de capacidades que es un superconjunto de capacidades de otro actor.7. Una vez que los objetos interfaces han sido definidos, los objetos interface centrales pueden revisarse para detectar similitudes, en cuyo caso pueden combinarse.Una vez que los objetos interfaces han sido identificados, es necesario considerar que atributos y operaciones los objetos requieren. El tipo de comportamiento asignado a los objetos interface son los que:• Requieren información desde el exterior del sistema.• Presentan información al exterior del sistema.• Cambia si el comportamiento del usuario cambia.• Es dependiente del tipo de dispositivo.A menudo existen objetos interfaz con ciclos de vida complejos en orden de manejar ingresos de datos alternativos, o diferentes secuencias de navegación. En tales casos es conveniente utilizar diagramas de ciclo de vida.Los detalles de cómo la interface de usuario debe aparecer se finaliza durante el diseño lógico usando un constructor GUI y objetos interfaz en combinación.Como identificar objetos de control.Los objetos de control contienen comportamiento que no pertenece naturalmente ni a objetos entidad ni a objetos interfaz. Son por lo tanto identificados luego que estos dos tipos de objetos.Los objetos de control son generalmente temporales y su duración se extiende solo durante la secuencia de transacciones.La lógica contenida en un objeto de control puede ser lógica de control de sistema, requerida si se está desarrollando un sistema de computación. También puede ser lógica de la aplicación. A menudo es útil utilizar objetos de control para encapsular la lógica de control de secuencias de transacciones.Los objetos de control pueden identificarse inicialmente asignando un objeto de control por cada secuencia de transacción. Luego que se ha asignado el comportamiento a los objetos entidad e interfaz, puede darse que todo el comportamiento

haya sido satisfactoriamente asignado, sin dejar requerimientos para el objeto de control. Pero si existe comportamiento que no pertenece naturalmente ni a los objetos entidad ni de interfaz, este debe permanecer en el objeto de control.El tipo de comportamiento que puede ser asignado a un objeto de control puede ser:• Comportamiento que no cambia si el vecindario del objeto cambia.• Comportamiento que no cambia sustancialmente si el comportamiento de los objetos entidad varía.• Comportamiento que afecta a más de un objeto entidad.• Lógica dependiente del estado.• Lógica de control para una secuencia de transacciones.Los objetos de control se vinculan con los actores a través de objetos interfaz. Los objeto s de control a menudo actúan como un conjunto de buffers entre los objetos entidad y los de control.Los objetos de control que son demasiado complejos y de baja cohesión funcional deben dividirse. En contraposición si existen varios objetos de control que tienen alta cohesión funcional entre ellos, deben combinarse.Los objetos de control pueden tener asociados atributos, que normalmente son privados. La decisión de cuando considerar algunos objetos que contienen cálculos requeridos en el dominio del problema (p.e. cálculos de impuestos, índices, etc.) como objetos de control o entidad puede ser arbitraria. Como regla se puede tomar, que aquellos objetos que tienen atributos y deben ser persistentes, deben considerarse del tipo entidad. Los que no contienen atributos y son temporales, se consideran como de control.Debe tenerse la precaución de no utilizar objetos de control para separar funciones de datos, ya que esto va en contra del principio de encapsulamiento de la orientación a objetos.Asociaciones posibles entre los distintos tipos de objetos.Usualmente solo los siguientes tipos de asociaciones pueden existir entre objetos de diferentes tipos:ObjetoEmisor del mensaje

Objeto Receptor del mensaje

Entidad Interface ControlEntidad CO - RE - HE - AG CO COInterface CO – RE CO - RE - HE - AG COControl CO – RE CO CO - HE - AG

Prof.: Oscar Núñez M.28Diseño Orientado a ObjetosReferencias:CO: comunicación por mensajes (enlace dinámico) RE: relación estática HE: herencia AG: agregaciónLas letras en azul indican asociaciones que pueden ocurrir pero que rara vez se dan. Normalmente los actores se comunican con objetos interface, no con objetos entidad ni de control.Las relaciones estáticas normalmente sólo son modeladas para objetos entidad. Para los objetos interface y de control usualmente solo son relevantes las asociaciones por comunicación.Las relaciones de herencia y de agregación solo se dan entre las clases de objetos del mismo tipo.Identificando y definiendo Operaciones.Una operación es un proceso que se puede requerir como una unidad a un objeto. Una misma operación puede estar disponible para objetos de diferentes clases.Una misma operación define un servicio que es ofrecido. Esta definición incluye una descripción de la semántica de la operación, y una descripción de la sintaxis (como debe ser invocado el servicio). La semántica central de una operación debe ser siempre la misma independientemente de la clase de objeto que la implemente. La sintaxis indica la información que debe suministrarse en orden de invocar la operación, esto es el nombre y sus parámetros de entrada/salida.Un método es una implementación de una operación para una clase específica, y puede variar para cada clase.Notación de punto.Tanto para especificar atributos como operaciones durante el diseño lógico puede utilizarse la "notación de punto".Objeto.atributo u Objeto.operaciónEjemplo:DocumentoAutor Especifica el atributo autor del objeto documentoAuto.Conductor.Nombre Especifica el nombre de la persona que conduce el auto. Aquí Conductor identifica la relación entre las clases Auto y Persona.Cómo identificar operaciones.Existen tres posibles maneras de identificar operaciones:1. Considerando el rol y responsabilidades de cada clase de objetos, usando los enfoques basados en el análisis de las secuencias de transacciones o en el enfoque de "lista de compras".2. Identificando las interacciones de objetos requeridas para soportar cada secuencia de transacciones, con la asistencia de los diagramas de interacción de objetos.3. Analizando los ciclos de vida de objetos y determinando las operaciones que ellos implican.Los tres enfoques son valiosos y pueden ser utilizados en combinación. Cualquiera sea el enfoque utilizado, los puntos clave a considerar son:• ¿Cómo puede una funcionalidad dividirse entre operaciones?• ¿Qué clase de objeto es responsable de una determinada operación?1. Considerando roles y responsabilidades para cada clase de objetosAcorde con Wirfs-Brock, cada clase de objetos debe tener un rol o función simple y coherente claramente definido. En soporte de dicho rol, un objeto toma ciertas responsabilidades y comportamiento que es lógico que otros objetos esperen de él. Las operaciones que un objeto tiene le permiten cumplir con sus responsabilidades.Las responsabilidades y por lo tanto las operaciones, son identificadas analizando los requerimientos del sistema representados en las secuencias de transacciones.Habiendo identificado los primeros objetos entidad, interface, y control, podemos ahora considerar cada secuencia de transacciones en orden de identificar que operaciones deben asignarse a cada clase de objetos.Para realizar esto es conveniente utilizar un diagrama de estructura de objetos que contenga las clases relevantes a la secuencia de transacciones que se analiza.

Prof.: Oscar Núñez M.29Diseño Orientado a ObjetosAlternativamente, las responsabilidades pueden identificarse utilizando el enfoque llamado de "lista de compra". Usando este enfoque, el analista identifica operaciones considerando cada clase de objetos de una en vez y considerando "¿de qué es responsable este objeto, y qué deseo realizar con estos datos?".Cuando una clase de objetos es claramente responsable de un comportamiento en particular requerido por una secuencia de transacciones, la operación debe asignarse a dicha clase. Cuando no existe una clara responsabilidad perteneciente a una clase en particular se puede hacer lo siguiente:- Asignar la responsabilidad a la clase que más se adecue- Distribuir la responsabilidad en más de una clase- Introducir un objeto de control y asignar la operación al objeto de controlCuál es la mejor opción depende del contexto y del juicio del diseñador. La asignación correcta de operaciones es un factor clave en un sistema bien diseñado y mantenible.2. Interacción de objetos requerida para soportar cada secuencia de transaccionesLas interacciones de objetos requeridas para soportar una secuencia de transacciones puede modelarse usando diagramas de interacción de objetos. Normalmente se utiliza un diagrama de interacción de objetos por cada secuencia de transacción o por cada camino (estándar o alternativo) de la secuencia de transacción.El punto de entrada para el desarrollo de un diagrama de interacción de objetos se extrae del diagrama de estructura de objetos. Esto debe incluir todos los objetos entidad relevantes para la secuencia de transacciones y los objetos interfaz y de control que se asignan a la secuencia de transacción.El primer paso es considerar que interacción de objetos se requiere para describir la funcionalidad de la secuencia de transacción. Estas interacciones de objetos son llamadas eventos.Una secuencia de transacciones es iniciada por un evento. Un evento puede ser externo o temporal. Los eventos externos son generados por actores. Los eventos temporales son disparados cuando se alcanza un instante de tiempo determinado (fecha, hora, proceso periódico).Si para identificar las secuencias de transacciones se utiliza el enfoque de particionamiento por eventos, entonces los eventos de negocio ya se tienen disponibles. Si el generador del evento de negocio interactúa directamente con el sistema (como en un cajero automático), entonces este evento, su generador, y el objeto que recibe inicialmente el evento, pueden introducirse en el diagrama de interacción. Si el generador del evento de negocio no interactúa directamente con el sistema, entonces el evento que inicia la secuencia de transacciones es el evento en el cual un actor interno a la empresa reacciona al evento de negocio iniciando una interacción con el sistema.Siguiendo el evento inicial, eventos internos son agregados al diagrama de interacción de objetos para representar la comunicación entre objetos que se requiere para soportar la secuencia de transacciones. Un evento interno es un mensaje por un objeto a otro invocando la ejecución de una operación.Otros eventos pueden ser enviados o recibidos desde los actores que interactúan con la secuencia de transacciones.3. Analizando ciclos de vida de objetosLos diagramas de ciclo de vida deben revisarse para identificar operaciones. Cada evento mostrado en un diagrama de ciclo de vida causa la invocación de una operación en el objeto que recibe el evento. La revisión de los diagramas de ciclo de vida no revelan todas las operaciones, ya que en estos diagramas normalmente solo se modelan los eventos que producen cambios de estado.Especificación de la semántica y sintaxis de las operaciones.Debe definirse la semántica de cada operación identificada. El nombre, la sintaxis, y la semántica deben proveer toda la información que un usuario de la operación necesito para decidir cuando utilizarla o no.La especificación de la semántica puede expresarse en forma de texto, tablas de decisión, pseudocódigo, etc. Deben especificarse las precondiciones y postcondiciones de las operaciones como parte de la definición.También debe especificarse la sintaxis de la operación, los argumentos de entrada/salida requeridos. Puede definirse el tipo y dominio de cada argumento, como así también si es opcional o mandatario.Operaciones de clase.Una operación puede ser definida como operación de clase. Una operación de clase es una operación que es invocada por la clase misma no por las instancias. Tales operaciones pueden por ejemplo retornar información estadística sobre los objetos instanciados de dicha clase (promedios, totales, etc.). Un objeto particular puede ser creado durante el diseño físico si el lenguaje utilizado no soporta operaciones de clase.Herencia de operaciones.Operaciones concretas, abstractas y templados.Prof.: Oscar Núñez M.29Diseño Orientado a ObjetosEn cualquier clase concreta, las operaciones definidas deben siempre tener una implementación. Sin embargo, en las clases abstractas (de las cuales no se generan instancias) la implementación de una operación no es obligatoria, ya que las mismas pueden ser implementadas en las subclases.Los siguientes tipos de operación pueden especificarse para clases abstractas:• Operación abstracta: no tiene un método de implementación, solo se definen la sintaxis y semántica de la operación.• Operación templado: es una operación concreta que se implementa en términos de una o más operaciones abstractas.• Operación concreta: es aquella para la que se especifica completamente su implementación. Redefiniendo operaciones heredadas.Cuando una clase de objetos hereda una operación concreta de una superclase y la utiliza sin modificarla, no debe agregarse ninguna definición para la operación en la subclase.Normalmente solo debería necesitarse especificaciones adicionales en la subclase en los siguientes casos:• Adición de una implementación para una operación abstracta.• Extensión de una operación para agregar comportamientos específicos de la subclase.• Redefinición de los tipos de argumentos y dominio de los mismos.• Optimización del código de la operación.Redefiniendo el Modelo de Estructura de Objetos.• Adición y remoción de clases de objetos.

Las clases de objetos descubiertas durante el análisis de requerimientos son llevadas al diseño lógico y, objetos de control e interfaz adicionales son agregados.En aplicaciones complejas puede necesitarse cambiar el nivel de abstracción en que las clases de objetos son vistas. Por ejemplo, desde el punto de vista del análisis de requerimientos, puede ser claro que un número de objetos similares son requeridos y que cada uno debe ser descrito como una subclase de una superclase. Desde el punto de vista del diseño lógico, puede determinarse que solo es necesaria la superclase en el diseño final.• Identificación de atributo.Durante el diseño lógico, los atributos para cada clase de objetos deben ser completamente identificados. Se especifican las restricciones de acceso determinado atributos públicos, protegidos, y privados. También aquí se determinan atributos derivados.• Definición de persistencia de atributos.Los objetos entidad son usualmente persistentes mientras que los de interface o de control no. Deben identificarse objetos entidad que no son persistentes, y los de interface y de control que si lo son.• Subsistemas.Subsistemas pueden haber sido definidos en etapas previas o pueden definirse durante el diseño lógico. En el caso en que hayan sido definidos con anterioridad, igualmente es conveniente revisarlos en esta etapa luego de que las clases han sido convenientemente definidas, para verificar que los subsistemas definidos en verdad representan unidades coherentes.Durante el diseño lógico las principales razones para definir subsistemas son:• Para definir unidades de entrega, unidades funcionales que se entregarán al usuario en diferentes momentos.• Para definir unidades de distribución.• Para definir módulos que garanticen la robustez del diseño del sistema.• Con propósitos de validación, para chequear la calidad del diseño del sistema.• Con propósitos de presentación.Prof.: Oscar Núñez M.30Diseño Orientado a ObjetosDiseño Físico.El propósito del diseño físico es agregar los detalles técnicos dependientes de la plataforma, requeridos para construir el sistema a partir del diseño lógico.Las principales actividades del diseño físico son:1. Establecimiento de la arquitectura del sistema.2. Implementación de las clases del dominio del problema del sistema.3. Construcción de la interface de usuario.4. Diseño e implementación del componente de administración de datos.5. Diseño de la integración con sistemas existentes (legacy systems)Arquitectura del sistema.La arquitectura del sistema es la organización general del sistema en componentes (o subsistemas).Como se ha mencionado, es útil y común dividir sistemas grandes y complejos en susbsistemas para facilitar su desarrollo. Pero además es útil dividir un sistema de cualquier tamaño en subsistemas basados en consideraciones arquitecturales que son específicamente relevantes durante la fase de diseño físico de la aplicación.Un sistema puede particionarse vertical y horizontalmente (en capas). Las particiones verticales son utilizadas para subdividir la funcionalidad de la funcionalidad. En tanto que las particiones horizontales son utilizadas particularmente para aislar dependencias del sistema operativo, bases de datos, o hardware. La subdivisión en capas horizontales asiste en el salvaguardo de la portabilidad del sistema.Las particiones verticales deben estar débilmente acopladas y trabajar en configuración cliente/servidor o peer-to-peer. Las capas horizontales están en una relación cliente-servidor, donde las capas más bajas (servidores) suministran servicios a las capas superiores (clientes).La arquitectura del sistema puede diagramarse utilizando diagramas de visión general (diagrama global del sistema). Estos diagramas muestran subsistemas y los servicios que se proveen mutuamente.El presente enfoque de desarrollo orientado a objetos recomienda la siguiente arquitectura de seis componentes:

• Componente Dominio de Problema (PDC)Representa la parte del sistema que corresponde con el dominio del problema (mundo real). Consiste de todos los objetos entidad y de control identificados durante las fases previas.• Componente de Interacción Humana (HIC)Consiste de todos los objetos requeridos para la implementación de la interface de usuario. Se corresponde con los objetos intefaz con usuarios humanos identificados durante las fases previas.• Componente de Interfaces Externas (EIC)Consiste de todos los objetos intefaz con usuarios no humanos, como ser sistemas externos, dispositivos, impresoras, etc.• Componente de Administración de Datos (DMC)Provee la infraestructura para el almacenamiento y recuperación de los objetos persistentes en algún medio de almacenamiento.• Componente de Administración de Tareas (TMC)

Se encarga de administrar concurrencia cuando es necesaria. La utilización de este componente es muy rara en sistemas administrativos, siendo de utilidad solo en algunos sistemas en tiempo real.• Componente de Servicio de Utilidades (USC)Prof.: Oscar Núñez M.31Diseño Orientado a ObjetosProvee servicios de utilidad general que pueden ser requeridos por todos los demás componentes.

• Componente Dominio del Problema (PDC).Este componente representa la parte del mundo real (dominio del problema) del sistema. Esta componente no debe ser afectado por dependencias del hardware, sistema operativo, sistema de interfaz, o de base de datos.Este componente comprende todas las clases de objetos entidad y control, definidas durante las fases previas, pudiéndose extender con clases específicas de la implementación.El diseño físico implica la implementación de las clases y la especificación formal de las operaciones. Para esto es conveniente trabajar con lenguajes orientados a objetos que soportan todas las características y permiten una traslación directa de las clases a las construcciones del lenguaje.Los principales puntos a considerar durante la implementación de las clases del dominio del problema son:• Elección de tipos y estructuras de datos.• Implementación de relaciones.• Implementación de ciclos de vida.• Implementación de restricciones.• Implementación de atributos y relaciones derivadas.• Manejo de errores.• Componente de Administración de Datos (DMC).Las clases del componente de administración de datos proveen la infraestructura para el almacenamiento y recuperación de objetos en un sistema de manejo de datos (DBMS o sistema de archivos). La separación de estas clases en un componente específico permite aislar al sistema de la dependencia de un sistema de manejo de datos específico.La implementación en bases de datos puede contemplar diferentes tecnologías, sin embargo, las más importantes son las relacionales (RDBMS) y las orientadas a objetos (ODBMS).Los RDBMS no permiten almacenar en forma directa objetos lo cual obliga a realizar una capa de traslación, sin embargo, actualmente para aplicaciones con grandes volúmenes de datos son los más maduros y robustos. Por otro lado la tecnología de ODBMS si bien se integra mejor a un sistema orientado a objetos, todavía se encuentra en evolución y es considerada por algunos, inmadura para soportar aplicaciones críticas.Los principales pasos en la construcción del componente de administración de datos son:1. Mapeo de clases persistentes en las estructuras de datos del sistema de administración de datos (p.e. tablas de unRDBMS).2. Diseño de las clases de objeto para manejar las transformaciones y para interfacear con el DBMS.3. Diseño detallado de la interacción de objetos necesaria para soportar el almacenamiento y recuperación de objetos persistentes.Prof.: Oscar Núñez M.31Diseño Orientado a ObjetosArquitectura del dominio de administración de datos.

Diseño de base de datos relacional.Para cada objeto persistente debe identificarse un identificador unívoco (Object ID; Clave Primaria). La aplicación misma es responsable de la generación y administración de este Object ID. Para la generación de este Object ID pueden utilizarse atributos de identificación definidos durante el diseño lógico.Los atributos compuestos deben separarse en sus componentes atómicos.Las relaciones estáticas entre clases pueden realizarse a través de la implementación de claves foráneas. En general, se tiene tres alternativas para el mapeo de relaciones:1. Cualquier relación (cualquiera sea su cardinalidad) puede siempre mapearse como una tabla separada en la cual cada fila contiene un par de Object ID y se corresponde con una instancia de la relación.2. Relaciones uno-a-muchos o uno-a-uno, pueden mapearse incluyendo claves foráneas en una de las tablas relacionadas.3. Para relaciones uno-a-uno existe una tercera alternativa que consiste en combinar las tablas relacionadas en una sola.Para el mapeo de agregaciones, se aplican las mismas reglas que para las relaciones estáticas, ya que en realidad son un caso particular de las mismas.Para el mapeo de jerarquías de herencia existen tres alternativas:1. Cada clase de la jerarquía es mapeada a una tabla separada. Todas comparten un mismo Object ID, y tienen una columna para cada atributo propio de la clase.2. Cada clase no abstracta en la jerarquía es mapeada a una tabla separada que contiene una columna adicional para cada atributo heredado.3. Todas las clases en la jerarquía son mapeadas a una única tabla agregándose columnas para todos los atributos de la jerarquía.•Prof.: Oscar Núñez M.32Diseño Orientado a ObjetosFASE DE PRUEBASVerificación y validación a lo largo del ciclo de vidaLas pruebas comienzan a nivel de módulo y trabajan hacia fuera. La prueba y la depuración son actividades diferentes pero la depuración se incluye en la prueba.La verificación son el conjunto de actividades que aseguran que el software implementa correctamente una función específica. La validación se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente.Organización para las pruebas del softwareEl responsable del software es el responsable de las pruebas de las unidades del programa. Algunas veces, también se encarga de las pruebas de integración. Un grupo independiente de prueba se encarga de probar el sistema cuando ya está probado por sus creadores. Esta última fase de pruebas está supervisada por el creador del software que corregirá los errores encontrados por el grupo independiente.Una estrategia de prueba del softwareLas pruebas se asemejan a una espiral, que comienza con las pruebas de cada unidad y terminan con las de integración de todo el sistema. Después están las pruebas de validación y por último las del sistema.■ Pruebas de unidad: Se prueban las unidades funcionales a nivel de código (nivel de implementación). Para las pruebas de unidad se utilizan técnicas de caja blanca.■ Pruebas de integración: Se prueba la interconexión entre las diferentes unidades (nivel de diseño). Para las pruebas de integración se utilizan técnicas de caja negra y algunas de caja blanca.■ Pruebas de validación: Se prueba si el sistema cumple los requisitos del cliente (nivel de análisis). Para las pruebas de validación se utilizan técnicas de caja negra.■ Pruebas de sistema: Se prueba el sistema en su totalidad.TÉCNICAS Y MÉTODOS DE PRUEBA. PRUEBAS ORIENTADAS A OBJETOSDurante el análisis es posible que se cometan errores en el diseño de las clases, por lo que hay que tener mucho cuidado. Si el error no está en el análisis, se pasa al diseño. Si no se encuentra en el diseño, habrá que buscar en la codificación, con un considerable aumento en el esfuerzo de corrección.Exactitud de los modelos de AOO y DOO: Aunque el Análisis y el Diseño no son código, se puede probar su exactitud semántica; que debe reflejar un modelo del problema del mundo real a resolver.Cons is tencia de los modelos de AOO y DOO: Se debe de comprobar que haya consistencia entre las clases, para ello se utilizan los modelos clase-responsabilidad-colaboración (CRC) y diagrama objeto-relación. Se debe comprobar que cuando a una clase se le solicita un servicio, ésta debe servirlo adecuadamente. También se debe comprobar que el reparto de responsabilid ades es adecuado.TIPOS DE PRUEBASPruebas de unidad en OO: La unidad básica en OO es la clase u objeto encapsulado, por lo que se debe comprobar todos.

Pruebas de integración en OO: Aunque no suele ser posible probar la integración de los diferentes componentes de una clase uno por uno, se puede probar mediante hilos (se prueban las clases que interacciona con un determinado suceso o entrada al sistema) o basarse en el uso (primero se prueban las clases que requieren a menos clases que las sirvan y luego las demás). Así sucesivamente hasta completar todo el sistema.Pruebas de validación en OO: Se utilizan los casos de uso. Se utilizan pruebas de caja negra.DISEÑO DE CASOS DE PRUEBA EN OODebido al encapsulamiento y a la herencia, sacar una instantánea de los atributos de los objetos es muy difícil. Se suelen utilizar pruebas de caja negra.Se deben diseñar pruebas que busquen errores, en la integración (resultados inesperados, uso incorrecto de mensajes/operaciones e invocaciones incorrectas) se buscan errores en los objetos clientes.También hay pruebas que buscan el error en lo que el usuario hace y eso causa el error del sistema, esas pruebas se llaman pruebas basadas en el escenario. Estas pruebas sirven para validar.Se pueden hacer pruebas al azar, pruebas de partición en estados, o pruebas del dinamismo del sistema utilizando los diagramas de transición de estados.Prof.: Oscar Núñez M.33