UML

ROBERT ALEXANDER HANCCO ROMERO

UML

El modelo capta los aspectos importantes de lo que estamos modelando y simplifica el resto.

NIVELES DE LOS MODELOS

La cantidad de detalle del modelo debe adaptarse a los siguientes propósitos:

-Guías al proceso de pensamiento.-Especificaciones abstractas de la estructura esencial de un sistema.

-Especificaciones completa de un sistema final.

-Ejemplos de sistemas típicos o posibles.

-Descripciones completas o parciales de un sistema.

¿CUÁL ES EL SIGNIFICADO DE UN MODELO?

Es un generador de potenciales configuraciones de sistemas, también es una descripción de la estructura genérica y del significado de un sistema.En los modelos hay que considerar los siguientes aspectos:-Abstracción frente a detalle.-Especificación frente a implementación.-Descripción frente a instancia.-Variaciones en la interpretación.

SECCIÓN 2:PERSPECTIVA GENERAL DE UML:

Es un lenguaje para visualizar. Detrás de cada símbolo de la notación de

UML hay una semántica bien definida. De esta manera, un desarrollador puede escribir un modelo en UML, y otro desarrollador, o incluso otra herramienta puede interpretar esa herramienta sin ambigüedad.

CICLO DE VIDA DEL DESARROLLO DE SOFTWARE

-Dirigido por los casos de uso significa que los casos de uso se utilizan como un artefacto básico para establecer el comportamiento deseado del sistema, para verificar y validar la arquitectura del sistema, para las pruebas y para la comunicación entre las personas involucradas en el proyecto.

-Centrado en la arquitectura significa que la arquitectura del sistema se utiliza como un artefacto básico para conceptuar, construir, gestionar y hacer evolucionar el sistema en desarrollo.

-Un proceso iterativo es aquel que involucra la gestión de un flujo de ejecutables del sistema.

HISTORIA DE UML

LOS MÉTODOS DE DESARROLLO ORIENTADO A OBJETOS

Emergieron en los años 70 y fueron difundidos en los 80. Alcanzaron cierta penetración en le área de los grandes sistemas.El primer lenguaje que es generalmente reconocido como orientado a objetos es Simula 67, desarrollado en 1967. El movimiento de orientación de objetos se hizo popular en los 80’s.Aparecieron muchos libros cuyos temas estaban enfocados en el modelaje orientado a objetos.

¿QUÉ SIGNIFICA UNIFICADO?-A través de los métodos históricos y notaciones.-A través de los dominios de aplicación.-A través de los lenguajes de implementación y plataformas.-A través de procesos de desarrollo.-A través de los conceptos internos.

OBJETIVOS DE UML

-UML es un lenguaje de propósito general que pueden utilizar todos los programadores.-basado en el común acuerdo.-Pretende abordar los problemas actuales de desarrollo de software.-UML pretende trabajar correctamente con todos.

-UML incluye todos los conceptos que consideramos necesarios para utilizar un proceso moderno iterativo.-Ser tan simple como fuera posible.

CLASES Y OBJETOSUna 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.

DIAGRAMAS DE UML

Es una representación gráfica de un conjunto de elementos, se utilizan para visualizar un sistema desde diferentes perspectivas.

DIAGRAMAS ESTRUCTURALES

-Diagramas de clases.-Diagramas de objetos.-Diagramas de componentes.-Diagramas de despliegue.DIAGRAMAS DE COMPORTAMIENTO

-Diagramas de casos de uso-Diagramas de secuencia.-Diagramas de colaboración.

-Diagramas de estados.

-Diagramas de actividades.

VISTA DE LOS CASOS DE USO

Modela la funcionalidad del sistema según actúen los usuarios externos llamados actores.RELACIONESSe da entre los objetos.

DEPENDENCIARelación de uso que declara que un cambio en la especificación de un elemento puede afectar a otro elemento que lo utiliza.

GENERALIZACIÓNRelación entre un elemento general y un caso más específico de ese elemento.ASOCIACIÓNRelación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro.

CAPÍTULO 3:

NOMBRES

Cada caso debe tener un nombre que lo distinga de otros casos de uso. Es una cadena de texto.

CASOS DE USO Y ACTORES

Un actor representa un conjunto coherente de roles que los usuarios de los casos de uso juegan al interactuar con éstos.

CASOS DE USO Y FLUJO DE EVENTOS

El comportamiento de un caso de uso se puede especificar describiendo un flujo de eventos de forma textual, lo suficientemente claro para que alguien ajeno al sistema lo atienda fácilmente.CASOS DE USO Y COLABORACIONES

Un caso de uso debe implementarse al fin y al cabo, y esto se hace creando una sociedad de clases y otros elementos que colaborarán para llevar a cabo el comportamiento del caso de uso.

ORGANIZACIÓN DE CASOS DE USO

Pueden organizarse agrupándolos en paquetes. También pueden agruparse especificando relaciones de generalización, inclusión y extensión entre ellos.

CONTENIDOS

Un diagrama de casos de uso contiene.-Casos de uso.-Actores.-Relaciones de dependencia, generalización y asociación.

USOS COMUNES-Para modelar el contexto de un sistema.-Para modelar los requisitos de un sistema.

OBJETIVOS DEL USUARIO E INTERACIONES CON EL SISTEMA

Los verdaderos objetivos del usuario se describirán con términos como “garantizar el formateo consistente de un documento” y “hacer que el formato de un documento sea igual que el de otro”. Las interacciones con el sistema permiten decir que los casos de uso incluirán cosas como: “define estilo”, “cambia estilo” y “mueva un estilo de un documento a otro”.

CUANDO EMPLEAR CASOS DE USO

La captura de los casos de uso es una de las tareas principales durante la fase de elaboración; de hecho es lo primero que se debe hacer, aunque ese usa en otras fases también.

MODELADO DE LOS REQUISISTOS DE UN SISTEMA

-Establecer el contexto del sistema.

-Considerar el comportamiento de cada actor.

-Nombrar esos comportamientos comunes como casos de uso.

-Factorizar el comportamiento común en nuevos casos de uso que puedan ser utilizados por otros.-Modelar los casos de uso, actores y relaciones en un diagrama de casos de uso.

-Adornar esos casos de uso con notas que enuncien los requisitos no funcionales.

INGENIERÍA DIRECTA E INVERSA

La 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.La 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ífico.