0% encontró este documento útil (0 votos)
12 vistas23 páginas

Funcionales

El Lenguaje Unificado de Modelado (UML) es una notación visual para el análisis y desarrollo de software, que permite crear diagramas comprensibles para usuarios y desarrolladores. UML no es un lenguaje de programación, sino un estándar para visualizar y documentar sistemas de software, incluyendo modelos funcionales, de objetos y dinámicos. Entre sus diagramas más comunes se encuentran los de clases, objetos, componentes, secuencias, casos de uso y máquinas de estados, cada uno con elementos y relaciones específicas que ayudan a representar la estructura y comportamiento de un sistema.

Cargado por

ligeri7477
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
12 vistas23 páginas

Funcionales

El Lenguaje Unificado de Modelado (UML) es una notación visual para el análisis y desarrollo de software, que permite crear diagramas comprensibles para usuarios y desarrolladores. UML no es un lenguaje de programación, sino un estándar para visualizar y documentar sistemas de software, incluyendo modelos funcionales, de objetos y dinámicos. Entre sus diagramas más comunes se encuentran los de clases, objetos, componentes, secuencias, casos de uso y máquinas de estados, cada uno con elementos y relaciones específicas que ayudan a representar la estructura y comportamiento de un sistema.

Cargado por

ligeri7477
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd

UML

El lenguaje unificado de modelado (UML), sostiene la idea de que una imagen vale
más que mil palabras. Por ello, nos permite crear y generar diagramas para forjar
un lenguaje visual común en el complejo mundo del análisis y desarrollo de
software. Estos diagramas también son comprensibles para los usuarios y quien
desee entender un sistema.

Es importante aclarar que UML no es un lenguaje de programación, pero existen


herramientas que se pueden usar para generar código en diversos lenguajes
usando los diagramas UML. Además, UML guarda una relación directa con el
análisis y el diseño orientados a objetos.

“No es una metodología, sino una notación para desarrollar modelos (…) UML es
el estándar para visualizar, especificar, construir y documentar los artefactos de un
sistema de software”

Ahora veamos algunos conceptos de modelado especificados por UML. El


desarrollo de sistemas se centra en tres modelos generales de sistemas
diferentes:

1. Funcionales: Se trata de diagramas de casos de uso que describen la


funcionalidad del sistema desde el punto de vista del usuario.

2. De objetos: Se trata de diagramas de clases que describen la estructura


del sistema en términos de objetos, atributos, asociaciones y operaciones.

3. Dinámicos: Los diagramas de interacción, los diagramas de máquina de


estados y los diagramas de actividades se usan para describir el
comportamiento interno del sistema.

Un software que nos permite realizar Diagramas en UML es Lucidchart, y puedes


registrarte en el siguiente link: https://www.lucidchart.com

Más adelante visualizaremos con más detalle todas las características de UML.
Por ahora, vamos a conocer 2 tipos de diagramas para entender la POO (los
Diagramas de Clases, y los Diagramas de Secuencias)
Diagrama de Clases
El diagrama de clases es el diagrama UML más comúnmente usado, y la base
principal de toda solución orientada a objetos. En el se presentan las clases dentro
de un sistema, atributos y operaciones, y la relación entre cada clase. Las clases
se agrupan para crear diagramas de clases al crear diagramas de sistemas
grandes.

Los componentes básicos son:

1. 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.

2. Sección central: Contiene los atributos de la clase. Esta sección se usa


para describir cualidades de la clase.

3. Sección inferior: Incluye operaciones de clases (métodos). Estas se


organizan en un formato de lista y cada operación requiere su propia línea.
Las operaciones describen cómo una clase puede interactuar con los datos.
Todas las clases pueden tener diferente Visibilidad, es decir diferentes niveles de
acceso: Los más comunes son los Privados (-), y Protegidos (#)

Algunas clases pueden ser abstractas, porque en nuestro sistema no se crearía


una instancia de ella. El nombre de una clase abstracta puede colocarse en
Cursiva, o entre: <<nombre>>.

Además, hay diferentes relaciones entre clases:

1. Herencia: Es el proceso en el que una subclase o clase derivada recibe la


funcionalidad de una superclase o clase principal, también se conoce como
"generalización". Se simboliza mediante una línea de conexión recta con
una punta de flecha cerrada que señala a la superclase.

2. Asociación: Es la relación predeterminada entre dos clases. Ambas clases


están conscientes una de la otra y de la relación que tienen entre sí. Esta
asociación se representa mediante una línea recta entre dos clases.
3. Agregación: Relación en donde un objeto derivado puede existir sin su
objeto principal.

4. Composición: Relación en donde un objeto derivado no puede existir sin


su objeto principal.

5. Multiplicidad: Permite definir las relaciones numéricas (por ejemplo, 0..1,


n, 0..*, 1..*, m..n)

Diagrama de objetos
El diagrama de objetos muestra la relación entre objetos por medio de ejemplos
del mundo real e ilustra cómo se verá un sistema en un momento dado.
Representa a un objeto instanciado (creado en tiempo de ejecución) dentro de una
clase, estableciendo valores a los atributos. Dado que los datos están disponibles
dentro de los objetos, estos pueden usarse para clarificar relaciones entre objetos.

Los componentes básicos son:


Objetos: Los objetos son instancias de una clase. Por ejemplo, si "Auto" es una
clase, un 208 compacto de Peugeot es un objeto de una clase.

1. Títulos de clase: Los títulos de clases son los atributos específicos de una
clase dada. Se pueden listar títulos de clases como elementos en el objeto
o incluso en las propiedades del propio objeto (como el color).

2. Atributos: Los atributos de clases se representan por medio de un


rectángulo con dos pestañas que indica un elemento de software.

3. Enlaces: Los enlaces son líneas que conectan dos figuras de un diagrama
de objetos entre sí (debe nombrarse la interacción).

También, al igual que en el diagrama de clases, se puede agregar una tercera


sección donde estén indicados los métodos u operaciones.

"El diagrama de objetos también es conocido como diagrama de instancias"


Diagrama de components
El diagrama de componentes es uno de los principales diagramas UML. Está
clasificado como diagrama de estructura y, como tal, representa de forma estática
el sistema de información. Habitualmente se utiliza después de haber creado el
diagrama de clases, pues necesita información de este diagrama como pueden
ser las propias clases.

Este diagrama proporciona una vista de alto nivel de los componentes dentro de
un sistema. Los componentes pueden ser un componente de software, como una
base de datos o una interfaz de usuario; o un componente de hardware como un
circuito, microchip o dispositivo; o una unidad de negocio como un proveedor,
nómina o envío.

Algunos usos de este tipo de diagrama es el siguiente:

 Se utilizan en desarrollo basado en componentes para describir sistemas


con arquitectura orientada a servicios.
 Mostrar la estructura del propio código.
 Se puede utilizar para centrarse en la relación entre los componentes
mientras se ocultan los detalles de las especificaciones.
 Ayudar a comunicar y explicar las funciones del sistema que se está
construyendo a los interesados o stakeholders.

Elementos del diagrama de componentes


1. Componente

Un componente es un bloque de unidades lógicas del sistema, una abstracción


ligeramente más alta que las clases. Se representa como un rectángulo con un
rectángulo más pequeño en la esquina superior derecha con pestañas o la palabra
escrita encima del nombre del componente para ayudar a distinguirlo de una
clase.

Un componente puede representar dos tipos de elementos: componentes lógicos


(como por ejemplo componentes de negocio o proceso) o
componentes físicos (como
componentes .NET, EJB…). Por ejemplo, en una aplicación
desarrollada en java habrá, con total seguridad,
varios componentes “.java”, que son componentes
lógicos del sistema.
2. Interfaz

La interfaz está siempre asociada a un componente y se utiliza para representar la


zona del módulo que es utilizada para la comunicación con otro de los
componentes.

Se representa con una línea que tiene al final un circulo no relleno:

Otros módulos pueden conectarse a una


interfaz. Esto se hace cuando un componente requiere o utiliza al otro componente
mediante su interfaz, que son las operaciones externas que ofrece el componente.
Se representa con un linea que termina en un semicírculo que rodea la interfaz del
otro componente. En el diagrama se vería de la siguiente manera:
3. Relación de dependencia

La relación de dependencia representa que un componente requiere de otro para


ejecutar su trabajo. Es diferente a la interfaz, pues esta identifica que un
componente ofrece una serie de operaciones. En cualquier caso, en ocasiones
para simplificar el diagrama no se usan las interfaces sino que solamente se
utilizan relaciones de dependencia.

Una relación de dependencia se representa mediante una flecha discontinua que


va desde el componente que requiere de otro componente hasta el requerido.

Diagrama de componentes de una tienda online


Diagrama de secuencias
El diagrama de secuencia es un esquema conceptual que permite representar el
comportamiento de un sistema. Muestra cómo los objetos interactúan entre sí y el
orden de la ocurrencia. Representan interacciones para un escenario concreto.

El diagrama de secuencia describe básicamente cómo los objetos (e instancias)


intercambian mensajes en un orden determinado. Los objetos son los bloques de
construcción básicos de los diagramas UML y representan ciertas características
de un elemento del sistema, que varían dependiendo del diagrama. En las
interacciones, los objetos son las conocidas como líneas de vida.

Los diagramas de secuencia UML también son útiles cuando es necesario


representar gráficamente operaciones complicadas para su mejor comprensión.
Gracias a un modelado claro es posible identificar rápidamente las estaciones por
las que debe pasar una única tarea para que se complete con éxito. Así, por
ejemplo, es posible planificar y probar distintos métodos antes de implementarlos
en el negocio diario o en un sistema informático

Elementos del diagrama de secuencia


1. 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.

2. Activación

Los cuadros de activación representan el tiempo que un objeto necesita para


completar una tarea.

3. Líneas de vida

Una línea de vida representa el curso del tiempo de un proceso. A la cabeza se


sitúa un rectángulo que contiene normalmente el nombre del objeto y el nombre de
la clase. Si falta el nombre del objeto, la línea de vida representa a una instancia
de objeto sin nombre. En este caso, se puede suponer que todos los objetos de la
misma clase actúan de la misma forma en esta secuencia. La línea de vida
siempre representa un solo operando. Si el operando tiene varios valores, se debe
seleccionar uno de ellos, es decir, la multiplicidad nunca es >1.

La línea discontinua situada bajo el encabezamiento representa el transcurso del


tiempo. El tiempo tiene un desarrollo lineal descendente. A lo largo de la línea
temporal se envían los mensajes y las respuestas. Un mensaje que haya de
enviarse tras otro se sitúa más abajo en la línea de tiempo. En esta notación no se
trata de puntos concretos en el tiempo, sino siempre de una secuencia. Los
mensajes siempre están dispuestos uno debajo de otro, a menos que existan en
fragmentos combinados de forma paralela.

Las líneas de vida indican cuánto tiempo participa activamente un objeto en un


proceso, lo que se puede ver por la longitud de una línea en comparación con
otras. Algunos objetos se destruyen antes de que el proceso haya terminado.
Cuando ya no se necesita un objeto, se indica con una X el punto en la línea de
vida en el que se ha de destruir.

Si quieres comprobar la robustez de tu sistema, el diagrama de secuencia es muy


adecuado pues muestra una vista muy detallada. Se pueden utilizar tres
estereotipos de clase de la línea de la vida:

 Entidad
 Límite
 Control
En la imagen de arriba se pueden ver estas tres líneas de vida con la notación: la
entidad tiene una cabeza circular que se sitúa sobre una línea horizontal. El
estereotipo de línea de vida denominado límite consta de una cabeza de la misma
forma de la que sale una línea horizontal que conecta con otra vertical: a modo de
T rotada noventa grados a la izquierda. La cabeza del estereotipo de control está
compuesta por una flecha que gira en círculo. De todos estos estereotipos sale
una línea de vida discontinua, que desciende en vertical.

Los límites (boundaries) representan interfaces que interactúan con actores


externos. Estos objetos pueden ser, por ejemplo, interfaces de usuario, en cuyo
caso el actor correspondería a una persona. Las entidades (entities), por otro lado,
son contenedores de datos, o sea, objetos que contienen datos del sistema. Para
que los límites y las entidades se comuniquen, se necesita un elemento de control.
El control no tiene que ser necesariamente un objeto; también funciona un método
que se asigna a uno de los otros dos elementos. Se trata del medidador que
conecta entidad y límite, monitoriza las señales de los dos elementos y comprueba
su lógica.

Los tres estereotipos se comunican siguiendo estas cuatro reglas:

 Los objetos de límite son, como interfaces, responsables de la


comunicación con los actores. De este modo, los actores se comunican
exclusivamente con las fronteras.
 Por el contrario, los objetos de control se comunican con otros objetos de
control, así como con entidades y límites. Pero no interactúan con los
actores.
 Los límites se comunican con los objetos de control y con los actores.
 Las entidades son los soportes de datos más arraigados en el sistema. Solo
intercambian datos con objetos de control.

4. Mensajes

El mensaje es un elemento básico del diagrama de secuencia. En la programación


orientada a objetos, un sistema se compone de objetos. UML presenta estos
objetos como nodos unidos entre sí por los elementos de conexión, que en UML
pueden realizar varias tareas. Concretamente, en el diagrama de secuencia UML
se encargan de modelar los mensajes de metaclase. Como forma básica del
elemento de conexión la notación establece una línea. Las flechas son una forma
especial de elemento de conexión que representan una relación direccional o flujo
de información. En el diagrama de secuencia simbolizan a los mensajes.

5. Destrucción de objetos

Los objetos pueden ser eliminados tempranamente usando una flecha etiquetada
«<<destruir>>» que apunta a una X.
Ejemplo de un diagrama de secuencia

Diagrama de casos de uso


Un caso de uso es una descripción de las acciones de un sistema desde el punto
de vista del usuario. Es una herramienta valiosa dado que es una técnica de
aciertos y errores para obtener los requerimientos del sistema, justamente desde
el punto de vista del usuario.

Los diagramas de caso de uso modelan la funcionalidad del sistema usando


actores y casos de uso. Los casos de uso son servicios o funciones provistas por
el sistema para sus usuarios.

Elemento del diagrama de casos de uso


1. Sistema

El rectángulo representa los límites del sistema que contiene los casos de uso.
Los actores se ubican fuera de los límites del Sistema
2. Casos de uso

Se representan con óvalos. La etiqueta en el óvalo indica la función del sistema

3. Actores

Un diagrama de caso de uso contiene los símbolos del actor y del caso de uso,
junto con líneas conectoras. Los actores son similares a las entidades externas;
existen fuera del sistema. El término actor se refiere a un rol específico de un
usuario del sistema.
4. Relaciones

Las relaciones entre un actor y un caso de uso, se dibujan con una línea
simple. Para relaciones entre casos de uso, se utilizan flechas etiquetadas
«incluir» o «extender.» Una relación «incluir» indica que un caso de uso es
necesitado por otro para poder cumplir una tarea. Una relación «extender»
indica opciones alternativas para un cierto caso de uso.

Ejemplo de un diagrama de caso de uso


Diagrama de máquina de estados
Un diagrama de estado UML (también llamado diagrama de estado, diagrama de
transición de estados o diagrama de máquina de estados) muestra los estados por
los que pasa una máquina de estados finitos, es decir, un modelo de
comportamiento que consiste en acciones y estados o transiciones a otros
estados. El diagrama proporciona un estado inicial y uno final, así como al menos
un estado intermedio para cada objeto. El diagrama de estado permite, de este
modo, representar el ciclo de vida completo de cualquier sistema, subsistema o
componentes o clases del mismo, como podrían ser una máquina de café, un
lector de libros electrónicos o un componente tecnológico de un vehículo.

Entre otras cosas, esta representación gráfica de los procesos debería dar
respuesta a las siguientes preguntas:

 ¿Qué sucede cuando el objeto está en un estado concreto?


 ¿En qué estado debe estar el objeto para cambiar de comportamiento?
 ¿Cuáles son los desencadenantes?
 ¿Qué propiedades debe tener el objeto para poder cambiar de estado?

Por lo tanto, los diagramas de estado UML se utilizan para optimizar cualquier
proceso de desarrollo donde sea útil visualizar los estados del objeto y las
condiciones para que se produzca la transición de un estado a otro. Suelen
emplearse, por ejemplo, en el diseño de sistemas embebidos (en inglés,
embedded systems), donde las señales automatizadas y los procesos en segundo
plano deben estar perfectamente coordinados. En este caso, el diagrama de
estado ayuda a los desarrolladores a visualizar todas las funciones de control y
regulación más importantes en un solo esquema.

La función de interrupción de la toma de agua que tienen casi todas las lavadoras
puede servirnos de ejemplo para imaginar un diagrama de estado UML. En este
contexto, esta función se representaría como un sistema independiente. En este
caso, el esquema mostraría en qué estado y bajo qué condiciones se activa la
función.

Elementos del diagrama de máquina de estados


1. Estados

Los estados son el componente principal de un diagrama de estado. Cada estado


real se muestra siempre en un rectángulo de esquinas redondeadas. Por ejemplo,
una puerta puede tener dos valores de estado

Asimismo, en el diagrama de estado de la puerta se indicaría que siempre debe


cumplirse la siguiente condición:

 El objeto siempre se encuentra en uno de los dos estados: la puerta está


abierta o cerrada, pero nunca abierta y cerrada al mismo tiempo.
2. Transacciones
La transición que figura en el siguiente ejemplo se considera externa y tiene como
resultado que el objeto cambie de estado (entry/exit).

Ejemplo: después de que se active la alarma de una radio-despertador, el estado


cambia de “alarma activada” a “alarma desactivada”.

Ejemplo diagrama máquina de estados

Diagrama de actividad
Los diagramas de actividad son uno de los cinco diagramas en el UML para
modelar los aspectos dinámicos de un sistema. Un diagrama de actividad es un
caso especial de un diagrama de estado, en el cual casi todos los estados son
estados de acción (identifican qué acción se ejecuta al estar en él) y casi todas las
transiciones son enviadas al terminar la acción ejecutada en el estado anterior.
Este diagrama es el menos familiar y se utiliza poco en UML.

Los diagramas de actividad pueden visualizar, especificar y documentar la


dinámica de un conjunto de objetos. También se pueden usar para modelar el flujo
de control de una operación. Mientras que los diagramas de interacción enfatizan
el flujo de control de un objeto a otro, los diagramas de actividad subrayan el flujo
de control de una actividad a otra. La gran desventaja de los diagramas de
actividad es que no indican de forma explícita qué objetos ejecutan qué
actividades ni tampoco la forma en que el servicio de mensajería trabaja entre
ellos.

Para mostrar tales interacciones de forma clara son necesarios los diagramas de
interacción, los cuales son más utilizados en la práctica.

 Los diagramas de actividad son útiles cuando queremos describir un


comportamiento paralelo, o cuando queremos mostrar qué
comportamientos interactúan en varios casos de uso
 Los diagramas de interacción se utilizan cuando se quiere mostrar cómo
colaboran los objetos para implementar un diagrama de actividad.
 Los diagramas de estado se utilizan cuando se quiere mostrar cómo
cambia un objeto a lo largo de su tiempo de vida.lementos de un diagrama
de actividad

Elementos de un diagrama de actividad


Ejemplo de un diagrama de actividad

También podría gustarte