Guía Didáctica 2.-UML

Unidad Curricular:

Sistemas de Información II

Programa Académico:

Educación Matemática Mención Informática

UMLLenguaje de Modelado Unificado

Guía Didáctica 2

Universidad Nacional Experimental

Francisco de Miranda (UNEFM)Vicerectorado Académico

Aprendizaje Dialógico Interactivo

Área Ciencias de la Educación

Dpto. Informática y Tecnología Educativa (DITE)


UNEFM::DITE::Educación Matemática Mención Informática

UML::Índice

Introducción

Objetivo Didáctico

Conceptualización de elementos del UML

Notación y Semántica

Construcción de Diagramas con UML

Herramientas CASE

Clasificación

Herramientas CASE y UML

Resumen

Autoevaluación



UML::IntroducciónLos procesos de negocio y estructuras organizacionales representan

un reto para todo analista en el proceso de representar situaciones

desencadenadas por el ser humano, y que por ende suelen ser

complejas o variables.

En este sentido es necesario contar con reglas y notaciones, en fin,

especificaciones que permitan mostrar de manera estándar los

aspectos esenciales de un sistema de información, y segmentando en

una variedad de ilustraciones las complejidades identificadas y que se

pretenden describir.

De este modo el Lenguaje de Modelado Unificado constituye la

oportunidad de que en cada fase de desarrollo de un sistemas de

información se pueda contar con representaciones que ilustren las

situaciones reales y las esperadas en las acciones producto del

análisis de requerimiento.



UML:: Objetivo Didáctico

Aplicar los fundamentos básicos del Lenguaje

de Modelado en el análisis y diseño de una

propuesta de Sistemas de Información.




UML::Conceptos Fundamentales? Clase

Se define como la representación de un conjunto de objetos que tienen una

estructura, un comportamiento y unas relaciones con propiedades parecidas.

Objetos

Son instancias de clases (sus atributos tienen valores específicos).

Relaciones

Las clases no están asiladas, entre ellas pueden relacionarse de muchas

maneras. La representación básica es una línea entre las clases relacionadas.

Asociaciones

Es una relación conceptual, que no es inherente de la

naturaleza de las clases, sino al papel que juegan en el

modelo y especifica que las instancias de una clase están

conectadas con las de otra. Cuando una instancia de una

clase puede estar relacionada con un número de variable

de instancias de otra se expresa con la MULTIPLICIDAD.



UML::Conceptos Fundamentales? Agregación

Es un tipo de relación del tipo todo/parte y sirve para modelar

elementos que se relacionan utilizando expresiones como: “es

parte de”, “consta de”, “tienen un”, etc. Para ello, en el diagrama se

utiliza el diamante en blanco, y se coloca en el extremo del todo,

no en el extremo de la línea que conecta una de las partes.

Composición

Es un tipo de asociación donde cada componente o partes

pertenecen a un todo y solo a uno.

Herencia o Generalización

Indica que una subclase secundaria hereda los atributos y métodos

definidos en una superclase o clase principal. Es un tipo de:

Interfaces

Son un conjunto de operaciones que especifican parte de la

funcionalidad proporcionada por una clase. Una clase sin atributos.



UML::Notación y Semántica Modelado Comportamiento

Diagrama de Casos de Uso:

Representa la forma en como un Cliente (Actor) opera con el sistema

en desarrollo, además de la forma, tipo y orden en como los

elementos interactúan (operaciones o casos de uso).

Consta de los siguientes elementos:

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

más bien la labor que realiza frente al sistema.

Casos de Uso

Es una operación/tarea específica que se realiza tras una orden de

algún agente externo, sea desde una petición de un actor o bien

desde la invocación desde otro caso de uso.

http://www.docirs.cl/uml.htm



UML::Notación y Semántica Modelado Comportamiento

Diagrama de Casos de Uso.


Actor, Casos de Uso.

Relaciones:

Asociación

Es el tipo de relación más básica que indica la invocación desde un actor o caso

de uso a otra operación (caso de uso). Dicha relación se denota con una flecha

simple.

Dependencia o Instanciación

Es una forma muy particular de relación entre clases, en la cual una clase

depende de otra, es decir, se instancia (se crea). Dicha relación se denota con

una flecha punteada.

Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble función

dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de

Herencia (<<extends>>).

Este tipo de relación esta orientado exclusivamente para casos de uso (y no

para actores).



UML:: Notación y Semántica Modelado Comportamiento



Actor, Casos de Uso.

Relaciones:

Asociación, Dependencia o Instanciación,

Generalización :

Extends

Se recomienda utilizar cuando un caso de

uso es similar a otro (características).

Uses

Se recomienda utilizar cuando se tiene un

conjunto de características que son

similares en más de un caso de uso y no se

desea mantener copiada la descripción de la

característica.




UML:: Notación y Semántica Modelado de Comportamiento





UML:: Notación y Semántica Modelado Estructural

Diagrama de Clases.

Describe los tipos de objetos que hay en el sistema y las diversas clases de relaciones

estáticas que existen entre ellos.

También muestran los atributos y operaciones de una clase y las restricciones a que se

ven sujetos, según la forma en que se conecten los objetos.

Conceptos fundamentales:

Asociaciones

Representan relaciones entre instancias de clases (una persona trabaja para una

empresa; una empresa tiene cierta cantidad de oficinas).

Acá se incluye la multiplicidad, la cual es una indicación de la cantidad de objetos que

participarán en la relación dada.

La multiplicidad más común son:

uno o muchos: 1..* (1..n)

0 o muchos: 0..* (0..n)

número fijo: m (m denota el número).





Diagrama de Clases.

Conceptos fundamentales:

Asociaciones

Las líneas indican navegabilidad.

Si existe una navegabilidad en una sola dirección, a la asociación se le llama asociación

unidireccional. Una asociación bidireccional contiene navegabilidades en ambas

direcciones. El UML dice que las asociaciones sin flechas significan que la navegabilidad

es desconocida o que la asociación es bidireccional.

Atributos

Los atributos o características de una Clase pueden ser de tres tipos, los que definen el

grado de comunicación 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 accesible desde todos lados.

private (-): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus

métodos lo pueden accesar).

protected (#): Indica que el atributo no será accesible desde fuera de la clase, pero si

podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver

herencia).





Diagrama de Clases::Conceptos fundamentales:

Asociaciones, Atributos

Operaciones

Los métodos u operaciones de una clase son la forma en como ésta interactúa con su

entorno, éstos pueden tener las características:

public (+): Indica que el método será visible tanto dentro como fuera de la clase, es decir,

es accesible desde todos lados.

private (-): Indica que el método sólo será accesible desde dentro de la clase (sólo otros

métodos de la clase lo pueden accesar).

protected (#): Indica que el método no será accesible desde fuera de la clase, pero si

podrá ser accesado por métodos de la clase además de métodos de las subclases que se

deriven (ver herencia).

La sintaxis del UML completa para las operaciones es

visibilidad nombre (lista-de-parámetros) : expresión-tipo-de-dato-a-regresar

{cadena-de-propiedades}

El método de obtención (getting) es un método que devuelve el valor de un campo (sin

hacer nada más). El método de establecimiento (setting) pone un valor en un campo (y

nada más).





Asociaciones, Atributos, Operaciones

Generalización

Indica que una subclase hereda los métodos y atributos especificados por una Super

Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá

las características y atributos visibles de la Super Clase (public y protected).





Asociaciones, Atributos, Operaciones, Generalización

Agregación y Composición

Cuando se requiere componer objetos que son instancias de clases definidas por el

desarrollador de la aplicación, tenemos dos posibilidades:

Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto

incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada

Agregación (el objeto base utiliza al incluido para su funcionamiento).

Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido

esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es

comúnmente llamada Composición (el Objeto base se construye a partir del objeto

incluido, es decir, es "parte/todo").





Asociaciones, Atributos, Operaciones, Generalización, Agregación y Composición

Dependencia

Representa un tipo de relación muy particular, en la que una clase es instanciada (su

instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

El uso más particular de este tipo de relación es para denotar la dependencia que tiene

una clase de otra.

Clase Parametrizada

Se denota con un subcuadro en el extremo superior de la clase, en donde se especifican

los parámetros que deben ser pasados a la clase para que esta pueda ser instanciada.




Diagrama de Clases




Diagrama de Interacción (Secuencia):

Representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si

en petición a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se

obtienen las responsabilidades claramente.

Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estático de Clases

o el de Casos de Uso (son diferentes).

Los componentes de un diagrama de interacción son:

Un Objeto o Actor:

El rectángulo representa una instancia de un Objeto en particular, y la línea punteada

representa las llamadas a métodos del objeto.






Un Objeto o Actor

Mensaje a Otro Objeto:

Se representa por una flecha entre un objeto y otro, representa la llamada de un método

(operación) de un objeto en particular.

Mensaje al Mismo Objeto:

No solo llamadas a métodos de objetos externos pueden realizarse, también es posible

visualizar llamadas a métodos desde el mismo objeto en estudio.






Un Objeto o Actor, Mensaje a Otro Objeto, Mensaje al Mismo Objeto.



CASE:: Concepto CASE(Computer Aided Software Engineering - Ingeniería del Software Asistido

por Computador)

De acuerdo con Kendall y Kendall la ingeniería de sistemas asistida por ordenador

es la aplicación de tecnología informática a las actividades, las técnicas y las

metodologías propias de desarrollo, su objetivo es acelerar el proceso para el que

han sido diseñadas, en el caso de CASE para automatizar o apoyar una o más fases

del ciclo de vida del desarrollo de sistemas.

Tecnologías CASE

son diversas aplicaciones informáticas destinadas a aumentar la productividad en el

desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de

dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de

vida de desarrollo del software en tareas como el proceso de realizar un diseño del

proyecto, calculo de costes, implementación de parte del código automáticamente

con el diseño dado, compilación automática, documentación o detección de errores

entre otras.



CASE:: Objetivos CASE(Computer Aided Software Engineering - Ingeniería del Software Asistido

por Computador) :: Objetivos

Permitir la aplicación práctica de metodologías estructuradas, las cuales al ser realizadas con una herramienta se consigue agilizar el trabajo.

Facilitar la realización de prototipos y el desarrollo conjunto de aplicaciones.

Simplificar el mantenimiento de los programas.

Mejorar y estandarizar la documentación.

Aumentar la portabilidad de las aplicaciones.

Facilitar la reutilización de componentes software.

Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilización de gráficos.



CASE:: Composición CASE(Computer Aided Software Engineering - Ingeniería del Software Asistido

por Computador)

Como está Compuesto?

CASE

Repositorio (diccionario)

Meta modelo

(no siempre visible)

Carga o descarga de

datos

Comprobación de errores



CASE:: Estructura CASE(Computer Aided Software Engineering - Ingeniería del Software Asistido

por Computador)

Cual es su estructura?

CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases

finales o superiores del ciclo de vida del desarrollo de sistemas como la planificación

de sistemas, el análisis de sistemas y el diseño de sistemas.

CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases

finales o inferiores del ciclo de vida como el diseño detallado de sistemas, la

implantación de sistemas y el soporte de sistemas.

CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan

actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen

actividades como la gestión de proyectos y la estimación.



CASE:: Clasificación CASE(Computer Aided Software Engineering - Ingeniería del Software Asistido

por Computador)

Clasificación:

CASE

Considerando su Amplitud

TOOLKIT

WORKBENCH

Considerando las fases (y/o tareas) del

ciclo de vida que automatizan

UPPER CASE

MIDDLE CASE

LOWER CASE

Considerando su funcionalidad

Herramientas de generación

semiautomática de código

Herramientas de Refactorización de código

Editores UML

Herramientas de mantenimiento



CASE:: Ejemplos CASE(Computer Aided Software Engineering - Ingeniería del Software Asistido

por Computador)

Algunos ejemplos:

Herramientas Abiertas

Umbrello, Tutorial

ArgoUML

Gaphor

BoUML, Tutorial

Omondo Eclipse

Dia, dia2code , Tutorial

Herramientas Comerciales/Cerradas

Rational Rose

Together

System Architect

Visual Paradigm

Poseidon

http://uml.sourceforge.net/

http://docs.kde.org/stable/es/kdesdk/umbrello/

http://argouml.tigris.org/

http://gaphor.sourceforge.net/

http://bouml.free.fr/

http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=bouml

http://bouml.free.fr/

http://dia-installer.de/index.html.es

http://dia2code.sourceforge.net/

http://trevinca.ei.uvigo.es/~jgarcia/TO/usoDia/index.html

http://www-01.ibm.com/software/awdtools/developer/rose/

http://www.borland.com/us/products/together/index.html

http://www.sparxsystems.com.au/

http://www.visual-paradigm.com/product/vpuml/

http://www.gentleware.com/



UML::Editor UMLPara efectos de este curso, realizaremos diagramas utilizando la aplicación Dia 0.96.1, la cual permite la

creación de diagramas estructurados.

Esta aplicación presenta dos ventanas: una con las diferentes opciones de figuras para la diagramación;

y otra que constituye el área de trabajo y en la cual, realizaremos los diferentes gráficos propuestos.

Una vez dibujada cada figura, esta presenta una serie de propiedades a las que se puede acceder desde

el botón derecho del ratón o haciendo doble clic cobre la misma.



UML::Editor UMLDiagrama de Clases

Es un modelo estático, el cual permite representar a las clases y sus interacciones. Se define

como un modelo que contiene: clases, interfaces, colaboraciones (conjunto de clases,

interfaces y demás que exhiben un comportamiento), relaciones de dependencia,

colaboraciones y asociación. Para efectos de este curso, este diagrama consistirá en la

representación gráfica de los diferentes módulos del sistema propuesto, haciendo énfasis en la

determinación de atributos y operaciones por entidad.

Clases Línea de Asociación



UML::Editor UML

Nombre de la clase:

nombre del módulo.

Diagrama de Clase.



UML::Editor UML

Atributos:

especificar nombres

y tipología de los

mismos en español.

Marque la casilla

“vista de clase”

para señalar la

clave primaria.

Indicar si el atributo

es público (acceso

desde otra clase) o

privado (restringido

a su clase).

Características de

los atributos

Nivel de accesoMarca de

clave primaria



UML::Editor UML

Operaciones: incluir

todas las acciones

posibles en un

modulo (obtener

datos de..., validar

datos de.., incluir

datos de..., etc.).

Debe señalar cuáles

de los atributos

definidos estarán

involucrados en las

diferentes

operaciones. Indicar

si la operación es

pública (acceso

desde otra clase) o

privada (restringida

a su clase).

Nivel de acceso

Atributos

Diagrama de Clase.



UML::Editor UML

Nombre: establece

la relación entre los

módulos (contiene,

solicita, es

utilizado, etc.)

Multiplicidad: permite

identificar el tipo de

correlación existente entre

módulos.

Flecha: complementa la

multiplicidad, señalando a

aquellas clases que tienen

relación única con otra.

Diagrama de Clase.



UML::Editor UMLDiagrama de Clase.



UML::Editor UML

Línea de Asociación: esta

línea permitirá establecer

vincular a los actores con sus

actividades (caso de uso).

Actor: se deberán establecer los

usuarios involucrados de forma directa o

indirecta con el sistema. Únicamente se

señalará el nombre de los usuarios

debajo de la figura (administrador,

operador, estudiante, etc.).

Paquete Grande: se

definirá un paquete

representativo del sistema

propuesto por cada una de

las sesiones de usuario

(administrador, operador,

etc.). Este deberá contener

el nombre del sistema y -

de existir- el de la sesión.

Línea de Dependencia: esta línea define la dependencia que pueda

existir entre una actividad y otra, o entre una actividad y el sistema.

Esta dependencia fijará condicionantes para la ejecución de una

actividad y se indicará con el extremo flecha la actividad dependiente.

Caso de Uso: se agregará por

cada actividad prevista dentro o

fuera del sistema. La que sean

internas se deben dibujar dentro

del paquete correspondiente.

Cada acción debe estar

relacionada con al menos un

actor del sistema y deberá ser los

más específica y concreta

posible.




UML::Editor UMLDiagrama de Casos de Uso.

Paquete Grande: se definirá un paquete

representativo del sistema propuesto por

cada una de las sesiones de usuario

(administrador, operador, etc.). Este

deberá contener el nombre del sistema y

-de existir- el de la sesión.









UML::Editor UMLDiagrama de Secuencia.

Objeto:

Clase

Actor

Mensaje

s

Línea de

Vida




objetoA:A objetoB:B objetoC:C

<<create>>

mensaje2( )

mensaje3( )

mensaje4( )

mensaje5( )

mensaje1( )

mensaje6( )




Ejemplo 1:

Se quiere modelar la llamada telefónica que realizan dos interlocutores a través de una

central telefónica.

s:Interlocutor :Central r:Interlocutor

c:Conversación

descolgarAuricular( )

darTonoDeLlamada( )

*marcarDigito( )

marcando

{marcando.tiempoEjecucion < 30 segs}

enrutarLlamadas(s,n)

<<create>>

llamar( )

descolgarAuricular( )conectar(r,s)

conectar(r) conectar(s)

Los interlocutores r y s pueden

intercambiar información después

de conectarse.



UML::ResumenAhora que ha completado esta guía didáctica, usted debe ser

capaz de:

Establecer la notación y semántica de los tipos de

diagramas en el lenguaje de modelado de sistema de

información.

Construir diagramas en el lenguaje de modelado de

sistemas de información para situaciones propuestas.

Conceptualizar Herramientas CASE.

Formular la clasificación de las herramientas CASE.

Aplicar las herramientas CASE y lenguaje de modelado de

sistemas de información en situaciones hipotéticas



UML::Autoevaluación1) ¿Cuáles son los elementos que conforman el diagrama de casos de uso?.

a) Actor

b) Relaciones

c) Clases

d) Objetos

2) ¿Cuáles son los niveles posibles de visibilidad de los atributos y métodos en el

diagrama de clases?

a) Protegido

b) Público

c) Local

d) Privado

3) ¿Cuáles son los criterios para la clasificación de las herramientas CASE?

a) Considerando su amplitud .

b) Considerando las fases del ciclo de vida del S.I.

c) Considerando su funcionalidad.

d) Considerando su reutilización.



UML::Autoevaluación4) ¿Cuál es la relación donde el Objeto base se construye a partir del objeto

incluido, es decir, es "parte/todo")?

a) Composición.

b) Agregación.

c) Asociación.

d) Generalización

5) ¿El diagrama de secuencia corresponde al modelado estructural?

a) Verdadero

b) Falso

6) ¿Cuáles de los siguientes símbolos se asocia a los niveles de visibilidad en el

diagrama de clases?

a) -.

b) *.

c) #.

d) ^.



UML::Autoevaluación(Respuestas)

1) a, b.

2) a, b y d.

3) a, b, c.

4) a.

5) b.

6) a, c.

Unidad Curricular:




Felicidades,

Cumplidas las lecturas necesarias y

pudiendo evidenciar ejemplos que

demuestran los fundamentos del

UML, puedes avanzar para efectuar

las actividades didácticas.


Guía Didáctica 2

Unidad Curricular:




Equipo Editor:

Prof. Joan Cardozo


Guía Didáctica 2

Education

Guía Didáctica 2.-UML