Universidad Nacional de Ingeniería

facultad de Electrotecnia y Computación

Recinto Universitario “Simón Bolívar”

Administración de Sistemas Informáticos

Profesora: Grupo: #01

Magda Luna.

Integrantes:

Gómez Pérez Danissa Scarlet 2007-21331

Silva Flores Orlando José 2007-22457

¿Que es UML?

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en

inglés, Unified Modeling Language) es el lenguaje de modelado de

sistemas de software más conocido y utilizado en la actualidad; está

respaldado por el OMG (Grupo de Gestión de Objetos). Es un lenguaje

gráfico para visualizar, especificar, construir y documentar un sistema.

Continuación…

UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Objetivos del UML establecido por los

diseñadores:

1

• Modelar sistemas (y no solo software) utilizando conceptos orientados a objetos.

2

• Establecer un acoplamiento explícito tanto a los artefactos conceptuales como los ejecutables.

3

• Resolver los problemas de escala inherente en sistemas complejos de misión crítica.

4

• Crear un lenguaje de modelaje utilizable por los humanos y las máquinas.

Las metas primarias en el diseño del UML fueron:

Proporcionar a los usuarios un lenguaje de modelaje visual listo para usarse y expresivo de tal forma que permita desarrollar e intercambiar modelos con significado.

Proporcionar mecanismos de extensibilidad y especialización para extender los conceptos centrales.

Ser independiente de lenguajes de programación particulares y procesos de desarrollo.

Metas del UML

Proporcionar una base formal para entender el lenguaje de modelaje.

Incentivar el crecimiento del mercado de herramientas orientadas a objetos.

Soportar conceptos de desarrollo de más alto nivel tales como colaboraciones, estructuras, patrones y componentes.

Integrar las mejores prácticas en la industria.

Metas del UML – Continuación…

El UML es utilizado para modelar sistemas, cuyo rango es muy

amplio: muchos tipos diferentes de sistemas entre ellos:

Uso del UML

Sistemas de Información: Manejan grandes cantidades de datos con relaciones complejas, los cuales son almacenados en bases de datos relacionales o de objetos.

Sistemas Técnicos: Mantienen y controlan equipo técnico tal como procesos de telecomunicaciones, procesos de sistemas militares o procesos industriales.

Sistemas de Tiempo Real Empotrados: Se ejecutan en un hardware simple empotrado en cualquier otro equipo tal como un teléfono móvil, un carro, un utensilio del hogar, etc.

Sistemas Distribuidos: Distribuidos en una serie de máquinas donde los datos son transferidos fácilmente de una máquina a otra.

Software de Sistemas: Definen la infraestructura técnica que utiliza otro software.

Sistemas de Negocios: Describen los objetivos, los recursos (humanos, computadoras, etc.), las reglas (leyes, estrategias del negocio, políticas, etc.), y el trabajo actual en el negocio (procesos del negocio).

El UML puede ser utilizado también en las diferentes fases del

desarrollo de un sistema, desde la especificación de los requerimientos

hasta la prueba del sistema terminado.

El objetivo del UML es describir cualquier tipo de sistema, en

términos de diagramas orientados a objetos. Naturalmente, el uso más

común es crear modelos de sistemas de software, pero el UML también

es utilizado para describir sistemas mecánicos sin ningún software o la

organización de un negocio.

Uso del UML – Continuación…

Partes del UML

• Las vistas muestran diferentes aspectos de los sistemas que son modelados. Una vista no es un gráfico, pero es una abstracción que consiste en una serie de diagramas.

Vistas:

• Son los gráficos que describen los contenidos en una vista. El UML tiene nueve tipos diferentes de diagramas que son utilizados en combinación para proporcionar todas las vistas del sistema.

Diagramas:

• Los conceptos utilizados en los diagramas son los elementos del modelo los cuales representan conceptos orientados a objetos comunes, tales como clases, objetos, mensajes, y las relaciones entre estos conceptos incluyendo asociación, dependencia y generalización.

Elementos del modelo:

• Los mecanismos generales proporcionan comentarios extras, información, o semántica acerca de un elemento del modelo; ellos proporcionan también mecanismos de extensión para adaptar o extender el UML a un método, proceso, organización o usuario específico.

Mecanismos Generales:

1

• Divide cada proyecto en un número de diagramas que representan las distintas vistas del proyecto y juntos representan la arquitectura del mismo

2

• Permite describir un sistema en diferentes niveles de abstracción

3

• Se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los componentes del desarrollo de una aplicación, sin definir un modelo de desarrollo.

Características del UML

Diseño y documentación.

Código reutilizable.

Descubrimiento de tallas.

Ahorro de tiempo en el desarrollo del software.

Mucho más fáciles las modificaciones.

Más fácil comunicación entre programadores.

Ventajas

UML no es una metodología es una notación

No es un lenguaje de programación, se complementan.

No pretende sustituir al XML

Desventajas

Ventajas y Desventajas de UML

Objeto

Un objeto es una representación de una entidad, ya sea del

mundo real o conceptual. Un objeto puede representar algo

concreto. Podría ser parte de cualquier tipo de sistema, por

ejemplo, una máquina, una organización, o un negocio.

Un objeto es un concepto, abstracción, o cosa con fronteras y

significado bien definidos para una aplicación. Cada objeto en un

sistema tiene tres características: estado, comportamiento e

identidad.

¿Que es Objeto?

El estado de un objeto es una de las posibles condiciones en la

cual puede existir. El estado de un objeto típicamente cambia en el

tiempo, y es definido por los valores de un conjunto de

propiedades (llamadas atributos) más las relaciones que pueda

tener con otros objetos.

Por ejemplo, un Grupo puede estar abierto o cerrado. Si el número

de grupos registrados para el curso pasa de un límite

predeterminado, el Grupo se cierra.

Características de un Objeto

El comportamiento determina cómo un objeto responde a

peticiones de otros objetos, y tipifica todo lo que el objeto puede

hacer. El comportamiento es implementado por un conjunto de

operaciones para el objeto.

Por ejemplo, un Grupo podría tener las operaciones Añadir un

estudiante y Eliminar un estudiante.

Características de un Objeto

La identidad significa que cada objeto es único – aún si su estado

es idéntico al de otro objeto.

Por ejemplo, Matemáticas I – A1 y Matemáticas I – A2 son dos

objetos Grupo del mismo Curso pero tienen una identidad única.

Características de un Objeto

En el UML, los objetos son representados como rectángulos,

y el nombre del objeto es subrayado como se muestra a

continuación.

Notación del UML para un Objeto

Representación de los objetos en UML

Algebra 101, Sección1

Los objetos por referencia son cosas como Cliente. Aquí, la identidad es

muy importante, porque usualmente se desea que solamente un objeto de

software represente a un cliente del mundo real.

Cualquier objeto que haga referencia a un objeto cliente lo hará a través de

una; todos los objetos que hagan referencia a este cliente harán referencia al

mismo objeto. De esa forma, los cambios al cliente están disponibles a

todos los usuarios del cliente.

Si tiene dos referencias a un cliente y desea ver si son el mismo,

usualmente compara sus identidades.

Las copias pueden no ser permitidas y si lo son se hacen raramente, tal vez

para propósitos de respaldos o replicación a través de una red. Si se hacen

copias se tiene que buscar una forma de sincronizar los cambios.

Objeto por Referencia

Los objetos por valor son cosas como Fecha. A menudo se tienen

múltiples objetos que representan el mismo objeto del mundo real. Por

ejemplo, es normal tener cientos de objetos que designan 1-Ene-99.

Estas son todas copias intercambiables. Nuevas fechas son creadas y

destruidas frecuentemente.

Si tiene dos fechas y desea ver si son la misma, no se miran sus

identidades – se miran los valores que representan. Esto significa

usualmente que tienen que escribir un operador de igualdad, el cual

para las fechas haría una prueba en el año, mes, y día. Usualmente el

objeto que referencia 1-Ene-99 tiene su objeto dedicado, pero a veces

se tienen fechas compartidas.

Objetos por Valor

Los objetos por valor deben ser inmutables. En otras palabras, no debe

ser capaz de tomar un objeto fecha 1-Ene-99 y cambiarlo a 2-Ene-99.

Lo que se tiene que hacer es crear un objeto nuevo 2-Ene-99 y enlazarlo

al primer objeto. La razón para esto es que si la fecha fuera compartida,

actualizaría la fecha de otro objeto en una forma impredecible. Como

una regla general, no cambie los objetos por valor.

Dentro del UML, los atributos son usualmente usados para objetos por

valor y las asociaciones para objetos por referencia. También puede usar

composición para objetos por valor.

Objetos por Valor - Continuación

Clase

Una clase es una descripción de un grupo de objetos con propiedades

(atributos), comportamiento (operaciones), relaciones a otros objetos, y

semántica comunes. Por lo tanto, una clase es una plantilla para crear

objetos. Cada objeto es una instancia de una clase y por lo tanto, tiene

un valor para los atributos y acceso a las operaciones especificadas por

la clase.

Los objetos se relacionan con la clase similarmente a la relación entre

una variable y un tipo de datos en un lenguaje de programación

ordinario.

Las clases son usadas para describir sistemas y clasificar los objetos

que identificamos en el mundo real.

¿Que es una Clase?

Una buena clase captura una y solo una abstracción – debería

tener un tema principal.

Por ejemplo, una clase que tiene la capacidad de mantener

información sobre dos entidades no es una buena clase, pues no

tiene un tema principal; esta clase debe ser dividida en dos clases

relacionadas.

Cuando modelamos y construimos sistemas de negocio, sistemas

de información, máquinas u otros sistemas, las clases deben ser

nombradas usando el vocabulario del dominio para hacer los

modelos entendibles y fáciles de comunicar.

¿Que es una Clase? - Continuación

El nombre de la clase debe ser un nombre singular que caracterice de

la mejor forma la abstracción. Se pueden usar acrónimos a menos que

el acrónimo tenga diferente significado para diferentes personas, en

cuyo caso el nombre completo debe ser usado. Si una clase es

nombrada con un acrónimo, el nombre completo debe ser contenido

en la documentación de la clase.

Una clase podría ser una descripción de un objeto en cualquier tipo

de sistema:

¿Que es una Clase? - Continuación

Sistema de Información Sistema Distribuido

Sistema Técnico Sistema de Software

Sistema de Tiempo real

empotrado

Sistema de Negocio

Los artificios en un negocio, es decir, información que debería ser

almacenada o analizada y los roles que juegan los actores en el negocio

a menudo se transforman en clases en los sistemas de información y de

negocios.

Ejemplos de clases en sistemas de información y de negocios son:

cliente, acuerdo, factura, débito, activo.

Las clases en los sistemas técnicos a menudo involucran objetos

técnicos como los dispositivos usados en los sistemas.

Ejemplos de clases en los sistemas técnicos son: sensor, pantalla,

tarjeta de entrada/salida, máquina, botón, clase de control.

Tipos de sistemas

Los sistemas de software tienen clases que representan entidades de

software en un sistema operativo.

Ejemplos de clases en un sistema de software son: archivo,

programa ejecutable, dispositivo, icono, ventana, barra de

desplazamiento.

Tipos de sistemas - Continuación

En el UML las clases son representadas como rectángulos con

compartimentos. El compartimento superior contiene el nombre de la

clase en negrillas, el compartimento medio contiene la estructura de la

clase (atributos), y el compartimento inferior contiene el comportamiento

de la clase (operaciones). La sintaxis usada para los compartimentos es

independiente de los lenguajes de programación.

Una clase se muestra a continuación.

Representación de las clases en UML

Nombre

Atributos

Operaciones

Las clases pueden tener estereotipos. Un estereotipo proporciona la

capacidad de crear un nuevo tipo de elemento de modelaje, es decir

nuevos tipos de clases.

Algunos estereotipos comunes para las clases son entity (entidad),

boundary (frontera), control, utility (utilidad) y exception (excepción).

La esencia del estereotipo es que sugiere cierta responsabilidad para

una clase.

El estereotipo para una clase es mostrado arriba del nombre de la

clase entre guillemets (<< >>). Si se desea, un icono gráfico o un color

específico puede ser asociado con un estereotipo.

Clases y Estereotipos

Por ejemplo, todas las clases con el estereotipo <<Exception>>

(excepción) pueden ser mostradas en rojo.

Una clase con estereotipo es mostrada en la siguiente figura.

Clases y Estereotipos - Continuación

<<Entity>>

Estudiante

Clase con un Estereotipo

El Proceso Unificado recomienda encontrar las clases para un sistema

de bajo desarrollo, buscando las clases de entidad (entity), frontera

(boundary) y control. Estos tres estereotipos conforman un punto de

vista modelo-vista-controlador y permiten al analista particionar el

sistema separando el dominio, la vista y el control necesitados por el

sistema.

Debido a que el proceso de análisis y diseño es repetido, la lista de

clases cambiará a medida que pasa el tiempo.

Identificación de las Clases

¿Hay información que debe ser almacenada o analizada?

Si hay cualquier tipo de información que tiene que ser almacenada,

transformada, analizada, o manejada de cualquier otra forma, entonces es

un posible candidato para una clase.

La información podrían ser conceptos que deben estar siempre

registrados en el sistema, eventos o transacciones que ocurran en un

momento específico.

¿Hay sistemas externos?

Si es así, son de interés cuando modelamos. El sistema externo podría

ser visto como clases que nuestro sistema contiene o con las que debería

interactuar.

¿Hay patrones, librerías de clase, componentes, etc.?

Si tenemos algunos de ellos de proyectos anteriores, colegas, o

fabricantes, normalmente contienen clases candidatas.

¿Hay dispositivos que el sistema debe manejar?

Cualquier dispositivo técnico conectado al sistema se convierte en clases,

especialmente en modelos de negocio.

¿Qué roles juegan los actores en el negocio?

Estos roles pueden ser vistos como clases; por ejemplo, usuario,

operador del sistema, cliente, etc.

Si se tiene una especificación de requerimientos o análisis de negocio,

éste debe ser usado como base para encontrar clases.

1 Clases de Entidad

2 Clases de Frontera

3 Clases de Control

Tipos de Clase

Encapsulamiento

El encapsulamiento significa que toda esta información se encuentra

empaquetada.

Al empaquetamiento de las variables de un objeto con la protección

de sus métodos se le llama encapsulamiento.

Típicamente, el encapsulamiento es utilizado para esconder detalles,

de la puesta en práctica no importantes de otros objetos. Entonces, los

detalles de la puesta en práctica, pueden cambiar en cualquier tiempo

sin afectar otras partes del programa.

Encapsulamiento - Definición

El encapsulamiento de variables y métodos en un componente de

software ordenado es, todavía, una simple idea poderosa que provee

dos principales beneficios a los desarrolladores de software:

Encapsulamiento - Continuación

Modularidad

•Esto es, el código fuente de un objeto puede ser escrito, así como darle mantenimiento, independientemente del código fuente de otros objetos. Así mismo, un objeto puede ser transferido alrededor del sistema sin alterar su estado y conducta.

Ocultamiento de la información

•Es decir, un objeto tiene una "interfaz publica" que otros objetos pueden utilizar para comunicarse con él. Pero el objeto puede mantener información y métodos privados que pueden ser cambiados en cualquier tiempo sin afectar a los otros objetos que dependan de ello.

Abstracción

La abstracción en programación es la forma mas general de ver un

objeto, sin meternos en su composición interior o en otros

componentes.

Por ejemplo la TV, la abstracción de la TV es un aparato que sirve

para el entretenimiento, nos interesa los circuitos, los chips y demás

cosas que esta integrada por dentro.

Abstracción - Definición

Herencia

El Caso de Uso origen hereda la especificación del Caso

de Uso destino y posiblemente la modifica y/o amplía.

Herencia

Polimorfismo

El término polimorfismo se refiere a que una Característica de una

clase puede tomar varias formas.

El polimorfismo representa en nuestro caso la posibilidad de

desencadenar operaciones distintas en respuesta a un mismo mensaje.

Cada subclase hereda las operaciones pero tiene la posibilidad de

modificar localmente el comportamiento de estas operaciones.

Polimorfismo

Ejemplo: todo animal duerme, pero cada clase lo hace de forma

distinta.

Polimorfismo - Continuación

La búsqueda automática del código que en cada momento se va a

ejecutar es fruto del enlace dinámico.

El cumplimiento del Principio de Sustitución permite obtener un

comportamiento y diseño coherente.

Polimorfismo - Continuación

Vista de Casos de Uso: Es una vista que muestra la

funcionalidad de un sistema como es percibida por los actores

externos.

Vista Lógica: Es una vista que muestra como es diseñada la

funcionalidad dentro del sistema, en términos de las estructuras

estáticas del sistema y su comportamiento dinámico.

Vista de Componentes: Es una vista que muestra la

organización de los componentes de código.

Vistas

Vista de Procesos: Es una vista que muestra la concurrencia en

el sistema, resolviendo problemas de comunicación y

sincronización que estén presentes en un sistema concurrente.

Vista de Despliegue: Es una vista que muestra el despliegue de

un sistema dentro de una arquitectura física con computadoras y

dispositivos llamados nodos.

Vistas – Continuación…

Vista de Diseño

*Diagrama de clases

*Diagrama de Actividades

*Diagrama de Estados

*Diagrama de Objetos

*Diagrama de Secuencia

Vista de Implementación

*Diagrama de Estructura Compuesta

*Diagrama de Componentes

*Diagrama de Paquetes

*Diagrama de Clases

Vista de Interacción

*Diagrama de Secuencia

*Diagrama de Comunicación

Diagrama de Tiempos

Vista de Despliegue

*Diagrama de Despliegue

*Diagrama de Paquetes

Vista de Casos de Uso

*Diagrama de Casos de Uso

*Diagrama de Secuencia

*Diagrama de Actividad

Arquitectura de un Sistema de Software(UML)

Vocabulario

Funcionalidad

Ensamblado del Sistema

Gestión de la Configuración

Comportamiento

Rendimiento

Escalabidad

Capacidad de

Procesamiento

Topología del Sistema

Distribución

Entrega

Instalación

Diagramas

Un diagrama de casos de uso es una vista gráfica de algunos o todos

los actores, casos de uso y sus interacciones, identificados para un

sistema. Cada sistema típicamente tiene un diagrama de Caso de Uso

Principal, el cual es la imagen de las fronteras del sistema (actores) y la

funcionalidad principal proporcionada por el sistema (casos de uso).

Otros diagramas de caso de uso pueden ser creados cuando sea

necesario. Algunos ejemplos son:

Un diagrama que muestre todos los casos de uso para un actor

determinado.

Un diagrama que muestre todos los casos de uso

implementados en una iteración.

Un diagrama que muestre un caso de uso y sus relaciones.

Diagramas de Casos de uso

Un diagrama de clases es un tipo de modelo estático. Un diagrama de

clases describe la vista estática del sistema. Un propósito de los diagramas

de clases es definir una base para otros diagramas donde otros aspectos del

sistema son mostrados (tales como los estados de los objetos o la

colaboración entre ellos mostrados en los diagramas dinámicos).

El diagrama de clases principal en la vista lógica del modelo es

típicamente una imagen de los paquetes del sistema. Cada paquete también

tiene su diagrama de clases principal, que típicamente despliega las clases

públicas del paquete. Otros diagramas se crean según sea necesario.

Algunos usos típicos de otros diagramas son:

Vista de todas las clases de implementación en un paquete.

Vista de la estructura y comportamiento de una o más clases.

Vista de una jerarquía de herencia.

Diagramas de Clases

Un diagrama de objetos es una variante del diagrama de clases y utiliza

casi la misma notación. La diferencia entre los dos es que el diagrama

de objetos muestra una serie de objetos (instancias de las clases), en vez

de las clases actuales.

Los diagramas de objetos no son tan importantes como los diagramas

de clases, pero pueden ser utilizados para ejemplificar un diagrama de

clases complejo mostrando cómo se verían las instancias actuales y las

relaciones. Los diagramas de objetos son también utilizados como parte

de los diagramas de colaboración, en los cuales es mostrada la

colaboración dinámica entre los objetos.

Diagramas de Objetos

Un diagrama de estados es típicamente un complemento de la descripción

de una clase. Muestra todos los estados posibles que los objetos de la clase

puedan tener, y qué eventos causan un cambio de estado.

Los diagramas de estados no son dibujados para todas las clases,

solamente para aquellas que tienen una serie de estados bien definidos y

en donde el comportamiento de la clase es afectado y cambiado por los

estados diferentes. Los diagramas de estados pueden también ser

dibujados para el sistema en su totalidad.

Diagramas de Estados

Un diagrama de secuencia muestra una colaboración dinámica

entre una serie de objetos. El aspecto importante de este

diagrama es mostrar una secuencia de mensajes enviados entre

los objetos.

Los diagramas consisten en una serie de objetos mostrados con

líneas verticales. El tiempo pasa descendentemente en el

diagrama, y el diagrama muestra el intercambio de mensajes

entre los objetos a medida que pasa el tiempo en la secuencia o

función.

Diagramas de Secuencia

Un diagrama de colaboración muestra una colaboración dinámica,

como el diagrama de secuencia. Además de mostrar el intercambio de

mensajes (llamado interacción), el diagrama de colaboración muestra

los objetos y sus relaciones (a veces referidos como el contexto).

El diagrama de colaboración es dibujado como un diagrama de

objetos, donde una serie de objetos son mostrados junto con sus

relaciones (utilizando la notación en el diagrama de clases o de

objetos). Las flechas de mensajes son dibujadas entre los objetos para

mostrar el flujo de mensajes entre los objetos.

Un diagrama de colaboración puede también contener objetos activos

que se ejecutan concurrentemente con otros objetos activos.

Diagramas de Colaboración

Un diagrama de actividades muestra el flujo secuencial de las

actividades, es utilizado típicamente para describir las actividades

realizadas en una operación, aunque puede ser también utilizado

para describir otros diagramas, tal como un caso de uso o de

interacción.

El diagrama de actividades consiste de estados de acción, los cuales

contienen una especificación de la actividad que va a ser realizada

(una acción). Un estado de acción termina cuando ha sido realizada

la acción (un estado en un diagrama de estados necesita un evento

explícito aún antes que deje el estado).

Diagramas de Actividades

Un diagrama de componentes muestra la estructura física del

código en términos de los componentes de código. Un componente

puede ser un componente de código fuente, un componente binario,

o un componente ejecutable.

Los componentes pueden ser mostrados también con cualquiera de

las interfaces que exponen, y pueden ser agrupados en paquetes. El

diagrama de componentes es utilizado en trabajos prácticos de

programación.

Diagramas de Componentes

El diagrama de despliegue muestra la arquitectura física del

hardware y el software en el sistema. Se pueden mostrar las

computadoras y los dispositivos (nodos), junto con las conexiones

que tienen unos con otros; también se puede mostrar el tipo de

conexión.

El diagrama de despliegue muestra la vista de despliegue la cual

describe la arquitectura física actual del sistema.

Diagramas de Despliegue

Los conceptos utilizados en los diagramas son llamados elementos del

modelo. Un elemento del modelo es definido con una semántica, una

definición formal del elemento o el significado exacto de lo que

representa en un enunciado no ambiguo.

Un elemento del modelo también tiene un elemento de vista

correspondiente, el cual es una representación gráfica del elemento o el

símbolo gráfico utilizado para representar al elemento en los diagramas.

Un elemento puede existir en varios tipos diferentes de diagramas, pero

hay reglas para las cuales los elementos pueden ser mostrados en cada

tipo de diagrama

Elementos del Modelo

En la siguiente figura se muestran algunos ejemplos de elementos del

modelo tales como clase, objeto, estado, entre otros

Elementos del Modelo - Continuación

El UML utiliza algunos mecanismos generales en todos los

diagramas, para añadir información adicional en los mismos, lo cual

típicamente no puede ser representado utilizando las habilidades

básicas de los elementos del modelo.

Adornos

Los adornos gráficos pueden ser incorporados a los elementos del

modelo en los diagramas. Los adornos agregan semántica al elemento.

Un ejemplo de adorno es la técnica utilizada para separar un tipo de

una instancia. Cuando un elemento representa un tipo, su nombre es

mostrado en negrillas.

Mecanismos Generales

Notas:

No todo puede ser definido en un lenguaje de modelaje, no importa

cuán extenso sea el lenguaje. Para permitir agregar información al

modelo que de otra manera no puede ser representada, el UML

proporciona las notas.

Una nota puede ser puesta en cualquier lugar del diagrama, y puede

contener cualquier tipo de información. Su tipo de información es una

cadena que no puede ser interpretada por el UML. La nota es agregada

típicamente a algún elemento en el diagrama con alguna línea punteada

que especifica cuál elemento está siendo explicado o detallado, junto

con la información en la nota.

Mecanismos Generales – Continuación…

Una clase de entidad modela información y comportamiento

asociado que es generalmente de larga duración. Este tipo de clase

puede reflejar una entidad del mundo real, o puede ser necesaria para

realizar tareas internas del sistema.

Típicamente son independientes de sus alrededores; es decir, no son

sensibles a la forma en que los alrededores se comunican con el

sistema. Muchas veces, son independientes de la aplicación, lo que

significa que pueden ser usadas en más de una aplicación.

Clase de Entidad

El primer paso es examinar las responsabilidades documentadas en

el flujo de eventos para los casos de uso identificados (lo que el

sistema debe hacer).

Las clases de entidad típicamente son clases que son necesarias por

el sistema para realizar alguna responsabilidad. Los nombres y frases

usadas para describir las responsabilidades pueden ser un buen punto

de inicio.

Clase de Entidad

Las clases de frontera manejan la comunicación entre el entorno del sistema y

el interior del mismo.

Pueden proporcionar la interfaz a un usuario u otro sistema (la interfaz a un

actor). Constituyen la parte dependiente del entorno. Las clases de frontera son

usadas para modelar las interfaces del sistema.

Por ejemplo, se puede modelar una ventana pero no cada uno de sus cuadros

de diálogo y botones. En esta etapa se están documentando los requerimientos

de la interfaz del usuario, no implementándolos.

Las clases de frontera son también añadidas para facilitar la comunicación con

otros sistemas. Durante el diseño, estas clases son refinadas para tomar en

cuenta los protocolos de comunicación escogidos.

Clase de Frontera

Las clases de control modelan comportamiento de secuencia específico

a uno o más casos de uso. Las clases de control coordinan los eventos

necesarios para realizar el comportamiento especificado en el caso de

uso. Puede pensar de una clase de control como la que “corre” o

“ejecuta” el caso de uso. Las clases de control típicamente son clases

dependientes de la aplicación.

En las etapas iníciales de la fase de Elaboración, una clase de control

es añadida para cada par actor/caso de uso. La clase de control es

responsable por el flujo de eventos en el caso de uso.

Clase de Control