DESARROLLO GUIA #4

DIAGRAMAS UML

OSCAR ENRIQUE QUIROGA CONTRERAS

SENA
CENTRO DE MARIALES Y ENSAYOS
PROGRAMACION SOFTWARE

BOGOTÁ
2019
3. FORMULACION DE LAS ACTIVIDADES DE APRENDIZAJE

3.1Actividades de Reflexión inicial

. Cuando se tiene un sistema manual o combinado o sistematizado, se manejan diferentes

herramientas para determinar su funcionamiento, detallar, construir y documentar un
sistema; es decir realizar una descripción gráfica o plano del sistema actual o modelo
propuesto.

El lenguaje modelado (UML), especifica, describe métodos o procesos para detallar el

sistema, documentar y construir; por lo anterior permite visualizar el sistema actual o el
sistema propuesto tomando como base el levantamiento de información y el análisis de
requerimientos, para luego iniciar su desarrollo u optimización.

•¿Considera qué los diagramas, facilitan la resolución de un problema o necesidad

identificando con claridad cada uno de sus actores?

R: si porque podemos resolver un problema, planteando una pregunta inicial, e identificar

exactamente que se necesita para solucionarlo

•¿En el diseño y desarrollo de sistemas de información, aplicar diagramas UML beneficia

el reconocimiento del sistema?
R: Si porque con los diagramas UML podemos diferenciar los esquemas y así ver de una
forma más detallada el diseño y desarrollo en los sistemas de información.

3.2 Actividades de contextualización e identificación de conocimientos necesarios para el

aprendizaje.
Se debe tener claro los términos que intervienen en la POO (programación orientada a
objetos), para modelar el sistema partiendo del levantamiento de información y análisis,
mediante el manejo del Lenguaje Unificado de Modelado (UML).
¿Qué significan los siguientes conceptos?

Clase: En informática, una clase es una plantilla para la creación de objetos de datos según
un modelo predefinido. Las clases se utilizan para representar entidades o conceptos, como
los sustantivos en el lenguaje. Cada clase es un modelo que define un conjunto de variables
-el estado, y métodos apropiados para operar con dichos datos -el comportamiento. Cada
objeto creado a partir de la clase se denomina instancia de la clase.
Invariancia: Un invariante es una condición o propiedad que se mantiene cierta en ciertos
puntos del programa. Se usa sobre todo en la depuración de programas en las últimas fases
de su desarrollo o al modificar código existente (prueba de regresión).
Polimorfismo: el polimorfismo se refiere a la propiedad por la que es posible enviar
mensajes sintácticamente iguales a objetos de tipos distintos. El único requisito que deben
cumplir los objetos que se utilizan de manera polimórfica es saber responder al mensaje que
se les envía.
Método: un método es una subrutina cuyo código es definido en una clase y puede
pertenecer tanto a una clase, como es el caso de los métodos de clase o estáticos, como a un
objeto, como es el caso de los métodos de instancia. Análogamente a los procedimientos en
lenguajes imperativos, un método consiste generalmente de una serie de sentencias para
llevar a cabo una acción, un juego de parámetros de entrada que regularán dicha acción o,
posiblemente, un valor de salida (o valor de retorno) de algún tipo.
Herencia: la herencia es, después de la agregación o composición, el mecanismo más
utilizado para alcanzar algunos de los objetivos más preciados en el desarrollo de software
como lo son la reutilización y la extensibilidad. A través de ella, los diseñadores pueden
crear nuevas clases partiendo de una clase o de una jerarquía de clases preexistente (ya
comprobadas y verificadas) evitando con ello el rediseño, la modificación y verificación de
la parte ya implementada.
Instancia: En los lenguajes de programación orientada a objetos un objeto es una instancia
de una clase. Esto es, un miembro de una clase que tiene atributos en lugar de variables. En
un contexto del mundo real, podríamos pensar en "Casa" como una clase y en un chalet
como una instancia de esta e incluso otro chalet u otro tipo de casa como puede ser un
apartamento como otra instancia.

Atributo: un atributo es una especificación que define una propiedad de un objeto, elemento
o archivo. También puede referirse o establecer el valor específico para una instancia
determinada de los mismos.

Sin embargo, actualmente, el término atributo puede y con frecuencia se considera como si
fuera una propiedad dependiendo de la tecnología que se use.

Para mayor claridad, los atributos deben ser considerados más correctamente como
metadatos. Un atributo es con frecuencia y en general una característica de una propiedad.
3.3Actividades de apropiación del conocimiento (Conceptualización y Teorización).

Actividad 3.3.1

Consultar por medio de un motor de búsqueda como www.google.com o en diferentes

fuentes bibliográficas como sistemas de bibliotecas url (http://biblioteca.sena.edu.co), la
definición, composición y elaboración de los diagramas UML que intervienen en el diseño
del desarrollo de software, además de un ejemplo de cada uno, mediante un informe en un
procesador de texto como Word. Adicionalmente se recomienda consultar el ítem 6
referentes bibliográficos de la guía como material de apoyo para la consulta.

DIAGRAMA DE CLASES

En ingeniería de software, un diagrama de clases en Lenguaje Unificado de Modelado

(UML) es un tipo de diagrama de estructura estática que describe la estructura de un
sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las
relaciones entre los objetos.

UML especifica dos tipos de ámbitos para los miembros: instancias y clasificadores y estos
últimos se representan con nombres subrayados.

 Los miembros clasificadores se denotan comúnmente como “estáticos” en muchos

lenguajes de programación. Su ámbito es la propia clase.
o Los valores de los atributos son los mismos en todas las instancias
o La invocación de métodos no afecta al estado de las instancias
 Los miembros instancias tienen como ámbito una instancia específica.
o Los valores de los atributos pueden variar entre instancias
o La invocación de métodos puede afectar al estado de las instancias(es decir,
cambiar el valor de sus atributos)

Para indicar que un miembro posee un ámbito de clasificador, hay que subrayar su nombre.
De lo contrario, se asume por defecto que tendrá ámbito de instancia.
 DIAGRAMA DE OBJETOS

El Object Management Group, en la especificación UML (versiones 2.1 y anteriores),

definía al diagrama de objetos como:

"Un diagrama de objetos es un gráfico de instancias, incluyendo objetos y datos. Un

diagrama de objetos es una instancia de un diagrama de clases; muestra una 'foto'
del estado de un sistema en un punto de tiempo determinado."

Los diagramas de objeto están ligados a los diagramas de clase y comparten virtualmente
los mismos símbolos para la notación. Los diagramas de objetos pertenecen a la categoría
de diagramas estructurales en UML.

DIAGRAMA DE COMPONENTES
Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado.

Un diagrama de componentes representa cómo un sistema de software es dividido en

componentes y muestra las dependencias entre estos componentes. Los componentes
físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o
paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de
software pero pueden ser usados para modelar y documentar cualquier arquitectura de
sistema.

Debido a que los diagramas de componentes son más parecidos a los diagramas de casos de
usos, éstos son utilizados para modelar la vista estática y dinámica de un sistema. Muestra
la organización y las dependencias entre un conjunto de componentes. No es necesario que
un diagrama incluya todos los componentes del sistema, normalmente se realizan por
partes. Cada diagrama describe un apartado del sistema.

En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del
sistema.

Uno de los usos principales es que puede servir para ver qué componentes pueden
compartirse entre sistemas o entre diferentes partes de un sistema.

DIAGRAMA DE PAQUETES

Un diagrama de paquetes en el Lenguaje Unificado de Modelado representa las

dependencias entre los paquetes que componen un modelo. Es decir, muestra cómo un
sistema está dividido en agrupaciones lógicas y las dependencias entre esas agrupaciones.

Dado que normalmente un paquete está pensado como un directorio, los diagramas de
paquetes suministran una descomposición de la jerarquía lógica de un sistema.

Los paquetes están normalmente organizados para maximizar la coherencia interna dentro
de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas líneas
maestras sobre la mesa, los paquetes son buenos elementos de gestión. Cada paquete puede
asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el
orden de desarrollo requerido.

Elementos básicos

 Paquete: Un mecanismo de propósito general para la organización de elementos y

diagramas de modelo en grupos. Proporciona un espacio de nombres encapsulado
dentro del cual todos los nombres deben ser únicos. Se utiliza para agrupar
elementos relacionados semánticamente. Es un espacio de nombres, así como un
elemento que puede estar contenida en los espacios de nombres de otros paquetes.
Visualmente se representa como una carpeta.

Dependencia: Indica que un elemento de un paquete requiere a otro de un paquete

distinto. Visualmente se representa mediante una flecha discontinua con inicio en el
paquete que depende del otro, es decir, la flecha parte del elemento de origen y
apunta hacia el elemento destino.

 Estereotipos: Existen tres estereotipos de relación de dependencia entre paquetes.

Visualmente un estereotipo de dependencia se representa como el nombre de la
dependencia entre un par de símbolos mayor y un par de símbolos menor (<< >>),
se coloca junto a la flecha que señala la dependencia. <<import>> significa una
importación publica, los elementos importados tienen visibilidad pública dentro del
espacio de nombre del paquete origen o paquete importador, <<access>> significa
una importación privada, se utiliza para indicar la visibilidad privada, y <<merge>>
significa que la fuente de la combinación importa los contenidos importados por el
destino.
 DIAGRAMA DE DESPLIEGUE

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado

que se utiliza para modelar la disposición física de los artefactos software en nodos
(usualmente plataforma de hardware).

Muestra la arquitectura del sistema como el despliegue (la distribución) de los artefactos de
software a los objetivos de despliegue.

Usos

Algunos de los usos que se les da a los diagramas de despliegue son para modelar:

 Sistemas empotrados: Un sistema empotrado es una colección de hardware con una

gran cantidad de software que interactúa con el mundo físico.
 Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del espectro
de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de
red de los clientes a los servidores y sobre la distribución física de los componentes
software del sistema a través de nodos.
 Sistemas completamente distribuidos: En el otro extremo encontramos aquellos
sistemas que son ampliamente o totalmente distribuidos y que normalmente
incluyen varios niveles de servidores. Tales sistemas contienen a menudo varias
versiones de componentes software, alguno de los cuales pueden incluso migrar de
un nodo a otro. El diseño de tales sistemas requiere tomar decisiones que permitan
un cambio continuo de la topología del sistema.
 DIAGRAMA CASOS DE USO

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una forma de

diagrama de comportamiento UML mejorado. El Lenguaje de Modelado Unificado (UML),
define una notación gráfica para representar casos de uso llamada modelo de casos de uso.
UML no define estándares para que el formato escrito describa los casos de uso, y así
mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso;
sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso
o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos
con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son
mucho más detallados que los diagramas de casos de uso. En los conceptos se debe detallar
más de un caso de uso para poder identificar qué es lo que hace un caso de uso.

 La descripción escrita del comportamiento del sistema al afrontar una tarea de

negocio o un requisito de negocio. Esta descripción se enfoca en el valor
suministrado por el sistema a entidades externas tales como usuarios humanos u
otros sistemas.

 La posición o contexto del caso de uso entre otros casos de uso. Dado que es un
mecanismo de organización, un conjunto de casos de uso coherentes y consistentes
promueven una imagen fácil de comprender del comportamiento del sistema, un
entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.

En esta práctica es común crear especificaciones suplementarias para capturar detalles de

requisitos que caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos de
esos temas incluyen restricciones de diseño como: rendimiento, temas de
escalabilidad/gestión, o cumplimiento de estándares.
 DIAGRAMA DE ACTIVIDADES

El diagrama de flujo o flujograma o diagrama de actividades es la representación gráfica de

un algoritmo o proceso. Se utiliza en disciplinas como programación, economía, procesos
industriales y psicología cognitiva.

En Lenguaje Unificado de Modelado (UML), es un diagrama de actividades que representa

los flujos de trabajo paso a paso. Un diagrama de actividades muestra el flujo de control
general.

En SysML el diagrama ha sido extendido para indicar flujos entre pasos que mueven
elementos físicos (p. ej., gasolina) o energía (p. ej., presión). Los cambios adicionales
permiten al diagrama soportar mejor flujos de comportamiento y datos continuos. Estos
diagramas utilizan símbolos con significados definidos que representan los pasos del
algoritmo, y representan el flujo de ejecución mediante flechas que conectan los puntos de
inicio y de fin del proceso.

Tipos de diagramas de actividad

 Formato vertical: en él, el flujo y la secuencia de las operaciones, va de arriba hacia

abajo. Es una lista ordenada de las operaciones de un proceso con toda la
información que se considere necesaria, según su propósito.
 Formato horizontal: en él, el flujo o la secuencia de las operaciones, va de izquierda
a derecha.
 Formato panorámico: el proceso entero está representado en una sola carta y puede
apreciarse de una sola mirada mucho más rápido que leyendo el texto, lo que facilita
su comprensión, aun para personas no familiarizadas. Registra no solo en línea
 vertical, sino también horizontal, distintas acciones simultáneas y la participación de
más de un puesto o departamento que el formato vertical no registra.
 Formato arquitectónico: describe el itinerario de ruta de una forma o persona sobre
el plano arquitectónico del área de trabajo. El primero de los flujogramas es
eminentemente descriptivo, mientras que los utilizados son fundamentalmente
representativos.

DIAGRAMA DE ESTADO

Un equipo de estado, que está vinculado a un clase o caso de uso, es un gráfico de Estados
y transiciones que describe la respuesta de un objeto a estímulos externos.

Un diagrama de estado representa una máquina de estado. Documentación de eventos y

transiciones, un diagrama de estado muestra la secuencia de Estados que pasa un objeto
durante su vida.

Para representar un flujo controlado por acciones generadas internamente en lugar de

eventos externos, utilice un diagrama de actividades.
 DIAGRAMA DE SECUENCIA

El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre

objetos en un sistema según UML.

Utilidad

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una

aplicación a través del tiempo y se modela para cada caso de uso. A menudo es útil para
complementar a un diagrama de clases, pues el diagrama de secuencia se podría describir
de manera informal como "el diagrama de clases en movimiento", por lo que ambos deben
estar relacionados entre sí (mismas clases, métodos, atributos...). Mientras que el diagrama
de casos de uso permite el modelado de una vista business del escenario, el diagrama de
secuencia contiene detalles de implementación del escenario, incluyendo los objetos y
clases que se usan para implementar el escenario y mensajes intercambiados entre los
objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son
necesarios para la implementación del escenario. Si se dispone de la descripción de cada
caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos
pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un
diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas
discontinuas verticales, y los mensajes pasados entre los objetos como flechas

DIAGRAMA DE COLABORACIÓN

Un diagrama de colaboración en las versiones de UML 1.x es esencialmente un diagrama

que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas
de secuencia, los diagramas de colaboración, también llamados diagramas de
comunicación, muestran explícitamente las relaciones de los roles. Por otra parte, un
diagrama de comunicación no muestra el tiempo como una dimensión aparte, por lo que
resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como
los hilos concurrentes.
  Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir
un objetivo común.
 Implementa las asociaciones del diagrama de clases mediante el paso de mensajes
de un objeto a otro. Dicha implementación es llamada "enlace".

Un diagrama de comunicación es también un diagrama de clases que contiene roles de

clasificador y roles de asociación en lugar de sólo clasificadores y asociaciones. Los roles
de clasificador y los de asociación describen la configuración de los objetos y de los
enlaces que pueden ocurrir cuando se ejecuta una instancia de la comunicación. Cuando se
instancia una comunicación, los objetos están ligados a los roles de clasificador y los
enlaces a los roles de asociación. El rol de asociación puede ser desempeñado por varios
tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales
del procedimiento. Los símbolos de enlace pueden llevar estereotipos para indicar enlaces
temporales.

Un uso de un diagrama de colaboración es mostrar la implementación de una operación. La

comunicación muestra los parámetros y las variables locales de la operación, así como
asociaciones más permanentes. Cuando se implementa el comportamiento, la secuencia de
los mensajes corresponde a la estructura de llamadas anidadas y el paso de señales del
programa.

Un diagrama de secuencia muestra secuencias en el tiempo como dimensión geométrica,

pero las relaciones son implícitas. Un diagrama de comunicación muestra relaciones entre
roles geométricamente y relaciona los mensajes con las relaciones, pero las secuencias
temporales están menos claras.

3.3.2 Seleccione un tema de su entorno para aplicar los diagramas UML.

R: Un tema de mi entorno para aplicar los diagramas de UML sería una compra en un
supermercado.

3.3.3 inglés: Realizar un glosario en inglés, donde cada aprendiz incluya los conceptos más
sobresalientes, relacionados con las definiciones que intervienen en los diagramas UML.
Class: In object-oriented programming, a class is an extensible program-code-template for
creating objects, providing initial values for state (member variables) and implementations
of behavior (member functions or methods). In many languages, the class name is used as
the name for the class (the template itself), the name for the default constructor of the class
(a subroutine that creates objects), and as the type of objects generated by instantiating the
class; these distinct concepts are easily conflated.

Invariance:When an object is created by a constructor of the class, the resulting object is

called an instance of the class, and the member variables specific to the object are called
instance variables, to contrast with the class variables shared across the class.

Many programming language type systems support subtyping. Variance refers to how
subtyping between more complex types relates to subtyping between their components. For
instance, if the type Cat is a subtype of Animal, then an expression of type Cat can be used
wherever an expression of type Animal is used. How should a list of Cats relate to a list of
Animals? Or how should a function returning Cat relate to a function returning Animal?
How should a list of Animals contain at the same time an instance of Cat and another of
Fish? Depending on the variance of the type constructor, the subtyping relation of the
simple types may be either preserved, reversed, or ignored for the respective complex
types. In the OCaml programming language, for example, "list of Cat" is a subtype of "list
of Animal" because the list constructor is covariant. This means that the subtyping relation
of the simple types are preserved for the complex types. On the other hand, "function from
Animal to String" is a subtype of "function from Cat to String" because the function type
constructor is contravariant in the argument type. Here the subtyping relation of the simple
types is reversed for the complex types.

Polymorphism: In programming languages and type theory, polymorphism is the provision

of a single interface to entities of different types or the use of a single symbol to represent
multiple different types.

The most commonly recognised major classes of polymorphism are:

 Ad hoc polymorphism: defines a common interface for an arbitrary set of

individually specified types.
 Parametric polymorphism: when one or more types are not specified by name but
by abstract symbols that can represent any type.
 Subtyping (also called subtype polymorphism or inclusion polymorphism): when a
name denotes instances of many different classes related by some common
superclass.

Method: method in object-oriented programming (OOP) is a procedure associated with a

message and an object. An object consists of data and behavior. The data and behavior
comprise an interface, which specifies how the object may be utilized by any of various
consumers of the object.
Data is represented as properties of the object and behaviors are represented as methods of
the object. For example, a Window object could have methods such as open and close,
while its state (whether it is opened or closed at any given point in time) would be a
property.

Instance: In object-oriented programming (OOP), an instance is a concrete occurrence of

any object, existing usually during the runtime of a computer program. Formally,
"instance" is synonymous with "object" as they are each a particular value (realization), and
these may be called an instance object; "instance" emphasizes the distinct identity of the
object. The creation of an instance is called instantiation.

In class-based programming, objects are created from classes by subroutines called

constructors, and destroyed by destructors. An object is an instance of a class, and may be
called a class instance or class object; instantiation is then also known as construction. Not
all classes can be instantiated – abstract classes cannot be instantiated, while classes that
can be instantiated are called concrete classes. In prototype-based programming,
instantiation is instead done by copying (cloning) a prototype instance.

Attribute: In computing, an attribute is a specification that defines a property of an object,

element, or file. It may also refer to or set the specific value for a given instance of such.
For clarity, attributes should more correctly be considered metadata. An attribute is
frequently and generally a property of a property. However, in actual usage, the term
attribute can and is often treated as equivalent to a property depending on the technology
being discussed. An attribute of an object usually consists of a name and a value; of an
element, a type or class name; of a file, a name and extension.

3.3.4 Promover: Con el objetivo de aplicar técnicas para el mejoramiento de su expresión

corporal, desempeño laboral según la naturaleza y complejidad del área ocupacional, los
aprendices dejarán por escrito teniendo en cuenta las normas: Instituto de Ingeniería
Eléctrica y Electrónica (IEEE), las conclusiones grupales, y enfatizarán mediante un foro,
la importancia de los conceptos que intervienen en los diagramas UML.

R: Ya comentaré en el foro profesor porque aún no está habilitado.