Unidad 2 Diseo orientado a objetos Diseo orientado a objetos es una fase de la metodologa orientada a objetos para el desarrollo de Software.

Su uso induce a los programadores a pensar en trminos de objetos, en vez de procedimientos, cuando planifican su cdigo. Un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La 'interfaz del objeto', esto es, las formas de interactuar con el objeto, tambin es definida en esta etapa. Un programa orientado a objetos es descrito por la interaccin de esos objetos. El diseo orientado a objetos es la disciplina que define los objetos y sus interacciones para resolver un problema de negocio que fue identificado y documentado durante el anlisis orientado a objetos. 2.1 Diseo del sistema en base a procesos Lenguaje Unificado de Modelado (UML, por sus siglas en ingls, Unified Modeling Language) es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad; est respaldado por el OMG (Object Management Group). Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes reutilizables. Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est descrito el modelo. Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodologa de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en s mismo qu metodologa o proceso usar. UML no puede compararse con la programacin estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad de una utilizacin en un requerimiento. Mientras que, programacin estructurada, es una forma de programar como lo es la orientacin a objetos, sin embargo, la programacin orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML slo para lenguajes orientados a objetos. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas. Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado: Diagrama de clases Diagrama de componentes Diagrama de objetos Diagrama de estructura compuesta (UML 2.0) Diagrama de despliegue Diagrama de paquetes

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado: Diagrama de actividades Diagrama de casos de uso Diagrama de estados

Los Diagramas de Interaccin son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado: Diagrama de secuencia Diagrama de comunicacin, que es una versin simplificada del Diagrama de colaboracin (UML 1.x) Diagrama de tiempos (UML 2.0) Diagrama global de interacciones o Diagrama de vista de interaccin (UML 2.0)

2.1.1 Actividades y casos de uso En el Lenguaje de Modelado Unificado, un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general. Diagrama de actividad. Es una forma especial de diagrama de estado usado para modelar una secuencia de acciones y condiciones tomadas dentro de un proceso. Un diagrama de actividades puede considerarse como un caso especial de un diagrama de estados en el cual casi todos los estados son estados accin (identifican una accin que se ejecuta al estar en l) y casi todas las transiciones evolucionan al trmino de dicha accin (ejecutada en el estado anterior). Un diagrama de actividades puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto. Permiten representar transiciones internas al margen de las transiciones o eventos externos. La interpretacin de un diagrama de actividades depende de la perspectiva considerada: en un diagrama conceptual, la actividad es alguna tarea que debe ser realizada; en un diagrama de especificacin o de implementacin, la actividad es un mtodo de una clase. Generalmente se suelen utilizar para modelar los pasos de un algoritmo.

Un estado de accin representa un estado con accin interna, con por lo menos una transicin que identifica la culminacin de la accin (por medio de un evento implcito). No deben tener transiciones internas ni transiciones basadas en eventos, ya que si fuera este el caso, se representara con un diagrama de estados. Los estados de accin se representan por un rectngulo con bordes redondeados, y permiten modelar un paso dentro de un algoritmo. Las flechas dirigidas entre estados de accin representan transiciones con evento implcito que, en el caso de decisiones, pueden tener una condicin o guarda asociada (que al igual que en los diagramas de estado evala a true o a false). Las decisiones se representan mediante una transicin mltiple que sale de un estado y donde cada camino tiene una etiqueta distinta. Se representa mediante un rombo al cual llega la transicin del estado origen y del cual salen las mltiples transiciones de los estados destino. En un diagrama de actividades tambin pueden existir barras de sincronizacin (synchronization bar), como la que sigue a [found cofee] en la figura, a las que se encuentran asociadas varios caminos salientes. Cada camino saliente se dirige a una actividad (Put Coffee in Filter, Add Water to Reservoir y Get Cups), realizndose dichas actividades en paralelo. Esto quiere decir que el orden en que se realicen dichas actividades es irrelevante, siendo vlido cualquier orden entre ellas. Dado que el diagrama de actividades permite expresar el orden en que se realizan las cosas, resulta adecuado para el modelado de organizaciones (business modeling) y el de programas concurrentes (permite representar

grficamente los hilos de ejecucin). Como la mayora de las tcnicas de modelado de comportamiento, los diagramas de actividades tienen sus puntos fuertes y sus puntos dbiles, de forma que es necesario utilizarlos en combinacin con otras tcnicas. Su principal aportacin al modelado del comportamiento es que soportan el comportamiento paralelo, lo que resulta adecuado para el modelado de flujo de trabajo ( workflow) y programacin multihilo (multi-thread). Por contra, su principal desventaja es que no muestran de una forma clara los enlaces existentes entre las acciones y los objetos, siendo mucho ms apropiado para ello los diagramas de interaccin. En general resulta adecuado utilizar diagramas de actividades para: Anlisis de casos de uso: Durante el anlisis de los casos de uso no estamos interesados en asociar acciones a objetos, sino en entender qu acciones se necesitan llevar a cabo y cules son las dependencias en el comportamiento. Comprensin del flujo de trabajo a lo largo de diferentes casos de uso. Modelado de aplicaciones multihilo. Diagramas de Casos de Uso El estndar de Lenguaje de Modelado Unificado de OMG define una notacin grfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocacin pensando que un caso de uso es una notacin grfica (o es su descripcin). Mientras la notacin grfica y las descripciones son importantes, ellos forman parte de la documentacin de un caso de uso --un propsito para el que el actor puede usar el sistema. El valor verdadero de un caso de uso reposa en dos reas: La descripcin escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripcin se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas. La posicin o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organizacin, un conjunto de casos de uso coherentes, consistentes promueve una imagen fcil del comportamiento del sistema, un entendimiento comn entre el cliente/propietario/usuario y el equipo de desarrollo. Es prctica comn crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del mbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen rendimiento, temas de escalabilidad/gestin, o cumplimiento de estndares.

El diagrama describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso estn representados por elipses y los actores estn representados por las figuras humanas. El actor Crtico de comidas puede Probar la comida, Pagar la comida, o Beber vino. Slo el actor Chef puede Preparar la comida. Podra ser que ambos Patrn y Cajero estn involucrados en el caso de uso Pagar la comida. El marco define los lmites del sistema Restaurante, por ejemplo, los casos de uso se muestran como parte del sistema que est siendo modelado, los actores no. La interaccin entre actores no se ve en el diagrama de casos de uso. Si esta interaccin es esencial para una descripcin coherente del comportamiento deseado, quizs los lmites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interaccin entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa puede jugar varios papeles o roles. As el Chef y el Cajero podran ser realmente la misma persona. Relaciones de Casos de Uso Las tres relaciones principales entre los casos de uso son soportadas por el estndar UML, el cual describe notacin grfica para esas relaciones. Inclusin (include o use) Es una forma de interaccin, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es til para extraer comportamientos verdaderamente comunes desde mltiples casos de uso a una descripcin individual, desde el caso de uso que lo incluye hasta el caso de uso incluido, con la etiqueta "include". Este uso se asemeja a una expansin de una macro, donde el comportamiento del caso incluido es colocado dentro del comportamiento del caso de uso base. No hay parmetros o valores de retorno. Extensin (Extend) Es otra forma de interaccin, un caso de uso dado, (la extensin) puede extender a otro. Esta relacin indica que el comportamiento del caso de uso extensin puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notacin, es una flecha de punta abierta con lnea discontinua, desde el caso de uso extensin al caso de uso extendido, con la etiqueta extend. Esto puede ser til para lidiar con casos especiales, o para acomodar nuevos

requisitos durante el mantenimiento del sistema y su extensin. La extensin se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensin o inclusin. "La extensin, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensin son los ejemplos o instancias de los conceptos." Generalizacin En la tercera forma de relaciones entre casos de uso, existe una relacin generalizacin/especializacin. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notacin es una lnea solida terminada en un tringulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la prctica puede ser til factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados. "Entonces la Generalizacin es la actividad de identificar elementos en comn entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonmicas entre conceptos que entonces se representan en jerarquas de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intensin y extensin." 2.1.2 Interfaces de usuario Las interfaces bsicas de usuario son aquellas que incluyen cosas como mens, ventanas, teclado, ratn, los beeps y algunos otros sonidos que la computadora hace, en general, todos aquellos canales por los cuales se permite la comunicacin entre el ser humano y la computadora. La mejor interaccin humano-mquina a travs de una adecuada interfaz (Interfaz de Usuario), que le brinde tanto comodidad, como eficiencia. Tipos de interfaces de usuario Dentro de las Interfaces de Usuario se puede distinguir bsicamente dos tipos: A) Una interfaz de hardware, a nivel de los dispositivos utilizados para ingresar, procesar y entregar los datos: teclado, ratn y pantalla visualizadora. B) Una interfaz de software, destinada a entregar informacin acerca de los procesos y herramientas de control, a travs de lo que el usuario observa habitualmente en la pantalla. C) Una interfaz de Software-Hardware, esta permite un puente entre la maquina y las personas, permite a la maquina entender la instruccin y a el hombre entender el cdigo binario traducido a informacin legible. Funciones principales Sus principales funciones son los siguientes: Puesta en marcha y apagado. Control de las funciones manipulables del equipo. Manipulacin de archivos y directorios. Herramientas de desarrollo de aplicaciones. Comunicacin con otros sistemas. Informacin de estado. Configuracin de la propia interfaz y entorno.

Intercambio de datos entre aplicaciones. Control de acceso. Sistema de ayuda interactivo.

Tipos de interfaces de usuario Segn la forma de interactuar del usuario Atendiendo a como el usuario puede interactuar con una interfaz, nos encontramos con varios tipos de interfaces de usuario: Interfaces alfanumricas (intrpretes de mandatos) que solo presentan texto. Interfaces grficas de usuario (GUI, graphics user interfaces), las que permiten comunicarse con el ordenador de una forma muy rpida e intuitiva representando grficamente los elementos de control y medida. Interfaces tctiles, que representan grficamente un "panel de control" en una pantalla sensible que permite interaccionar con el dedo de forma similar a si se accionara un control fsico.

Segn su construccin Pueden ser de hardware o de software: Interfaces de hardware: Se trata de un conjunto de controles o dispositivos que permiten la interaccin hombre-mquina, de modo que permiten introducir o leer datos del equipo, mediante pulsadores, reguladores e instrumentos. Interfaces de software: Son programas o parte de ellos, que permiten expresar nuestros deseos al ordenador o visualizar su respuesta.

2.2 Diseo de la lgica El diseo lgico traduce los escenarios de uso creados en el diseo conceptual en un conjunto de objetos de negocio y sus servicios. El diseo lgico se convierte en parte en la especificacin funcional que se usa en el diseo fsico. El diseo lgico es independiente de la tecnologa. El diseo lgico refina, organiza y detalla la solucin de negocios y define formalmente las reglas y polticas especficas de negocios. Un objeto de negocios es la encapsulacin de un servicio que abstrae las cualidades esenciales de algo de inters. Un servicio es una unidad con capacidad de cmputo. Un servicio debe satisfacer lo siguiente: Ser seguro, lo que equivale a un uso correcto y con autorizacin Ser vlido, qu tareas o reglas se pueden aplicar Manejar excepciones, informando al cliente Contar con un catlogo de servicios que constituye un repositorio de servicios.

Los objetos de negocio deben verificarse y probarse de tal manera que asegure que los mdulos operen como unidades completas de trabajo. Las tareas de verificacin incluyen: Una verificacin independiente: o Pre y post condiciones o Lgica y funcionalidad individual

Una verificacin dependiente: o Verificacin de dependencias o Que operan como una unidad especfica de trabajo

El diseo lgico comprende las siguientes tareas: Identificar y definir los objetos de negocio y sus servicios Definir las interfaces Identificar las dependencias entre objetos Validar contra los escenarios de uso Comparar con la arquitectura de la empresa Revisar y refinar tanto como sea necesario

Para definir los objetos de negocios y sus servicios se puede usar la tcnica de anlisis nombre-verbo de los escenarios de uso. Tambin se puede emplear la tcnica sujeto-verbo-objeto directo. En estas tcnicas los sujetos y el objeto directo son los candidatos a objetos de negocio y los verbos activos son los candidatos a servicios. Una interface tiene las siguientes partes: Nombre Precondiciones, lo que debe estar presente antes de ejecutarse Postcondiciones, estado final Capacidad o funcionalidad (SQL, pseudocdigo, funcin matemtica) Dependencias

La tarea de identificar las dependencias entre objetos permite identificar eventos, sucesos o condiciones que permitan la realizacin de tareas de negocios coordinadamente o transaccionalmente. Para ello se debe considerar lo siguiente: Identificar los eventos disparadores (triggers) Determinar cualquier dependencia (existencial o funcional) Determinar cualquier problema de consistencia o secuencia Identificar cualquier regulacin de tiempo crtica Considerar algn problema organizacional (transacciones) Identificar y auditar los requerimientos de control Determinar lugares y dependencias a travs de la ubicacin Determinar cuando el servicio que controla la transaccin es dependiente de los servicios contenidos en otros objetos de negocio

La validacin del modelo lgico debe ser tal que ste sea: Completo debe representar todos los escenarios de uso, Correcto el comportamiento lgico debe corresponder con el comportamiento conceptual, y Claro los objetos de negocio y servicios no deben ser ambiguos

En el diseo lgico conceptualmente se divide en tres niveles de servicios con el fin de que la aplicacin resulte flexible ante los cambios de requerimientos y/o de tecnologa cambiando nicamente la capa o capas necesarias. Los tres niveles son: servicios de usuario, servicios de negocio y servicios de datos. Los servicios de usuario (user services) controlan la interaccin. Un servicio de usuario son personas, aplicaciones, otros servicios o la combinacin de stos. Generalmente involucra una interfase grfica de usuario (GUI) o pude ser

no visual (mensajes o funciones), maneja todos los aspectos de la interaccin con la aplicacin. El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la informacin. Un servicio de usuario incluye un contenido (qu se necesita comunicar al usuario) y una forma (cmo se comunica el contenido) cuando es necesaria la comunicacin. Los servicios de negocio (bussines services) convierten datos recibidos de los servicios de datos y de usuario en informacin (datos + regla de negocio) y pueden usar otros servicios de negocio para completar su tarea. Las tareas de los servicios de negocio son: Dar formato a los datos Obtener y mover datos desde y hasta los servicios de datos Transformar los datos en informacin Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada la transaccin.

Los servicios de datos (data services) son los servicios de bajo nivel que apoyan los servicios de negocio y son de una amplia gama de categoras como las siguientes: Declaracin del esquema y su evolucin (estructuras de datos, tipos, acceso indexado, SQL, APIs) Respaldo y recuperacin (recuperacin de datos si un evento falla) Bsqueda y Lectura (bsquedas, compilacin, optimizacin y ejecucin de solicitudes, formacin de un conjunto de resultados) Insercin, actualizacin y borrado (procesar modificaciones consistentemente transaccional). Una transaccin es atmica (ocurre o no), consistente (preserva integridad), aislada (otras transacciones ocurren antes o despus) y durable (una vez completada, sta sobrevive). Bloqueo (permite al acceso concurrente a los datos) Validacin de datos (verifica la integridad del dominio, triggers y gateways para verificar el estado de los datos antes de aceptarlos, manejo de errores) Seguridad (acceso seguro a los objetos, operaciones, permisos a usuario y grupos y servicios) Administracin de la conexin (mecanismos bsicos para establecer una sesin de los servicios de datos). Establecer una conexin involucra: una identificacin, la colocacin y provisin de datos, tiempo de sesin, el tipo de interaccin (conversacional, transaccional, multiusuario, monousuario). Distribucin de datos (Distribuye informacin, a mltiples unidades de recuperacin, bases de datos heterogneas, segn la topologas de la red).

2.2.1 Clases y objetos Objetos Un objeto es una cosa tangible, algo a que se puede capturar intelectualmente o algo hacia lo que se puede dirigir una accin o pensamiento. Un objeto representa un item individual e identificable, o una entidad real o abstracta, con un papel definido en el dominio del problema. Los objetos tienen estados. El estado de un objeto abarca todas las propiedades del objeto, y los valores actuales de cada una de esas propiedades. Las propiedades de los objetos suelen ser estticas, mientras los valores que toman estas propiedades cambian con el tiempo. El hecho de que los objetos tengan estado implica que ocupan un espacio, ya en el mundo fsico, ya en la memoria del ordenador.

El estado de un objeto est influido por la historia del objeto. No deben confundirse los objetos, que existen en el tiempo, son mutables, tienen estado, pueden ser creados, destruidos y compartidos..., con los valores (los asignados a una variable, por ejemplo) que son cantidades con las propiedades de ser atemporales, inmutables. El estado de un objeto representa el efecto acumulado de su comportamiento. Comportamiento

Comportamiento es como un objeto acta y reacciona, en trminos de sus cambios de estado y de los mensajes que intercambia. El comportamiento de un objeto representa su actividad externamente visible y comprobable. Son las operaciones que una clase realiza (llamadas tambin mensajes) las que dan cuenta de cmo se comporta la clase. Por operacin se denota el servicio que una clase ofrece a sus clientes. Un objeto puede realizar cinco tipos de operaciones sobre otro, con el propsito de provocar una reaccin: o o o o o Modificador: altera el estado de un objeto. Selector: accede al estado de un objeto, sin alterarlo. Iterador: permite a todas las partes de un objeto ser accedidas en un orden. Constructor: crea un objeto y/o inicializa su estado. Destructor: libera el estado de un objeto y/o destruye el objeto.

Identidad

Identidad es la propiedad de un objeto que lo lleva a distinguirse de otros. Relaciones entre objetos

Las relaciones entre objetos abarcan las operaciones, resultados y suposiciones que unos hacen sobre los otros. Clases Una clase es un conjunto de objetos que comparten una estructura y comportamiento comunes. Clase representa una abstraccin, la esencia que comparten los objetos. Un objeto es un ejemplo de una clase. Un objeto no es una clase, y una clase no es un objeto Las clases actan como intermediarias entre una abstraccin y los clientes que pretenden utilizar la abstraccin. De esta forma, la clase muestra: Visin externa de comportamiento (interface), que enfatiza la abstraccin escondiendo su estructura y secretos de comportamiento. Visin interna (implementacin), que abarca el cdigo que se ofrece en la interface de la clase.

2.2.2 Interaccin Los diagramas UML de secuencia y de colaboracin (llamados diagramas de interaccin) se utilizan para modelar los aspectos dinmicos de un sistema. Un diagrama de interaccin consiste en un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar entre ellos. Los diagramas de secuencia destacan el orden temporal de los mensajes. Los diagramas de colaboracin destacan la organizacin estructural de los objetos que envan y reciben mensajes. Diagrama de secuencia: destaca el orden temporal de los mensajes. Diagrama de colaboracin: destaca la relacin estructural entre los objetos que interactan objetos tiempo <<destroy>> Ambos diagramas (secuencia y colaboracin) son semnticamente equivalentes. Se puede pasar de uno a otro sin prdida de informacin. En los diagramas de secuencia, la lnea de vida de un objeto es la lnea discontinua vertical, que representa la existencia de un objeto a lo largo de un periodo de tiempo. El foco de control es un rectngulo delgado que representa el periodo de tiempo durante el cual un objeto ejecuta una accin. Ejemplo 1: Se quiere modelar una llamada a travs de una central telefnica. Para esto se tienen cuatro objetos involucrados: dos interlocutores (s y r), una central y una conversacin. La secuencia empieza cuando un interlocutor enva un mensaje a la central al descolgar el auricular. La central da el tono de llamada, y el interlocutor marca el nmero al que desea llamar. El tiempo de marcado debe ser menor que 30 segundos. Ejemplo s:Interlocutor :Central r:Interlocutor c:Conversacin descolgarAuricular( ) darTonoDeLlamada( ) *marcarDigito( ) marcando {marcando.tiempoEjecucion < 30 segs} enrutarLlamadas(s,n) <<create>> llamar( ) descolgarAuricular( ) conectar(r,s) conectar(r) conectar(s) Los interlocutopres r y s pueden intercambiar informacin despus de conectarse.

2.2.3 Estados y transiciones Lenguaje Unificado de Modelado (UML) especifica una notacin estandarizada para diagramas de estado que puede utilizarse para describir clases, sistemas, subsistemas o incluso procesos de negocio. Los elementos bsicos de notacin que pueden usarse para componer un diagrama son: Crculo lleno, apuntando a un estado inicial Crculo hueco que contiene un crculo lleno ms pequeo en el interior, indicando el estado final (si existiera) Rectngulo redondeado, denotando un estado. En la parte superior del rectngulo est el nombre del estado. Puede contener una lnea horizontal en la mitad, debajo de la cual se indican las actividades que se hacen en el estado Flecha, denotando transicin. El nombre del evento (si existiera) que causa esta transicin etiqueta el cuerpo de la flecha. Se puede aadir una expresin de Guarda, encerrada en corchetes( [] ) denotando que esta expresin debe ser cierta para que la transicin tenga lugar. Si se realiza una accin durante la transicin, se aade a la etiqueta despus de "/". NombreDeEvento[ExpresinGuarda]/accin Lnea horizontal gruesa con x>1 lneas entrando y 1 lnea saliendo o 1 lnea entrando y x>1 lneas saliendo. Estas denotan Unin/Separacin, respectivamente.