Elementos de UMLOs Diagramas de Casos de Uso descrevem as relações e as dependências entre um grupo de Casos de Uso e os Actores que participam no processo.
É importante reparar que os Diagramas de Casos de Uso não são adequados para representar o desenho e também não podem descrever os detalhes internos de um sistema. Os Diagramas de Casos de Uso pretendem facilitar a comunicação com os utilizadores futuros do sistema e com o cliente, e são especialmente úteis para determinar as funcionalidades necessárias que o sistema deverá ter. Os Diagramas de Casos de Uso indicam o que o sistema deverá fazer mas não devem — e não podem — especificar como isto deverá ser feito.
Umbrello UML Modeller a mostrar um diagrama de Casos de Utilização
Um Caso de Utilização descreve — do ponto de vista dos actores — um grupo de actividades de um sistema que produzem um resultado concreto e tangível.
Os Casos de Uso são descrições das interacções típicas entre os utilizadores de um sistema e o sistema propriamente dito. Eles representam a interface externa do sistema e especificam um dado tipo de requisitos sobre o que o sistema tem de fazer (lembre-se, só 'o quê', não 'como').
Ao lidar com os Casos de Uso, é importante recordar algumas regras simples:
Cada Caso de Utilização está relacionado com pelo menos um actor
Cada Caso de Utilização tem um iniciador (ou seja, um actor)
Cada Caso de Uso conduz a um resultado relevante (um resultados com “valor de negócio”)
Os Casos de Uso também poderão ter relações com outros Casos de Uso. Os três tipos de relações mais típicos entre Casos de Uso são:
<<include>> (incluir) que indica que um Caso de Uso toma lugar dentro de outro Caso de Uso
<<extends>> (extende) que indica que, em certas situações ou numa dada altura (chamada de ponto de extensão), um Caso de Uso será extendido por outro.
Generalization (generalização) indica que um Caso de Uso herda as características do “Super”-Caso de Uso e poderá implementar novamente algumas delas ou adicionar novas de uma forma semelhante à da herança de classes.
Um actor é uma entidade externa (fora do sistema) que interage com o sistema ao participar (ou iniciar normalmente) um Caso de Uso. Os actores poderão ser pessoas reais (como, por exemplo, utilizadores do sistema), outros sistemas informáticos ou eventos exteriores.
Os actores não representam as pessoas físicas ou os sistemas, mas sim o seu papel. Isto significa que, quando uma pessoa interage com o sistema de formas diferentes (assumindo papéis diferentes), ele será representado por vários actores. Por exemplo, uma pessoa que dá suporte ao cliente por telefone e que recebe encomendas do cliente para colocar no sistema seria representado por um actor “Técnico de Suporte” e por um actor “Representante de Vendas”
Os Diagramas de Classes mostram as diferentes classes que compõem um sistema e como elas se relacionam umas com as outras. Os Diagramas de Classes são apontados normalmente como “estáticos” porque mostram as classes, em conjunto com os seus métodos e atributos, assim como as relações estáticas entre elas, quais as classes que “conhecem” outras classes ou que “fazem parte” de outra classe, mas não mostram as chamadas de métodos entre elas.
O Umbrello UML Modeller a mostrar um diagrama de Classes
Uma classe define os atributos e os métodos para um conjunto de objectos. Todos os objectos desta classe (as instâncias da mesma) partilham o mesmo comportamento e têm o mesmo conjunto de atributos (cada objecto tem o seu próprio conjunto). O termo “Tipo” é usado em algumas ocasiões em vez de Classe, mas é importante mencionar que os dois conceitos não são iguais e que o Tipo é um termo mais genérico.
No UML, as Classes são representadas por rectângulos com o nome da classe, e poderão também mostrar os atributos e as operações da classe em outros dois “compartimentos” dentro do rectângulo.
Representação visual de uma Classe em UML
No UML, os Atributos são mostrados como tendo o seu nome, pelo menos, e poderão mostrar também o seu tipo, o seu valor inicial e outras propriedades. Os atributos também poderão ser mostrados com a sua visibilidade:
+Representa atributos públicos#Representa atributos protegidos-Representa atributos privados
As operações (métodos) são também mostradas contendo pelo menos o seu nome e poderão também mostrar os seus parâmetros e tipos de valor devolvidos. As operações podem, assim como os Atributos, mostrar a sua visibilidade:
+Corresponde a operações públicas#Corresponde a operações protegidas-Corresponde a operações privadas
As Classes poderão ter modelos, um valor que é usado para uma classe ou tipo não especificado. O tipo de modelo é definido quando uma classe é iniciada (isto é um objecto é criado). Os modelos existem como 'template' no C++ actual e serão introduzidos no Java 1.5 onde serão chamados de 'Generics'.
Uma classe pode-se relacionar (ser associada) com outra qualquer de diferentes maneiras:
A herança é um dos conceitos fundamentais da programação orientada por objectos, nos quais uma classe “ganha” todos os atributos e operações da classe que herda, podendo sobrepor ou modificar algumas delas, assim como adicionar mais atributos ou operações próprias.
No UML, uma associação por Generalização entre duas classes representa o conceito de herança entre uma classe de base e uma classe derivada. No UML, as Generalizações são representadas com uma linha que liga as duas classes, em que existe uma seta do lado da classe de base.
Representação visual de uma generalização em UML
Uma associação representa uma relação entre classes e dá a semântica e a estrutura comum para vários tipos de “ligações” entre os objectos.
As associações são o mecanismo que permite aos objectos comunicarem uns com os outros. Descreve a ligação entre as diferentes classes (a ligação entre os objectos em si é chamada de ligação do objecto.
As associações podem ter um papel que indica o objectivo da associação e pode ser unidireccionais ou bidireccionais (indica se os dois objectos que participam na relação poderão enviar mensagens um para o outro, ou se só um deles é que conhece o outro). Cada extremo da associação também tem um valor de multiplicidade, que define quantos objectos desse lado da associação poder-se-ão relacionar com um objecto do outro lado.
No UML, as associações são representadas como linhas que ligam as classes que participam na relação e poderá também mostrar o papel e a multiplicidade de cada um dos participantes. A multiplicidade é mostrada como um intervalo [mín..máx] de valores não-negativos ou com um asterisco (*) no lado do máximo que representa o infinito.
Uma representação visual de uma associação em UML
As agregações são um tipo especial de associações nas quais as duas classes participantes não têm um estado igual, mas têm uma relação “do 'todo' para as partes”. Uma agregação diz como é que a classe que têm o papel do 'todo' é composta (ou tem) as outras classes, que têm o papel das partes. Para as agregações, a classe que actua como o 'todo' tem sempre uma multiplicidade de um.
No UML, as agregações são representados por uma associação com um losango do lado do 'todo'.
Uma representação visual de uma relação de agregação no UML
As composições são associações que representam agregações muito fortes. Isto significa que as composições formam também relações do 'todo' para as partes, mas a relação é tão forte que as partes não podem existir por si só. Elas só existem dentro do todo e se o todo for destruído, as partes desaparecem também.
No UML, as Composições são representadas por um losango a cheio do lado do 'todo'.
Os diagramas de classe poderão conter outros itens para além das classes.
As interfaces são classes abstractas, o que significa que as instâncias não podem ser criadas directamente a partir delas. Elas poderão contem operações, mas não podem conter atributos. As classes podem herdar das interfaces (através de uma relação de realização) e as instâncias poderão então ser compostas a partir desses diagramas.
Os tipos de dados são primitivas que vêm tipicamente incorporadas numa linguagem de programação. Os exemplos comuns incluem os inteiros e os booleanos. Eles não poderão ter relações com as classes, mas as classes poderão ter relações com eles.
Os enumerados são uma lista simples de valores. Um exemplo típico são os enumerados para os dias da semana. Como os tipos de dados, os enumerados não poderão ter relações com as classes, mas as classes poderão ter relações com eles.
Os Diagramas de Sequência mostram a troca de mensagens (isto é as chamadas aos métodos) entre os vários objectos numa situação específica delimitada no tempo. Os objectos são instâncias das classes. Os Diagramas de Sequência colocam uma ênfase especial na ordem e nas alturas em que as mensagens são enviadas para os objectos.
Nos Diagramas de Sequência, os objectos são representados através de linhas tracejadas verticais, com o nome do objecto no topo. O eixo do tempo também é vertical, e vai aumentando de cima para baixo, de modo a que as mensagens sejam enviadas de um objecto para outro, sob o formato de setas com o nome da operação e dos parâmetros.
O Umbrello UML Modeller a mostrar um Diagrama de Sequência
As mensagens tanto podem ser síncronas, o que acontece normalmente nas chamadas de mensagens quando o controlo é passado para o objecto que é invocado até que esse método termine a sua execução, ou poderão também ser assíncronas, onde o controlo é passado de volta directamente para o objecto que invoca o método. As mensagens síncronas têm uma caixa vertical do lado do objecto que é chamado para mostrar o fluxo de controlo do programa.
Os Diagramas de Colaboração mostram as interacções entre os objectos que participam numa dada situação. Esta é mais ou menos a mesma informação que é mostrada pelos Diagramas de Sequência, mas existe também uma ênfase posta sobre como as interacções ocorrem no tempo, enquanto que os Diagramas de Colaboração colocam as relações entre os seus objectos e a sua topologia em primeiro plano.
Nos Diagramas de Colaboração, as mensagens enviadas de um objecto para o outro são representadas por setas que mostram o nome da mensagem, os parâmetros e a sequência da mensagem. Os Diagramas de Colaboração são particularmente adequados a mostrar um fluxo específico de um programa ou situação, e são uns dos melhores tipos de diagramas para demonstrar ou explicar rapidamente um processo na lógica do programa.
O Umbrello UML Modeller a mostrar um Diagrama de Colaboração
Os Diagramas de Estados mostram os diferentes estados de um objecto durante a sua vida, bem como os estímulos que fazem com que o objecto mude o seu estado.
Os Diagramas de Estados vêem os objectos como máquinas de estados ou autónomos finitos que poderão estar num estado pertencente a uma lista de estados finitos e que poderão mudar o seu estado através de um estímulo pertencente a um conjunto finito de estímulos. Por exemplo, um objecto do tipo ServidorRede poderá estar num dos seguintes estados durante a sua vida:
Pronto
À espera
A trabalhar
Parado
e os eventos que poderão fazer com que o Objecto mude de estado são
O objecto é criado
O objecto atende a mensagem
Um cliente pede uma ligação pela rede
Um cliente termina um pedido
O pedido é executado e terminado
O objecto recebe a mensagem parar
etc
O Umbrello UML Modeller a mostrar um Diagrama de Estado
Os estados são os blocos de construção dos Diagramas de Estado. Um estado pertence a exactamente uma classe e representa um resumo dos valores que os atributos de uma classe poderão obter. Um Estado no UML descreve o estado interno de um objecto de uma determinada classe
Tenha em atenção que nem todas as alterações de um atributo de um objecto deverão ser representadas por um estado, mas só mesmo aquelas alterações que poderão afectar significativamente o funcionamento do objecto
Existem dois tipos especiais de Estados: o Inicial e o Final. Eles são especiais na medida em que não existe nenhum evento que possa fazer um objecto voltar ao seu estado inicial, da mesma forma que não há nenhum evento que possa retirar um objecto do seu estado final, logo que o tenha atingido.
Os Diagramas de Actividades descrevem a sequência de actividades de um sistema, com a ajuda das Actividades propriamente ditas. Os Diagramas de Actividades são um tipo especial de Diagramas de Estados, que só (ou em grande parte) contêm Actividades.
O Umbrello UML Modeller a mostrar um Diagrama de Actividade
Os Diagramas de Actividades são semelhantes aos fluxogramas procedimentais, com a diferença que todas as Actividades estão claramente associadas a objectos.
Os Diagramas de Actividades estão sempre associados a uma Classe, uma Operação ou um Caso de Uso.
Os Diagramas de Actividades suportam as Actividades sequências, assim como as paralelas. A execução paralela é representada através de ícones de 'Fork' (Bifurcação) ou 'Wait' (Espera) e, para as actividades que decorrem em paralelo, não é importante a ordem pela qual são desempenhadas (elas poderão ser executadas ao mesmo tempo ou uma a seguir à outra)
Uma Actividade é um passo único num processo. Uma Actividade é um estado no sistema com actividade interna e, pelo menos, uma transição de saída. As Actividades também poderão conter mais do que uma transição de saída se tiverem diferentes condições.
As Actividades poderão formar hierarquias, o que significa que uma Actividade poderá ser composta por várias Actividades de “detalhe”, onde nesse caso as transições de entrada e de saída deverão corresponder às transições de entrada e de saída do diagrama de detalhe.
Existem alguns elementos no UML que não têm nenhum valor semântico real para o modelo, mas que ajudam a clarificar partes do diagrama. Esses elementos são
Linhas de texto
Notas de Texto e âncoras
Caixas
As linhas de texto são úteis para adicionar algumas informações textuais breves para um diagrama. Correspondem a texto livre e não têm nenhum significado para o modelo em si.
As notas são úteis para adicionar informações mais detalhada sobre um objecto ou uma dada situação. Têm a grande vantagem de poderem ser anexadas a Elementos de UML para mostrar que a nota “pertence” a um dado objecto ou situação.
As caixas são rectângulos livres que poderão ser usados para agrupar os itens em conjunto para tornar os diagramas mais legíveis. Elas não têm significado lógico no modelo.
Os Diagramas de Componentes mostram os componentes do 'software' (sejam referentes a tecnologias de componentes como os KParts, os componentes do CORBA ou Java Beans, ou mesmo secções do sistema que sejam claramente distintas), bem como os artefactos de que são compostos, como os ficheiros de código-fonte, as bibliotecas de programação ou as tabelas de bases de dados relacionais.
Os componentes poderão ter interfaces (isto é classes abstractas com operações) quer permitem associar os componentes.
Os Diagramas de Entrada em Produção mostram as instâncias em execução, bem como as suas associações. Eles incluem os Nós, que são recursos físicos, correspondendo tipicamente a um único computador. Mostram também as interfaces e os objectos (as instâncias das classes).
Os Diagramas de Entidade-Associação (Diagramas ER) mostram o desenho conceptual das aplicações de bases de dados. Estes definem as várias entidades (conceitos) no sistema de informação e as relações e restrições entre eles. Uma extensão dos Diagramas Entidade-Associação, chamada 'Diagramas Estendidos Entidade-Associação' (EER) são usados para incorporar as técnicas de desenho Orientado por Objectos nos diagramas ER.
O Umbrello a mostrar um Diagrama de Entidade-Associação
Uma Entidade é qualquer conceito no mundo real com uma existência independente. Poderá ser um objecto com uma existência física (exemplo, Computador, Robot) ou poderá ser um objecto com uma existência conceptual ( p.ex.: Curso Universitário). Cada entidade tem um conjunto de atributos que descrevem as propriedades da Entidade.
Nota: Não existem ainda notações normalizadas para desenhar Diagramas ER. Os diferentes textos sobre este assunto usam notações diferentes. Os conceitos e notações para os diagramas ER usados no Umbrello são do seguinte livro: Elmasri R. e Navathe S. (2004). Fundamentals of Database Systems 4a ed. Addison Wesley
Num Diagrama ER, as Entidades são representadas por rectângulos com o nome da classe, e poderão também mostrar os atributos de uma entidade noutro “compartimento” dentro do rectângulo.
Representação visual de uma entidade num Diagrama ER
Nos Diagramas ER, os Atributos das Entidades aparecem com o seu nome num compartimento diferente da Entidade a que pertencem.
As restrições nos diagramas ER definem as limitações sobre os dados no esquema de informação.
Existem quatro tipos de restrições suportados no Umbrello :
Chave Primária: O conjunto de atributos declarado como chave primária é único para a entidade. Só poderá existir uma chave primária numa Entidade e nenhum dos seus atributos constituintes poderá ser nulo.
Chave Única: O conjunto de atributos declarado como chave única é único para a entidade. Poderão existir várias restrições de chaves únicas. Os seus atributos constituintes poderão ser nulos. As Chaves Únicas e Chaves Primárias identificam de forma única uma linha numa tabela (entidade)
Chave Estrangeira: Uma Chave Estrangeira é uma restrição de referência entre duas tabelas. A chave estrangeira identifica uma coluna ou conjunto de colunas numa tabela (de referência) que aponta para uma coluna ou conjunto de colunas noutra tabela (referenciada). As colunas da tabela referenciada deverão formar uma chave primária ou única.
Restrição de Verificação: Uma restrição de verificação (também conhecida como restrição de verificação de tabelas) é uma condição que define os dados válidos ao adicionar ou actualizar um item numa tabela de uma base de dados relacional. Uma restrição de verificação é aplicada a cada linha na tabela. A tabela deverá ser um predicado. Poderá fazer uma referência a uma ou várias colunas da tabela.
Exemplo: preço >= 0
A especialização é uma forma de criar novas entidades com base em entidades que já tenham sido definidas. As entidades novas, conhecidas como entidades derivadas, recebem (ou herdam) os atributos das entidades pré-existentes, as quais são referenciadas como entidades de base. Pretende ajudar a reutilizar os dados existentes com poucas ou nenhumas modificações.
No Umbrello, uma pessoa poderá definir Especializações Disjuntas e Sobrepostas
A Especialização Disjunta define que as sub-classes da especialização deverão ser disjuntas. Isto significa que uma entidade poderá ser um membro de no máximo uma das entidades derivadas da especialização
Representação visual de uma Especialização Disjunta num Diagrama ER
Quando as entidades derivadas não estão restritas para serem disjuntas, o seu conjunto de entidades são consideradas uma especialização sobreposta. Isto significa que a mesma entidade no mundo real poderá ser um membro de mais de uma entidade derivada da especialização
Representação visual de uma Especialização Sobreposta num Diagrama ER
Diz-se que uma entidade derivada é uma Categoria quando representa uma colecção de objectos que é um sub-conjunto da União dos tipos de entidades distintos. Uma categoria modela-se quando surge a necessidade de uma relação única de super-classe/sub-classe com mais de uma super-classe, onde as super-classes representam diferentes tipos de entidades (como acontece na herança múltipla da Programação Orientada por Objectos ).
Representação visual de uma categoria num Diagrama ER