LENGUAJE MODELADO UML

CAPITULO I
INTRODUCCION
Es una representación que puede ser en el mismo medio o en otro donde capta los aspectos importantes y es expresado en un modelo de acorde con el trabajo se puede hacer en diferente tipo de materiales como papel, cartón, etc.
El modelo de un sistema está construido en lenguaje de modelado como el UML el cual puede ser semántico y de notación, a la vez puede adoptar varios formatos ya sean gráficos o de texto el cual pretende ser más fácil de usar par ciertos propósitos.

LA IMPORTANCIA DE MODELAR.
Son para muchos propósitos como:
- Para captar y enumerar los requisitos y el dominio del conocimiento de modo que los usuarios puedan entenderlos y estar de acuerdo con ellos.
- Para pensar del diseño de un sistema.
- Para capturar decisiones del diseño de una forma de una forma mutable a partir de los requisitos.
- Para generar productos aprovechables para el trabajo.
- Para organizar, encontrar, filtrar, recuperar, examinar y corregir la información en grandes sistemas.
- Para explorar económicamente posibles soluciones.
- Para domesticar los sistemas complejos.
Todo modelo debe adaptarse a principios: Guías al proceso de pensamiento, Especificaciones abstractas de la estructura esencial del sistema, Especificaciones completas de un sistema final, Ejemplos de sistemas típicos o posibles, Descripciones completas o parciales del sistema.
Un modelo tiene aspectos; la información semántica que capta el significado como una red de construcciones lógicas y la presentación visual que puede ser corregida por los seres humanos donde el significado de un modelo es de potenciales configuraciones de sistemas donde se considera la abstracción frente o el detalle, la especificación frente a implementación, la descripción frente a instancia y las variaciones en la interpretación.
El modelado tiene cuatro principios muy importantes que son:
- La elección de que modelos crear tiene una gran influencia sobre cómo se acomode un problema y como se da forma a una solución.
- Todo modelo puede ser expresado a diferentes modelos de precisión.
- Los mejores modelos están ligados a la realidad.
- Un único modelo no es suficiente, cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes.



MODELO CONCEPTUAL DE UML.
Para comprenderlo necesitamos de un modelo conceptual de lenguaje el cual necesita aprender tres elementos importantes: los bloques lógicos de construcción de UML (elementos, relaciones, diagramas), las reglas que dicen cómo se pueden combinar los bloques y algunos mecanismos comunes que se aplican a través delo UML. Los tipos de elementos de UML son estructurales (son partes estáticas de un modelo), de comportamiento (son verbos de un modelo que representan comportamiento en el tiempo y espacio), de agrupación (son las cajas en las que puede descomponerse un modelo) y de notación (son comentarios que se pueden aplicar para describir, clarificar y hacer observaciones sobre cualquier elemento del modelo).Existen tipos de relaciones como dependencia (es donde el cambio de un elemento puede afectar a los otros elementos), asociación( es la relación estructural de un conjunto de enlaces entre un todo y sus partes), generalización( es una realización de especialización donde los objetos especializados pueden sustituir a los objetos del elemento general) y realización (un clasificador garantiza un contrato que otro clasificador garantiza que cumplirá).
Tiene nueve modelos de diagramas: clases, objetos, casos de uso, secuencia, colaboración, estados, actividades, componentes, despliegue.
El UML es en lenguaje de modelado visual que se usa para especificar, visualizar, construir, documentar artefactos de un sistema de software, modelado unificado pretendiendo unificar la experiencia pasada sobre técnicas de modelado e incorporar las practicas en un acercamiento estándar donde pretende dar apoyo a la mayoría de los procesos de desarrollo orientados a objetos.

CAPITULO II
CONCEPTOS DE UML.

Clases y Objetos
Una clase es un descriptor de un conjunto de objetos que comparten los mismos atributos, operaciones, métodos, relaciones y comportamiento.
Un objeto es el valor de una variable debe tener una clase compatible para el tipo de esta variable, es decir, debe ser de la misma clase.

Diagramas.
Es una presentación grafica de un conjunto de elementos que la mayoría de veces se dibuja como nodos o elementos y arcos o relaciones el cual nos sirve para visualizar un sistema desde diferentes perspectivas, donde cuenta con clases de diagramas como:

Diagramas estructurales:
- Diagramas de clase presenta un conjunto de clases, interfaces colaboraciones entre ellas.
- Diagramas de objetos representa un conjunto de objeto y sus relaciones, se utiliza para describir estructura de datos.
- Diagramas de componentes se utiliza para describir la vista de implementación estática de un sistema.
- Diagramas de despliegue se utiliza para describir la vista de de despliegue estática de una arquitectura.
Diagramas de comportamiento
- Diagramas de caso de uso se utilizan para describir la vista de uso estático de un sistema y sirve para organizar y modelar el comportamiento de un sistema.
- Diagramas de secuencia presenta un conjunto de objetos y mensajes recibidos por ellos y se utilizan para describir la vista dinámica de un sistema.
- Diagramas de colaboración resalta la organización estructural de un objeto que recibe y envía mensajes.
- Diagramas de estado muestra un conjunto de objetos y los enlaces entre los objetos y mensajes recibidos por estos objetos.
- Diagramas de estados son importantes para modelar el comportamiento de una interfaz, una clase y colaboración.
- Diagramas de actividades muestra un conjunto de actividades, el flujo secuencial de las actividades y los objetos que actúan sobre los que se actúan.

VISTAS DE UML.-Es un subconjunto que modela un sistema que representa un aspecto de un sistema, las vistas se pueden dividir en tres áreas: clasificación estructural, comportamiento dinámico y gestión del modelo.

Vista Estática.- Modela los conceptos del dominio de la aplicación así como los conceptos inventados como parte de la implementación, describe del sistema dependiente del tiempo que se describe en otras vistas. Las clases se dibujan como rectángulos, los atributos y operaciones se muestran por separado y las relaciones se muestran como líneas y se conectan a los rectángulos.

VISTAS DE CASOS DE USO.- Modela la funcionalidad del sistema según actúen los usuarios externos llamados actores, es una unidad coherente expresada como transacción expresada entre los actores y el sistema.

VISTA DE INTERACCION.- Describe secuencias de intercambio de mensajes entre los roles que implementan el comportamiento del sistema el cual es el que desempeña un papel dentro de una interacción de los objetos iguales.

VISTA DE LA MAQUINA DE ESTADOS.- Esta formado por un conjunto de estados y cada uno de ellos modela un periodo de tiempo durante la vida de un objeto que satisface algunas condiciones.

VISTA DE ACTIVIDADES.- Es una variante de una maquina de estados que muestra las actividades de una ejecución de un cálculo, nos sirve para entender el alto nivel de la ejecución de un sistema.

VISTA DE IMPLEMENTACION.- Se puede establecer correspondencias entre las clases y los componentes de implementación y nodos.

VISTA DE GESTION DEL MODELO.- Organiza el modelo en sí mismo, este contiene el conjunto de paquetes que contiene el modelo, clases, maquinas de estado y casos de uso; un modelo es una descripción completa de un sistema con una determinada precisión.

RELACIONES.
El modelado tiene tres tipos de relaciones:
- Dependencia.- Es una relación de uso que declara que un cambio en la especificación de un elemento puede afectar a otro que lo utilice.
- Generalización.- Es una relación entre un elemento general y un caso más específico de ese elemento, los objetos hijo se pueden emplear en cualquier lugar donde pueda aparecer el padre pero no a la inversa.
- Asociación.- Es una relación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro elemento.

CAPITULO III
CASO DE USOS.

Introducción
Durante mucho tiempo las personas se auxiliaban de escenarios que les ayudaba a comprender los requerimientos y donde Jacobson elevo la visibilidad del caso de uso convirtiendo en un elemento primario de la planificación y el desarrollo de proyectos.

Términos y Conceptos.
Un caso de uso es un conjunto de secuencia de acciones que ejecuta un sistema para producir resultado de valor para el actor, cada caso de uso tiene un único nombre que es una cadena de texto que los distingue de los demás , puede utilizar el nombre letra mayúscula, minúsculas, números, signos.

Casos de Uso y Actores.
Un actor es un conjunto coherente de roles que los usuarios de los casos de uso realizan cuando interactúan con ellos, un actor representa un rol que es realizado por una persona, dispositivo de hardware y un sistema que interactúa con otro.
Los mecanismos de extensibilidad de UML pueden utilizar un actor como estereotipo para proporcionar un icono que ofrezca una señal apropiada que indique los objetivos que se pretende lograr.

Casos de Uso y Flujos de eventos.
Describe que es lo que hace un sistema pero no específica como lo hace donde es importante tener clara la separación de objetivos entre las vistas internas y externas; este tipo de clase de uso especifica claramente que hace el sistema en la que una persona ajena lo puede entender perfectamente.

Casos de Uso y Escenarios.
Describe un conjunto de secuencia donde cada una describe un flujo posible a través de las variantes, el escenario es una secuencia específica de acciones que ilustra un comportamiento o una instancia del caso de uso.

Casos de Uso y Colaboraciones.
Este captura el comportamiento esperado del sistema sin especificar como se complementa ese comportamiento, esta separación es importante porque el sistema no debe de estar influenciado por cuestiones de implementación.

Organización de Casos de Uso.
Se agrupan en paquetes organizados por la realización de generalización (hereda el comportamiento del caso de usos padre), inclusión (incorpora el comportamiento de otro caso de uso en el lugar adecuado en el caso base)y extensión ( para modelar la parte de un caso de uso que el usuario puede ver como el comportamiento opcional de un sistema) entre ellos que nos sirve para factorizar el comportamiento común y factorizar las variantes.
Otra característica puedes ser los objetos dentro del caso se uso que son necesarios para describir el comportamiento externo.
Un diagrama de casos de uso contienen: casos de uso, actores, relación de dependencia y también pueden tener notas y restricciones.

Usos Comunes.
Se puede usar en dos formas:
- Para modelar el contexto de un sistema; es dibujar una línea alrededor de todo el sistema, ver que actores quedan fuera del sistema y dentro de el.
- Para modelar los requisitos de un sistema, especificar que debería de hacer el sistema muy aparte de cómo lo hace, se especifica el comportamiento deseado del sistema.

Objetivos de Usuarios e Interacciones con el Sistema.
El verdadero objetivo de un usuario es describir los términos como garantizar el formateo de un documento y hacer que el formato de un documento sea igual al otro.
Entre el objetivo del usuario e interacción con el sistema no se presentan en todas las situaciones.
Usos Comunes.
Se puede usar en dos formas:
- Para modelar el contexto de un sistema; es dibujar una línea alrededor de todo el sistema, ver que actores quedan fuera del sistema y dentro de el.
- Para modelar los requisitos de un sistema, especificar que debería de hacer el sistema muy aparte de cómo lo hace, se especifica el comportamiento deseado del sistema.

Objetivos de Usuarios e Interacciones con el Sistema.
El verdadero objetivo de un usuario es describir los términos como garantizar el formateo de un documento y hacer que el formato de un documento sea igual al otro.
Entre el objetivo del usuario e interacción con el sistema no se presentan en todas las situaciones.

Cuando Emplear Caso de Usos.
Son una herramienta esencial para captura requerimientos, planificación y control de proyectos iterativos que se hace durante la fase de elaboración; otros prefieren listar y analizar los casos de uso primero y luego llevar a cabo un poco de modelado, donde es aconsejable usar las dos maneras según sea necesario.
Modelado de Casos de Uso.
La mayoría de veces se utiliza para el modelado del comportamiento de un elemento de un sistema completo, subsistema o una clase pero es recomendable aplicar en tres razones:
- El modelado de comportamiento de un elemento para especificar su vista externa del sistema.
- Proporciona una forma de abordar y comprender elemento.
- De base para probar cada elemento según como evoluciona durante el desarrollo.
Para modelar el comportamiento de un elemento:
- Identificar los actores que interactúan con el elemento.
- Organizar a los actores por sus roles como por su especialidad.
- Considerar las formas mas importantes que tiene el actor de interactuar con el elemento.
- Considera las formas en la que el actor puede interactuar con el elemento.
- Organizar los comportamientos como casos de uso utilizando relaciones de inclusión y extensión para factorizar el comportamiento común y reconocer el comportamiento excepcional.

Modelado Del Contexto de un Sistema.
Debemos tener presente:
- Identificar los actores entorno al sistema viendo que grupos requieren ayuda para llevar a cabo sus tareas.
- Organizar a los actores por jerarquías de generalización y especialidad,
- Proporcionar un estereotipo para cada uno de los actores para ayudar a entender el sistema.
- Introducir a los actores en un diagrama de casos de uso y especificar las vías de comunicación de cada actor con los casos de uso del sistema.


Modelado de los Requisitos de un Sistema.
Para modelar tenemos:
- Establecer el contexto del sistema identificando los actores a su alrededor.
- Considerar el comportamiento de cada actor espera del sistema o quiere que este le proporcione.
- Nombrar los comportamientos comunes de los casos de uso.
- Factorizar el comportamiento común de los casos de uso que puedan ser utilizados por otros.
- Modelar esos casos de uso, actores y relaciones en un diagrama de casos de uso.
- Adornar esos casos de uso con notas que anuncien los requisitos no funcionales


Ingeniería Directa e Inversa.
Ingeniería directa es el proceso de transformar un modelo en código a través de una correspondencia con un lenguaje de implementación, nos sirve para hacer pruebas con un elemento que se utiliza, para hacer este tipo de ingeniería con un diagrama de casos de uso se debe:
- Identificar el flujo de evento de cada caso de uso.
- Según su grado de profundización hay que generar una prueba para cada flujo.
- Hay que generar una estructura de prueba par representar cada actor que interactúa en el caso de uso.
- Usar herramientas que ejecuten estas pruebas cada vez que se genere una nueva versión del elemento al que se aplica el diagrama de caso de uso.
Ingeniería inversa es el proceso de transformar código en un modelo a través de una correspondencia a partir de un lenguaje de implementación específica, para hacer uso de un diagrama de casos de uso de una ingeniería inversa se debe:
- Identificar cada actor que interactúa con el sistema.
- Considerar la forma en que cada actor interactúa con el sistema, cambia de estado o responde a algún evento.
- Trazar el flujo de eventos del sistema ejecutable en relación con cada actor.
- Agrupar los flujos relacionados declarando el caso de uso considerando el modelado de variantes con relación de extensión.
- Representar a los actores y casos de uso en un diagrama de casos de uso y establecer sus relaciones.



Sugerencias.
Cuando se modelan los casos de uso se deben representar u n comportamiento distinto del sistema o de una parte del mismo, como:
- Nombrar un comportamiento simple, identificable y razonablemente atomice del sistema o parte del sistema.
- Factorizar el comportamiento común incorporando el de otros casos de uso.
- Factorizar las variables colocando el comportamiento en otros casos de uso que lo extiendan.
- Describe el flujo de eventos de manera clara para que alguien externo del sistema lo entienda.
- Describe un conjunto mínimo de escenario que especifican la semántica normal y variantes dl casos e uso.
Un Diagrama de Casos de Uso Bien Estructurado.
Es el que:
- Se ocupa de modelar un aspecto de vista de los casos de uso.
- Se Contiene los casos de uso y actores importantes.
- Proporciona detalles de manera consistente con su nivel de abstracción.
- No es tan minimalista que no ofrezca información al lector sobre los aspectos importantes de la semántica.
Cuando se dibuja un diagrama de casos de uso
Se debe:
- Hay que darle un nombre que comunique su propósito.
- Es que distribuir sus elementos para minimizar las cruces de líticas.
- Hay que organizar sus elementos para que los comportamientos y roles semánticos cercanos se encuentren cercanos físicamente.
- Hay que utilizar las notas y los colores como señales visuales para llamar la atención sobre las características importantes de un diagrama.
- Hay que intentar no mostrar demasiados tipos de relaciones.