# Fundamentos de &UML;

## Acerca de &UML;

Este capítulo daralle unha introdución rápida aos fundamentos de &UML;. Teña en conta que este non é un titorial extenso de &UML; senón unha breve introdución que pode ser lida como un titorial. Se quer aprender máis acerca do Unified Modelling Language, ou en xeral acerca da análise e deseño de sóftware, consulte un dos moitos libros disponíbeis que tratan deste tema. Tamén hai moitos titoriais en internet que pode tomar como un punto de comezo.

O "Unified Modelling Language" (&UML;) é unha linguaxe ou notación de deseño para especificar, visualizar e documentar modelos de sistemas de sóftware Orientados a Obxectos. &UML; non é un método de desenvolvimento, o que significa que non lle di o que debe facer primeiro e o que debe facer despois nen como deseñar o seu sistema, senón que o axuda a visualizar o deseño e a comunicarllo a outros. &UML; está controlado polo "Object Management Group" (OMG) e é o estándar da industria para descreber graficamente o sóftware.

&UML; foi pensado para o deseño de sóftware Orientado a Obxectos e ten unha utilidade moi limitada para outros paradigmas de programación.

&UML; está composto de diversos elementos de modelo que representan as diferentes partes dun sistema de sóftware. Os elementos &UML; son usados para criar diagramas, que representan unha parte, ou un ponto de vista do sistema. &umbrello; soporta os seguintes tipos de diagrama:

- Diagramas de caso de uso mostra actores (xente ou outros usuarios do sistema), casos de uso (os cenarios en que o sistema é usado), e as súas relacións

- Diagramas de clase mostra clases e as relacións entre elas

- Diagramas de secuencia mostra obxectos e a secuencia de chamadas a métodos de outros obxectos que fan.

- Diagramas de colaboración mostra obxectos e a súa relación, enfatizando os obxectos que participan no intercambio de mensaxes

- Diagramas de estado mostra estados, mudanzas de estado e eventos nun obxecto ou unha parte do sistema

- Diagramas de actividade mostra actividades e os cambios dunha activade para outra cos eventos que acontecen nalgunha parte do sistema

- Diagramas de componentes mostra as componentes de alto nível (como KParts ou Java Beans).

- Diagramas de implementación mostra as instancias das componentes e as súas relacións.

- Os Diagramas de relacións entre entidades mostran datos e as relacións e restricións entre os datos.

## Elementos &UML;

### Diagrama de caso de uso

Os diagramas de caso de uso descreben as relacións e dependencias entre un grupo de Casos de Uso e os Actores a participar no proceso.

É importante decatarse de que os diagramas de casos de uso non son apropriados para representar o deseño, e non poden descreber o interior dun sistema. Estes diagramas serven para facilitar a comunicación cos futuros usuarios do sistema, e cos clientes, e son especialmente úteis para determinar as funcionalidades que o sistema debe ter. Os diagramas de casos de uso indican o que o sistema debera ter, pero non especifica como o acada, —nen pode—.

Un diagrama de caso de uso de exemplo. &umbrello; mostrando un diagrama de caso de uso

&umbrello; mostrando un diagrama de caso de uso

#### Caso de uso

Un caso de uso descrebe —desde o ponto de vista dos actores— un grupo de actividades nun sistema que produce un resultado concreto, tanxíbel.

Os casos de uso son descricións das interaccións típicas entre os usarios dun sistema e o sistema en si. Representan a interface externa do sistema e especifican unha forma de requerimentos do que debe facer o sistema (lembre, só o que, non como).

Cando se traballa cos casos de uso, é importante lembrar algunhas regras simples:

- Cada caso de uso estará relacionado con polo menos un actor

- Cada caso de uso ten un iniciador (&ie; un actor)

- Cada caso de uso conduce a un resultado relevante (un resultado con valor de negocio)

Os casos de uso tamén teñen relacións con outros casos de uso. Os tres tipos de relación máis típicas entre os casos son:

- <<inclusión>> que indica que un caso de uso acontece dentro doutro caso de uso

- <<extensión>> que indica que en certas situacións, ou nalgún ponto (chamado ponto de extensión) un caso de uso será ampliado por outro.

- Xeneralización indica que un caso de uso herda as características do Supercaso de uso, e pode sobrescreber algunhas deles ou engadir outras novas, de xeito similar á herdanza entre clases.

#### Actor

Un actor é unha entidade externa (fora do sistema) que interactúa co sistema ao participar (e a miúdo iniciar) un caso de uso. Os actores poden ser xente real (por exemplo os usuarios do sistema), outros sistemas informáticos ou eventos externos.

Os actores non representan a xente ou sistemas físicos, senón o seu papel. Isto significa que cando unha persoa interactúa co sistema de diferentes xeitos (asumindo diferentes papeis) estará representada por varios actores. Por exemplo unha persoa que dá servizo técnico aos clientes por teléfone e recive pedidos dos clientes, no sistema estaría representado por un actor Servizo Técnico e un actor Comercial

#### Descrición do caso de uso

As descricións dos casos de uso son textos que o explican o caso. Polo xeral toman a forma dunha nota ou documento que está ligado dalgún xeito ao caso de uso, e explica os procesos ou actividades que acontecen nese caso de uso.

### Diagramas de clase

Os diagramas de clase mostran as diferentes clases que conforman o sistema e como se relacionan entre si. Sóese dicir que os diagramas de clase son estáticos porque mostran as clases, xunto cos seus métodos e atributos así como as relacións estáticas entre elas: que clases coñecen da existencia de outras ou que clases son parte de outras clases, pero non mostran as chamadas a métodos entre elas.

Un exemplo de diagrama de clase &umbrello; mostrando un diagrama de clases

&umbrello; mostrando un diagrama de clases

#### Clase

Unha clase define os atributos e métodos dun conxunto de obxectos. Todos os obxectos desa clase (instancias da clase) teñen o mesmo comportamento, e teñen o mesmo conxunto de atributos (cada obxecto ten o seu proprio conxunto). Ás veces chámaselles Tipo no canto de Clase, pero é importante mencionar que non son o mesmo, e que Tipo é un termo máis xeral.

En &UML; as clases son representadas por rectángulos, co nome da clase, que poden mostrar tamén os atributos e operacións da clase en outros dous compartimentos dentro do rectángulo.

Unha clase en &UML; Representación visual dunha clase en &UML;

Representación visual dunha clase en &UML;

##### Atributos

En &UML; os atributos son mostrados con polo menos o seu nome, e tamén pode mostrar o tipo, valor inicial e outras propiedades. Os atributos tamén poden ser mostrados coa súa visibilidade:

- `+` Significa que o atributo é público

- `#` Significa que o atributo é protexido

- `-` Significa que o atributo é privado

##### Operacións

As operacións (métodos) tamén son mostradas con polo menos o seu noe, e tamén pode mostrar os seus parámetros e tipo de retorno. Os igual que cos atributos, tamén pode ver a súa visibilidade:

- `+` Significa que a operación é pública

- `#` Significa que a operación é protexida

- `-` Significa que a operación é privada

##### Modelos

As clases poden ter modelos, un valor que é usada para unha clase ou tipo non especificado. O tipo do modelo é especificado cando a clase é iniciada (&ie; cando se cría un obxecto). Os modelos existen en C++ e serán introducidos en Java 1.5 onde serán chamados Generics.

#### Asociacións entre clases

As clases poden relacionarse (estar asociadas con) unhas coas outras de distintos xeitos:

##### Xeneralización

A herdanza é un dos conceitos fundamentais da programación orientada a obxectos, na que unha clase gaña todos os atributos e operacións da clase da que herda, e pode sobrescreber/modificar algúns deles, así como engadir máis atributos e operacións proprias.

En &UML;, unha asociación de Xeneralización entre dúas clases ponnas nunha hierarquía que representa o conceito de herdanza dunha clase derivada respeito dunha clase base. En &UML;, as xeneralizacións son representadas por unha liña que conecta as dúas clases, cunha frecha ao lado da clase base. Xeneralización Representación visual dunha xeneralización en &UML;

Representación visual dunha xeneralización en &UML;

##### Asociacións

Unha asociación representa unha relación entre clases, e dá a semántica común e a estrutura de moitos tipos de conexóns entre obxectos.

As asociacións son o mecanismo que lles permite aos obxectos comunicarse entre si. Describen a conexón entre diferentes clases (a conexón entre os obxectos reais é denominada conexón entre obxectos, ou ligazón).

As asociacións poden ter un papel que especifica o propósito da asociación e pode ser uni ou bidireccional (indica se os dous obxectos participantes na relación poden enviar mensaxes uns aos outros, ou se só un deles sabe do outro). Cada extremo da asociación pode ter tamén unha multiplicidade, que dictamina cantos obxectos neste lado da asociación poden relacionarse cun obxecto do outro lado).

En &UML; as asociacións represéntanse como liñas que conectan as clases participantes na relación, e tamén poden mostrar o papel e a multiplicidade de cada un dos participantes. A multiplicidade é mostrada como un rango [mín..máx] de valores non negativos, onde un asterísco (`*`) no máximo representa o infinito. Asociación &UML; Representación visual dunha asociación en &UML;

Representación visual dunha asociación en &UML;

##### Agregación

As agregacións son un tipo especial de asociación na que as dúas clases participantes non teñen o mesmo estatus, senón que teñen unha relación todo-parte. Unha agregación descrebe como a clase que adopta o papel de todo, está composta por(ten) outras clases, que adoptan o papel de partes. Nas agregacións, a clase que actúa como o todo sempre ten unha multiplicidade de un.

En &UML; as agregacións represéntanse mediante unha asociación cun rombo no lado do todo. Agregación Representación visual dunha relación de agregación en &UML;

Representación visual dunha relación de agregación en &UML;

##### Composición

As composicións son asociación que representan agregacións moi fortes. Isto significa que as composicións tamén representan relacións todo-parte, pero cunha relación tan forte que as partes non poden existir por si mesmas. Só existen dentro do todo, e se o todo é destruído as partes tamén.

En &UML; as Composicións represéntanse cun rombo sólido no lado do todo.

Composición Representación visual dunha relación de composición en &UML;

#### Outros elementos dos diagramas de clase

Os diagramas de clase ademais de clases poden conter outro elementos.

##### Interfaces

As interfaces son clases abstractas que representan instancias que non poden ser criadas directamente. Poden conter operacións pero non atributos. As clases poden herdar de interfaces (mediante unha asociación de realización) e as instancias pode estar feitas destes diagramas.

##### Tipos de datos

Os tipos de datos son primitivas que tipicamente veñen incorporadas na linguaxe. Exemplos habituais son os inteiros e os booleanos. Non poden ter relacións con clases, pero as clases poden ter relacións con eles.

##### Enumeracións

As enumeracións son listas simples de valores. Un exemplo típico é unha enumeración dos días da semana. As opcións dunha enumeración son denominadas Literais da enumeración. Ao igual cos tipos de datos non poden ter relacións coas clases pero as clases poden ter relacións con elas.

##### Paquetes

Os paquetes representan un espazo de nomes na linguaxe de programación. Nos diagramas son usados para representar partes dun sistema que conteñen máis dunha clase, mesmo centos delas.

### Diagramas de secuencia

Os diagramas de secuencia mostran o intercambio de mensaxes (&ie; chamadas a métodos) entre varios obxectos nunha situación concreta delimitada no tempo. Os obxectos son instancias das clases. Os diagramas de secuencia fan énfase na orden e tempos nos que se envían as mensaxes aos obxectos.

Nos diagramas de secuencia os obxectos son representados mediante liñas verticais de pontos co nome do obxecto no cume. O eixo do tempo tamén é vertical, aumentando cara baixo, de tal xeito que as mensaxes son enviasa dun obxecto para outro na forma de frechas co nome e os parámetros da operación.

Diagrama de secuencia
&umbrello; mostrando un diagrama de secuencia

&umbrello; mostrando un diagrama de secuencia

As mensaxes poden ser síncronas, o tipo normal de mensaxe no que o control é pasado á obxecto chamado até que o seu método remate a execución, ou asíncronas, onde o control é devolto directamente ao obxecto que fai a chamada. As mensaxes síncronas teñen unha caixa vertical ao lado do obxecto chamado para mostrar o fluxo de control do programa.

### Diagramas de colaboración

Os diagramas de colaboración mostran as interaccións que acontecen entre os obxectos que participan nunha situación dada. Isto é similar á información que se mostra nun diagrama de secuencia pero neste faise fincapé en como acontecen as interaccións no tempo mentres que nos diagramas de colaboración poñen de relevo as relacións entre os obxectos e a súa topoloxía.

Nos diagramas de colaboración as mensaxes enviadas entre obxectos son representadas por frechas, co nome da mensaxe, os parámetros e a secuencia da mensaxe. Os diagramas de colaboración son adecuados para mostrar un fluxo específico do programa ou unha situación e son un dos mellores tipos de diagrama para demostrar rapidamente ou explicar un proceso na lóxica do programa.

Colaboración
&umbrello; mostrando un diagrama de colaboración

&umbrello; mostrando un diagrama de colaboración

### Diagrama de estado

Os diagramas de estado mostran os diferentes estados dun obxecto durante a súa existencia e os estímulos que fan que o obxecto mude o seu estado.

Os diagramas de estado consideran os obxectos como máquinas de estados ou autómatas finitos que poden estar nun dun conxunto finito de estados e que poden mudar o seu estado mediante un conxunto finito de estímulos. Por exemplo un obxecto do tipo NetServer pode estar nun dos seguintes estados durante a súa vida:

- En aguarda

- A escoitar

- A traballar

- Parado

e os eventos que poden facer que o obxecto mude de estado son

- O obxecto é criado

- O obxecto recebe a mensaxe "escoitar"

- Un cliente pide unha conexón sobre a rede

- Un cliente finaliza unha conexón

- A petizón é executada e finaliza

- O obxecto recebe a mensaxe "parar"

- etc

Diagrama de estado &umbrello; mostrando un diagrama de estado

&umbrello; mostrando un diagrama de estado

#### Estado

Os estados son os tixolos cos que se fan os diagramas de estado. Un estado pertence a exactamente unha clase e representa un resumo dos valores que poden tomar os atributos dunha clase. Un estado en &UML; representa o estado interno dun obxecto nunha clase particular

Lembre que non todas as alteración nun atributo dun obxecto debe ser representado por un estado senón só aquelas modificación que poden afectar de xeito significativo a como traballe o obxecto

Hai dous tipos especiais de estado: Inicio e Fin. Son especiais porque nengún evento pode facer que un obxecto volte ao seu estado de Inicio, do mesmo xeito que nengún evento pode facer que un obxecto volte do estado de Fin unha vez que é acadado.

### Diagrama de actividade

Os diagramas de actividade descreben a secuencia do traballo nun sistema coa axuda de Actividades. Os diagramas de actividade son unha forma especial de diagrama de estados, que só (ou maiormente) contén Actividades.

Un exemplo de diagrama de actividade. &umbrello; mostrando un diagrama de actividade

&umbrello; mostrando un diagrama de actividade

Os diagramas de actividade son similares aos Diagramas de Fluxo dos procedimentos, coa diferenza de que todas as Actividades están claramente ligadas a Obxectos.

Os diagramas de actividade sempre están asociados ou a unha Clase, a unha Operación ou a un Caso de uso.

Os diagramas de actividade admiten actividades tanto secuenciais como paralelas. A execución en paralelo é representada mediante ícones Ramificar/Xuntar, e para as actividades con execución en paralelo, non é importante a orden na que son realizadas (poden ser executadas á vez ou unha tras da outra)

#### Actividade

Unha actividade é unha etapa simples dun proceso. Unha actividade é un estado do sistema activo e, polo menos, unha transición saínte. As actividades tamén poden ter máis dunha transición saínte se teñen diferentes condicións.

As actividades poden formar hierarquías, isto significa que unha actividade pode estar composta por varias actividades de detalle, neste caso as transicións entrantes e saíntes deben coincidir coas transicións de entrada e saída do diagrama de detalle.

### Elementos auxiliares

Hai uns poucos elementos &UML; que non teñen valor semántico real para o modelo, pero axudan a aclarar partes do diagrama. Estes elementos son

- Liñas de texto

- Notas de texto e enganches

- Caixas

As liñas de texto son úteis para engadir un texto informativo breve ao diagrama. Non están ligadas a nengún elemento e non teñen significado para o modelo en si.

As notas son úteis para engadir información máis detallada acerca dun obxecto ou situación específica. Teñen a grande vantaxe de que poden estar ligadas a elementos &UML; para mostrar que a nota pertencea un obxecto ou situación específica.

As caixas son rectángulos non ligado a nada que poden ser usadas para agrupar elementos e facer os diagramas máis lexíbeis. Non teñen significado lóxico no modelo.

### Diagrama de componentes

Os diagramas de componentes mostrans os componentes do sóftware (sexantecnoloxías de componentes como KParts, componentes CORBA ou Java Beans ou só seccións do sistema claramente diferenciábeis) e os artefactos cos que están feitos, como ficheiros de código fonte, bibliotecas de programación ou táboas de bases de datos relacionais.

As componentes poden ter interfaces (&ie; clases abstractas con operacións) que permiten asociacións entre componentes.

### Diagramas de implementación

Os diagramas de implementación mostran as instancias en tempo de execución e as súas asociación. Inclúen Nós, que son recursos físicos, tipicamente un ordenador. Tamén mostran as interfaces e os obxectos (intancias de clases).

### Diagramas de relacións entre entidades

Os diagramas de relacións entre entidades (Diagramas ER) mostran o deseño conceptual das bases de datos. Con eles tense unha visión das diferentes entidades (conceitos) do sistema de información e das relacións e restricións existentes entre elas. Emprégase unha extensión dos diagramas de relacións entre entidades, chamada "Diagramas ampliados de relacións entre entidades" (EER), para incorporar técnicas de deseño orientado a obxectos nos diagramas ER.

Un diagrama de relacións entre entidades de exemplo. Umbrello mostrando un diagrama de relacións entre entidades

Umbrello mostrando un diagrama de relacións entre entidades

#### Entidade

Unha entidade é calquer conceito do mundo real que teña existencia independente. Pode ser un obxecto físico (por exemplo un ordenador, ou un bolígrafo) ou só ter existencia conceptual (p.ex: un curso da universidade). Cada entidade ten un conxunto de atributos que descreben as propriedades da entidade.

Nota: Non hai unha notación estándar para os diagramas ER. Os diferentes textos que tratan desta materia empregan notacións distintas. Os conceitos e notacións dos diagramas EER empregados en Umbrello son tomados do seguinte libro: Elmasri R. e Navathe S. (2004). Fundamentals of Database Systems 4th edn. Addison Wesley

Nun diagrama ER, as entidades son representadas por rectángulos, co nome da entidade na parte superior, e tamén pode mostras os atributos da entidade en outro compartimento dentro do rectángulo.

Unha entidade nun diagrama ER Representación visual dunha entidade nun diagrama ER

Representación visual dunha entidade nun diagrama ER

##### Atributos da entidade

Nos diagramas ER, os atributos das entidades represéntanse polo seu nome nun compartimento diferente da entidade á que pertencen.

##### Restricións

As restricións nus diagramas ER especifican as restricións nos datos do esquema de información.

Umbrello admite catro tipos de restricións:

- Chave primaria O conxunto de atributos declarados como chave primaria son únicos da entidade. Só pode haber unha chave primaria nunha entidade e nengún dos atributos que a constitúan pode ser NULO.

- Chave única: O conxunto de atributos declarados como únicos son específicos da entidade. Poda haber varias restricións de unicidade nunha entidade. Os atributos que a constitúen poden ser NULO. As chaves únicas e as chaver primarias idenfican univocamente unha fila dunha táboa (entidade)

- Chave externa: Unha chave externa é unha restrición referencial entre dúas táboas. A chave externa identifica unha coluna ou conxunto de colunas nunha táboa (referinte) que se refete a unha coluna ou conxunto de colunas de outra táboa (referida). As colunas na táboa referida deben formar unha chave primaria ou única.

- Restrición por comprobación: Unha restrición por comprobación (tamén coñecida por restrición de comprobación da táboa) é unha condición que define os datos válidos cando se engade ou actualiza unha entrada nunha táboa dunha base de datos relacional. Estas restricións aplícanse a cada fila da táboa. A restrición debe ser un predicado. Pode referirse a unha só ou a varias colunas da táboa.

  Exemplo: prezo >=0

#### Conceitos dos diagramas de relacións ampliadas entre entidades (EER)

##### Especialización

A especialización é unha maneira de formar novas entidades empregando entidades xa definidas. As entidades novas, coñecidas como entidades derivadas, toman (herdan) atributos das preexistentes, ás que se coñece por entidades base. O propósito é reutilizar datos xa existentes con pouca ou nengunha modificación.

En Umbrello, pódese especificar que a especialización sexa Disxunta ou Sobreposicionante

###### Especialización disxunta

A especialización disxunta indica que as subclases da especialización deben ser disxuntas. Isto significa que unha entidade pode ser membro de como moito unha das entidades derivadas da especialización

Entidates participando nunha especialización disxunta Representación visual da especialización disxunta nun diagrama EER

Representación visual da especialización disxunta nun diagrama EER

###### Especialización sobreposicionante

Cando as entidades derivadas non teñen a restrición de ser disxuntas, dise que o seu conxunto de entidades está en especialización con sobreposición. Isto significa que a mesma entidade do mundo real pode ser membro de máis dunha entidade derivada da especialización.

Entidades a tomar parte nunha especialización sobreposicionante Representación visual da especialización sobreposicionante nun diagrama EER

Representación visual da especialización sobreposicionante nun diagrama EER

###### Categoría

Dise que unha entidade derivada é unha Categoría cando representa unha coleccion de obxectos que é un subconxunto da unión dos distintos tipos de dato. A categoría modelízase cando surxe a necesidade dunha única relación superclase/subclase con máis dunha superclase, onde a superclase representa diferentes tipos de entidades. (Como a herdanza múltipla na programación orientada a obxectos).

Entidades a tomar parte nunha relación de Categoría Representación visual dunha Categoría nun diagrama EER

Representación visual dunha Categoría nun diagrama EER