ANLISIS Y MODELADO DE SISTEMAS DE INFORMACIN

ANTOLOGA

UNIDAD 1. El modelo del proceso del software 1.1. Conceptualizacin de tecnologa orientada a objetos.

Conceptos de la Programacin tradicional. En la programacin tradicional, tambin conocida como programacin estructurada, un programa o aplicacin consta de mltiples datos y funciones globales. El trmino global describe el hecho que todos los datos o funciones son visibles en todo el programa y, por lo tanto pueden ser llamados desde cualquier ubicacin en la aplicacin. Esta forma de programacin tiene sus orgenes en las primeras computadoras modernas basadas en la arquitectura Von Neuman de 1945 donde las instrucciones de un programa se guardaban en memoria creando el concepto de programa almacenado. Las instrucciones de un programa definidas dentro de funciones o procedimientos, eran ejecutadas por el procesador de manera secuencial afectando los datos del programa, los cuales eran almacenados en otras secciones de la memoria. Esta arquitectura es similar a la que actualmente se usa en la mayora de las computadoras personales. Debido a esta separacin de funciones y datos en la memoria, se ha desarrollado un gran nmero de lenguajes de programacin que explotan este concepto. Sin embargo este tipo de programacin tiene dos problemas principales: a) Que el programador debe organizar su programa de acuerdo a la arquitectura de la computadora, o que piense como la mquina. b) Los datos se vuelven globalmente visibles al estar separados de las funciones. Dado esto cualquier cambio en la estructura de los datos pudiera llegar a requerir la modificacin de todas las funciones del programa en correspondencia con los cambios en los datos. Conceptos de la Programacin Orientada a Objetos A diferencia de la programacin tradicional, la orientada a objetos tiene una estructura de ms alto nivel llamada objeto, que ofrece dos ventajas sobre la tradicional: a) Permite al programador que organice su programa de acuerdo con abstracciones de ms alto nivel, siendo stas ms cercanas a la manera de pensar de la gente. En otras palabras, los objetos son las unidades de

representacin de las aplicaciones, por ejemplo, cuentas de bancos, reservaciones de vuelo, etc. b) Los datos globales desaparecen, siendo stos junto con las funciones parte interna de los objetos. Por lo tanto cualquier cambio en la estructura de alguno de los datos solo deber afectar las funciones definidas en ese mismo objeto y no en los dems. En general, un programa orientado a objetos, se define exclusivamente en trminos de objetos y sus relaciones.

objeto

objeto

objeto

Fig.

Programacin orientada a objetos

Los datos y funciones se guardan dentro de los objetos, como se muestra en la figura.

Funciones
Datos

Objeto

Fig.

Programacin orientada a objetos: objetos globales que contienen datos y funciones locales

Hoy en da la tecnologa orientada a objetos ya no se aplica solamente a los lenguajes de programacin, adems se viene aplicando en el anlisis y diseo con mucho xito, al igual que en las bases de datos. Es que para hacer una buena programacin orientada a objetos hay que desarrollar todo el sistema aplicando esta tecnologa, de ah la importancia del anlisis y el diseo orientado a objetos. La programacin orientada a objetos es una de las formas ms populares de programar y viene teniendo gran acogida en el desarrollo de proyectos de software desde los ltimos aos. Esta acogida se debe a sus grandes capacidades y ventajas frente a las antiguas formas de programar.

Una Perspectiva Histrica Tradicionalmente, la programacin fue hecha en una manera secuencial o lineal, es decir una serie de pasos consecutivos con estructuras consecutivas y bifurcaciones.

Los lenguajes basados en esta forma de programacin ofrecan ventajas al principio, pero el problema ocurre cuando los sistemas se vuelven complejos. Estos programas escritos al estilo espaguetti no ofrecen flexibilidad y el mantener una gran cantidad de lneas de cdigo en slo bloque se vuelve una tarea complicada. Frente a esta dificultad aparecieron los lenguajes basados en la programacin estructurada. La idea principal de esta forma de programacin es separar las partes complejas del programa en mdulos o segmentos que sean ejecutados conforme se requieran. De esta manera tenemos un diseo modular, compuesto por mdulos independientes que puedan comunicarse entre s. Poco a poco este estilo de programacin fue reemplazando al estilo espaguetti impuesto por la programacin lineal. Entonces, vemos que la evolucin que se fue dando en la programacin se orientaba siempre a ir descomponiendo ms el programa. Este tipo de descomposicin conduce directamente a la programacin orientada a objetos. Pues la creciente tendencia de crear programas cada vez ms grandes y complejos llev a los desarrolladores a crear una nueva forma de programar que les permita crear sistemas de niveles empresariales y con reglas de negocios muy complejas. Para estas necesidades ya no bastaba la programacin estructurada ni mucho menos la programacin lineal. Es as como aparece la programacin

orientada a objetos (POO). La POO viene de la evolucin de la programacin estructurada; bsicamente la POO simplifica la programacin con la nueva filosofa y nuevos conceptos que tiene. La POO se basa en la dividir el programa en pequeas unidades lgicas de cdigo. A estas pequeas unidades lgicas de cdigo se les llama objetos. Los objetos son unidades independientes que se comunican entre ellos mediante mensajes. Origen Los conceptos de la programacin orientada a objetos tienen origen en Simula 67, un lenguaje diseado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard del Centro de Cmputo Noruego en Oslo. En este centro, se trabajaba en simulaciones de naves, que fueron confundidas por la explosin combinatoria de cmo las diversas cualidades de diferentes naves podan afectar unas a las otras. La idea surgi al agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamientos. Fueron refinados ms tarde en Smalltalk, desarrollado en Simula en Xerox PARC (cuya primera versin fue escrita sobre Basic) pero diseado para ser un sistema completamente dinmico en el cual los objetos se podran crear y modificar "sobre la marcha" (en tiempo de ejecucin) en lugar de tener un sistema basado en programas estticos. La programacin orientada a objetos se fue convirtiendo en el estilo de programacin dominante a mediados de los aos ochenta, en gran parte debido a la influencia de C++, una extensin del lenguaje de programacin C. Su dominacin fue consolidada gracias al auge de las Interfaces grficas de usuario, para las cuales la programacin orientada a objetos est particularmente bien adaptada. En este caso, se habla tambin de Programacin dirigida por eventos. Las caractersticas de orientacin a objetos fueron agregadas a muchos lenguajes existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp, Pascal, entre otros. La adicin de estas caractersticas a los lenguajes que no fueron diseados inicialmente para ellas condujo a menudo a problemas de compatibilidad y en la capacidad de mantenimiento del cdigo. Los lenguajes orientados a objetos "puros", por su parte, carecan de las caractersticas de las cuales muchos programadores haban venido a depender. Para saltar este obstculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en mtodos orientados a objetos, pero permitiendo algunas caractersticas imperativas de maneras "seguras". El Eiffel de Bertrand Meyer fue un temprano y moderadamente acertado lenguaje con esos objetivos pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la aparicin de Internet, y a la implementacin de la mquina virtual de Java en la mayora de navegadores. PHP en su versin 5 se ha modificado, soporta una orientacin completa a objetos, cumpliendo todas las caractersticas propias de la orientacin a objetos.

Cules son las ventajas de un lenguaje orientado a objetos?

Fomenta la reutilizacin y extensin del cdigo. Permite crear sistemas ms complejos. Relacionar el sistema al mundo real. Facilita la creacin de programas visuales. Construccin de prototipos Agiliza el desarrollo de software Facilita el trabajo en equipo Facilita el mantenimiento del software

Lo interesante de la POO es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible. El modelo Orientado a Objetos Conceptos bsicos: Objetos, Clases, Herencia, Envo de mensajes (mtodos) La programacin orientada a objetos o POO (OOP segn sus siglas en ingls) es un paradigma de programacin que usa objetos y sus interacciones, para disear aplicaciones y programas informticos. Est basado en varias tcnicas, incluyendo herencia, abstraccin, polimorfismo y encapsulamiento. Su uso se populariz a principios de la dcada de los aos 1990. En la actualidad, existe variedad de lenguajes de programacin que soportan la orientacin a objetos. Los objetos son entidades que tienen un determinado comportamiento (mtodo) e identidad.

El estado est compuesto de datos, ser uno o varios atributos a los que se habrn asignado unos valores concretos (datos). El comportamiento est definido por los mtodos o mensajes a los que sabe responder dicho objeto, es decir, qu operaciones se pueden realizar con l. La identidad es una propiedad de un objeto que lo diferencia del resto, dicho con otras palabras, es su identificador (concepto anlogo al de identificador de una variable o una constante).

Un objeto contiene toda la informacin que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interaccin llamados mtodos, que favorecen la comunicacin entre ellos. Esta comunicacin favorece a su vez el cambio de estado en los propios objetos. Esta caracterstica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado y el comportamiento.

Los mtodos (comportamiento) y atributos (estado) estn estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de mtodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a alguno de ellos. Hacerlo podra producir el hbito errneo de crear clases contenedoras de informacin por un lado y clases con mtodos que manejen a las primeras por el otro. De esta manera se estara realizando una programacin estructurada camuflada en un lenguaje de programacin orientado a objetos. La POO difiere de la programacin estructurada tradicional, en la que los datos y los procedimientos estn separados y sin relacin, ya que lo nico que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programacin estructurada anima al programador a pensar sobre todo en trminos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programacin estructurada slo se escriben funciones que procesan datos. Los programadores que emplean POO, en cambio, primero definen objetos para luego enviarles mensajes solicitndoles que realicen sus mtodos por s mismos. Conceptos fundamentales La programacin orientada a objetos es una forma de programar que trata de encontrar una solucin a estos problemas. Introduce nuevos conceptos, que superan y amplan conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:

Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciacin es la lectura de estas definiciones y la creacin de un objeto a partir de ellas. Herencia: (por ejemplo, herencia de la clase C a la clase D) Es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos mtodos y variables pblicas declaradas en C. Los componentes registrados como "privados" (private) tambin se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y slo pueden ser accedidos a travs de otros mtodos pblicos. Esto es as para mantener hegemnico el ideal de OOP. Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (mtodos) los mismos que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase. Mtodo: Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecucin se desencadena tras la recepcin de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un

mtodo puede producir un cambio en las propiedades del objeto, o la generacin de un "evento" con un nuevo mensaje para otro objeto del sistema. Evento: Es un suceso en el sistema (tal como una interaccin del usuario con la mquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. Tambin se puede definir como evento, a la reaccin que puede desencadenar un objeto, es decir la accin que genera. Mensaje: una comunicacin dirigida a un objeto, que le ordena que ejecute uno de sus mtodos con ciertos parmetros asociados al evento que lo gener. Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus caractersticas predeterminadas, y cuyo valor puede ser alterado por la ejecucin de algn mtodo. Estado interno: es una variable que se declara privada, que puede ser nicamente accedida y alterada por un mtodo del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase. Componentes de un objeto: atributos, identidad, relaciones y mtodos. Identificacin de un objeto: un objeto se representa por medio de una tabla o entidad que est compuesta por sus atributos y funciones correspondientes.

En comparacin con un lenguaje imperativo, una "variable", no es ms que un contenedor interno del atributo del objeto o de un estado interno, as como la "funcin" es un procedimiento interno del mtodo del objeto. Caractersticas de la POO Existe un acuerdo acerca de qu caractersticas contempla la "orientacin a objetos", las caractersticas siguientes son las ms importantes:

Abstraccin: denota las caractersticas esenciales de un objeto, donde se capturan sus comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cmo se implementan estas caractersticas. Los procesos, las funciones o los mtodos pueden tambin ser abstrados y cuando lo estn, una variedad de tcnicas son requeridas para ampliar una abstraccin. El proceso de abstraccin permite seleccionar las caractersticas relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstraccin es clave en el proceso de anlisis y diseo orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar.

Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstraccin. Esto permite aumentar la cohesin de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultacin, principalmente porque se suelen emplear conjuntamente. Modularidad: Se denomina Modularidad a la propiedad que permite subdividir una aplicacin en partes ms pequeas (llamadas mdulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicacin en s y de las restantes partes. Estos mdulos se pueden compilar por separado, pero tienen conexiones con otros mdulos. Al igual que la encapsulacin, los lenguajes soportan la Modularidad de diversas formas. Principio de ocultacin: Cada objeto est aislado del exterior, es un mdulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cmo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificacin por quien no tenga derecho a acceder a ellas, solamente los propios mtodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstraccin. La aplicacin entera se reduce a un agregado o rompecabezas de objetos. Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizar el comportamiento correspondiente al objeto que se est usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocacin de un comportamiento en una referencia producir el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecucin", esta ltima caracterstica se llama asignacin tarda o asignacin dinmica. Algunos lenguajes proporcionan medios ms estticos (en "tiempo de compilacin") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++. Herencia: las clases no estn aisladas, sino que se relacionan entre s, formando una jerarqua de clasificacin. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en rboles o enrejados que reflejan un comportamiento comn. Cuando un objeto hereda de ms de una clase se dice que hay herencia mltiple.

Recoleccin de basura: la recoleccin de basura o garbage collector es la tcnica por la cual el entorno de objetos se encarga de destruir automticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignacin o liberacin de memoria, ya que el entorno la asignar al crear un nuevo objeto y la liberar cuando nadie lo est usando. En la mayora de los lenguajes hbridos que se extendieron para soportar el Paradigma de Programacin Orientada a Objetos como C++ u Object Pascal, esta caracterstica no existe y la memoria debe desasignarse manualmente.

Repasando, la programacin orientada a objetos es un paradigma que utiliza objetos como elementos fundamentales en la construccin de la solucin. Surge en los aos 70. Un objeto es una abstraccin de algn hecho o ente del mundo real que tiene atributos que representan sus caractersticas o propiedades y mtodos que representan su comportamiento o acciones que realizan. Todas las propiedades y mtodos comunes a los objetos se encapsulan o se agrupan en clases. Una clase es una plantilla o un prototipo para crear objetos, por eso se dice que los objetos son instancias de clases. Lenguajes orientados a objetos Simula (1967) es aceptado como el primer lenguaje que posee las caractersticas principales de un lenguaje orientado a objetos. Fue creado para hacer programas de simulacin, en donde los "objetos" son la representacin de la informacin ms importante. Smalltalk (1972 a 1980) es posiblemente el ejemplo cannico, y con el que gran parte de la teora de la programacin orientada a objetos se ha desarrollado. Entre los lenguajes orientados a objetos se destacan los siguientes:

ABAP ABL Lenguaje de programacin de OpenEdge de Progress Software ActionScript ActionScript 3 Ada C++ C# Clarion Clipper (lenguaje de programacin) (Versin 5.x con librera de objetos Class(y)) D Object Pascal (Embarcadero Delphi) Gambas Harbour Eiffel Java

JavaScript (la herencia se realiza por medio de la programacin basada en prototipos) Lexico (en castellano) Objective-C Ocaml Oz R Perl (soporta herencia mltiple. La resolucin se realiza en preorden, pero puede modificarse al algoritmo linearization C3 por medio del mdulo Class::C3 en CPAN) PHP (a partir de su versin 5) PowerBuilder Python Ruby Smalltalk (Entorno de objetos puro) Magik (SmallWorld) Vala VB.NET Visual FoxPro (en su versin 6) Visual Basic 6.0 Visual Objects XBase++ Lenguaje DRP Lenguaje de programacin Scala (lenguaje usado por Twitter) http://www.scala-lang.org/page.jsp

Muchos de estos lenguajes de programacin no son puramente orientados a objetos, sino que son hbridos que combinan la POO con otros paradigmas. Al igual que C++ otros lenguajes, como OOCOBOL, OOLISP, OOPROLOG y Object REXX, han sido creados aadiendo extensiones orientadas a objetos a un lenguaje de programacin clsico. Un nuevo paso en la abstraccin de paradigmas de programacin es la Programacin Orientada a Aspectos (POA). Aunque es todava una metodologa en estado de maduracin, cada vez atrae a ms investigadores e incluso proyectos comerciales en todo el mundo. Estructura de un objeto Un objeto puede considerarse como una especie de cpsula dividida en tres partes: relaciones, propiedades, mtodos. Cada uno de estos componentes desempea un papel totalmente independiente:

Las relaciones permiten que el objeto se inserte en la organizacin y estn formadas esencialmente por punteros a otros objetos.

Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organizacin y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organizacin. Los mtodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarn incorporados en forma de programas (cdigo) que el objeto es capaz de ejecutar y que tambin pone a disposicin de sus descendientes a travs de la herencia.

Encapsulamiento y ocultacin Como hemos visto, cada objeto es una estructura compleja en cuyo interior hay datos y programas, todos ellos relacionados entre s, como si estuvieran encerrados conjuntamente en una cpsula. Esta propiedad (encapsulamiento), es una de las caractersticas fundamentales en la OOP. Los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los programadores conozcan cmo est distribuida la informacin o qu informacin hay disponible. Esta propiedad de los objetos se denomina ocultacin de la informacin. Esto no quiere decir, sin embargo, que sea imposible conocer lo necesario respecto a un objeto y a lo que contiene. Si as fuera no se podra hacer gran cosa con l. Lo que sucede es que las peticiones de informacin a un objeto. Deben realizarse a travs de mensajes dirigidos a l, con la orden de realizar la operacin pertinente. La respuesta a estas rdenes ser la informacin requerida, siempre que el objeto considere que quien enva el mensaje est autorizado para obtenerla. El hecho de que cada objeto sea una cpsula facilita enormemente que un objeto determinado pueda ser transportado a otro punto de la organizacin, o incluso a otra organizacin totalmente diferente que precise de l. Si el objeto ha sido bien construido, sus mtodos seguirn funcionando en el nuevo entorno sin problemas. Esta cualidad hace que la OOP sea muy apta para la reutilizacin de programas. Organizacin de los objetos En principio, los objetos forman siempre una organizacin jerrquica, en el sentido de que ciertos objetos son superiores a otros de cierto modo. Existen varios tipos de jerarquas: sern simples cuando su estructura pueda ser representada por medio de un "rbol". En otros casos puede ser ms compleja. En cualquier caso, sea la estructura simple o compleja, podrn distinguirse en ella tres niveles de objetos. -La raz de la jerarqua. Se trata de un objeto nico y especial. Este se caracteriza por estar en el nivel ms alto de la estructura y suele recibir un nombre muy

genrico, que indica su categora especial, como por ejemplo objeto madre, Raz o Entidad. -Los objetos intermedios. Son aquellos que descienden directamente de la raz y que a su vez tienen descendientes. Representan conjuntos o clases de objetos, que pueden ser muy generales o muy especializados, segn la aplicacin. Normalmente reciben nombres genricos que denotan al conjunto de objetos que representan, por ejemplo, VENTANA, CUENTA, FICHERO. En un conjunto reciben el nombre de clases o tipos si descienden de otra clase o subclase. -Los objetos terminales. Son todos aquellos que descienden de una clase o subclase y no tienen descendientes. Suelen llamarse casos particulares, instancias o tems porque representan los elementos del conjunto representado por la clase o subclase a la que pertenecen. Veamos ahora en detalle los tres elementos mencionados en "Estructura de un Objeto". 1. Relaciones. Las relaciones entre objetos son, precisamente, los enlaces que permiten a un objeto relacionarse con aquellos que forman parte de la misma organizacin. Las hay de dos tipos fundamentales: -Relaciones jerrquicas. Son esenciales para la existencia misma de la aplicacin porque la construyen. Son bidireccionales, es decir, un objeto es padre de otro cuando el primer objeto se encuentra situado inmediatamente encima del segundo en la organizacin en la que ambos forman parte; asimismo, si un objeto es padre de otro, el segundo es hijo del primero (en la fig. 2, B es padre de D,E y F, es decir, D,E y F son hijos de B; en la fig. 3, los objetos B y C son padres de F, que a su vez es hijo de ambos). Una organizacin jerrquica simple puede definirse como aquella en la que un objeto puede tener un solo padre, mientras que en una organizacin jerrquica compleja un hijo puede tener varios padres). -Relaciones semnticas. Se refieren a las relaciones que no tienen nada que ver con la organizacin de la que forman parte los objetos que las establecen. Sus propiedades y consecuencia solo dependen de los objetos en s mismos (de su significado) y no de su posicin en la organizacin. Se puede ver mejor con un ejemplo: supongamos que vamos a construir un diccionario informatizado que permita al usuario obtener la definicin de una palabra cualquiera. Supongamos que, en dicho diccionario, las palabras son objetos y que la organizacin jerrquica es la que proviene de forma natural de la estructura de nuestros conocimientos sobre el mundo. La raz del diccionario podra llamarse TEMAS. De ste trmino genrico descendern tres grandes ramas de objetos llamadas VIDA, MUNDO y HOMBRE. El primero (vida) comprender las ciencias biolgicas: Biologa y Medicina. El segundo (mundo), las ciencias de la naturaleza inerte: las

Matemticas, la Fsica, la Qumica y la Geologa. El tercero (hombre) comprender las ciencias humanas: la Geografa, la Historia, etc. Como ejemplo: estableceremos la relacin trabajo entre los objetos NEWTON y OPTICA y la interpretaremos diciendo que significa que Newton trabaj en ptica (vase la fig. 4). La relacin es, evidentemente, semntica, pues no establece ninguna connotacin jerrquica entre NEWTON y OPTICA y su interpretacin depende exclusivamente del significado de ambos objetos. La existencia de esta relacin nos permitir responder a preguntas como: Quin trabaj en ptica?, En qu trabaj Newton?, Quien trabaj en Fsica? Las dos primeras se deducen inmediatamente de la existencia de la relacin trabajo. Para la tercera observamos que si Newton trabaj en ptica automticamente sabemos que trabaj en Fsica, por ser ptica una rama de la Fsica (en nuestro diccionario, el objeto OPTICA es hijo del objeto FISICA). Entonces gracias a la OOP podemos responder a la tercera pregunta sin necesidad de establecer una relacin entre NEWTON y FISICA, apoyndonos slo en la relacin definida entre NEWTON y OPTICA y en que OPTICA es hijo de FISICA. De este modo se elimina toda redundancia innecesaria y la cantidad de informacin que tendremos que definir para todo el diccionario ser mnima. 2. Propiedades. Todo objeto puede tener cierto nmero de propiedades, cada una de las cuales tendr, a su vez, uno o varios valores. En OOP, las propiedades corresponden a las clsicas "variables" de la programacin estructurada. Son, por lo tanto, datos encapsulados dentro del objeto, junto con los mtodos (programas) y las relaciones (punteros a otros objetos). Las propiedades de un objeto pueden tener un valor nico o pueden contener un conjunto de valores ms o menos estructurados (matrices, vectores, listas, etc.). Adems, los valores pueden ser de cualquier tipo (numrico, alfabtico, etc.) si el sistema de programacin lo permite. Pero existe una diferencia con las "variables", y es que las propiedades se pueden heredar de unos objetos a otros. En consecuencia, un objeto puede tener una propiedad de maneras diferentes: -Propiedades propias. Estn formadas dentro de la cpsula del objeto. -Propiedades heredadas. Estn definidas en un objeto diferente, antepasado de ste (padre, "abuelo", etc.). A veces estas propiedades se llaman propiedades miembro porque el objeto las posee por el mero hecho de ser miembro de una clase. 3. Mtodos. Una operacin que realiza acceso a los datos. Podemos definir mtodo como un programa procedimental o procedural escrito en cualquier lenguaje, que est asociado a un objeto determinado y cuya ejecucin slo puede desencadenarse a travs de un mensaje recibido por ste o por sus descendientes.

Son sinnimos de 'mtodo' todos aquellos trminos que se han aplicado tradicionalmente a los programas, como procedimiento, funcin, rutina, etc. Sin embargo, es conveniente utilizar el trmino 'mtodo' para que se distingan claramente las propiedades especiales que adquiere un programa en el entorno OOP, que afectan fundamentalmente a la forma de invocarlo (nicamente a travs de un mensaje) y a su campo de accin, limitado a un objeto y a sus descendientes, aunque posiblemente no a todos. Si los mtodos son programas, se deduce que podran tener argumentos, o parmetros. Puesto que los mtodos pueden heredarse de unos objetos a otros, un objeto puede disponer de un mtodo de dos maneras diferentes: -Mtodos propios. Estn incluidos dentro de la cpsula del objeto. -Mtodos heredados. Estn definidos en un objeto diferente, antepasado de ste (padre, "abuelo", etc.). A veces estos mtodos se llaman mtodos miembro porque el objeto los posee por el mero hecho de ser miembro de una clase. Polimorfsmo Una de las caractersticas fundamentales de la OOP es el polimorfsmo, que no es otra cosa que la posibilidad de construir varios mtodos con el mismo nombre, pero con relacin a la clase a la que pertenece cada uno, con comportamientos diferentes. Esto conlleva la habilidad de enviar un mismo mensaje a objetos de clases diferentes. Estos objetos recibiran el mismo mensaje global pero responderan a l de formas diferentes; por ejemplo, un mensaje "+" a un objeto ENTERO significara suma, mientras que para un objeto STRING significara concatenacin ("pegar" strings uno seguido al otro) Beneficios que se obtienen del desarrollo con OOP Da a da los costos del Hardware decrecen. As surgen nuevas reas de aplicacin cotidianamente: procesamiento de imgenes y sonido, bases de datos multimediales, automatizacin de oficinas, ambientes de ingeniera de software, etc. An en las aplicaciones tradicionales encontramos que definir interfaces hombre-mquina "a-la-Windows" suele ser bastante conveniente. Lamentablemente, los costos de produccin de software siguen aumentando; el mantenimiento y la modificacin de sistemas complejos suele ser una tarea trabajosa; cada aplicacin, (aunque tenga aspectos similares a otra) suele encararse como un proyecto nuevo, etc. Todos estos problemas an no han sido solucionados en forma completa. Pero como los objetos son portables (tericamente) mientras que la herencia permite la reusabilidad del cdigo orientado a objetos, es ms sencillo modificar cdigo existente porque los objetos no interaccionan excepto a travs de mensajes; en

consecuencia un cambio en la codificacin de un objeto no afectar la operacin con otro objeto siempre que los mtodos respectivos permanezcan intactos. La introduccin de tecnologa de objetos como una herramienta conceptual para analizar, disear e implementar aplicaciones permite obtener aplicaciones ms modificables, fcilmente extendibles y a partir de componentes reusables. Esta reusabilidad del cdigo disminuye el tiempo que se utiliza en el desarrollo y hace que el desarrollo del software sea ms intuitivo porque la gente piensa naturalmente en trminos de objetos ms que en trminos de algoritmos de software. Problemas derivados de la utilizacin de OOP en la actualidad Un sistema orientado a objetos, por lo visto, puede parecer un paraso virtual. El problema sin embargo surge en la implementacin de tal sistema. Muchas compaas oyen acerca de los beneficios de un sistema orientado a objetos e invierten gran cantidad de recursos luego comienzan a darse cuenta que han impuesto una nueva cultura que es ajena a los programadores actuales. Especficamente los siguientes temas suelen aparecer repetidamente: Curvas de aprendizaje largas. Un sistema orientado a objetos ve al mundo en una forma nica. Involucra la conceptualizacin de todos los elementos de un programa, desde subsistemas a los datos, en la forma de objetos. Toda la comunicacin entre los objetos debe realizarse en la forma de mensajes. Esta no es la forma en que estn escritos los programas orientados a objetos actualmente; al hacer la transicin a un sistema orientado a objetos la mayora de los programadores deben capacitarse nuevamente antes de poder usarlo. Dependencia del lenguaje. A pesar de la portabilidad conceptual de los objetos en un sistema orientado a objetos, en la prctica existen muchas dependencias. Muchos lenguajes orientados a objetos estn compitiendo actualmente para dominar el mercado. Cambiar el lenguaje de implementacin de un sistema orientado a objetos no es una tarea sencilla; por ejemplo C++ soporta el concepto de herencia mltiple mientras que SmallTalk no lo soporta; en consecuencia la eleccin de un lenguaje tiene ramificaciones de diseo muy importantes. Determinacin de las clases. Una clase es un molde que se utiliza para crear nuevos objetos. En consecuencia es importante crear el conjunto de clases adecuado para un proyecto. Desafortunadamente la definicin de las clases es ms un arte que una ciencia. Si bien hay muchas jerarquas de clase predefinidas usualmente se deben crear clases especficas para la aplicacin que se est desarrollando. Luego, en 6 meses 1 ao se da cuenta que las clases que se establecieron no son posibles; en ese caso ser necesario reestructurar la jerarqua de clases devastando totalmente la planificacin original. Performance. En un sistema donde todo es un objeto y toda interaccin es a travs de mensajes, el trfico de mensajes afecta la performance. A medida que la tecnologa avanza y la velocidad de microprocesamiento, potencia y tamao de la

memoria aumentan, la situacin mejorar; pero en la situacin actual, un diseo de una aplicacin orientada a objetos que no tiene en cuenta la performance no ser viable comercialmente. Idealmente, habra una forma de atacar estos problemas eficientemente al mismo tiempo que se obtienen los beneficios del desarrollo de una estrategia orientada a objetos. Debera existir una metodologa fcil de aprender e independiente del lenguaje, y fcil de reestructurar que no drene la performance del sistema.
Bibliografa consultada Revista COMPU MAGAZINE, Nmero 51, Octubre '92 Revista COMPU MAGAZINE, Nmero 50, Septiembre '92

1.2.

Metodologas emergentes de desarrollo de software.

Proceso. Un proceso define quin hace qu, cundo y cmo para alcanzar cierto objetivo. El xito de las organizaciones radica en gran medida en la correcta definicin y empleo de sus procesos. Los sistemas de software pueden llegar a ser muy complejos, para administrar dicha complejidad es necesario contar con modelos de procesos y tecnologas de software apropiadas. Modelo de proceso. Define cmo solucionar la problemtica del desarrollo de sistemas de software. Para desarrollar software se requiere resolver ciertas fases de su proceso, las cuales se conocen como el ciclo de vida de desarrollo de software. Un modelo de proceso debe considerar aspectos como el conjunto de personas, estructuras organizacionales, reglas, polticas, actividades, componentes de software, metodologas y herramientas. No existe un solo modelo de proceso aplicable a cualquier proyecto, pues el modelo de proceso depende del tipo particular de proyecto: Primer proyecto de su tipo. Se crea desde cero, requiere de ms tiempo para especificarlo y analizarlo, la incertidumbre crea riesgos adicionales. Segundo proyecto de su tipo. Se busca agregar nueva funcionalidad a un o conocido. Variacin de un proyecto. Se extiende un sistema ya existente, lo cual involucra introducir componentes de software reutilizables como un marco de trabajo (framework), crear nuevos componentes o simplemente extender la aplicacin existente mediante nueva funcionalidad. Dependiendo de la estrategia a utilizar, el modelo del proceso debe variar. Proyecto de reescritura de legado (legacy). Se busca transformar o hacer una reingeniera de un sistema ya existente, desarrollado bajo tecnologas anteriores y transformarlo a tecnologas nuevas.

Proyecto de creacin de software reutilizable. Se busca crear uno o ms componentes de software reutilizables, debe ser diseado de tal manera que se asegure de que el diseo sea lo suficientemente general para ser til en otras situaciones desconocidas, por ello no hay muchos proyectos as. Proyecto de mejora de sistema o mantenimiento. Se busca modificar los componentes bsicos de un sistema para apoyar a una nueva funcionalidad. Son regularmente pequeos y afectan solo a partes del sistema.

Componentes de un modelo de proceso Arquitectura. Estructura general de un sistema y vara de acuerdo con el tipo de sistema a desarrollarse: Transformacin en lote (batch). Sistemas de transformacin sobre un conjunto de entradas de valor constante, para generar un conjunto de salidas, ejemplo un compilador. Transformacin continua. Sistemas de transformacin sobre un conjunto de entradas de valor constante, para generar un conjunto de salidas que difieren en el tiempo, ejemplo sistema de control de seales. Sistemas interactivos. Regidos por interacciones externas, por lo general un usuario, son controlados por manejadores de eventos, encargados de procesar acontecimientos generados por el usuario, ejemplo un click o presionar una tecla. Simulacin dinmica. Sistemas que simulan sistemas del mundo real y evolucionan con el tiempo, ejemplo simuladores de sistemas financieros, redes neuronales, etc. Sistemas de tiempo real. Regidos por restricciones estrictas en el tiempo y requieren garantas en el tiempo de respuesta, ejemplos controladores de procesos industriales y dispositivos de comunicacin. Administracin de transaccin. Sistemas para interactuar con las bases de datos y que incluyen acceso concurrente y distribuido de mltiples usuarios, ejemplo reservaciones de vuelo y control de inventario. Tambin la arquitectura involucra las interfaces (elementos grficos), la funcionalidad (reglas del negocio), los datos y las funciones (elementos internos de los objetos) Actividad. Es una unidad o paso bsico de un proceso. En el proceso de software las actividades definen los pasos necesarios para lograr las metas y los objetivos. Las actividades bsicas del proceso de desarrollo de software son conocidas como el ciclo de vida: Requisitos. Para especificar aspectos funcionales del sistema, que describen cmo interactuara un usuario con la aplicacin, se genera un Modelo de Requisitos.

Anlisis. Para dar al sistema una estructura o arquitectura robusta y extensible, se genera un Modelo de Anlisis. Diseo. Para adoptar y refinar la arquitectura del sistema y adaptarla sl ambiente de implementacin, se genera un Modelo de Diseo (de estructuras o de objetos y de sistema). Implementacin. Para codificar el sistema, se genera un Modelo de Implementacin (lenguajes de programacin, bases de datos). Integracin. Para combinar componentes del sistema, se genera un Modelo de Integracin. Pruebas. Para validar y verificar el sistema, se genera un Modelo de Pruebas (validacin de acuerdo a la especificacin del cliente y verificacin si el sistema est siendo desarrollado correctamente). Documentacin. Para describir los diversos aspectos del sistema, se generan los manuales de usuario, programador, operador, administrador). Mantenimiento. Para extender la funcionalidad del sistema, es la continuacin del ciclo de vida, una vez concluida la primera versin del sistema.

Mtodos y Metodologas. Los mtodos definen las reglas para las transformaciones internas de las actividades, mientras que las metodologas definen el conjunto de mtodos. Un mtodo es un procedimiento que define tareas o acciones a realizar, donde cada tarea incluye condiciones de entrada y de salida que se deben satisfacer antes y despus de completarse. Los mtodos deben: Apoyar conceptos bsicos significativos para resolver problemas. Se deben utilizar en distintos dominios de aplicacin segn las arquitecturas: secuencial, concurrente, distribuido, en tiempo real. Deben ajustarse al ciclo de vida del proceso, apoyando a todas las actividades. Deben proveer tcnicas para recopilar informacin. Deben apoyar su propia extensibilidad, su propia documentacin. Deben permitir la generacin de modelos a partir de la informacin recopilada por el mtodo. Deben apoyar la integridad de los modelos generados, verificando y evitando errores de consistencia. Deben ofrecer entradas y salidas bien definidas que permitan la integracin de varios mtodos. Deben contar con notaciones especficas y estandarizadas para representar los modelos desarrollados, los cuales deben incluir elementos grficos, de texto o combinacin de ambos. Deben tener confianza en los mtodos y las herramientas correspondientes; para lo cual se debe contemplar que stos se mantendrn en el mercado y, que cuenten con capacitacin y apoyo tcnico.

Existen una gran variedad de mtodos y metodologas en apoyo al proceso de software, como son las estructuras y orientadas a objetos. Estructuradas: Se enfocan en la descomposicin funcional de un sistema. El objetivo es lograr una definicin completa del sistema, estableciendo los datos de entrada y salida. Estas metodologas se conocen como anlisis y diseo estructurado (SA/SD Structured Analysis and Structured Design) y se basan en herramientas como: o Diagramas de flujo de datos. Modelado de transformacin de datos entre funciones del sistema. Se compone de procesos, flujo de datos, actores, y almacenamiento de datos (DFD). o Diagramas de transicin de estado. Sirven para modelar el comportamiento a travs del tiempo, describen el efecto de eventos externos en los procesos y funciones. o Diagramas entidad-relacin. Para modelar un almacenamiento de datos. Orientadas a objetos: Se enfocan en el modelado de un sistema en trminos de objetos. Se identifican inicialmente los objetos del sistema para luego especificar su comportamiento y usan las herramientas siguientes: o Diagramas de clase. Describen los componentes esenciales de la arquitectura de un sistema. A diferencia de los DFD, los de clases muestran relaciones de asociacin entre clases y no flujo de datos entre ellas. o Diagramas de casos de uso. Especifican un sistema en trminos de su funcionalidad. A diferencia de las metodologas estructuradas los de casos de uso no son descompuestos en funciones de programacin. o Diagramas de transicin de estado. Describen los cambios de estado de los objetos. o Diagramas de secuencia. Describen los aspectos dinmicos de sistema, mostrando el flujo de eventos entre objetos en el tiempo. o Diagramas de colaboracin. Describen la comunicacin entre objetos de un sistema. o Diagramas de subsistemas. Se usan para describir agrupaciones de clases en un sistema. Estrategias. Una estrategia es como un plan para lograr un objetivo. Afectan aspectos como la arquitectura del sistema, el orden en que se llevarn a cabo las actividades del proceso y las metodologas a utilizarse. Las estrategias incluyen la seleccin del tipo de proyecto a desarrollarse, seleccin de una tecnologa y lenguaje de programacin (ej. Tecnologa OO y lenguaje JAVA), otras estrategias aceptadas son los prototipos (versin preliminar de un sistema) y la reutilizacin (componentes desarrollados anteriormente).

Herramientas. Aplicaciones que apoyan la administracin del proceso de software y el conjunto de estas herramientas se le conoce como ingeniera de software asistida por computadora (CASE, Computer-Aided Software Engineering), cuyo objetivo es asistir al desarrollador durante las diferentes actividades del ciclo de vida del proceso de software: Editores de texto, generadores de modelos grficos (diagramas), generadores de cdigo, compiladores, depuradores, verificadores, validadores, medidores (monitores), administracin de configuracin y administradores de proyecto. Metodologas de desarrollo de software
1970s

Programacin estructurada sol desde 1969 Programacin estructurada Jackson desde 1975

1980s

Structured Systems Analysis and Design Methodology (SSADM) desde 1980 Structured Analysis and Design Technique (SADT) desde 1980 Ingeniera de la informacin (IE/IEM) desde 1981

1990s

Rapid application development (RAD) desde 1991. Programacin orientada a objetos (OOP) a lo largo de la dcada de los 90's Virtual finite state machine (VFSM) desde 1990s Dynamic Systems Development Method desarrollado en UK desde 1995. Scrum (desarrollo), en la ltima parte de los 90's Rational Unified Process (RUP) desde 1999.

Emergentes

Ganar-ganar (win-win). Extiende el modelo de espiral, haciendo nfasis en la identificacin de las condiciones de ganancia para todas las partes, creando un plan para alcanzar las condiciones ganadoras y los riesgos correspondientes. Se consideran cuatro ciclos compuestos de cuatro actividades: 1. Elaborar los objetivos, restricciones y alternativas del proceso y producto del sistema y subsistema. 2. Evaluar las alternativas con respecto a los objetivos y restricciones. Identificar y resolver las fuentes principales de riesgo en el proceso y el producto. 3. Elaborar la definicin del producto y el proceso.

4. Planear el siguiente ciclo y actualizar el plan de su ciclo de vida, incluyendo la particin del sistema en subsistemas para ser considerados en ciclos paralelos. Programacin Extrema (XP, eXtreme Programming. .. desde 1999 Proceso Unificado (UP, Unified Process). Es una extensin al proceso objectory (object factory), que tiene sus orgenes en la dcada de 1980. Se basa especialmente en la especificacin de requerimientos de un sistema mediante casos de uso; parte de la arquitectura del sistema, siguiendo un proceso iterativo e incremental; integra aspectos como ciclos, fases, flujos de trabajo, mitigacin de riesgo, control de calidad, administracin de proyecto y control de configuracin; considera las 4 P del desarrollo del software (personas, proyecto, producto y proceso); y se basa en las creencias de que para que un sistema sea exitoso se debe saber qu quiere y necesita el usuario, as como que las arquitecturas de los sistemas de software deben permitir visualizar un sistema desde diferentes perspectivas (como los edificios electricidad, estructura, etc.-) y que dividir en etapas es prctico porque el desarrollo y la implementacin pueden durar mucho tiempo.
Enterprise Unified Process (EUP) extensiones RUP desde 2002 Constructionist design methodology (CDM) desde 2004 por Kristinn R. Thrisson Agile Unified Process (AUP) desde 2005 por Scott Ambler

Cada metodologa de desarrollo de software tiene ms o menos su propio enfoque para el desarrollo de software. Estos son los enfoques ms generales, que se desarrollan en varias metodologas especficas. Estos enfoques son los siguientes:

Modelo en cascada: Framework lineal. Prototipado: Framework iterativo. Incremental: Combinacin de framework lineal e iterativo. Espiral: Combinacin de framework lineal e iterativo. RAD: Rapid Application Development, framework iterativo.

1.3.

Mtodos de desarrollo de software orientado a objetos. (Alfredo Weitzenfeld)

Mtodos de desarrollo de software orientados a objetos Siglas Mtodo RDD Responsability-Driven Design CRC Tarjetas Clase-Responsabilidad-Colaboracin OOAD Object-Oriented Analysis and Design OOD Object-Oriented Design OMT Object Modeling Technique OOSE Object Oriented Software Engineering OOK/MOSES Object-Oriented Knowledge

OOSA OBA OORA Synthesis OOSD OOAD/ROSE FUSION UP

Object-Oriented System Analysis Object Behavior Analysis Object-Oriented Requirements Analysis Synthesis Method Object-Oriented System Development Object-Oriented Analysis and Design Object-Oriented Development Unified Software Development Process

Actividad
Requisitos

Mtodo
Mtodos de requisitos OBA FUSION UP Mtodos de anlisis OBA FUSION UP Mtodos de diseo UML FUSION RDD Mtodos de codificacin Tcnicas de JAVA Tcnicas de C++ Tcnicas de Smalltalk

Notacin

Actor 1

Casos de uso

en UML

Actor 2

Anlisis

Clase 1 Asociacin de clases en UML

Clase 2

Diseo

Clase 1

Clase 2

Asociacin de clases en UML

Implementacin

class Clase 1 extends Clase X

..

Fig.

Contraste de las actividades, mtodos y notaciones de desarrollo de software

1.4.

El proceso de desarrollo unificado RUP.

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que ofrecer desde la perspectiva del usuario. Este modelo puede trabajar como un contrato entre el desarrollador y el cliente o usuario del sistema, por lo que deber proyectar lo que el cliente desea segn la percepcin del desarrollador. Por ello, es esencial que los clientes lo comprendan. El modelo de requisitos es el primero en desarrollarse, y es la base para formar todos los dems modelos en el desarrollo de software. En general, cualquier cambio en la funcionalidad del sistema es ms fcil de hacer, y con menores consecuencias a este nivel que posteriormente. El modelo de requisitos que se desarrollar se basa en la metodologa Objectory (Jacobson, 1992), que tiene su fundamento en el modelo de casos de uso. Actualmente esta metodologa es parte del Proceso Unificado Racional (RUP, Rational Unified Process). El modelo de casos de uso y el propio modelo de requisitos son la base para los dems modelos.

El proceso unificado de desarrollo de software es el conjunto de actividades necesarias para transformar requisitos de usuarios en software. La tendencia actual en el software lleva a la construccin de sistemas ms grandes y ms complejos. El UP (proceso unificado) naci bajo la premisa de renovar la manera de desarrollar software empleando lo mejor de las viejas prcticas y adoptando nuevas y ms eficientes maneras, de tal manera que el UP es un intento de obtener lo mejor de otros modelos. El proceso unificado est basado en componentes interconectados a travs de interfaces bien definidas, utiliza las bases del UML (Lenguaje Unificado de Modelado Unified Modeling Languaje), se resume en tres fases clave: Dirigido por casos de uso, Centrado en la arquitectura, Iterativo e incremental. El UP est dirigido por casos de uso. Para construir un sistema con xito debemos conocer lo que sus futuros usuarios necesitan y desean. El trmino usuario no hacer referencia solo a humanos sino tambin a otros sistemas, as el trmino usuario representa a alguien o algo que interacta con el sistema en desarrollo, ejemplo, un persona utiliza un cajero automtico, inserta la tarjeta de plstico, responde a las preguntas que le hace la mquina mediante la pantalla y recibe su dinero; con este proceso se llevan a cabo una secuencia de acciones que proporcionan al usuario un resultado. Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado, los casos de uso representan los requisitos funcionales, todos los casos de uso juntos constituyen el modelo de casos de uso, el cual describe la funcionalidad total del sistema (qu debe hacer el sistema), los casos de uso guan el diseo, implementacin y prueba del sistema, es decir el proceso de desarrollo de software Centrado en la arquitectura. El papel de la arquitectura de software es parecido al papel que juega la arquitectura de la construccin de edificios. El edificio se contempla desde varios puntos de vista: estructura, servicios, calefaccin, fontanera, electricidad, etc. Esto permite a un constructor ver una imagen completa antes de que comience la construccin. Analgicamente, la arquitectura de un sistema de software se describe mediante diferentes vistas del sistema. La arquitectura se ve influida por la plataforma de software y surge de las necesidades de la empresa y se refleja en los casos de uso (arquitectura hardware, sistema operativo, sistemas de gestin de bases de datos, protocolos de red), los bloques de construccin reutilizables, consideraciones de implantacin, sistemas heredados, y requisitos no funcionales (rendimiento, fiabilidad). La arquitectura y los casos de uso se relacionan en que todo producto de software tiene tanto una forma como una funcin, los casos de uso representan la funcin (funcionalidad) y la arquitectura representa la forma (que permite el desarrollo inicial y las adecuaciones en el futuro).

El arquitecto: crea un borrador de la arquitectura (plataforma), debe tener en mente los casos de uso generales; contina con un subconjunto de casos de uso en detalle (subsistemas, clases, componentes); a medida que los casos de uso se especifican y maduran, se descubre mejor la arquitectura, esto lleva a ms casos de uso y contina hasta que se considera la arquitectura ya es estable. Iterativo e incremental. El proceso de desarrollo puede durar meses hasta un ao o ms. Por tal motivo es prctico dividir el trabajo en partes o miniproyectos, cada miniproyecto es una iteracin (pasos en el flujo de trabajo) que resulta en un incremento (crecimiento del producto). Los desarrolladores basan su implementacin en dos factores: La iteracin trata un grupo de casos de uso y juntos amplan la utilidad del producto desarrollado hasta ahora; y La iteracin trata los riesgos ms importantes. Los beneficios del proceso iterativo controlado: La iteracin reduce el costo del riesgo, ya que se van controlando a la vez que se visualizan, con lo que se fortalece el producto desde el principio y no se van arrastrando riesgos que en el futuro podran llevar al producto de software al fracaso; as la organizacin slo perdera el esfuerzo empleado en la iteracin y no de todo el producto. La iteracin controlada reduce el riesgo de no sacar al mercado el producto en el tiempo previsto, se reconoce mejor el problema desde el principio y no hasta la fase de pruebas. La iteracin controlada acelera el ritmo del esfuerzo de desarrollo porque los desarrolladores trabajan ms eficientemente para obtener resultados claros a corto plazo y no tener un periodo de desarrollo prolongado. La iteracin controlada reconoce una realidad que a menudo se ignora: que las necesidades del usuario y sus requisitos no pueden definirse completamente al principio, pues stas se refinan en iteraciones sucesivas; esto hace ms fcil la adaptacin a requerimientos cambiantes. La arquitectura proporciona la estructura para guiar la iteracin y los casos de uso definen objetivos y dirigen el trabajo de cada iteracin. La VIDA del UP, FASES del proceso unificado. (I. Jacobson, 2000) Se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema, donde cada ciclo es una versin del producto, las fases del ciclo de vida son: Requisitos, Anlisis, Diseo, Implementacin, Pruebas. Nacimiento Muerte

Tiempo

Ciclos/versiones

Fases del proceso unificado. (Roger P., 2010)

Elaboracin

Concepcin

Construccin Transicin Lanzamiento Incremento del software

Produccin

Concepcin. Agrupa actividades tanto de comunicacin con el cliente como de planeacin. Al colaborar con los participantes, se identifican los requerimientos del negocio, se propone una arquitectura aproximada para el sistema y se desarrolla un plan para la naturaleza iterativa e incremental del proyecto en cuestin, los requerimientos fundamentales del negocio se describen por medio de un conjunto de casos de uso preliminares que detallan las caractersticas y funciones que desea cada clase principal de usuarios. La planeacin identifica los recursos, evala los riesgos principales, define un programa de actividades y establece una base para las fases que siguen. Elaboracin. Incluye las actividades de planeacin y modelado del modelo general del proceso. La elaboracin mejora y ampla los casos de uso preliminares desarrollados como parte de la fase de concepcin y aumenta la representacin de la arquitectura para incluir cinco puntos de vista distintos del software; en algunos casos en este punto se crea una versin ejecutable. La planeacin incluye aspectos como la estimacin, programacin de tiempos y anlisis de riesgos; el modelado incluye aspectos de anlisis, diseo). Construccin. En esta fase se hacen operativos los casos de uso para los usuarios finales; se obtiene el cdigo fuente y a medida que se va codificando se van desarrollando pruebas unitarias y poco a poco las actividades de integracin (ensamble de componentes y pruebas de integracin). Transicin. Incluye la entrega y la retroalimentacin, es donde se proporciona a los usuarios para la prueba beta, para que reporten los defectos y los cambios necesarios. El

equipo de software genera la informacin de apoyo necesaria (manuales de usuario, guas de solucin de problemas, procedimientos de instalacin, etc.) que se requieren para el lanzamiento. Incluye a las actividades de construccin y despliegue. Produccin. No siempre las fases son secuenciales, pueden darse en forma escalonada o bien pueden desarrollarse algunas a la vez. Coincide con la actividad del despliegue, durante la produccin se vigila el uso que se le da al software, se brinda apoyo para la operacin y se reportan defectos y solicitudes de cambio para su evaluacin. Las cuatro P en el desarrollo de software. (I. Jacobson, 2000) El resultado final de un proyecto de software es un producto que toma forma durante su desarrollo gracias a la intervencin de muchos tipos distintos de personas. Un proceso de desarrollo de software gua los esfuerzos de las personas implicadas en el proyecto, a modo de plantilla que explica los pasos necesarios para terminar el proyecto. Todo proceso de software est automatizado por medio de una herramienta o conjunto de ellas.
Proceso

Plantilla Personas Participantes Proyecto Automatizacin Herramientas

Resultado Producto

Personas. Los principales autores de un proyecto de software son los arquitectos, desarrolladores, ingenieros de prueba y el personal de gestin que les da soporte, adems de los usuarios, clientes y otros interesados. Las personas son decisivas y los procesos afectan el comportamiento de las personas, considerando el modo en que se organizan y gestionan los proyectos de software, conceptos como la viabilidad del proyecto (la gente no se siente cmoda trabajando en un proyecto que parece imposible, se afecta la moral de las personas), la gestin del riesgo (cuando la gente siente que los riesgos no han sido analizados y reducidos, se sienten incmodos), la organizacin de los equipos (la gente trabaja mejor en equipos o grupos pequeos de seis a ocho miembros), la planificacin del proyecto (en ocasiones la gente cree que la planificacin de un proyecto no es realista, lo cual la moral se afecta, pensando en que nunca se acabar con el proyecto de software) y la facilidad de comprensin del proyecto (a la gente le gusta saber lo que est haciendo, requieren tener una comprensin global de lo que se est haciendo) tienen un papel importante, as como una sensacin de cumplimiento (en un ciclo de vida iterativo, la gente recibe retroalimentacin frecuentemente, lo que hace llegar a conclusiones y la retroalimentacin constante acelera el ritmo de trabajo, esto aumenta la sensacin de progreso) . Proyecto. Elemento organizativo a travs del cual se gestiona el desarrollo de software. El resultado de un proyecto es una versin de un producto.

Producto. Artefactos que se crean durante la vida del proyecto, como los modelos, cdigo fuente, ejecutables y documentacin. Un artefacto es un trmino general para cualquier tipo de informacin creada, producida, cambiada o utilizada por los trabajadores o desarrolladores del sistema, como ejemplo: diagramas UML y su texto asociado, los bocetos de la interfaz de usuario y los prototipos, los componentes, los planes de prueba y los procedimientos de prueba. Hay dos tipos de artefactos: artefactos de ingeniera (creados durante las distintas fases del proceso de software requisitos, anlisis, diseo, implementacin y prueba-), se ver ms ampliamente durante las unidades 2, 4 y 5; y artefactos de gestin (anlisis de riesgo, plan de desarrollo incluyendo el plan de iteraciones y versiones-, un plan para la asignacin de personas puestos y responsabilidades de los usuarios, ingenieros de prueba, diseadores, analistas, jefe de proyecto, arquitectos-), se ver ms ampliamente en la unidad 3. Un modelo es una abstraccin del sistema, el proceso de construccin de modelos es un artefacto usado para construir un sistema, utilizando distintos modelos para describir todas las perspectivas diferentes del sistema, la eleccin de los modelos para un sistema es una de las decisiones ms importantes del equipo de desarrollo. A travs de los modelos se describen elementos importantes como los actores. Proceso. Un proceso de ingeniera de software es una definicin del conjunto completo de actividades necesarias para transformar los requisitos de usuario en un producto. Un proceso es una plantilla para crear productos. El proceso dirige los proyectos, en la forma de desarrollo de software tradicional se usan los diagramas de flujo para describir el proceso en partes pequeas, en cambio en este modelo unificado se identifican primero los distintos tipos de trabajadores que participan en el proceso, despus se identifican los artefactos necesarios para cada tipo de trabajador o desarrollador. Una vez que se ha identificado, se puede describir cmo fluye el proceso a travs de los diferentes trabajadores, y cmo ellos crean, producen, y utilizan los diferentes artefactos, de aqu surgen los Diagramas de Actividad que describen el flujo de trabajo en el modelado de casos de uso, y con ello se pueden identificar claramente las actividades que los trabajadores (tambin son los usuarios y/o clientes) deben realizar cuando se activan. En otras palabras, se describe el proceso entero en partes llamadas flujos de trabajo en trminos de UML, un flujo de trabajo es un estereotipo de colaboracin, en el cual los trabajadores y los artefactos son los participantes. Los procesos de desarrollo de software no son de aplicabilidad universal, varan segn su contexto, segn restricciones del negocio como plazos, costos, calidad, fiabilidad: existen factores que influyen en el tipo de procesos y son: factores organizativos (estructura organizacional, cultura empresarial, organizacin y gestin del proyecto, aptitudes y habilidades, experiencias de desarrollo de software previas), factores del dominio (proceso de negocio, clientes, competencia), factores del ciclo de vida (tiempo de salida al mercado, la tecnologa, la experiencia o conocimiento de las personas en el desarrollo de software y las versiones planificadas y futuras), factores tcnicos (lenguajes de programacin, herramientas de desarrollo, bases de datos, marcos de trabajo y arquitecturas estndar, comunicaciones).

Herramientas. Software que se utiliza para automatizar las actividades definidas en el proceso (CASE- Computer Assisted Software Engineering). Soportan los procesos de desarrollos modernos, las herramientas influyen en el proceso, ya que son buenas para automatizar procesos repetitivos, mantener las cosas estructuradas, gestionar grandes cantidades de informacin y para guiarnos a lo largo del desarrollo; son usadas para aumentar la calidad, la productividad y para reducir el tiempo de desarrollo. Existen herramientas que soportan todos los aspectos del ciclo de vida del software, orientadas a la funcionalidad: Gestin de requisitos. Se utiliza para almacenar, examinar, revisar, hacer el seguimiento y navegar por los diferentes requisitos de un proyecto de software. Modelado visual. Se utiliza para automatizar el uso de UML, es decir, para modelar y ensamblar una aplicacin visualmente. Con esta herramienta se consigue la integracin con entornos de programacin y se asegura que el modelo y la implementacin sean consistentes. Herramientas de programacin. Editores, compiladores, depuradores, detectores de errores y analizadores de rendimiento. Aseguramiento de la calidad. Se utilizan para probar aplicaciones y componentes, para uso de las pruebas de estrs y carga (cmo responder el sistema cuando se estn utilizando 10,000 usuarios concurrentes. Adems de stas, hay otras que abarcan todo el ciclo de vida: control de versiones, gestin de la configuracin, seguimiento de defectos, documentacin, gestin de proyecto y automatizacin de procesos. 1.5. El lenguaje de modelado unificado UML.

http://www.que-informatica.com/index.php/software/uml-lenguaje-unificado-de-modelado-2/ http://www.docirs.cl/uml.htm definiciones de diagramas UML http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/docmodelado-sistemas-uml.pdf

Una parte esencial de todas las tareas del desarrollo del software, y de las especificaciones de requisitos y diseo en particular, es la utilizacin de una notacin que permita representar los aspectos esenciales de las mismas y que al mismo tiempo permita una mecanizacin parcial del proceso de desarrollo. Dado que en la actualidad la fase de implementacin se suele realizar con tecnologas orientadas a objetos y que adicionalmente este tipo de enfoque tambin es aplicable en otras fases del desarrollo, es importante que el alumno conozca, al menos los principios bsicos, de las notaciones orientadas a objetos, y en especial la ms extendida ltimamente, como es el UML (Unified Modelling Language, Lenguaje Unificado de Modelado).

Modelos

Cuando alguien intenta resolver un problema complejo lo primero que hace es estudiarlo: Ver cuales son sus componentes, establecer relaciones entre las partes, comprender sus propiedades e imaginar como funciona de un modo dinmico. Pero como la mente humana es perezosa, no estarn todos los detalles, slo los esenciales. Esto no es importante, con tal de que la representacin mental funcione igual que el problema real los detalles se pueden abstraer. El resultado de este proceso es un modelo. Por tanto, modelo es una representacin de la realidad donde se abstrae lo no esencial. Para un mismo sistema se puede establecer ms de un modelo diferente en funcin de que aspecto interese resaltar o del nivel de detalle que se quiera conseguir. ``UML'' son las siglas de Unified Modeling Language y como su nombre indica es un lenguaje de modelado, es decir, su utilidad est en que sirve para expresar modelos. No es nada ms que eso, no indica cmo se debe hacer el anlisis o el desarrollo orientados a objetos y en consecuencia, no es una metodologa de desarrollo, tan solo es una notacin, ahora bien, es la notacin que se ha convertido en el estndar de facto de la mayor parte de las metodologas de desarrollo orientado a objetos que existen hoy en da. Su utilidad est en la especificacin, visualizacin, construccin y documentacin. De esta frase, la palabra visualizacin es la ms importante; UML es un lenguaje basado en diagramas y est pensado para entrar por los ojos, tanto a los desarrolladores como a los clientes. Este captulo no pretende ser exhaustivo, debe entenderse ms bien como una introduccin inicial abreviada.
Historia

Grady Booch, Jim Rumbaugh e Ivar Jacobson (los tres amigos) desarrollaron las tres metodologas de desarrollo orientado a objetos ms seguidas de la industria. Rumbaugh con su OMT (Object Modeling Technique) y Booch unificaron sus mtodos, de ello naci la primera versin del UML en el ao 1994. Posteriormente, Jacobson, creador del mtodo OOSE (Object-Oriented Software Engineering) se uni al grupo. Actualmente el UML va por la versin 1.3 y la 2.0 est en preparacin

Elementos del lenguaje UML

A continuacin se vern una serie de elementos notacionales pero sin entrar en detalle en la esencia de lo que es el concepto de cada cosa (que se da por supuesto), sino solo en la forma de dibujarlo en UML.
1.3.2.1 Clase

Es el grfico ms importante. En la figura 1.8 podemos ver que tiene cuatro partes que se disponen de arriba a abajo en el orden siguiente:

Figure 1.8: Plantilla para una clase en UML

1. Nombre: Si aparece en cursiva la clase es abstracta. 2. Atributos: Pueden mostrar mucha informacin. 1. Tipo: Atributo:Tipo 2. Valor predeterminado: Atributo:Tipo=Valor Atributo=Valor 3. Restricciones: Las restricciones se pueden poner como se ha visto en el grfico, pero UML cuenta con un mtodo an ms formal que es el lenguaje OCL. 4. Alcance: Un atributo puede ser pblico(+), protegido(#) o privado(-). 5. mbito: Hay dos tipos Instancia: Cada objeto tiene su propio valor. Archivador: Solo hay un valor en todas las instancias de una clase (como las variables static en Java). Estos atributos aparecen subrayados. Toda esta informacin es opcional, de hecho la mayora de las veces se pone slo el nombre del atributo.

3. Mtodos: Al igual que los atributos tambin pueden especificar su alcance o mbito. Adems pueden indicar el tipo de los argumentos que reciben y el tipo del valor devuelto. Tanto si tienen parmetros como si no deben llevar un parntesis abierto y otro cerrado al final del nombre. 4. Responsabilidades: Es una descripcin de lo que hace la clase en su conjunto. Est informacin casi nunca est en los diagramas. La informacin que se ha puesto en la figura de ejemplo es mucho ms de la que se suele mostrar, una clase puede representarse con un simple rectngulo con su nombre, como se ve en la figura 1.9.

Figure: La clase ms sencilla posible

Adems se puede omitir parte de la informacin de un apartado. Los puntos suspensivos que hay en el ejemplo al final de las secciones de atributos y mtodos indican que la clase est abreviada, o lo que es lo mismo, faltan atributos y mtodos. Slo se pone lo necesario para expresar la idea del diagrama. Los estereotipos son una forma de introducir nuevos trminos sobre el vocabulario propio de un dominio. Los paquetes son agrupaciones de clases relacionadas de alguna forma entre s (su representacin se ilustra en la figura 1.10). Las notas son un texto explicativo de algn elemento y se representa de la forma indicada en la figura 1.11.

Figure 1.10: Un paquete que se puede encontrar en Java

Figure: Una anotacin relativa a una clase

1.3.2.2 Objetos

Los objetos son instancias de clases (sus atributos tienen valores especficos) y, como se indica en la figura 1.12, se representan poniendo el nombre de la instancia a la izquierda, dos puntos y el nombre de la clase de la que deriva a la derecha.

Figure: Smbolo en UML de un objeto 1.3.2.3 Relaciones

Las clases no estn aisladas, entre ellas pueden relacionarse de muchas maneras. La representacin bsica de las relaciones es una lnea (con otros elementos adicionales como flechas, rombos, texto, etc.) entre las clases relacionadas.
1.3.2.3.1 Asociaciones

Es una relacin conceptual, que no es inherente a la naturaleza de las clases, sino al papel que juegan en el modelo y especifica que las instancias de una clase estn conectadas con las de otra. No es una relacin fuerte, es decir, el tiempo de vida de un objeto no depende del otro. Como se puede ver en la figura 1.13, la relacin tiene un nombre que indica en que consiste y su direccin, indicada con un tringulo relleno. Se puede indicar adems (de forma opcional) cual es el papel (rol) que representa cada una de las partes en la relacin.

Figure: Ejemplo de una asociacin

Es posible que dos clases estn relacionadas entre s por ms de una relacin en ambos sentidos o que una clase est relacionada con muchas. Se dice que una relacin es reflexiva cuando una clase est asociada consigo misma. Es posible que una instancia de una clase pueda estar relacionada con un nmero variable de instancias de otra. La notacin para expresar esa multiplicidad es flexible:
1. Nmeros concretos. Un nmero exacto: A. Por ejemplo: 5 (significa exactamente 5). 2. Intervalos. Entre A y B, ambos incluidos: A..B. Por ejemplo: 2..6 (es entre 2 y 6). 3. Asterisco. El smbolo * significa muchos. Si est en un intervalo se pone en el extremo superior. A..* se lee: A o ms. Por ejemplo: 3..* (es 3 o ms). Si el * est solo significa que puede ser un nmero cualquiera, cero incluido. 4. Combinacin de los elementos anteriores: Por ejemplo: 1..4,6,9..* (que significa entre 1 y 4, 6, 9 ms de 9, es decir, los valores 0, 5, 7 u 8 no estaran permitidos); 2,4,6 (es los valores 2, 4 6 y ninguno ms). En el siguiente ejemplo, representado en la figura 1.14, se hacen las siguientes suposiciones:

Figure 1.14: Relaciones entre alumnos, asignaturas y profesores

Un alumno puede estar matriculado como mnimo en una asignatura (si no est en ninguna no es alumno) y como mximo en 11. En una asignatura se pueden matricular un nmero ilimitado de alumnos pero tiene que haber al menos uno o de lo contrario la asignatura no existe.

Un alumno puede estar haciendo o no el proyecto fin de carrera. En caso afirmativo tendr un profesor asignado como coordinador. Existen asignaturas que tienen prcticas y algunas de ellas son entre varios. Un alumno puede estar asociado con un nmero variable de compaero para hacerlas, puede ser que con nadie, uno, dos, ...

1.3.2.3.2 Navegabilidad

Es una propiedad del rol. Indica la posibilidad de ir desde el objeto fuente al objeto destino. Significa visibilidad, o sea que generalmente se ``ven'' los atributos. Por defecto la navegabilidad es bidireccional, pero a veces no ser posible viajar en ambas direcciones. Por ejemplo, en el caso de la figura 1.15 no es posible la bidireccionalidad debido a que dado un password no se puede conocer el usuario al que pertenece (al menos en principio).

Figure 1.15: Navegabilidad

1.3.2.3.3 Calificacin

Cuando se tiene una relacin uno a muchos existe el problema de la bsqueda, es decir, localizar la instancia correcta en el lado ``muchos''. Para reducir el nmero de instancias a uno se utiliza un atributo de la relacin, representado como se ve en la figura 1.16.

Figure: Calificacin

1.3.2.3.4 Agregacin

Es un tipo de relacin del tipo todo/parte y se representa como se muestra en la figura 1.17. Sirve para modelar elementos que se relacionan utilizando expresiones como: ``es parte de'', ``tiene un'', ``consta de'', etc. Todo lo que se ha dicho antes acerca de la multiplicidad es vlido aqu.

Figure: Agregacin

1.3.2.3.5 Composicin

Es un tipo de agregacin donde cada componente pertenece a un todo y slo a uno (en el ejemplo anterior no se cumple esto, por ejemplo, la antigua Unin Sovitica tena una parte europea y una parte asitica). En la figura 1.18 vemos un ejemplo de este tipo de relacin.

Figure: Composicin

1.3.2.3.6 Herencia y generalizacin

Indica que una subclase o clase secundaria hereda los mtodos y atributos definidos en una superclase o clase principal. La superclase es ms genrica que la subclase. Este tipo de conexin se lee como ``es un tipo de''. En UML se utiliza el trmino generalizacin en vez de herencia, pero es lo mismo. En la figura 1.19 se muestra un ejemplo de representacin.

Figure 1.19: Herencia. Las clases abstractas van en cursiva

1.3.2.3.7 Dependencias

Es un tipo de relacin en la que una clase usa a la otra. Por ejemplo: Una interfaz de un programa de dibujo tiene varios objetos en la pantalla. La clase Pantalla tiene el mtodo DibujarObjetoGrafico(o:OG) y dibujar una recta, un punto, etc en funcin de lo que sea ese objeto. Esta relacin se representa como en la figura 1.20.

Figure 1.20: Dependencias

1.3.2.3.8 Interfaces

Son un conjunto de operaciones que especifican parte de la funcionalidad proporcionada por una clase. Una interfaz es como una clase pero sin atributos. Se representa de dos formas como se muestra en la figura 1.21. En una como una clase con el estereotipo interfaz y en otra abreviada, sin mostrar los mtodos. Entre los interfaces tambin existe herencia. Una clase puede implementar varios interfaces, y un interfaz puede ser implementado por ms de una clase. Todos los mtodos de un interfaz son pblicos.

Figure 1.21: Interfaces

1.3.3 Diagrama de clases

Es el diagrama ms importante en UML. Es un modelo esttico del sistema que contiene los siguientes elementos:

Clases Interfaces Colaboraciones: Conjunto de clases, interfaces y dems que exhiben un comportamiento. Relaciones de dependencia, colaboracin y asociacin.

Se puede utilizar para modelizar tres cosas: 1. Los elementos del sistema. 2. Colaboraciones. 3. Esquema lgico de bases de datos. Veamos el modelado con diagrama de clases con el ejemplo de una estructura documental. Un objeto documental es, por ejemplo, un ejemplar de ``La divina comedia'' o la ``enciclopedia Espasa'', que est compuesto por varios volmenes. Cada libro tiene una portada y un texto que se pueden ver. Los libros se pueden consultar, abrir, etc; tienen ttulo, autor y un nmero de pginas. Cada ejemplar puede haber sido editado por una editorial en una fecha determinada. Un libro puede haber sido traducido a varios idiomas y ser citado en algunos diccionarios, los cuales a su vez pueden ser de un nico tipo: multivolumen, que estn compuestos (como es lgico) por varios volmenes. Los tipos de libros que existen son: con anexo o hipermedia. Los de tipo hipermedia pueden tener sonido o enlaces. En la figura 1.22 vemos cmo se puede representar todo esto en un diagrama de clases.

Figure 1.22: Ejemplo completo de un diagrama de clases tomado de

http://do.ole.com/personal6/biblioteconomie/articulos/art8.html

1.3.4 Diagrama de objetos

Es un diagrama que contiene objetos y enlaces entre ellos. Pueden tambin agruparse en paquetes y se puede mostrar las clases si se considera oportuno para mostrar los objetos que vienen de una clase concreta. Sirve para tomar una instantnea del sistema en un momento dado del funcionamiento. Tambin es un modelo esttico porque no representa la evolucin a travs del tiempo, sino un momento concreto. Como se puede ver en el ejemplo de la figura 1.23, la notacin correspondiente es:

1. Se pone el objeto en un rectngulo. 2. El nombre es opcional pero se debe poner la clase a la que pertenece precedida por dos puntos, todo ello subrayado: NombreObjeto:Clase 3. Puede tener variables con su valor. 4. Al igual que las clases los objetos pueden estereotiparse. 5. Los objetos pueden estar relacionados por enlaces, que son instancias de las asociaciones definidas en el diagrama de clases.

Figure 1.23: Diagrama de objetos

1.3.5 Diagrama de casos de uso

Los casos de uso son una descripcin de una interaccin con el sistema por parte de algo externo al sistema que se llama actor. Por ejemplo: un usuario pulsa el botn de llamada de un ascensor. El nombre del caso de uso se pone en la elipse, como en el de la figura 1.24. Un caso de uso es un patrn o comportamiento que exhibe el sistema. Los casos de uso representan requisitos funcionales. Los casos de uso se escriben desde el punto de vista del actor, que es el usuario o sistema externo que interacta con el sistema.

Figure 1.24: Caso de uso

Relaciones que nos podemos encontrar en los casos de uso (ver figura 1.25):

Figure 1.25: Relaciones entre casos de uso

1. Include: Es el concepto de subrutina. Si por ejemplo tenemos dos casos de uso A y B que tienen una serie de pasos en comn se ponen esos pasos en un tercer caso de uso C y A y B lo incluyen para usarlo. 2. Extends: Significa que un caso de uso B es igual al A al cual extiende aadiendo algunos pasos. 3. Comunicates: Comunica un actor con un caso de uso o con otro actor. 1.3.5.0.1 Modelado del contexto

Hay que modelar la relacin que tiene el sistema con los elementos externos. Los pasos a seguir son:
1. Identificar los actores que interactan con el sistema. 2. Organizar los actores. 3. Especificar las vas de comunicacin con el sistema. 1.3.5.0.2 Modelado de requisitos

Esto significa incorporar los casos de uso necesarios, tanto los que son visibles externamente como los que no. Para ello las actividades a seguir son:
1. 2. 3. 4. Establecer su contexto. Identificar las necesidades de los elementos del contexto. Nombrar esas necesidades y darles nombre de casos de uso. Identificar que casos de uso pueden ser especializaciones de otros y buscar especializaciones comunes para los casos de uso ya encontrados. Los casos de uso se vern con detalle ms adelante.

1.3.6 Diagrama de estados

Un sistema evoluciona en el tiempo pasando por una serie de estados. Parte de un estado inicial y llega a un estado final. Un estado tiene:

Nombre. Variables. Actividades, que pueden ser de dos tipos: o Acciones. Programadas por los desarrolladores o Eventos: Sucesos a los que reacciona el sistema. Pueden ser de tres tipos: Entry: Actividades que se realizan al entrar al estado. Exit: Eventos al abandonar el estado. Do: Actividades mientras se est en el estado. Y constan de las siguientes partes:

Signature: Nombre y lista de parmetros. o Guard condition: Expresin lgica que habilita o no la transicin. o Accin: Accin interna a ser ejecutada. o Mensaje: Evento enviado a otro objeto (o a varios).

Las transiciones entre estados pueden tener parmetros. Cada transicin tiene un evento asociado. Cuando se terminan las actividades de un estado hay una transicin.

Por ejemplo, supongamos que tenemos un ascensor que cuando est en el stano (rea restringida a la que slo se puede acceder con llave) sube a los pocos segundos para evitar que si alguien se ha colado pueda acceder a las viviendas. Por otra parte el ascensor puede estar subiendo, bajando o parado. Cuando se est bajando al stano se considera como un estado especial y el hecho de estar en el stano tambin. Esto se puede representar como en la figura 1.26.

Figure 1.26: Diagrama de estados para un ascensor

1.3.7 Diagrama de secuencias

Muestra los objetos y los mensajes intercambiados entre ellos teniendo en cuenta la temporalidad con la que ocurren. Pueden mostrarse tambin los componentes porque son objetos reutilizables y los casos de uso porque se muestran como objetos que implementan el caso de uso. Sirven para documentar el diseo y validar los casos de uso. Gracias a estos diagramas se puede ver cuales don los cuellos de botella del sistema observando el tiempo que consume el mtodo invocado. Los conceptos a tener en cuenta son:
1. Lnea de vida de un objeto: Es una representacin de la actividad del objeto durante el tiempo que dura el escenario. El tiempo transcurre de arriba abajo. Se representa con una cabecera con un rectngulo con el nombre del objeto y una lnea vertical de puntos por debajo. Durante el tiempo en el cual el objeto tiene un mtodo funcionando la lnea de puntos se convierte en un rectngulo como se muestra en el ejemplo. 2. Activacin: Es el proceso por el que un objeto pasa a tener un mtodo en ejecucin. Esto puede ocurrir o bien porque otro objeto ha invocado alguno de sus mtodos o porque lo ha invocado el mismo (self-delegation). Cuando un objeto activa a otro siguen en actividad. 3. Mensaje: Un mensaje es un objeto que invoca el mtodo de otro. La notacin es una flecha horizontal desde la lnea de vida de un objeto hasta otro. 4. Tiempos de transicin: Es el tiempo que hay entre un mensaje y otro. 5. Condicionales: Si se desea representar una alternativa o threads. El mensaje slo se enva si la condicin es verdadera. La condicin se escribe entre corchetes y puede referenciar a otro objeto (ver figura 1.27).

Figure 1.27: Diagrama de secuencias. Condicionales

6. Iteracin: Se pone el smbolo * previo a la condicin. Se repite la accin mientras la condicin es verdadera (ver figura 1.28).

Figure: Diagrama de secuencias. Iteracin

7. Creacin y destruccin de un objeto: La creacin de un objeto se representa con un mensaje de creacin sobre un rectngulo. La destruccin se representa con un aspa al final de su lnea de vida (ver figura 1.29). 8. Mtodos recursivos: Se representan poniendo un rectngulo superpuesto al que est activo en el momento (ver figura 1.29).

Figure: Diagrama de secuencias. Mtodos recursivos y destruccin de objetos Las boundary classes, o clases de frontera, sirven para capturar y documentar los requisitos de interfaz. Muestran la interaccin con el usuario o con un sistema externo. Las clases de entidad son las inherentes al modelo del dominio y las de control son las que gestionan el caso de uso asociado al diagrama de secuencias. 1.3.7.0.1 Reglas a seguir:

La primera columna debe corresponder al actor que inicia el caso de uso. La segunda columna debe ser un objeto de frontera, que se comunica con el actor. La tercera columna debe ser un objeto de control que gestiona el caso de uso.

Los objetos de control son creados por el objeto de frontera que inicia el caso de uso. Los objetos de frontera son creados por objetos de control. Los objetos de entidad son accedidos por objetos de control y frontera. Los objetos de entidad nunca tienen acceso a los objetos de frontera o control. De esta forma estos objetos pueden ser reutilizados en varios casos de uso distintos.

1.3.8 Diagrama de actividades

Son un caso especial de los diagramas de estados. Modela el comportamiento del sistema y la participacin de las clases en ese comportamiento. Describen el comportamiento interno de una clase en vez del comportamiento en funcin de los eventos. Para construirlos se puede seguir la siguiente estrategia:
1. Identificar una clase que participa en el comportamiento cuyas actividades de proceso deban ser especificadas. 2. Identificar las distintas actividades que se van a modelar. 3. Identificar: estados, flujos y objetos. Este diagrama es til para modelar el flujo de trabajo de un negocio a alto nivel (ver ejemplo en la figura 1.30) y consta de los siguientes elementos:

Figure: Diagrama de actividades. Concurrencia, bifurcacin e indicacin

1. 2. 3. 4. 5.

Punto inicial. Se representa por un crculo negro. Punto final. Es una diana. Actividades. Son rectngulos con bordes redondeados. Transiciones. Son el paso de una actividad a otra. Se representan con flechas. Actividades concurrentes. Se representan por sus correspondientes actividades y una barra negra de la cual parten las flechas que las inician. 6. Bifurcaciones: Se representan con un rombo o sencillamente con dos flechas que salen de una actividad a otras dos. En cualquier caso, la condicin se indica en cada uno de los ramales entre corchetes. 7. Indicaciones: Se pueden enviar o recibir. El envo se representa con un rectngulo acabado en flecha. El que las recibe con una figura complementaria de la anterior. Una indicacin modela el envo y recepcin de eventos.

1.3.9 Diagrama de componentes

Modelan la vista esttica del sistema. Ilustran la organizacin y las dependencias entre componentes software. Un componente puede ser: cdigo fuente, un programa ejecutable, tablas, o cualquier otro tipo de documento que forme parte del sistema. No tienen que estar presentes todos los componentes, suele mostrarse una parte. Un componente puede implementar una interfaz (ver figura 1.31).

Figure 1.31: Diagrama de componentes

El estndar de UML define cinco estereotipos: executable, library, table, file y document.
1.3.9.0.1 Ejecutables

Para modelarlos (ver ejemplo en la figura 1.32) los pasos a seguir son:

Figure: Ejecutable que usa una librera de manipulacin de listas

1. Identificar los componentes, particiones del sistema, cuales son factibles de ser reutilizadas, agruparlas por nodos y realizar un diagrama por cada nodo que se quiera modelar. 2. Identificar cada componente con su estereotipo correspondiente (executable, library, etc). 3. Relacionar los componentes entre s. 1.3.9.0.2 Cdigo fuente

Podemos usar estos diagramas (ver ejemplo en la figura 1.33) para expresar las dependencias que existen entre los mdulos para formar libreras o programas ejecutables.

Figure: Dependencias entre el cdigo

1.3.10 Diagrama de colaboracin

Dibuja las interacciones entre objetos organizadas a travs de los objetos y los enlaces que hay entre ellos. Este diagrama (ver ejemplo en la figura 1.34) es otra forma de ver la secuencia de eventos. Es lo mismo que los diagramas de secuencia (se puede generar de un modo automtico un tipo de diagrama a partir del otro).

Figure: Diagrama de colaboracin

1.3.11 Diagrama de distribucin

Refleja la organizacin del hardware. El elemento principal de este diagrama es el nodo. Hay dos tipos: los nodos con capacidad de ejecutar componentes y los que no pueden ejecutar. La informacin que hay en un nodo es: nombre del nodo y componentes del nodo (se puede poner slo sus nombres o un diagrama de componentes). Los nodos a su vez pueden estar fsicamente conectados con otros, lo que se representa con una lnea que los

une. La utilidad principal de este tipo de diagramas es la modelizacin de una red (ver ejemplo en la figura 1.35).

Figure: Diagrama de distribucin