UNIVERSIDAD MAYOR DE SAN ANDRS FACULTAD DE CIENCIAS ECONMICAS Y FINANCIERAS CARRERA DE CONTADURA PBLICA

LENGUAJE UNIFICADO DE MODELADO

APRENDIENDO CON GILMAR

Elaborado por:
GUTIERREZ YUJRA GILMAR

Fecha de entrega: 24/04/2013

La Paz Bolivia

2 LENGUAJE UNIFICADO DE MODELADO CONTENIDO LENGUAJE UNIFICADO DE MODELADO .......................................... 3 UML ................................................................................................................ 3 DIAGRAMAS ESTATICOS........................................................................... 5 1.1 Diagramas de clases .............................................................................. 7 Diagramas de componentes ............................................................................. 9 1.2 Diagramas de despliegue ...................................................................... 9

APRENDIENDO CON GILMAR |

3 LENGUAJE UNIFICADO DE MODELADO

LENGUAJE UNIFICADO DE MODELADO

UML
El Lenguaje Unificado de Modelado (Unified Modeling Languaje, UML) es el lenguaje estndar para realizar el modelado de los sistemas de software y es independiente del lenguaje de programacin utilizado.

En este artculo no vamos a entrar en ms detalles de lo que es UML y de su historia, nos vamos a centrar en las partes ms significativas del lenguaje.

UML tiene tres elementos fundamentales: Bloques bsicos de construccin o o o Elementos Relaciones Diagramas

Reglas que dictan como se pueden combinar estos bloques bsicos. UML tiene reglas para: o o o o o Nombres Alcance Visibilidad Integridad Ejecucin

Mecanismos comunes. Que se basen en algn patrn, al igual que en arquitectura se puede hablar del barroco, romnico, etc.. o o o o Especificaciones Adornos Divisiones comunes Mecanismos de extensibilidad

APRENDIENDO CON GILMAR |

Como dijo Grady Booch: El 80 por ciento de la mayora de los problemas pueden modelarse usando alrededor del 20 por ciento de UML.

En todo proceso de software donde se utilice una metodologa orientada a objetos y la notacin UML no pueden faltar los diagramas, para representar las diferentes vistas del producto final.

Los diagramas de UML se pueden dividir en estticos (aportan una visin esttica del sistema) y dinmicos (aportan una visin dinnica del sistema).

Los diagramas estticos: Diagrama de casos de uso Diagrama de clases Diagrama de objetos Diagrama de componentes Diagrama de despliegue

Los diagramas dinmicos: Diagrama de estados Diagrama de actividad Diagramas de interaccin: Diagrama de secuencia Diagrama de colaboracin

Como se puede ver hay demasiados diagramas y en muchos proyectos no son necesarios todos los diagramas. Ser la prctica y experiencia y el tipo de sistema a desarrollar lo que nos ayudar a escoger los diagramas a utilizar, por ejemplo podemos decir que para aplicaciones cliente se suelen utilizar los diagramas de casos de uso, de clase y de colaboracin o de secuencia, para aplicaciones donde sean importantes los eventos se puede utilizar el diagrama de estados, para aplicaciones cliente-servidor aparte de los diagramas de casos de uso, clases y objetos tambin puede ser conveniente utilizar los diagramas de despliegue y componentes, y para aplicaciones complejas cliente-servidor pues si ser recomendable utilizar todos los diagramas ya que dar una visin ms amplia de cmo ser el sistema final.

DIAGRAMAS ESTATICOS
Diagramas de casos de uso. Los diagramas de casos de uso muestran la funcionalidad del sistema desde la perspectiva que tienen los usuarios y lo que el sistema debe de hacer para satisfacer los requisitos propuestos. Pueden mostrar el comportamiento de un sistema completo o de una parte.

Los elementos bsicos que se utilizan son: 1. Actores: Son los diferentes usuarios y el papel que representan dentro del sistema.

2. Caso de uso: Representan todo lo que el usuario puede realizar dentro del sistema

3. Relaciones: Para asociar los elementos anteriores.

Comunicacin

Generalizacin

Extensin (*)

Inclusin (*)

(*) En estas dos se deben de poner tambin las letras (include, o exclude).

Ejemplo:

1.1 Diagramas de clases

Los diagramas de clases son estticos porque no describen un comportamiento en funcin del tiempo. Tienen que ver con la implementacin de la aplicacin.

Los elementos son: 1. Clases: Se pueden definir como la descripcin de un conjunto de objetos con las mismas propiedades. Puede ser un concepto del mundo real, se puede decir que es una plantilla para crear objetos. 2. Relaciones: Las relaciones pueden ser de distintos tipos asociacin, agregacin, herencia (generalizacin, especializacin).

Ejemplo:

Diagramas de Objetos

Los diagramas de objetos pueden ayudar a explicar las clases y su herencia. A veces se dibujan durante el proceso de planificacin de clases o para ayudar a partes interesadas para quienes los diagramas de clases sean demasiado abstractos. Un objeto tambin se pueden entender como la descripcin de un individuo que forme parte de un grupo, mientras que las clases describen las caractersticas compartidas por el grupo. As pues "CuentaCorriente" puede definirse como una clase UML en UModel 2013 y "Cuenta corriente de John en Agency Bank" se ilustrara como un diagrama de objetos.

Diagramas de componentes
Los diagramas de componentes ilustran la estructura fsica del cdigo, al asignar la vista lgico de las clases del proyecto al cdigo propiamente dicho donde se implementa la lgica. Al generar cdigo, los diagramas de componentes representan la ubicacin de los archivos de cdigo fuente Java o C# para sus clases. Al realizar ingeniera inversa en un proyecto ya existente, los diagramas de componentes pueden ayudarle a establecer relaciones entre cada diagrama de clases de UModel 2013 y los archivos de cdigo fuente.

1.2 Diagramas de despliegue

En el diagrama de despliegue se indica la situacin fsica de los componentes lgicos desarrollados. Es decir se sita el software en el hardware que lo contiene. Cada Hardware se representa como un nodo.

Un nodo se representa como un cubo, un nodo es un elemento donde se ejecutan los componentes, representan el despliegue fsico de estos componentes. Aqu tenemos dos nodos, el cliente y el servidor, cada uno de ellos contiene componentes. El componente del cliente utiliza un interface de uno de los componentes del servidor. Se muestra la relacin existente entre los dos Nodos. Esta relacin podramos asociarle un estereotipo para indicar que tipo de conexin disponemos entre el cliente y el servidor, as como modificar su cardinalidad, para indicar que soportamos diversos clientes.

Como los componentes pueden residir en mas de un nodo podemos situar el componente de forma independiente, sin que pertenezca a ningn nodo, y relacionarlo con los nodos en los que se sita.