Guía Didáctica 2.-UML

Unidad Curricular:
Sistemas de Información II

UML
Lenguaje 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)

Programa Académico:
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

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


UML::Introducción
Los 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.



UML::Notación y Semántica
 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
 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.



 Modelado de Comportamiento



 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
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
por Computador)
 Como está Compuesto?

Meta modelo Carga o
(no siempre descarga de
visible) datos

Repositorio Comprobación
(diccionario) de errores

CASE



CASE:: Estructura
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
por Computador)
 Clasificación:
TOOLKIT
Considerando su Amplitud
WORKBENCH

UPPER CASE
Considerando las
CASE fases (y/o tareas) del MIDDLE CASE
ciclo de vida que Herramientas de
automatizan LOWER CASE generación
semiautomática de código

Herramientas de
Refactorización de código

Considerando su Editores UML
funcionalidad
Herramientas de
mantenimiento



CASE:: Ejemplos
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



UML::Editor UML
Para 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 UML
Diagrama 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
Diagrama de Clase.

Nombre de la clase:
nombre del módulo.



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 Características de
clave primaria. los atributos
Indicar si el atributo
es público (acceso
desde otra clase) o
privado (restringido
a su clase).

Marca de
clave primaria Nivel de acceso



UML::Editor UML

Operaciones: incluir
todas las acciones
posibles en un
modulo (obtener
datos de..., validar
datos de.., incluir Atributos
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 Nivel de acceso
privada (restringida
a su clase).



UML::Editor UML
Diagrama de Clase. Multiplicidad: permite
Nombre: establece
identificar el tipo de
la relación entre los
correlación existente entre
módulos (contiene,
módulos.
solicita, es
utilizado, etc.)

Flecha: complementa la
multiplicidad, señalando a
aquellas clases que tienen
relación única con otra.



UML::Editor UML



UML::Editor UML
Diagrama de Casos de Uso. 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.

Paquete Grande: se Línea de Asociación: esta
definirá un paquete línea permitirá establecer
representativo del sistema vincular a los actores con sus
propuesto por cada una de actividades (caso de uso).
las sesiones de usuario
(administrador, operador,
etc.). Este deberá contener
el nombre del sistema y -
de existir- el de la sesión.
Caso de Uso: se agregará por
cada actividad prevista dentro o
fuera del sistema. La que sean
internas se deben dibujar dentro
Actor: se deberán establecer los del paquete correspondiente.
usuarios involucrados de forma directa o Cada acción debe estar
indirecta con el sistema. Únicamente se relacionada con al menos un
señalará el nombre de los usuarios actor del sistema y deberá ser los
debajo de la figura (administrador, más específica y concreta
operador, estudiante, etc.). posible.


UML::Editor UML
Diagrama 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 UML
Diagrama de Casos de Uso.



UML::Editor UML
Diagrama de Secuencia.

Mensaje Objeto:
s Clase

Línea de
Vida
Actor



UML::Editor UML

objetoA:A objetoB:B objetoC:C

<<create>>
mensaje1( )
mensaje2( )
mensaje3( )

mensaje4( )

mensaje5( )
mensaje6( )



UML::Editor UML
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

descolgarAuricular( )
{marcando.tiempoEjecucion < 30 segs}
darTonoDeLlamada( )

*marcarDigito( )
enrutarLlamadas(s,n)
marcando
<<create>>
c:Conversación

llamar( )
descolgarAuricular( )
conectar(r,s)
conectar(r) conectar(s)

Los interlocutores r y s pueden
intercambiar información después
de conectarse.



UML::Resumen
Ahora 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ón
1) ¿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ón
4) ¿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:

UML
Guía Didáctica 2

Felicidades,
Cumplidas las lecturas necesarias y
pudiendo evidenciar ejemplos que
demuestran los fundamentos del
UML, puedes avanzar para efectuar
las actividades didácticas.

Unidad Curricular:

UML
Guía Didáctica 2

Equipo Editor:
Prof. Joan Cardozo


Guía Didáctica 2.-UML

Más contenido relacionado

La actualidad más candente (20)

Destacado (9)

Similar a Guía Didáctica 2.-UML (20)

Último (20)

Guía Didáctica 2.-UML