A nuestros padres por su apoyo incondicional.

INTRODUCCIN

El presente Trabajo de investigacin se realiz con la finalidad de compartir nuevos conocimientos con los estudiantes de la Carrera Profesional de Computacin e Informtica, sobre el lenguaje unificado de modelado..Para su mejor comprensin, he credo conveniente considerar dos captulos:Captulo I. LENGUAJE UNIFICADO DE MODELADOCaptulo II. FASES DEL DESARROLLO DE UN SISTEMAPor lo tanto; espero, contribuir con la finalidad de fortalecer el aspecto intelectual de los estudiantes.

Las Autoras.

INDICEDEDICATORIAINTROCUCCINRESUMENCAPTULO ILENGUAJE UNIFICADO DE MODELADO

0. Concepto 04 0. Historia 040. Qu es un UML? 05 0. Caractersticas de un UML 062 . Modelamiento de clases 082.1. Beneficios de un UML 13

CAPTULO II

FASES DEL DESARROLLO DE UN SISTEMA

2.1. Funciones de un UML 18

CONCLUSIONESSUGERENCIASREFERENCIA BIBLIOGRFICAANEXOS

CAPTULO ILENGUAJE UNIFICADO DE MODELADO1.1. ConceptoUML es ante todo un lenguaje. Un lenguaje proporciona un vocabulario y una regla para permitir una comunicacin. En este caso, este lenguaje se centra en la representacin grfica de un sistema.Este lenguaje nos indica cmo crear y leer los modelos, pero no dice cmo crearlos. Esto ltimo es el objetivo de las metodologas de desarrollo.1.2 Historia Se necesitaba por tanto un lenguaje no slo para comunicar las ideas a otros desarrolladores sino tambin para servir de apoyo en los procesos de anlisis de un problema. Con este objetivo se cro el Lenguaje Unificado de Modelado (UML). Se ha convertido en ese estndar tan ansiado para representar y modelar la informacin con la que se trabaja en las fases de anlisis y, especialmente, de diseo. El lenguaje UML comenz a gestarse en octubre de 1994 cuando Rumbaugh se uni a la compaa Rational fundada por Booch (dos reputados investiga-dores en el rea de metodologa del software). El objetivo de ambos era unificar dos mtodos que haban desarrollado: el mtodo Booch y el OMT (Object Modelling Tool). El primer borrador apareci en octubre de 1995. En esa misma poca otro reputado investigador, Jacobson, se uni a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los tres amigos. Adems, este lenguaje se abri a la colaboracin de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definicin de la primera versin de UML. 0. Qu es un UML?La UML se da tras la exigencia de la gran mayora de instituciones dentro de su Plan Informtico estratgico, es que los desarrollos de software bajo una arquitectura en Capas, se formalicen con un lenguaje estndar y unificado.Es decir, se requiere que cada una de las partes que comprende el desarrollo de todo software de diseo orientado a objetos, se visualice, especifique y documente con lenguaje comn. Se necesitaba un lenguaje que fuese grfico, a fin de especificar y documentar un sistema de software, de un modo estndar incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema.Este lenguaje unificado que cumple con estos requerimientos, es ciertamente UML, el cual cuenta con una notacin estndar y semnticas esenciales, para el modelado de un sistema orientado a objetos.As mismo, aquellos que deseen enmarcar conceptualmente desde su gnesis UML, recomiendo comprender los Fundamentos de los Lenguajes Estructurados.El UML unido a un gestin de calidad, evita malos entendidos y entrega ciertas precauciones en la evolucin y mantencin de programas. Especialmente en lo referente a los requerimientos asociados al levantamiento y diseo funcional de un sistema. En efecto, por ejemplo con los Clientes Dilema, quienes no podrn hacer pensar que el cambio que estn solicitando es pequeo, cuando detrs de la peticin existe una enorme cantidad de tareas relacionadas al requerimiento

1.4 .Caractersticas de un UML El UML, fusiona los conceptos de la orientacin a objetos aportados por Booch, OMT y OOSE (Booch, G. et al., 1999). UML incrementa la capacidad de lo que se puede hacer con otros mtodos de anlisis y diseo orientados a objetos. Los autores de UML apuntaron tambin al modelado de sistemas distribuidos y concurrentes para asegurar que el lenguaje maneje adecuadamente estos dominios. El lenguaje de modelado es la notacin (principalmente grfica) que usan los mtodos para expresar un diseo. El proceso indica los pasos que se deben seguir para llegar a un diseo.1.5 .Semntica y notacinUna de las metas principales de UML es avanzar en el estado de la integracin institucional proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr un intercambio exitoso de modelos de informacin entre herramientas, se requiri definir a UML una semntica y una notacin. La notacin es la parte grfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado. Por ejemplo, la notacin del diagrama de clases define como se representan los elementos y conceptos como son: una clase, una asociacin y una multiplicidad. Y qu significa exactamente una asociacin o multiplicidad en una clase?. Un meta modelo es la manera de definir esto (un diagrama, usualmente de clases, que define la notacin). Para que un proveedor diga que cumple con UML debe cubrir con la semntica y con la notacin.Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo modelo. Bajo esta definicin una herramienta que solo dibuje, no puede cumplir con la notacin de UML.El lenguaje est dotado de mltiples herramientas para lograr la especificacin determinante del modelo, pero en nuestro caso se trabaja en forma simplificada sobre: Modelamiento de Clases Casos de Uso Diagrama de Interaccin

Los diagramas de clases de UML forman la vista lgica. Los diagramas de interaccin de UML constituyen la vista de proceso. La vista de desarrollo captura el software en su entorno de desarrollo. Los diagramas de despliegue integran la vista fsica.

2. MODELAMIENTO DE CLASES:Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.Un diagrama de clases est compuesto por los siguientes elementos: Clase: atributos, mtodos y visibilidad. Relaciones: Herencia, Composicin, Agregacin, Asociacin y UsoElementos Clase:Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto es una instancia de una clase). A travs de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). En UML, una clase es representada por un rectngulo que posee tres divisiones:

En donde: Superior: Contiene el nombre de la Clase Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public). Inferior: Contiene los mtodos u operaciones, los cuales son la forma como interacta el objeto con su entorno (dependiendo de la visibilidad: private, protected o public). Ejemplo: Una Cuenta Corriente que posee como caracterstica: Balance Puede realizar las operaciones de: Depositar Girar y Balance El diseo asociado es:

Atributos y Mtodos: Atributos: Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que definen el grado de comunicacin y visibilidad de ellos con el entorno, estos son: public: Indica que el atributo ser visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados. private: Indica que el atributo slo ser accesible desde dentro de la clase (slo sus mtodos lo pueden accesar). protected: Indica que el atributo no ser accesible desde fuera de la clase, pero si podr ser accesado por mtodos de la clase adems de las subclases que se deriven (ver herencia). Mtodos: Los mtodos u operaciones de una clase son la forma en como sta interacta con su entorno, stos pueden tener las caractersticas: public: Indica que el mtodo ser visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. private: Indica que el mtodo slo ser accesible desde dentro de la clase (slo otros mtodos de la clase lo pueden accesar). protected: Indica que el mtodo no ser accesible desde fuera de la clase, pero si podr ser accesado por mtodos de la clase adems de mtodos de las subclases que se deriven (ver herencia).

Asociacin: La relacin entre clases conocida como Asociacin, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relacin fuerte, es decir, el tiempo de vida de un objeto no depende del otro. Ejemplo: Un cliente puede tener asociadas muchas rdenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente. 2.2. Casos de Uso (Use Case) El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, adems de la forma, tipo y orden en como los elementos interactan (operaciones o casos de uso). Un diagrama de casos de uso consta de los siguientes elementos: Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicacin. Elementos Actor:

Un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino ms bien la labor que realiza frente al sistema.

Caso de Uso:

Es una operacin/tarea especfica que se realiza tras una orden de algn agente externo, sea desde una peticin de un actor o bien desde la invocacin desde otro caso de uso. Relaciones: Asociacin Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a otra operacin (caso de uso). Dicha relacin se denota con una flecha simple. Dependencia o Instanciacin Es una forma muy particular de relacin entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relacin se denota con una flecha punteada. Generalizacin Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de su estereotipo, que puede ser de Uso () o de Herencia (). Este tipo de relacin esta orientado exclusivamente para casos de uso (y no para actores). extends: Se recomienda utilizar cuando un caso de uso es similar a otro (caractersticas). Otro aspecto es la impresin de comprobantes, que puede ser realizada despus de depositar algn item por un cliente o bien puede ser realizada a peticin de un operador. 2.3. 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. 2.4. 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. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo los smbolos utilizados en los modelos y un conjunto de mecanismos generales o reglas que indican cmo utilizar los elementos. Las reglas son sintcticas, semnticas y pragmticas

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.

CAPTULO IIFASES DEL DESARROLLO DE UN SISTEMALas fases del desarrollo de sistemas que soporta UML son: Anlisis de requerimientos, Anlisis, Diseo, Programacin y Pruebas. Anlisis de RequerimientosUML 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.

AnlisisLa fase de anlisis abarca las abstracciones primarias (clases y objetos) y mecanismos que estn presentes en el dominio del problema. Las clases quese 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. DiseoEn 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. ProgramacinEn 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. PruebasNormalmente, 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.

2.1. FUCIONES DEL UML.

Visualizar: UML permite expresar de una for-ma grfica un sistema de forma que otro lo puede entender. Especificar: UML permite especificar cules son las caractersticas de un sistema antes de su construccin. Construir: A partir de los modelos especifica-dos se pueden construir los sistemas diseados. Documentar: Los propios elementos grficos sirven como documentacin del sistema des-arrollado que pueden servir para su futura re-visin.

CONCLUSIONES

Despus del proceso de investigacin hemos llegado a las siguientes conclusiones:

Es muy importante conocer el lenguaje unificado de modelado para diferenciar sus caractersticas y sus funciones y utilizarlos correctamente. Te ayuda a diferenciar los componentes de un UML para fortalecimiento y la proyeccin al mdulo.

SUGERENCIAS

Teniendo en cuenta los resultados de esta investigacin se realizan las siguientes recomendaciones para los diferentes grupos de inters relacionados:

Todo estudiante debe reconocer las caractersticas y funciones con la finalidad del buen uso y cuidado.

El sector acadmico debe desarrollar programas de capacitacin y asesora que les permita a los estudiantes prepararse con conocimientos de acuerdo al avance tecnolgico.

El sector gubernamental debe continuar con la generacin de polticas sociales y econmicas que beneficien a los estudiantes adquirir una mquina.

A la Gerencia del Instituto; generar cursos de extensin de Ofimtica para que los estudiantes puedan cumplir correctamente los trabajos monogrficos que encomiendan los maestros.

BIBLIOGRAFA

1. EDP Auditors Foundation, Inc. (1990):Control Objetives. Steamwood.

2. BOE 12 Julio (1988): Ley 19/1988 de Auditora de Cuentas. Madrid.

3. MENDEZ, Oscar Auditoria Informtica

4. QUINM, Eduardo Horacio Auditoria Informtica Dentro de las Etapas de Anlisis del Sistema Administrativo

5. WILLIAN, E P. (1980): Selecting EDP Audit Areas. Audit Guide Series, ADP Auditora Fundacin, Inc Illinois. EE.UU.

6. Pgina Web.

ANEXO

21