Universidad Nacional Experimental

de la Gran Caracas.

Diagramas
Trayecto II

Estudiantes PNFI

Nombres y Apellidos CI E-mail

Beltrán Ámbar 14.428.177
Flores Daleidy 24.530.313
Gascón Ana 24.939.063
Gil Luis 20.414.102

Julio 2019

1
 Introducción

El lenguaje unificado de modelado UML Se utiliza para definir un sistema,

mediante el uso de objetos que forman parte de él así como, las relaciones estáticas
o dinámicas que existen entre ellos.

Cuando para el desarrollo de una aplicación se decide utilizar un lenguaje de

programación orientado a objetos, para representar de forma visual tanto las clases
que serán utilizadas como las relaciones existentes entre ellas se usa el lenguaje
UML (Unified Modeling Language, o Lenguaje de Modelado Unificado en español),
que define una serie de reglas para crear diagramas UML.
Dentro de los diagramas de comportamiento en UML que permiten enfatizar
las interacciones entre los objetos se encuentran los diagramas de clases,
diagramas de objetos, diagramas de secuencia.

Sin embargo, con UML se pueden crear los siguientes tipos de diagramas:
 Estáticos
 De clases: modelan la estructura estática de las clases.
 De objetos: para modelar la estructura estática de los objetos.
 De componentes: para modelar los componentes.
 De despliegue: modelan la distribución del sistema.
 Dinámicos
 De casos de uso: modelan los procesos de negocio.
 De secuencia: modelan el traspaso de mensajes entre objetos.
 De colaboración: representan las interacciones entre los objetos.
 De estados: representan el comportamiento de casos de uso, objetos
y operaciones.
 De actividades: modelan el comportamiento de los casos de uso,
objetos u operaciones.
1. Modelado orientado a objetos

Principios básicos del modelado

El modelaje tiene una rica historia en todas las disciplinas de ingeniería. Los
cuatro principios de modelado son derivados de esa historia.

1.1. El tipo de modelo que se crea influye la manera en que el problema es

atacado:

Los modelos correctos alivian los problemas de desarrollo más

demandantes, en cambio, los modelos incorrectos nos confunden, enfocándonos
en detalles irrelevantes. Los modelos que se seleccionan afectan de manera
importante la vista de la realidad, llevándonos a diferentes tipos de sistemas con
costos y beneficios distintos.

1.2. Cada modelo puede ser expresado en diferentes niveles de precisión:

Si se estuviesen construyendo chips de computadora, en ocasiones se

necesitará modelos de alto nivel, por ejemplo, cuando se desee mostrar el producto
final a la comunidad de clientes, en otras ocasiones será necesario bajar hasta el
nivel de compuertas, cuando por ejemplo se requiera optimizar la operación.
Cuando se desarrolla un sistema con interface gráfica de usuario, en ocasiones,
contar con un ejecutable burdo de la interface sería necesario para transmitir el “look
and feel”, mientras que, en otras ocasiones, cuando por ejemplo se estén diseñando
interfaces de conexión vía red entre sistemas sea requerido bajar hasta el nivel de
bits para definir el protocolo de comunicación.

1.3. Los mejores modelos están conectados con la realidad:

 Un modelo físico de un edificio que no reacciona de la misma forma que lo
haría uno real con el mismo tipo de materiales sería de poca utilidad. Es siempre
mejor tener modelos que estén conectados fuertemente a la realidad. Cuando esta
conexión es débil se debe tener una clara percepción de donde se encuentran estas
carencias. Todos los modelos simplifican la realidad, en consecuencia, el truco es
asegurar que esta simplificación no oculta detalles importantes o características
potencialmente fatales.

1.4. Un solo modelo no es suficiente:

La palabra clave de “modelos independientes”, significa que éstos pueden

ser desarrollados y estudiados por separado, pero que mantiene un nivel de
interrelación importante. Para entender la arquitectura de sistemas orientados a
objetos, es necesario contar con un conjunto de vistas complementarias y
sincronizadas del sistema. Una vista arquitectónica puede ser definida como una
descripción simplificada (una abstracción) de un sistema desde una perspectiva o
punto de vista particular. Que cubre ciertos aspectos de interés y omite elementos
que no son de importancia para ese tipo de interesados. Las vistas son “rebanadas”
de modelos.

2. Diagrama de Clases

Los diagramas de clases son uno de los tipos de diagramas más útiles en
UML, ya que trazan claramente la estructura de un sistema concreto al modelar sus
clases, atributos, operaciones y relaciones entre objetos.

Este tipo de diagrama es popular entre los ingenieros de software para

documentar arquitectura de software, los diagramas de clases son un tipo de
diagrama de estructura porque describen lo que debe estar presente en el sistema
que se está modelando.
 El UML se estableció como un modelo estandarizado para describir un
enfoque de programación orientada a objetos (POO). Como las clases son los
componentes básicos de los objetos, los diagramas de clases son los componentes
básicos del UML. Los diversos componentes en un diagrama de clases pueden
representar las clases que se programarán en realidad, los objetos principales o la
interacción entre clases y objetos.

La figura de clase en sí misma consiste en un rectángulo de tres filas. La fila

superior contiene el nombre de la clase, la fila del centro contiene los atributos de la
clase y la última expresa los métodos o las operaciones que la clase puede utilizar.
Las clases y las subclases se agrupan para mostrar la relación estática entre cada
objeto.

Componentes básicos:

El diagrama de clases estándar está compuesto por tres partes:

 Sección superior: Contiene el nombre de la clase. Esta sección siempre es

necesaria, ya sea que estés hablando del clasificador o de un objeto.
 Sección central: Contiene los atributos de la clase. Usa esta sección para
describir cualidades de la clase. Esto solo es necesario al describir una
instancia específica de una clase.
 Sección inferior: Incluye operaciones de clases (métodos). Esto está
organizado en un formato de lista. Cada operación requiere su propia línea.
Las operaciones describen cómo una clase puede interactuar con los datos.

Modificadores de acceso a miembros:

Todas las clases poseen diferentes niveles de acceso en función del
modificador de acceso (visibilidad). A continuación te mostramos los niveles de
acceso con sus símbolos correspondientes:
  Público (+)
 Privado (-)
 Protegido (#)
 Paquete (~)
 Derivado (/)
 Estático (subrayado)

Componentes:

 Clases: Una plantilla para crear objetos e implementar un comportamiento en

un sistema. En UML, una clase representa un objeto o un conjunto de objetos que
comparte una estructura y un comportamiento comunes. Se representan con un
rectángulo que incluye filas del nombre de la clase, sus atributos y sus operaciones.
Al dibujar una clase en un diagrama de clases, solo se debe cumplimentar la fila
superior. Las otras son opcionales y se usan si desea agregar más detalles.
 Nombre: La primera fila en una figura de clase.
 Atributos: La segunda fila en una figura de clase. Cada atributo de una clase está
ubicado en una línea separada.
 Métodos: La tercera fila en una figura de clase. También conocidos como
"operaciones", los métodos se organizan en un formato de lista donde cada
operación posee su propia línea.
 Señales: Símbolos que representan comunicaciones unidireccionales y
asincrónicas entre objetos activos.
 Tipos de datos: Clasificadores que definen valores de datos. Los tipos de datos
pueden modelar tanto enumeraciones como tipos primitivos.
 Paquetes: Figuras diseñadas para organizar clasificadores relacionados en un
diagrama. Se simbolizan con una figura de un gran rectángulo con pestañas.
 Interfaces: Una recopilación de firmas de operaciones o de definiciones de atributo
que define un conjunto uniforme de comportamientos. Las interfaces son similares
 a una clase, excepto por que una clase puede tener una instancia de su tipo, y una
interfaz debe poseer, como mínimo, una clase para implementarla.
 Enumeraciones: Representaciones de tipos de datos definidos por el usuario. Una
enumeración incluye grupos de identificadores que representan valores de la
enumeración.
 Objetos: Instancias de una clase o clases. Los objetos se pueden agregar a un
diagrama de clases para representar instancias prototípicas o concretas.
 Artefactos: Elementos modelo que representan las entidades concretas de un
sistema de software, como documentos, bases de datos, archivos ejecutables,
componentes de software y más.

3. Diagrama de objetos

Los diagramas de objetos modelan las instancias de elementos contenidos

en los diagramas de clases. Un diagrama de objetos muestra un conjunto de objetos
y sus relaciones en un momento concreto. En UML, los diagramas de clase se
utilizan para visualizar los aspectos estáticos del sistema y los diagramas de
interacción se utilizan para ver los aspectos dinámicos del sistema, y constan de
instancias de los elementos del diagrama de clases y mensajes enviados entre ellos.

Los diagramas de objetos se emplean para modelar la vista de diseño

estática o la vista de procesos estática de un sistema al igual que se hace con los
diagramas de clases, pero desde la perspectiva de instancias reales o prototípicas.
Esta vista sustenta principalmente los requisitos funcionales de un sistema. Los
diagramas de objetos permiten modelar estructuras de datos estáticas.

En general los diagramas de objetos se utilizan para modelar estructuras de

objetos, lo que implica tomar una instantánea de los objetos de un sistema en un
cierto momento. Un diagrama de objetos representa una escena estática dentro de
la historia representada por un diagrama de interacción.
Elementos:

Los diagramas de objetos son sencillos de crear: se componen de objetos,

representados por rectángulos, conectados mediante líneas.

 Objetos: Los objetos son instancias de una clase. Por ejemplo, si "coche" es
una clase, un Altima 2007 de Nissan es un objeto de una clase.
 Títulos de clases: Los títulos de clases son los atributos específicos de una
clase dada. En el diagrama de objetos de árbol genealógico, los títulos de
clases incluyen nombre, género y edad de los integrantes de la familia. Se
pueden listar títulos de clases como elementos en el objeto o incluso en las
propiedades del propio objeto (como el color).
 Atributos de clases: Los atributos de clases se representan por medio de
un rectángulo con dos pestañas que indica un elemento de software.
 Enlaces: Los enlaces son líneas que conectan dos figuras de un diagrama
de objetos entre sí. El diagrama de objetos corporativo siguiente muestra
cómo los departamentos están conectados al estilo del organigrama
tradicional.

4. Diagrama de secuencia

Un diagrama de secuencia es un tipo de diagrama de interacción porque

describe cómo y en qué orden un grupo de objetos funcionan en conjunto. Tanto los
desarrolladores de software como los profesionales de negocios usan estos
diagramas para comprender los requisitos de un sistema nuevo o documentar un
proceso existente. A los diagramas de secuencia en ocasiones se los conoce como
diagramas de eventos o escenarios de eventos.
Elementos:

 Rol de la Clase: El rol de la clase describe la manera en que un objeto se va

a comportar en el contexto. No se listan los atributos del objeto.
 Activación: Los cuadros de activación representan el tiempo que un objeto
necesita para completar una tarea.
 Mensajes: Los mensajes son flechas que representan comunicaciones entre
objetos. Las medias flechas representan mensajes asincrónicos. Los
mensajes asincrónicos son enviados desde un objeto que no va a esperar
una respuesta del receptor para continuar con sus tareas.
 Líneas de Vida: Las líneas de vida son verticales y en línea de puntos, ellas
indican la presencia del objeto durante el tiempo.

5. MVC (Modelo, vista, controlador)

 El MVC o Modelo-Vista-Controlador es un patrón de arquitectura de software
que, utilizando 3 componentes (Vistas, Models y Controladores) separa la lógica de
la aplicación de la lógica de la vista en una aplicación. Es una arquitectura
importante puesto que se utiliza tanto en componentes gráficos básicos hasta
sistemas empresariales.

Modelo: Que contiene una representación de los datos que maneja el sistema, su
lógica de negocio, y sus mecanismos de persistencia. Se encarga de los datos,
generalmente (pero no obligatoriamente) consultando la base de datos.
Actualizaciones, consultas, búsquedas, etc.

Controlador: Que actúa como intermediario entre el Modelo y la Vista, gestionando

el flujo de información entre ellos y las transformaciones para adaptar los datos a
las necesidades de cada uno. Se encarga de fiscalizar, recibe las órdenes del
usuario y se encarga de solicitar los datos al modelo y de comunicárselos a la vista.

Vista: Interfaz de usuario, que compone la información que se envía al cliente y los
mecanismos interacción con éste. Son la representación visual de los datos, todo lo
que tenga que ver con la interfaz gráfica. Ni el modelo ni el controlador se preocupan
de cómo se verán los datos, esa responsabilidad es únicamente de la vista.

Conclusión

En general se puede decir que los diagramas y sistemas de modelado fueron

creados para forjar un lenguaje de modelado visual común, semántica y
sintácticamente rico para la arquitectura, el diseño y la implementación de sistemas
de software complejos, tanto en estructura como en comportamiento.
 Por ejemplo, los diagramas de clases ofrecen una serie de beneficios para
toda organización, como ilustrar modelos de datos para sistemas de información,
sin importar qué tan simples o complejos sean, comprender mejor la visión general
de los esquemas de una aplicación, expresar visualmente cualesquier necesidades
específicas de un sistema y divulgar esa información en toda la empresa, y crear
diagramas detallados que resalten cualquier código específico que será necesario
programar e implementar en la estructura descrita.

Y por su parte, los diagramas de secuencia pueden ser referencias útiles para
las empresas y otras organizaciones. Ayudaran en mayor medida a representa los
detalles de un caso de uso en UML, modelar la lógica de una operación, una función
o un procedimiento sofisticados, ver cómo los objetos y los componentes interactúan
entre sí para completar un proceso, y planificar y comprender la funcionalidad
detallada de un escenario actual o futuro.

Referencias Bibliográficas

 S/A (2017) Modelado de sistemas con UML. Consultado y extraído de

https://www.ibiblio.org/pub/Linux/docs/LuCaS/Tutoriales/doc-modelado-
sistemas-UML/multiple-html/x291.html
 Joan Paon. (2013). UML – Diagramas de Clases – Interfaces. Consultado y
extraído de https://joanpaon.wordpress.com/2013/05/31/uml-diagramas-de-
clases-interfaces/
 S/A (S/D). Diagramas del UML. Consultado y extraído de
https://www.teatroabadia.com/en/uploads/documentos/iagramas_del_uml.p
df
 Patricia López y Francisco Ruiz Ingeniería del software I, tema 2 Lenguaje
Unificado Modelado -UML [página web en línea] (2011)
cc.etsii.ull.es/ftp/antiguo/.../MODELADO%20ORIENTADO%20A%20OBJET
OS.doc
 Rossi, Britos y Garcia modelado de objetos, CAPIS - Centro de Actualización
Permanente en Ingeniería de Software Escuela de Posgrado. ITBA.
{brossi,pbritos,rgm}@itba.edu.ar0.http://laboratorios.fi.uba.ar/lsi/rgm/articulo
s/R-ITBA-21-modeladodeobjetos.pdf