UNIVERSIDAD DE LAS FUERZAS ARMADAS “ESPE”

INGENIERIA EN
ELECTRONICA Y
AUTOMATIZACION
Nombre: Periodo:
Lino Suquilanda Bryan Alberto Marzo 2019-
Julio 2019
Asignatura: Programación orientada a objetos
NRC:4064
Fecha: 21-04-2019
1. Tema
Modelado UML
2. Objetivos
Objetivo General
Familiarizar con los diferentes tipos de diagramas que se usan en el Lenguaje Modelado
Unificado.
Objetivos Específicos
 Conocer la definición de un sistema de modelado UML y sus aplicaciones en el ámbito
de la programación.
 Generar nuestras propias definiciones sobre el sistema de modelado y los diferentes tipos
de diagramas.
 Analizar las diferentes estructuras de todos los diagramas que se encuentren
3. Desarrollo
3.1 Conceptos
UML
“El Lenguaje de Modelado Unificado (por sus siglas en inglés UML) es un lenguaje que
permite modelar, construir y documentar los elementos que forman un sistema software
orientado a objetos. Es un lenguaje estándar para poner por escrito un proyecto de sistema y
es parte del método de desarrollo del sistema”. (Mediavilla, 2008)
Características
- Puede usarse para visualizar, especificar, construir y documentar un sistema complejo.
- Al tratarse de un lenguaje de modelado, su vocabulario y normas se enfocan a la
representación conceptual y física del sistema. (Mediavilla, 2008)
- El vocabulario y las normas del UML indican cómo crear y leer modelos bien formados
gramaticalmente, pero no dicen qué modelos deben crearse ni cuándo hacerlo. Eso es el
papel del proceso de desarrollo del sistema. (Mediavilla, 2008)
- Detrás de cada símbolo de la notación UML hay una semántica bien definida. De esta
forma, un programador puede escribir un modelo en UML y otro programador, o incluso
una herramienta, puede interpretar ese modelo inequívocamente
(Mediavilla, 2008)
Diagrama de clase

1
Los diagramas de clase describen los tipos de objetos de un sistema, así como los distintos
tipos de relaciones que pueden existir entre ellos. Los diagramas de clase se convierten así
en la técnica más potente para el modelado conceptual de un sistema software, la cual suele
recoger los conceptos clave del modelo de objetos subyacente al método orientado a objetos
que la incorpora, en este caso UML. (Peñalvo, 1998)
3.2 Tipos de diagramas UML
Un modelo representa a un sistema software desde una perspectiva específica. Al igual que
la planta y el alzado de una figura en dibujo técnico nos muestran la misma figura vista
desde distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del
sistema. (Grau & Segura, 1999)
Los modelos de UML que se tratan en esta parte son los siguientes:
· Diagrama de Estructura Estática.
· Diagrama de Casos de Uso.
· Diagrama de Secuencia.
· Diagrama de Colaboración.
· Diagrama de Estados.
Diagramas de Estructura Estática
Con el nombre de Diagramas de Estructura Estática se engloba tanto al Modelo Conceptual
de la fase de Análisis como al Diagrama de Clases de la fase de Diseño. Ambos son
distintos conceptualmente, mientras el primero modela elementos del dominio el segundo
presenta los elementos de la solución software. (Grau & Segura, 1999)
Diagrama de Casos de Uso
Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del
sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su
interacción externa. (Grau & Segura, 1999)
Diagrama de Secuencia
Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal
de eventos. En particular, muestra los objetos participantes en la interacción y los mensajes
que intercambian ordenados según su secuencia en el tiempo. (Grau & Segura, 1999)
Diagrama de Colaboración
Un Diagrama de Colaboración muestra una interacción organizada basándose en los
objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la
interacción se refiere). A diferencia de los Diagramas de Secuencia, los Diagramas de
Colaboración muestran las relaciones entre los roles de los objetos. La secuencia de los
mensajes y los flujos de ejecución concurrentes deben determinarse explícitamente
mediante números de secuencia. (Grau & Segura, 1999)
Diagrama de Estados

2
 Un Diagrama de Estados muestra la secuencia de estados por los que pasa un caso de uso o
un objeto a lo largo de su vida, indicando qué eventos hacen que se pase de un estado a
otro y cuáles son las respuestas y acciones que genera. (Grau & Segura, 1999)
3.3 Diagramas de clase
Para UML una clase es “una descripción de un conjunto de objetos que comparten los
mismos atributos, operaciones, métodos, relaciones, y semántica”. De esta forma, un
diagrama de clase de UML puede describir todos los componentes de una clase de una
forma sencilla. Así, el elemento fundamental de los diagramas de clase es el icono que
representa una clase. (Peñalvo, 1998)

Figura 1: Iconos para representar clases

Fuente: (Peñalvo, 1998)
El icono de una clase es un rectángulo dividido en tres secciones, como se puede apreciar
en la Figura A. La sección superior contiene el nombre de la clase, la sección intermedia
contiene la lista de atributos, y la sección inferior contiene la lista de operaciones de la
clase.
Dependiendo del detalle del diagrama de clase, la notación para un atributo puede indicar
su nombre, su tipo, un valor de inicio y su visibilidad, siendo su sintaxis:
visibilidad nombre: tipo = valor
Donde:
• Visibilidad expresa si el atributo es visible para el resto de objetos del diagrama,
pudiéndose dar los siguientes casos.
+ Visibilidad pública: Visible por todos los objetos
# Visibilidad protegida: Visible sólo por el objeto y sus descendientes
- Visibilidad privada: Visible sólo por el objeto
• Nombre es el identificador del atributo
• Tipo indica el dominio del atributo
• Valor es un elemento opcional que indica un valor de inicio para el atributo
Atributos.

3
Las clases tienen atributos que representan alguna propiedad de la clase que comparten
todos los objetos de esa clase.
Un atributo es una propiedad nombrada de una clase, que describe un rango de valores que
puede tomar esa propiedad en las instancias.
Por ejemplo, nombre, edad o peso son atributos de objetos Persona
(Mediavilla, 2008)
Operaciones
Una operación es una función o transformación que puede ser aplicada por o sobre objetos
de una clase. Todos los objetos de una clase comparten las mismas operaciones. Una
operación es la implementación de un servicio que puede requerirse de cualquier objeto de
la clase.
Cada operación tiene a un objeto determinado como argumento implícito y el
comportamiento de la operación depende de la clase de este objeto. Un objeto conoce su
clase y, por tanto, la implementación correcta de la operación. (Mediavilla, 2008)
Métodos
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).
(Cornejo, 2008)
Estructura de un método
Los métodos en java pueden tener parámetros, es decir, que un método puede utilizar
variables predefinidas para ser utilizadas en sus procesos, Veamos un ejemplo de cómo hacer
un método en el siguiente ejemplo

Figura 2: ejemplo de método

Como lo mostramos en la figura 2

4
El modificador de accesos public indica que puede accederse a este miembro de la clase
desde el exterior de la clase
El modificados static indica que se trata de un método de clase (común para todos los objetos
de clase)
Void indica que el método main no devuelve ningún valor.
El paréntesis nos indica que se trata de un método: lo que aparece entre paréntesis son los
parámetros del método. (Berzal, 2004)
Relaciones entre Clases:
En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan
en cada extremo de la relación y éstas pueden ser:
uno o muchos: 1. * (1…..,n)
0 o muchos: 0. * (0……,n)
número fijo: m (m denota el número).
Herencia (Especialización/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, por ejemplo, la figura 3.

:
Figura 3. Herencia
Fuente: (Cornejo, 2008)
Agregación
Para modelar objetos complejos, no bastan los tipos de datos básicos que proveen los
lenguajes: enteros, reales y secuencias de caracteres, (ver figura 4). Cuando se requiere

5
 componer objetos que son instancias de clases definidas por el desarrollador de la aplicación
tenemos dos posibilidades:
Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido
está 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").
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). (Cornejo, 2008)

Figura 4.
Fuente: (Cornejo, 2008)
Dependencia o Instanciación (uso):
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, como por ejemplo (ver figura 5) una aplicación grafica que instancia una
ventana (la creación del Objeto Ventana está condicionado a la instanciación proveniente
desde el objeto Aplicación): (Cornejo, 2008)

Figura 5
Fuente: (Cornejo, 2008)
4. Conclusiones:
- Como consecuencia de lo antes expuesto, los sistemas de modelado son de gran
importancia en el ámbito de la programación orientada a objetos, como el modelado
UML que permite generar modelos precisos y entendibles para cualquier programador.
- Posteriormente, se analizó las diferentes formas que hay en cuanto se refiere a
diagramas de UML, y se pudo apreciar que estos sirven para conectarse a diversos
lenguajes de programación.
- Por tanto, el modelado UML esta diseñado para estandarizar a todos los
programadores, con el fin de que haya más intercambio de conocimientos en la
programación orientada a objetos.

6
5. Recomendaciones
- Se debe conocer todas las manera de declarar a una variable en los programas debido a
que si lo dejamos en modo público, por ejemplo, cualquier persona puede cambiar el
código que hayamos empleado
- Ya que este tipo de modelado también se suele usar mucho en las tesis de estudiantes,
es necesario realizar bueno diseños de los diagramas que se vayan a emplear y
referenciar.
- En última instancia, cabe recalcar que se debe tomar en cuenta el tipo de diagrama que
vayamos a usar y referenciarlo con sus respectivas estructuras

6. Bibliografía
Berzal, F. (2004). Apuntes de programcion orientada a objetos en java: fundamentos de
programcion y principios de diseño. En F. B. Galiano, Apuntes de programcion
orientada a objetos en java: fundamentos de programcion y principios de diseño (pág.
20). Eclipse.
Cornejo, J. E. (20 de Enero de 2008). DOCIRS TECHNOLOGY. Obtenido de
https://www.docirs.com/uml.htm
Grau, X. F., & Segura, M. I. (Marzo de 1999). UV.MX. Obtenido de
https://www.uv.mx/personal/maymendez/files/2011/05/umlTotal.pdf
Mediavilla, E. (18 de Febrero de 2008). CTR UNICAN. Obtenido de
https://www.ctr.unican.es/asignaturas/MC_OO/Doc/Introduccion.pdf
Peñalvo, F. J. (12 de Febrero de 1998). Repositorio.grial.eu. Obtenido de
https://repositorio.grial.eu/bitstream/grial/353/1/DClase.pdf