EL LENGUAJE UNIFICADO DE MODELADO (UML) En todas las disciplinas de la Ingeniera se hace evidente la importancia de los modelos ya que describen

el aspecto y la conducta de "algo". Ese "algo" puede existir, estar en un estado de desarrollo o estar, todava, en un estado de planeacin. Es en este momento cuando los diseadores del modelo deben investigar los requerimientos del producto terminado y dichos requerimientos pueden incluir reas tales como funcionalidad, performance y confiabilidad. Adems, a menudo, el modelo es dividido en un nmero de vistas, cada una de las cuales describe un aspecto especfico del producto o sistema en construccin. El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de pequeo tamao se obtienen beneficios de modelado, sin embargo es un hecho que entre ms grande y ms complejo es el sistema, ms importante es el papel de que juega el modelado por una simple razn: "El hombre hace modelos de sistemas complejos porque no puede entenderlos en su totalidad". UML es una tcnica para la especificacin sistemas en todas sus fases. Naci en 1994 cubriendo los aspectos principales de todos los mtodos de diseo antecesores y, precisamente, los padres de UML son Grady Booch, autor del mtodo Booch; James Rumbaugh, autor del mtodo OMT e Ivar Jacobson, autor de los mtodos OOSE y Objectory. La versin 1.0 de UML fue liberada en Enero de 1997 y ha sido utilizado con xito en sistemas construidos para toda clase de industrias alrededor del mundo: hospitales, bancos, comunicaciones, aeronutica, finanzas, etc. Los principales beneficios de UML son: Mejores tiempos totales de desarrollo (de 50 % o ms). Modelar sistemas (y no slo de software) utilizando conceptos orientados a objetos. Establecer conceptos y artefactos ejecutables. Encaminar el desarrollo del escalamiento en sistemas complejos de misin crtica. Crear un lenguaje de modelado utilizado tanto por humanos como por mquinas. Mejor soporte a la planeacin y al control de proyectos. Alta reutilizacin y minimizacin de costos.

UML, Mtodo o Lenguaje de Modelado? UML es un lenguaje para hacer modelos y es independiente de los mtodos de anlisis y diseo. Existen diferencias importantes entre un mtodo y un lenguaje de modelado. Un mtodo es una manera explcita de estructurar el pensamiento y las acciones de cada individuo. Adems, el mtodo le dice al usuario qu hacer, cmo hacerlo, cundo hacerlo y por qu hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los mtodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del mtodo. Un modelo es expresado en un lenguaje de modelado. . Las reglas son sintcticas, semnticas y pragmticas (figura 1).

figura 1 Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una grfica, pero s una abstraccin que consiste en un nmero de diagramas y todos esos diagramas juntos muestran una "fotografa" completa del sistema. Las vistas tambin ligan el lenguaje de modelado a los mtodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son: Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los actores externos. Vista Lgica: Muestra cmo se disea la funcionalidad dentro del sistema, en trminos de la estructura esttica y la conducta dinmica del sistema. Vista de Componentes: Muestra la organizacin de los componentes de cdigo. Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicacin y sincronizacin que estn presentes en un sistema concurrente. Vista de Distribucin: muestra la distribucin del sistema en la arquitectura fsica con computadoras y dispositivos llamados nodos.

Diagramas: Los diagramas son las grficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinacin para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboracin, de actividad, de componentes y de distribucin. Smbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociacin, dependencia y generalizacin. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbologa. Reglas o Mecanismos generales: Proveen comentarios extras, informacin o semntica acerca del elemento de modelo; adems proveen mecanismos de extensin para adaptar o extender UML a un mtodo o proceso especfico, organizacin o usuario. FASES DEL DESARROLLO DE UN SISTEMA Las fases del desarrollo de sistemas que soporta UML son: Anlisis de requerimientos, Anlisis, Diseo, Programacin y Pruebas.

Anlisis de Requerimientos UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A travs del modelado de casos de uso, los actores externos que tienen inters en el sistema son modelados con la funcionalidad que ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son modelados con relaciones y tienen asociaciones entre ellos o stas son divididas en jerarquas. Los actores y casos de uso son descritos en un diagrama use-case. Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo que l (o ella) espera del sistema sin considerar la funcionalidad que se implementar. Un anlisis de requerimientos puede ser realizado tambin para procesos de negocios, no solamente para sistemas de software. Anlisis La fase de anlisis abarca las abstracciones primarias (clases y objetos) y mecanismos que estn presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso tambin se consideran en esta fase a travs de los modelos dinmicos en UML. Es importante notar que slo se consideran clases que estn en el dominio del problema (conceptos del mundo real) y todava no se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc. Diseo En la fase de diseo, el resultado del anlisis es expandido a una solucin tcnica. Se agregan nuevas clases que proveen de la infraestructura tcnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio del problema del anlisis son agregadas en esta fase. El diseo resulta en especificaciones detalladas para la fase de programacin. Programacin En esta fase las clases del diseo son convertidas a cdigo en un lenguaje de programacin orientado a objetos. Cuando se crean los modelos de anlisis y diseo en UML, lo ms aconsejable es trasladar mentalmente esos modelos a cdigo. Pruebas Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integracin, pruebas de sistema, pruebas de aceptacin, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son tpicamente ejecutadas por el programador. Las pruebas de integracin integran componentes y clases en orden para verificar que se ejecutan como se especific. Las pruebas de sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de aceptacin conducidas por el cliente verifican que el sistema satisface los requerimientos y son similares a las pruebas de sistema.

CONCEPTOS DE LA METODOLOGA ORIENTADA A OBJETOS

La metodologa orientada a objetos ha derivado de las metodologas anteriores a ste. As como los mtodos de diseo estructurado realizados guan a los desarrolladores que tratan de construir sistemas complejos utilizando algoritmos como sus bloques fundamentales de construccin, similarmente los mtodos de diseo orientado a objetos han evolucionado para ayudar a los

desarrolladores a explotar el poder de los lenguajes de programacin basados en objetos y orientados a objetos, utilizando las clases y objetos como bloques de construccin bsicos. Actualmente el modelo de objetos ha sido influenciado por un nmero de factores no slo de la Programacin Orientada a Objetos, POO (Object Oriented Programming, OOP por sus siglas en ingls). Adems, el modelo de objetos ha probado ser un concepto uniforme en las ciencias de la computacin, aplicable no slo a los lenguajes de programacin sino tambin al diseo de interfaces de usuario, bases de datos y arquitectura de computadoras por completo. La razn de ello es, simplemente, que una orientacin a objetos nos ayuda a hacer frente a la inherente complejidad de muchos tipos de sistemas. Se define a un objeto como "una entidad tangible que muestra alguna conducta bien definida". Un objeto "es cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los mtodos que controlan dichos datos". Los objetos tienen una cierta "integridad" la cual no deber ser violada. En particular, un objeto puede solamente cambiar estado, conducta, ser manipulado o estar en relacin con otros objetos de manera apropiada a este objeto. Actualmente, el Anlisis Orientado a Objetos (AOO) va progresando como mtodo de anlisis de requisitos por derecho propio y como complemento de otros mtodos de anlisis. En lugar de examinar un problema mediante el modelo clsico de entrada-proceso-salida (flujo de informacin) o mediante un modelo derivado exclusivamente de estructuras jerrquicas de informacin, el AOO introduce varios conceptos nuevos. Estos conceptos nuevos le parecen inusuales a mucha gente, pero son bastante naturales. Una clase es una plantilla para objetos mltiples con caractersticas similares. Las clases comprenden todas esas caractersticas de un conjunto particular de objetos. Cuando se escribe un programa en lenguaje orientado a objetos, no se definen objetos verdaderos sino se definen clases de objetos. Una instancia de una clase es otro trmino para un objeto real. Si la clase es la representacin general de un objeto, una instancia es su representacin concreta. A menudo se utiliza indistintamente la palabra objeto o instancia para referirse, precisamente, a un objeto. En los lenguajes orientados a objetos, cada clase est compuesta de dos cualidades: atributos (estado) y mtodos (comportamiento o conducta). Los atributos son las caractersticas individuales que diferencian a un objeto de otro (ambos de la misma clase) y determinan la apariencia, estado u otras cualidades de ese objeto. Los atributos de un objeto incluyen informacin sobre su estado. Los mtodos de una clase determinan el comportamiento o conducta que requiere esa clase para que sus instancias puedan cambiar su estado interno o cuando dichas instancias son llamadas para realizar algo por otra clase o instancia. El comportamiento es la nica manera en que las instancias pueden hacerse algo a s mismas o tener que hacerles algo. Los atributos se encuentran en la parte interna mientras que los mtodos se encuentran en la parte externa del objeto (figura 2).

Representacin visual de un objeto como componente de software figura 2 Para definir el comportamiento de un objeto, se crean mtodos, los cuales tienen una apariencia y un comportamiento igual al de las funciones en otros lenguajes de programacin, los lenguajes estructurados, pero se definen dentro de una clase. Los mtodos no siempre afectan a un solo objeto; los objetos tambin se comunican entre s mediante el uso de mtodos. Una clase u objeto puede llamar mtodos en otra clase u objeto para avisar sobre los cambios en el ambiente o para solicitarle a ese objeto que cambie su estado. Cualquier cosa que un objeto no sabe, o no puede hacer, es excluida del objeto. Adems, como se puede observar de los diagramas, las variables del objeto se localizan en el centro o ncleo del objeto. Los mtodos rodean y esconden el ncleo del objeto de otros objetos en el programa. Al empaquetamiento de las variables de un objeto con la proteccin de sus mtodos se le llama encapsulamiento. Tpicamente, el encapsulamiento es utilizado para esconder detalles de la puesta en prctica no importantes de otros objetos. Entonces, los detalles de la puesta en prctica pueden cambiar en cualquier tiempo sin afectar otras partes del programa. Esta imagen conceptual de un objeto un ncleo de variables empaquetadas en una membrana protectora de mtodos es una representacin ideal de un objeto y es el ideal por el que los diseadores de sistemas orientados a objetos luchan. Sin embargo, no lo es todo: a menudo, por razones de eficiencia o la puesta en prctica, un objeto puede querer exponer algunas de sus variables o esconder algunos de sus mtodos. El encapsulamiento de variables y mtodos en un componente de software ordenado es, todava, una simple idea poderosa que provee dos principales beneficios a los desarrolladores de software: Modularidad, esto es, el cdigo fuente de un objeto puede ser escrito, as como darle mantenimiento, independientemente del cdigo fuente de otros objetos. As mismo, un objeto puede ser transferido alrededor del sistema sin alterar su estado y conducta. Ocultamiento de la informacin, es decir, un objeto tiene una "interfaz publica" que otros objetos pueden utilizar para comunicarse con l. Pero el objeto puede mantener informacin y mtodos privados que pueden ser cambiados en cualquier tiempo sin afectar a los otros objetos que dependan de ello.

Los objetos proveen el beneficio de la modularidad y el ocultamiento de la informacin. Las clases proveen el beneficio de la reutilizacin. Los programadores de software utilizan la misma clase, y por lo tanto el mismo cdigo, una y otra vez para crear muchos objetos. En las implantaciones orientadas a objetos se percibe un objeto como un paquete de datos y procedimientos que se pueden llevar a cabo con estos datos. Esto encapsula los datos y los procedimientos. La realidad es diferente: los atributos se relacionan al objeto o instancia y los mtodos a la clase. Por qu se hace as? Los atributos son variables comunes en cada objeto de

una clase y cada uno de ellos puede tener un valor asociado, para cada variable, diferente al que tienen para esa misma variable los dems objetos. Los mtodos, por su parte, pertenecen a la clase y no se almacenan en cada objeto, puesto que sera un desperdicio almacenar el mismo procedimiento varias veces y ello va contra el principio de reutilizacin de cdigo. Otro concepto muy importante en la metodologa orientada a objetos es el de herencia. La herencia es un mecanismo poderoso con el cual se puede definir una clase en trminos de otra clase; lo que significa que cuando se escribe una clase, slo se tiene que especificar la diferencia de esa clase con otra, con lo cual, la herencia dar acceso automtico a la informacin contenida en esa otra clase. Con la herencia, todas las clases estn arregladas dentro de una jerarqua estricta. Cada clase tiene una superclase (la clase superior en la jerarqua) y puede tener una o ms subclases (las clases que se encuentran debajo de esa clase en la jerarqua). Se dice que las clases inferiores en la jerarqua, las clases hijas, heredan de las clases ms altas, las clases padres. Las subclases heredan todos los mtodos y variables de las superclases. Es decir, en alguna clase, si la superclase define un comportamiento que la clase hija necesita, no se tendr que redefinir o copiar ese cdigo de la clase padre (figura 3).

figura 3 De esta manera, se puede pensar en una jerarqua de clase como la definicin de conceptos demasiado abstractos en lo alto de la jerarqua y esas ideas se convierten en algo ms concreto conforme se desciende por la cadena de la superclase. Sin embargo, las clases hijas no estn limitadas al estado y conducta provistos por sus superclases; pueden agregar variables y mtodos adems de los que ya heredan de sus clases padres. Las clases hijas pueden, tambin, sobreescribir los mtodos que heredan por implementaciones especializadas para esos mtodos. De igual manera, no hay limitacin a un slo nivel de herencia por lo que se tiene un rbol de herencia en el que se puede heredar varios niveles hacia abajo y mientras ms niveles descienda una clase, ms especializada ser su conducta. La herencia presenta los siguientes beneficios:

Las subclases proveen conductas especializadas sobre la base de elementos comunes provistos por la superclase. A travs del uso de herencia, los programadores pueden reutilizar el cdigo de la superclase muchas veces. Los programadores pueden implementar superclases llamadas clases abstractas que definen conductas "genricas". Las superclases abstractas definen, y pueden implementar parcialmente, la conducta pero gran parte de la clase no est definida ni implementada. Otros programadores concluirn esos detalles con subclases especializadas.

Ventajas de la metodologa orientada a objetos En sntesis, algunas ventajas que presenta son: Reutilizacin. Las clases estn diseadas para que se reutilicen en muchos sistemas. Para maximizar la reutilizacin, las clases se construyen de manera que se puedan adaptar a los otros sistemas. Un objetivo fundamental de las tcnicas orientadas a objetos es lograr la reutilizacin masiva al construir el software. Estabilidad. Las clases diseadas para una reutilizacin repetida se vuelven estables, de la misma manera que los microprocesadores y otros chips se hacen estables. El diseador piensa en trminos del comportamiento de objetos y no en detalles de bajo nivel. El encapsulamiento oculta los detalles y hace que las clases complejas sean fciles de utilizar. Se construyen clases cada vez ms complejas. Se construyen clases a partir de otras clases, las cuales a su vez se integran mediante clases. Esto permite construir componentes de software complejos, que a su vez se convierten en bloques de construccin de software ms complejo. Calidad. Los diseos suelen tener mayor calidad, puesto que se integran a partir de componentes probados, que han sido verificados y pulidos varias veces. Un diseo ms rpido. Las aplicaciones se crean a partir de componentes ya existentes. Muchos de los componentes estn construidos de modo que se pueden adaptar para un diseo particular. Integridad. Las estructuras de datos (los objetos) slo se pueden utilizar con mtodos especficos. Esto tiene particular importancia en los sistemas cliente-servidor y los sistemas distribuidos, en los que usuarios desconocidos podran intentar el acceso al sistema. Mantenimiento ms sencillo. El programador encargado del mantenimiento cambia un mtodo de clase a la vez. Cada clase efecta sus funciones independientemente de las dems. Una interfaz de pantalla sugestiva para el usuario. Hay que utilizar una interfaz de usuario grfica de modo que el usuario apunte a iconos o elementos de un men desplegado, relacionados con los objetos. En determinadas ocasiones, el usuario puede ver un objeto en la pantalla. Ver y apuntar es ms fcil que recordar y escribir. Independencia del diseo. Las clases estn diseadas para ser independientes del ambiente de plataformas, hardware y software. Utilizan solicitudes y respuestas con formato estndar. Esto les permite ser utilizadas en mltiples sistemas operativos,

controladores de bases de datos, controladores de red, interfaces de usuario grficas, etc. El creador del software no tiene que preocuparse por el ambiente o esperar a que ste se especifique. Interaccin. El software de varios proveedores puede funcionar como conjunto. Un proveedor utiliza clases de otros. Existe una forma estndar de localizar clases e interactuar con ellas. El software desarrollado de manera independiente en lugares ajenos debe poder funcionar en forma conjunta y aparecer como una sola unidad ante el usuario. Computacin Cliente-Servidor. En los sistemas cliente-servidor, las clases en el software cliente deben enviar solicitudes a las clases en el software servidor y recibir respuestas. Una clase servidor puede ser utilizada por clientes diferentes. Estos clientes slo pueden tener acceso a los datos del servidor a travs de los mtodos de la clase. Por lo tanto los datos estn protegidos contra su corrupcin. Computacin de distribucin masiva. Las redes a nivel mundial utilizarn directorios de software de objetos accesibles. El diseo orientado a objetos es la clave para la computacin de distribucin masiva. Las clases de una mquina interactan con las de algn otro lugar sin saber donde residen tales clases. Ellas reciben y envan mensajes orientados a objetos en formato estndar. Mayor nivel de automatizacin de las bases de datos. Las estructuras de datos (los objetos) en las bases de datos orientadas a objetos estn ligadas a mtodos que llevan a cabo acciones automticas. Una base de datos OO tiene integrada una inteligencia, en forma de mtodos, en tanto que una base de datos relacional bsica carece de ello. Migracin. Las aplicaciones ya existentes, sean orientadas a objetos o no, pueden preservarse si se ajustan a un contenedor orientado a objetos, de modo que la comunicacin con ella sea a travs de mensajes estndar orientados a objetos. Mejores herramientas CASE. Las herramientas CASE (Computer Aided Software Engineering, Ingeniera de Software Asistida por Computadora) utilizarn las tcnicas grficas para el diseo de las clases y de la interaccin entre ellas, para el uso de los objetos existentes adaptados a nuevas aplicaciones. Las herramientas deben facilitar el modelado en trminos de eventos, formas de activacin, estados de objetos, etc. Las herramientas OO del CASE deben generar un cdigo tan pronto se definan las clases y permitir al diseador utilizar y probar los mtodos recin creados. Las herramientas se deben disear de manera que apoyen el mximo de creatividad y una continua afinacin del diseo durante la construccin.

DIAGRAMA DE CASO DE USO (USE-CASE) Un modelo de casos de uso es descrito en UML como un diagrama de casos de uso (diagrama use-case) y dicho modelo puede ser dividido en varios diagramas de caso de uso. Un diagrama de casos de uso contiene elementos de modelo para el sistema, los actores y los casos de uso y muestra las diferentes relaciones tales como generalizacin, asociacin y dependencia entre estos elementos. El diagrama de caso de uso debe ser fcil de entender por el usuario final (figura 4).

figura 4 Los elementos de un diagrama de casos de uso son: Sistema Un sistema en un diagrama de caso de uso es descrito como una caja; el nombre del sistema aparece arriba o dentro de la caja. sta tambin contiene los smbolos para los casos de uso del sistema. Actores Un actor es alguien o algo que interacta con el sistema; es quien utiliza el sistema. Por la frase "interacta con el sistema" se debe entender que el actor enva a o recibe del sistema unos mensajes o intercambia informacin con el sistema. En pocas palabras, el actor lleva a cabo los casos de uso. Un actor puede ser una persona u otro sistema que se comunica con el sistema a modelar. Un actor es un tipo (o sea, una clase), no es una instancia y representa a un rol. Grficamente se representa con la figura de "stickman".

Encontrando a los actores de un diagrama de casos de uso. Es posible obtener a los actores de un diagrama de casos de uso a travs de las siguientes preguntas: Quin utilizar la funcionalidad principal del sistema (actores primarios)? Quin necesitar soporte del sistema para realizar sus actividades diarias? Quin necesitar mantener, administrar y trabajar el sistema (actores secundarios)? Qu dispositivos de hardware necesitar manejar el sistema? Con qu otros sistemas necesitar interactuar el sistema a desarrollar? Quin o qu tiene inters en los resultados (los valores) que el sistema producir?

Casos de uso Un caso de uso representa la funcionalidad completa tal y como la percibe un actor. Un caso de uso en UML es definido como un conjunto de secuencias de acciones que un sistema ejecuta y que permite un resultado observable de valores para un actor en particular. Grficamente se representan con una elipse y tiene las siguientes caractersticas: Un caso de uso siempre es iniciado por un actor. Un caso de uso provee valores a un actor. Un caso de uso es completo.

Encontrando casos de uso El proceso para encontrar casos de uso inicia encontrando al actor o actores previamente definidos. Por cada actor identificado, hay que realizar las siguientes preguntas: Qu funciones del sistema requiere el actor? Qu necesita hacer el actor? El actor necesita leer, crear, destruir, modificar o almacenar algn tipo de informacin en el sistema? El actor debe ser notificado de eventos en el sistema o viceversa? Qu representan esos eventos en trminos de funcionalidad? El trabajo diario del actor podra ser simplificado o hecho ms eficientemente a travs de nuevas funciones en el sistema? (Comnmente, acciones actuales del actor que no estn automatizadas)

Otras preguntas que nos ayudan a encontrar casos de uso pero que no involucran actores son: Qu entradas/salidas necesita el sistema? De dnde vienen esas entradas o hacia dnde van las salidas? Cules son los mayores problemas de la implementacin actual del sistema? DIAGRAMA DE SECUENCIA Este diagrama muestra la interaccin de los objetos entre ellos. Es importante comentar que hasta este momento no se han considerado objetos tcnicos. En UML, durante el Anlisis de los requerimientos y el Anlisis, no se consideran objetos tcnicos que definan detalles y soluciones en el sistema de software, tales como objetos para interfaces de usuario, bases de datos, comunicaciones, etc. Todos esos objetos se consideran hasta el diseo del sistema (figura 5).

figura 5 En este diagrama se observa que slo se consideran algunos objetos y es importante aclarar que estos no sern todos los objetos a considerar dentro del sistema, ya que todava es posible agregar nuevos objetos que no se haban considerado en el dominio del anlisis as como los objetos tcnicos, como se mencion anteriormente. Los objetos considerados se representan en rectngulos con el nombre subrayado y cada uno cuenta con su lnea de vida vertical que muestra la vida del objeto. DIAGRAMA DE COLABORACIN As mismo, se cuenta con el diagrama de colaboracin (figura 6), el cual se centra tanto en las interacciones y las ligas entre un conjunto de objetos colaborando entre ellos (una liga es una instancia de una asociacin). Ambos, el diagrama de secuencia y el diagrama de colaboracin, muestran interacciones, pero el diagrama de secuencia se centra en el tiempo mientras que el diagrama de colaboracin se centra en el espacio. Las ligas

muestran los objetos actuales y cmo ellos se relacionan unos con otros. As como los diagramas de secuencia, los diagramas de colaboracin pueden ser utilizados para ilustrar la ejecucin de una operacin, una ejecucin de un use-case o simplemente un escenario de interaccin dentro del sistema. En este diagrama tambin se representa a los objetos en cajas rectangulares y con el nombre subrayado. Las ligas se dibujan con lneas y se puede agregar una etiqueta para un mensaje y un nmero que define la secuencia de las ligas.

DIAGRAMA DE CLASES Para la realizacin del diagrama de clases (figura 7) se toman como base los diagramas de secuencia y de colaboracin por lo que se manejarn los objetos que ah se consideraron pero ahora a nivel de clases. Adems, se pueden agregar nuevas clases que no se haban considerado y este paso deber ser realizado por expertos en el dominio del problema. Para poder definir las clases, UML sugiere seis caractersticas selectivas que debe utilizar el analista para considerar una clase candidato en el modelo de anlisis:

1. Informacin retenida. La clase ser til durante el anlisis slo si la informacin sobre el
mismo ha de ser almacenada, transformada, analizada o manejada en algn otro modo. La informacin puede referirse a conceptos que debern estar siempre registrados en el sistema, eventos o transacciones que ocurren en un momento especfico.

2. Sistema externo. Si se tiene un sistema externo a este sistema, entonces es de inters en

la etapa de modelado. Los sistemas externos debern ser vistos como clases que el sistema contendr o con los cuales interactuar.

3. Patrones, libreras de clases o componentes. Si se tienen patrones, libreras de clases o

componentes, generalmente stos son clases candidatos.

4. Dispositivos que el sistema maneja. Dispositivos tcnicos que maneja el sistema se

convertirn en clases que manejarn esos dispositivos.

5. Partes organizacionales. Especialmente en modelos de negocio, todas las partes que

representan a la organizacin, sern clases candidatos.

6. Roles de actores. Los roles de actores sern vistos como clases, por ejemplo, usuario,
operador del sistema, administrador, cliente, etc.

figura 7

Grficamente, las clases se representan en una caja rectangular dividida en 3 compartimentos: en la parte superior se encuentra el nombre de la clase, en la parte media se encuentran los atributos y en la parte inferior se encuentran las operaciones o mtodos de la clase. Las clases se relacionan entre s a travs de las relaciones que son las lneas rectas entre dos clases y constan de roles y cardinalidad. Los roles son las frases que se encuentran en la relacin y sirven para definir la cardinalidad de la relacin, siempre considerando la unidad en la clase origen. Por ejemplo, observando la figura anterior, se puede decir que: "Un mapa puede contener una o ms computadoras y una computadora puede estar contenida en un mapa" Adems, tanto los atributos como los mtodos cuentan con una sintaxis. Para los atributos la sintaxis es la siguiente: visibilidad nombre : tipo = valor_inicial {lista_de_posibles_valores} y para los mtodos, la sintaxis es la siguiente: visibilidad nombre (lista_parmetros) : tipo_de_retorno {lista_de_posibles_valores} donde la lista de parmetros consta de la siguiente sintaxis: nombre : tipo = valor_default donde los parmetros van separados por comas y la visibilidad tanto para los atributos como para los mtodos, puede ser pblico o privado y se puede representar grficamente con un signo + para pblico y un signo para privado. DIAGRAMA DE ESTADOS Posteriormente se realiza el diagrama de estados (figura 8) el cual captura el ciclo de vida de los objetos, subsistemas y sistemas. Dicho diagrama determina los estados que un objeto puede tener y cmo los eventos afectan esos estados a travs del tiempo. Un diagrama de estado debe abarcar todas las clases que tengan estados y conducta definidos claramente. Todos los objetos tienen un estado y ste es el resultado de actividades previas ejecutadas por el objeto. Ese estado est determinado por los valores de los atributos de este objeto y sus relaciones con otros objetos. Una clase puede tener un atributo que especifique el estado, o el estado puede ser determinado por los valores de los atributos "normales" del objeto.

figura 8 Grficamente, los estados se representan en rectngulos con esquinas redondeadas y las lneas entre dos estados se llaman transiciones. Las transiciones constan de una sintaxis, la cual es la siguiente: nombre_evento (parmetros) [ condicin ] / accin_o_consecuencia donde los parmetros van separados por comas. La condicin es una expresin que tiene que considerarse para que el evento se genere y la accin o consecuencia es una expresin que se debe efectuar despus del evento y puede ser un incremento o un decremento. DIAGRAMA DE COMPONENTES Dentro de esta etapa se crea el diagrama de componentes que describe componentes de software y sus dependencias con otros componentes, representando la estructura del cdigo. Los componentes de software pueden ser: componentes de cdigo, componentes binarios que son los generados por la compilacin de los componentes de cdigo y los componentes ejecutables. En este diagrama se pueden manejar paquetes (figura 9), que son contenedores de clases utilizados para mantener el espacio de nombres de clases dividido en compartimentos, de manera que se utilizan para representar subsistemas del sistema en el mundo fsico. Cada paquete se liga con otros a travs de dependencias, que se representan con flechas de lneas discontinuas que van del componente dependiente al componente del cual depende.

figura 9 Cada paquete debe tener un diagrama de componentes para representar las clases que contiene internamente, similar a hacer un acercamiento o "zoom" al interior de cada uno de los paquetes (figura 10). Los componentes de software se representan con un rectngulo que contiene dos pequeos rectngulos en su extremo izquierdo.

DIAGRAMA DE COMPONENTES Por ltimo, se realiza el diagrama de despliegue, el cual contiene los nodos y las conexiones que muestran la arquitectura del sistema en tiempo de ejecucin a travs de procesadores, dispositivos y los componentes de software que se ejecutan en esta arquitectura. Esta es la ltima descripcin fsica de la topologa del sistema, describiendo la estructura de las unidades de hardware y el software que se ejecuta en cada unidad, como se muestra en la figura siguiente (figura 11). Los nodos se representan con cubos en tres dimensiones con su nombre en el interior. Si el nodo representa a una instancia en lugar de una clase, el nombre va subrayado. Las conexiones se representan con lneas continuas y contienen el nombre y el estereotipo de la conexin. El nombre es el identificador de la misma y el estereotipo indica el protocolo de comunicaciones entre los dos nodos implicados.

CRISIS DEL SOFTWARE La crisis del software es el hecho de que el software que se construye no solamente no satisface los requerimientos ni las necesidades pedidos por el cliente, sino que adems excede los presupuestos y los horarios de tiempos. El software es solicitado para ejecutar las tareas demandantes de hoy y est presente en todos los sistemas que van desde los ms sencillos hasta los de misin crtica. Las aplicaciones de software son complejas porque modelan la complejidad del mundo real. En estos das, las aplicaciones tpicas son muy grandes y complejas para que un individuo las entienda y, por ello, lleva gran tiempo implementar software. Uno de los principales problemas en el desarrollo de software de hoy en da es que muchos proyectos empiezan la programacin tan pronto se definen y concentran mucho de su esfuerzo en la escritura de cdigo. Una de las tcnicas que vino a solucionar este problema fue la Metodologa Orientada a Objetos. LA METODOLOGA ORIENTADA A OBJETOS A medida que se acercaban los aos 80, la metodologa orientada a objetos comenzaba a madurar como un enfoque de desarrollo de software. Empezamos a crear diseos de aplicaciones de todo tipo utilizando la forma de pensar orientada a los objetos e implementamos (codificamos) programas utilizando lenguajes y tcnicas orientadas a los objetos. La metodologa orientada a objetos presenta caractersticas que lo hacen idneo para el anlisis, diseo y programacin de sistemas; sin embargo, el anlisis de requisitos, que es la relacin entre la asignacin de software al nivel del sistema y el diseo del software, se qued atrs por lo que

empezaron a surgir diferentes mtodos de anlisis y diseo orientado a objetos, entre los que destacan los mtodos Booch, OOSE (Object Oriented Software Engineering) y OMT (Object Modeling Technique). Para poner fin a la "guerra de mtodos" que se present en ese momento, se cre el Lenguaje Unificado de Modelado (UML).