Modelação baseada em UML

Nesta secção, são discutidos os diagramas definidos na UML [65], que se tornou numa linguagem de modelação padrão para modelação orientada a objetos. A UML tem vários tipos de diagrama, e portanto, suporta a criação de muitos tipos diferentes de modelos do sistema [38], [60]:

1. Diagramas de atividades (activity diagrams), que mostram as atividades envolvidas num processo ou no processamento de dados;

2. Diagramas de casos de uso (use case diagrams), que mostram as interações entre um sistema e o seu ambiente;

3. Diagramas de sequência (sequence diagrams), que mostram interações entre os atores, o sistema e os componentes do sistema.

4. Diagramas de classes (class diagrams), que mostram as classes de objetos no sistema e as associações entre essas classes;

5. Diagramas de estados (statechart diagrams), que mostram como o sistema reage a eventos internos e externos.

6. Diagramas de objetos (Object diagrams), permite representar um conjunto de objetos e mostrar um exemplo de interação entre eles. Representa um momento na interação de objetos (um snapshot).

No sentido de se evitar a que esta secção se torne demasiado extenso, o foco é perceber como os seis tipos principais de diagramas UML são usados na modelação de sistemas. No entanto existem mais diagramas previstos na notação.

Ao desenvolver modelos do sistema, muitas vezes é preciso ser flexível na forma como a notação gráfica é usada. Nem sempre é preciso seguir de modo rígido os detalhes de uma

49

notação. O detalhe e o rigor de um modelo dependem de como se pretende usá-lo. Existem três formas pelas quais os modelos podem ser usados [22]:

1. Como meio para facilitar a discussão sobre um sistema existente ou proposto; 2. Como forma de documentar um sistema existente;

3. Como uma descrição detalhada do sistema que pode ser usada para desenvolver uma implementação do sistema.

No primeiro caso, o objetivo do modelo é estimular a discussão entre os engenheiros de

software envolvidos no desenvolvimento do sistema e o cliente. Os modelos podem estar

incompletos (desde que cubram os pontos-chave da discussão) e podem usar a notação de modelação informalmente [15]. É assim que os modelos são normalmente usados na chamada "modelação ágil" [66]. Quando os modelos são usados como documentação, eles não precisam ser completos, pois pode-se desejar apenas desenvolver modelos para algumas partes de um sistema [15].

No terceiro caso, onde os modelos são usados como parte de um processo de desenvolvimento baseado num modelo, os modelos do sistema devem ser completos, formais e corretos. A razão para isso é que eles são usados como base para gerar o código-fonte do sistema. Portanto, é necessário ter o máximo rigor uma vez que a geração pode ser automatizada [22], [67].

Diagramas UML

Abordam-se de seguida os diagramas UML mais importantes, de forma concisa e breve, permitindo ilustrar os aspetos mais significativos dos mesmos.

❖ Diagrama de Casos de Uso. Um caso de uso (UC – Use Case) representa uma interação entre um utilizador e o sistema [65]. A identificação dos UCs é muito importante na medida em que desta forma se recolhem os requisitos funcionais do sistema que se vai modelar. Uma mais-valia deste processo de recolha de requisitos está relacionada com o facto de que é nesta fase que o cliente, ou utilizadores, mais intervêm no processo. É indicativo que a captura de requisitos seja feita utilizando o vocabulário do utilizador, permitindo assim diminuir significativamente a

50

distância entre a equipa de projeto e os seus conceitos, e a visão do sistema fornecida por parte de quem o vai utilizar [60].

Figura 12 - Exemplo de um diagrama de casos de uso [60]

Os diagramas de casos de uso (Figura 12) são utilizados para ilustrar as respostas de um sistema. Os diagramas de UC são especialmente importantes na organização e modelação de comportamentos esperados do sistema [65].

❖ Diagrama de Sequência. Um diagrama de sequência é um diagrama de interação que enfatiza a ordem do tempo das mensagens [60]. Um diagrama de sequência mostra um conjunto de objetos e as mensagens enviadas e recebidas por esses objetos [68]. Os objetos são geralmente

51

instâncias nomeadas ou anônimas de classes, mas também podem representar instâncias de outras coisas, como colaborações, componentes e nós. Os diagramas de sequência são usados para ilustrar a visualização dinâmica de um sistema [65].

A Figura 13 apresenta um diagrama de sequência onde se ilustra a maioria dos conceitos presentes nestes diagramas: objetos, mensagens, períodos de inatividade e anotações textuais [60].

Figura 13 - Exemplo de um diagrama de sequência [15]

Os diagramas de sequência são utilizados sempre que se pretende detalhar o comportamento de vários objetos no contexto de um cenário de um caso de uso. Permitem estabelecer as características base da colaboração entre os objetos e são uma representação de alto nível do algoritmo que vai ser implementado [60].

52

Diagrama de interação é o nome dado a todos os diagramas de sequência juntamente com os diagramas de colaboração. Todos os diagramas de sequência e colaborações são diagramas de interação [65]

❖ Diagrama de Classes. Os diagramas de classe existentes em UML são semelhantes aos diagramas encontrados em todas as metodologias orientadas aos objetos. O conceito de classe é um conceito central no paradigma e qualquer metodologia orientada aos objetos privilegia esta vista pois está muito próxima dos conceitos do paradigma e das próprias linguagens de programação [60].

O diagrama de classes ilustra a componente estrutural do sistema e identifica claramente as classes, interfaces e respetivas relações existentes no sistema [65]. Os diagramas de classe são também um mecanismo necessário para a criação de outros diagramas, como sejam os de componentes e de implementação (deployment) [60].

Em UML existem genericamente cinco tipos diferentes de relacionamento entre as classes (Figura 14).

53

Uma das vantagens dos diagramas de classes é o facto de permitirem que lhes seja adicionada informação sobre o estado dos objetos, seus tipos de dados e nível de visibilidade, sobre as operações e a sua assinatura. Permitem efetuar num nível visual o mesmo esforço que um programador faz a nível de uma linguagem de programação orientada a objetos, apenas não descrevendo os algoritmos das operações [60].