LENGUAJE UNIFICADO DE MODELADO

CAPITULO I

INTRODUCCION

Un modelado es una representación, en cierto medio, de algo en el mismo u otro medio. el modelado capta los aspectos importantes de lo que estamos modelando, desde criterio o punto de vista y simplifica u omite el resto. La arquitectura, la ingeniería y otros campos utilizan este tipo de modelado.

LA IMPORTANCIA DE MODELAR

Los modelos se utilizan para muchos propósitos:

• Para captar y enumerar exhaustivamente los requisitos, y el dominio del conocimiento, de forma que todos los implicado puedan entenderlos y estar deacuerdo con ellos.


• Para pensar en el diseño del sistema un arquitecto utiliza diseños en el papel, sobre el computador, para visualizar y experimentar como posible diseño.


• Para capturar desiciones del diseño mutables apartir de los requisitos que nesecitemos .


• Para generar productos aprovechables para el trabajo.


• Para organizar, encontrar, filtrar, recuperar, examinar, y corregir la información en grandes sistemas.


• Para explotar económicamente múltiples soluciones.


• Para domesticar los sistemas complejos.

NIVELES DE MODELADO

Los modelados adquieren diferentes formas para diferentes propósitos, y aparecen en diferentes formas de abstracción. La cantidad de detalle del modelado debe adaptarse a uno de los siguientes propósitos:

• Guías al proceso de pensamiento: Los modelos de alto nivel construidos al principio de un proyecto, sirven para enfocar el proceso de pensamiento de los participantes y destacar determinadas opciones.


• Especificaciones abstractas de la estructura esencial de un sistema: Estos modelados esenciales deben corresponderse con los modelos completos y se centran en la semántica lógica y es generada en código y desarrollado por u programador.


• Especificaciones completas de un sistema final: Un modelo de implementación incluye suficiente información para construir el sistema, esta clase de modelado debe incluir la debe las construcciones para empaque modelado, para la compensación de la persona, y para la conveniencia de la computadora.


• Descripciones completas o parciales de sistemas: Un modelo puede ser una descripción completa de un solo sistema, sin referencias externas. Tales modelos tiene conexión que se deben enlazar a otros modelos en un sistema completo.

¿ QUE HAY EN UN MODELO?

Semántica y presentacion

los modelos tienen dos aspectos importantes:

Información semántica (semántica) y presentación visual (notación)

El aspecto semántico capta el significado de una aplicación como una red de construcciones lógicas, por ejemplo clases, asociaciones, estados, caso de uso, y mensajes. Los elementos semánticos del modelo se utiliza para generación de código, la comprobación de la validez las métricas de complejidad, etc.

La presentación visual muestra la información semántica de modo que se pueda ser considerada, hojeada y corregida por los seres humanos. Los elemento de la presentación llevan las presentación visual del modelo este es, lo muestra en una forma directamente comprensible por las personas, la información de un sistema incluye la información sobre todas las partes del entorno.

¿CUAL ES EL SIGNIFICADO DE UN MODELO?

Un modelo es un generador de potenciales configuraciones de sistemas, los posibles sistemas con sus extensiones, o valores.

• Abstraccion frente a detalle: Un modelo captura los aspectos esenciales de un sistema y omite otros. Cual son esenciales es una cuestión de juicio que depende del propósito del modelo, un lenguaje de modelado pude ser menos exacto a propósito, por el detalle adicional e irrelevante para el propósito actual.


• Especificación frente a implementación: un modelo puede decir que hace algo (especificación), y también como se logra la función (implementación), estos aspectos deben ser separados en un modelado.


• Descripción frente a instancia: los modelos son sobre todo descripción, las cosas que describen son las instancias, que generalmente aparece en los modelos solo como ejemplos, la mayoría de las instancias existen solamente como parte de la ejecución.


• Variación en la interpretación: hay muchas interpretaciones posibles de modelado en lenguaje de modelado. Uno puede definir ciertos puntos de variación semántica, lugares en los cuales son posibles diversas interpretaciones y asignar a cada interpretación un nombre como variación semántica, de modo que uno pueda indicar que variación esta utilizando.

PRINCIPIOS DEL MODELADO

El principio del modelado tiene una historia interesante en todas las diciplinas de ingenieria, de esa experiencia surge cuatro principos basicos.

• Primero: La eleccion de que modelo crear tiene una profunda influencia sobre como se acomete un problema y como se da forma a un solucion.


• Segundo: Todos los modelos pueden ser expresados a diferentes modelos de precision


• Tercero: Los mejores modelos estan basados en la realidad.


• Cuarto: Un unico modelo no es suficiente, cualquier sistema no trivial se aborda mejor a travez de un pequeño conjunto de modelos casi independientes.

MODELADO ORIENTADO A OBJETOS

La vision actual del desarrollo de software toma una perspectiva algoritmica, en este enfoque el bloque principal de construccion de todos los sistemas software es el objeto o clase. Para explicarlo sencillamente, un objeto es una cosa generalmente extraida del vocabulario del espacio del problema o del espacio de la solucion; una clase es un descripcion de un conjunto de objetos similares.

PRESPECTIVA GENERAL DEL UML

VISION GENERAL DE UML

UML es un lenguaje para:

• Visualizar


• Especificar


• Construir


• Documentar

Bloques de construccion UML

• Elementos


• Relaciones


• Diagramas

Elementos del UML

• Elementos estructurales


• Elementos de comportamiento


• Elementos de notacion


• Elementos agupacion

DIAGRAMAS UML

• Diagrama de clases


• Diagrama de objetos


• Diagrama de casos de uso


• Diagrama secuencia


• Diagrama colaboracion


• Diagrama estados (Statechart)


• Diagrama actividades


• Diagrama componentes


• Diagrama despliegue

CICLO DE VIDA DEL DESARROLLO DEL SOFTWARE

• Dirigido por los casos de uso


• Centrado en la arquitectura


• Iterativo e incrementa

BREVE RESUMEN DE UML

UML es ante todo un lenguaje. Un lenguaje pro-porciona un vocabulario y una reglas para permitir una comunicación. En este caso, este lenguaje se centra en la representación gráfica de un sistema.
Este lenguaje nos indica cómo crear y leer los modelos, pero no dice cómo crearlos. Esto último es el objetivo de las metodologías de desarrollo.
Las objetivos de UML son muchos, pero se pueden sintetizar sus funciones:

• Visualizar: UML permite expresar de una forma gráfica un sistema de forma que otro lo puede entender.


• Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción.


• Construir: A partir de los modelos especificados se pueden construir los sistemas diseñados.


• Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado que pueden servir para su futura revisión.

HISTORIA DE UML

El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados investigadores en el área de metodología del software). El objetivo de ambos era unificar dos métodos que habían desarrollado: el método 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". Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML.

Se necesitaba por tanto un lenguaje no sólo para comunicar las ideas a otros desarrolladores sino también para servir de apoyo en los procesos de análisis de un problema. Con este objetivo se creo el Lenguaje Unificado de Modelado (UML: Unified Modeling Language). UML se ha convertido en ese estándar tan ansiado para representar y modelar la información con la que se trabaja en las fases de análisis y, especialmente, de diseño.

¿POR QUE ES UNIFICADO?

• Combina conceptos comúnmente aceptados por distintos métodos O.O., determinando definición, notación y terminología.


• Es representativo.


• Involucra todo el ciclo de vida de desarrollo.


• Amplio dominio de aplicación.


• Pensado para varios lenguajes y plataformas.


• Es un lenguaje de modelado, no la descripción de un proceso.

OBJETIVOS DE UML

• De propósito general que puede ser usado por todos los modeladores.


• No tiene propietario y está basado en el común acuerdo de la comunidad informática.


• Reemplaza a los modelos de OMT, Booch y Objectory; tomando los mejores aportes de éstos.

AREAS CONCEPTUALES DE UML

• Estructura estatica


• Comportamiento dinamico


• Construccion de implementacion


• Organizacion del modelo


• Mecanismo de extencion

CAPITULO II

CONCEPTOS DE UML

CLASES Y OBJETOS

Una clase es una descripcion de un conjunto de objetos que comparten los mismos atributos operaciones metodos, relaciones y comportamiento. En UML una clase es un tipo de clasificador, los clasificadores son elemnetos similares a las clases, pero su exprecion mas clara es la clase.

Una clase consta de un nombre, una lista de atributos y una lista de operaciones.

DIAGRAMAS

Un diagrama es una representacion grafica de un conjunto de elementos, que la mayoria de veces se dibuja con un grafo conexo de nodos (elementos) y arcos (relaciones).

DIAGRAMAS ESTRUCTURALES

Normalmente las partes estaticas de un sistema se representan mediante uno de los cuatro diagramas siguientes:

• Diagrama de clases


• Diagrama de objetos


• Diagrama de componentes


• Diagrama despliegue
  

DIAGRAMAS DE COMPORTAMIENTO

A menudo se emplearan cinco diagramas adicionales para ver las partes dnamicas de un sistema.

• Diagrama de casos de uso


• Diagrama secuencia


• Diagrama colaboracion


• Diagrama estados (Statechart)


• Diagrama actividades

VISTAS DE UML

Una vista es simplemente un subconjunto de UML que modela construcciones que representan aspecto de un sistema.

La divicion en diversas vistas en algo arbitrario pero esperamos que sea intuitiva, una o dos diagramas proporcionan una notacion visual para los conceptos de cada vista. Las vistas se pueden dividir en tres areas: clasificacion estructural, comportamiento dinamico y gestion del modelo.

VISTA ESTATICA

La vista estatica modela los componentes del dominio de la aplicacion, asi como los componentes internos inventados como parte de la implementacion. Es estatica por que no describe el comportamiento del sistema dependiente del tiempo que se describe en otras vistas, los componentes principales de la vista estatica son sus clases y relaciones.

VISTA DE LOS CASOS DE USO

Esta vista moldela la funcionalidad del sistema segun actuen los usuarios externos llamados actores.

Un caso de uso es una unidad coherente de funcionalidad expresada con transaccion entre los actores y el sistema.

VISTA DE INTERACCION

La vista de interaccion describe secuencias de intercambi de mensajes entre los roles que implementan el comportamiento de un sistema. Un rol de clasificador, o simplemente "rol", es la descripcion de un objeto, que desarrolla un determinado papel dentro de una interaccion, distinto de los otros objetos de la misma clase.

VISTA DE MAQUINA DE ESTADOS

Una maquina de estados modela las posibles historias de vida de un objetos de una clase. Una maquina de estados contiene los estados conectados por transiciones, cada estado modela un periodo de tiempo, durante la vida de un objeto, en el que satisface ciertas condiciones.

VISTA DE ACTVIDADES

Un grafo de actividades es una variante de una maquina de estados, que muestra las actividades implicadas en la ejecucion de un calculo. Un estado de actividades representa una actividad un paso en el flujo de trabajo o en la ejecucion de un operacion.

VISTA DE IMPLEMENTACION

Las vistas anteriores modelan los conceptos de la aplicacion desde un punto de vista logico, esta vista es una vista fisica. Esta vista proporciona una oportunidad de establecer correspondencias entre las clases y los componentes de implementacion y nodos.

VISTA DE GESTION O MODELO

La vista de gestion del modelo modela la organizacion del modelo en si mismo, un modelo abarca un conjunto de paquetes que continen los elementos del modelo, tales como clases, maquinas de estados, y casos de uso, los paquetes puden contener otros paquetes, por lo tanto, un modelo señala una raiz que contiene indirectamente todo el contenido del modelo.

RELACIONES

En el modelo orientado a objetos hay tres tipos de relaciones especialmente importantes: dependencias, que representan relaciones de uso entre clases, generalizaciones, que conectan que conectan clases generales con especializaciones, y asociaciones, que representan relaciones estructurales entre objetos.

DEPENDENCIA

Una dependencia es una relacion de uso que declara que un cambio en la especificacion de un elemento puede afectar a otro elemento que la utiliza, pero no nesesario a la inversa.

GENERALIZACION

Una generalizacion es una relacion entre un elemento general (superclase o padre), y un caso mas especifico y un caso mas especifico de elemento (subclase hijo). Las generalizaciones se llaman aveces relacion , la generalizacion significa que los objeivos hijos se puedan emplear en cualquier lugar donde pueda aparecer el padre, pero no a la inversa.

ASOCIACION

Una asociacion es una relacion estructural que especifica que los elementos de los objetos estan conectados con los objetos de otro. Dada una asociacion entre dos clases, se puede navegar desde un objeto de una clase hasta un objeto de otra clase, y viseversa.

CAPITULO III

CASOS DE USO

INTRODUCCION

Este articulo describe cómo modelar la funcionalidad del sistema utilizando casos de uso.
En el UML, los casos de uso son los principales medios para capturar la funcionalidad del
sistema desde la perspectiva del usuario y muchas veces puede remplazar al documento
"requisitos funcionales".

TERMINOS Y CONCEPTOS

NOMBRES: Cada caso de uso debe tener un nombre que lo distinga de otros casos de uso, un nombre es un cadena de texto.

ACTORES: Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros sistemas computacionales. Un actor usa un Caso de Uso para ejecutar una porción de trabajo de valor para el negocio. El conjunto de casos de uso al que un actor tiene acceso define rol en el sistema y el alcance de su acción.

FLUJO DE EVENTOS: Tenemos a los siguientes flujos:

• Flujo de eventos principales
• Flujo de eventos excepcional

CASO DE USO ESCENARIO: Normalmente primero se escribe el flujo de eventos de un caso de uso mediante texto. Sin embargo conforme se mejora la comprencion de los requisitos del sistema estos flujos se pueden especificar graficamente mediante diagramas de interaccion.

CASO DE USO Y COLABORACIONES: Un caso de uso captura el comportamiento esperado del sistema (subsistema, clase o interfaz) que se esta desarrollando, sin tener que especificar como se implementa este comportamiento.

ORGANIZACIONES DE CASO DE USO

Los casos de uso tambien pueden organizarse especificando relaciones de generalizacion, inclucion y extencion entre ellos. Estas relaciones se utilizan para factorizar el comportamiento comun (extrayendo ese comportamiento de los casos de uso en los que se incluye) y para factorizar variantes (poniendo ese comportamiento en los casos de uso que se extienden).

OTRAS CARACTERISTICAS

Los casos de uso tambien son clasificadores, de forma que pueden tener operaciones y atributos que se pueden representar igual que en las clases. Se puede pensar en estos atributos como en los objetos dentro del caso de uso que son necesarios para describir el comportamiento externo.

PROPIEDADES COMUNES

Un diagrama de casos de uso es un tipo especial de diagrama y comparte las propiedades comunes al resto de los diagramas (un hombre y un contenido grafico que es la proyeccion de un modelo).

Lo que distingue un diagrama de caso uso de los otros tipos de diagramas es su contenido particular.

CONTENIDOS

Normalmente un diagrama de casos de uso contiene:

• Casos de uso
• Actores
• Relacion de dependencia, generalizacion y asociacion

USOS COMUNES

Los diagramas de casos de uso se emplean para modelar la vista de casos de uso estatica de un sistema estos puden ser:

• Para moldelar el contexto de un sistema
• Para moldelar los requisitos de un sistema

OBJETIVOS DEL USUARIO E INTERACCIONES CON EL SISTEMA

Un tema importante en los casos de uso es la diferencia que se llama objetivos del usuario e interacciones con el sistema, no obstante cuando los objetivos del usuario y las interacciones del sistema difieren, es muy importante tener clara la diferencia.

CUANDO EMPLEAR CASO DE USO

La mayoria de los casos de uso se generan durante esa fase del proyecto pero ira descubriendo otros a medida que avance. Este siempre pendiente de ellos. Todo caso de uso es requerimiento potencial y hasta que aya usted capturado un requerimiento, no podra planear como manejarlo en el proyecto.

MODELADO DE CASOS DE USOS

MODELADO DEL COMPORTAMIENTO DE UN ELEMTO

La mayoria de las veces, los casos de uso se utiliza para el modelado del comportamiento de un elemento, ya sea un sistema completo, un subsistema o una clase. Cuando se modela el compotamiento de estos elementos, es importante centrese en lo que hace el elemento, no en como lo hace.

MODELO DE CONTEXTO DE UN SISTEMA

En UML se puede modelar el contexto de un sistema con un diagrama de casos de uso destacando los actores en torno al sistema. La desicion sobre que incluir como un actor es importante por que la hacer eso se especifica un tipo de cosas que interactuan con el sistema.

Las deciciones sobre no incluir es igualmente importante, si no mas, por que restringe el entorno para que todo incluya aquellos actores necesarios en la vida del sistema.

INGENIERIA DIRECTA O INVERSA

La ingenieria directa es el proceso de transformar un modelo en codigo a travez de una correspondencia con un lenguaje de implementacion. A un diagrama de casos de uso se le puede aplicar ingenieria directa para generar pruebas del elemento al que se aplica.

Cada caso de uso de un diagrama especifico un flujo de eventos (y variacion de ese flujo) y esos flujos especifican como se espera que se comporte el elemento (algo que merece la pena probar). Un caso de uso bien estructurado especificara incluso pre y poscondiciones para definir el estado inicial de una prueba y los criterios del exito. Para cada caso de uso de un diagrama. Puede crearse un caso de prueba que pueda ejecutar cada vez que se produce una nueva version del elemento, con el fin de confirmar que funciona como se requeria, antes de que otros elemntos confien en el.

SUGERENCIAS

• Nombra un comportamiento simple identificable y razonablemente atomico del sistema o parte del sistema.
• Factoriza el comportamiento comun, incorporando ese comportamiento desde otros casos de uso que incluye.
• Describe el flujo de eventos de forma suficiente clara para que alguien externo al sistema lo entienda facilmente
• Se describe por un conjunto minimo de escenarios que especifican las semantica normal y de las variantes del caso de uso.

HECHO POR: VICTOR DANIEL ALEXANDER RIVAS PACHECO