Tipos de Diagramas

Nesta seção, apresentar-se-ão os principais diagramas de UML. Os diagramas apresentados nas seções 2.3.2.1, 2.3.2.2, 2.3.2.5 e 2.3.2.8 foram elaborados no contexto deste projeto e apresentar-se-ão na seção 3.

Dar-se-á a explicação dos diagramas, com maior ênfase nos diagramas elaborados neste projeto. Utilizar-se-ão, como base, os manuais: (FOWLER e SCOTT, 2000), (RUMBAUGH, JACOBSON e BOOCH, 2005) e (AMBLER, 2005). O objetivo desta seção não é servir como guia para implementação de diagramas UML, mas fornecer a base teórica para a compreensão daqueles elaborados neste projeto. Para utilização como guia, recomenda-se o uso do manual do autor (AMBLER, 2005).

2.3.2.1 Diagramas de Caso de Uso

Antes de iniciar a explicação do diagrama, necessita-se a compreensão dos conceitos de ator e caso de uso.

Um ator é a idealização de alguém ou algo que utiliza o sistema modelado. Ou seja, o ator pode ser uma pessoa, uma organização, um sistema externo, entre outros. Durante a execução do software, um usuário dele pode ser representado por vários atores, assim como vários usuários podem ser representados pelo mesmo ator. Representam-se os atores por bonecos “palito” no diagrama (RUMBAUGH, JACOBSON e BOOCH, 2005).

Já, um caso de uso é uma funcionalidade vista externamente pelos atores, representando um comportamento do sistema (RUMBAUGH, JACOBSON e BOOCH, 2005). Também pode ser visto como uma sequência de ações que geram valor a um ator. Representa-se um caso de uso por uma elipse no diagrama (AMBLER, 2005).

Um diagrama de caso de uso é, então, segundo (RUMBAUGH, JACOBSON e BOOCH, 2005), “um diagrama que mostra os relacionamentos entre atores e casos de uso dentro de um sistema”3_.

Os casos de uso podem participar de diversos tipos de relacionamento: associação, generalização, inclusão e extensão. Representam-se os relacionamentos por linhas no diagrama de caso de uso (RUMBAUGH, JACOBSON e BOOCH, 2005).

A associação possui a função de conectar um caso de uso com um ator que participa desse caso (RUMBAUGH, JACOBSON e BOOCH, 2005).

A generalização ocorre quando há um caso de uso, ou um ator, que é semelhante a um caso de uso base, ou um ator base, e herda características do seu parente, além de possuir outras características próprias (FOWLER e SCOTT, 2000).

Em um relacionamento do tipo include, um caso de uso base pode adicionar comportamentos de outro caso de uso (RUMBAUGH, JACOBSON e BOOCH, 2005), e sabe-se quando esse novo caso de uso será invocado, ou seja, sabe-se que em determinado momento, uma função, por exemplo, será invocada no código (AMBLER, 2005).

Já, um relacionamento do tipo extend, ocorre quando se insere um comportamento adicional em um caso de uso tido como base, dentro de determinadas condições, chamadas de pontos de extensão (FOWLER e SCOTT, 2000). Desse modo, não se sabe quando esse caso de uso pode acontecer e nem se ele vai ou não acontecer (AMBLER, 2005).

Esses conceitos ficam mais claros com um exemplo de diagrama de caso de uso, como o mostrado na Figura 11.

Primeiramente, nota-se a existência de dois atores: o estudante e o estudante internacional. O estudante internacional herda diversas características de um estudante regular, por isso, há uma seta, partindo do estudante internacional, apontada para o estudante. Entre os casos de uso, há generalização no de “matricular um membro da família na universidade”, que é um caso específico de “matricular um estudante na universidade”.

Além disso, nota-se que há uma extensão entre os casos de uso “fazer a verificação de segurança” e “matricular o estudante na universidade”. Isso ocorre, pois há uma sequência lógica entre esses dois casos de uso, que podem fazer com que o segundo caso de uso seja, ou não, executado.

Por fim, há uma inclusão entre “matricular o estudante na universidade” e “matricular no seminário”, pois sabe-se que a matrícula no seminário será realizada e sabe-se quando isso vai ocorrer.

Figura 11 - Diagrama de caso de uso.

Fonte: (AMBLER, 2005). 2.3.2.2 Diagramas de Classe

Utilizam-se os diagramas de classe para exibir as classes do sistema, as relações entre elas e os principais atributos e métodos delas. Esse tipo de diagrama auxilia na implementação de softwares com orientação à objetos (AMBLER, 2005).

As associações são as linhas que conectam as diversas classes no diagrama. Associações mais complexas, que possuem atributos e métodos para representá-las, podem ser inseridas em um diagrama de classes por meio de linhas tracejadas (AMBLER, 2005).

Uma associação também pode conter multiplicidade, indicando o número de objetos (exemplares de uma classe) que podem conter naquela associação. A multiplicidade é representada por números acima da linha de associação. Por exemplo, uma associação do tipo 1:*, indica que há uma instância da primeira classe, para múltiplas instâncias da segunda classe (RUMBAUGH, JACOBSON e BOOCH, 2005).

Mostra-se um exemplo de diagrama de classes na Figura 12. Nota- se que é possível, que nenhum estudante esteja relacionado a um curso, mas um estudante pode estar relacionado a múltiplos (*) cursos. A relação que une os estudantes e o curso é uma matrícula, que possui atributos e métodos próprios.

Figura 12 - Diagrama de classes.

Fonte: (AMBLER, 2005).

Utiliza-se uma simbologia em diagramas de classes para indicar a visibilidade de um atributo ou método, de acordo com o mostrado no Quadro 6.

Quadro 6 - Algoritmo do solver. Símbolo Descrição

+ Visibilidade pública, acessível a qualquer objeto no sistema - Visibilidade privada, acessível à classe que o implementa # Visibilidade protegida, acessível à classe que o implementa

e subclasses

~ Visibilidade no pacote, acessível à classes do mesmo pacote Fonte: (AMBLER, 2005).

2.3.2.3 Diagramas de Objetos

Utilizam-se diagramas de objetos para exibir instâncias, por exemplo, de um diagrama de classes, em determinado período. Desse modo, pode-se explorar situações reais de relacionamentos entre objetos do sistema (AMBLER, 2005).

Utilizando-se como exemplo, novamente, o do estudante, nota-se que no diagrama de objetos, dá-se nome às instâncias das classes, e criam- se variações delas, simulando possibilidades de execução real, conforme mostrado na Figura 13.

Figura 13 - Diagrama de objetos.

Fonte: (AMBLER, 2005). 2.3.2.4 Diagramas de Pacote

Pacotes de classes representam um conjunto de classes que possuem algo em comum, por exemplo, funcionalidades semelhantes, implementação conjunta, alta colaboração entre elas (AMBLER, 2005). Não se dispõe de regras para a separação de pacotes, mas deve-se ter em mente que esse procedimento visa facilitar a manutenção do modelo (RUMBAUGH, JACOBSON e BOOCH, 2005).

Um diagrama de pacotes, então, simboliza a relação entre diversos pacotes de um modelo. Dentro de cada pacote, podem conter classes, relações entre elas, casos de uso, e tudo o que seja exclusivo para aquele pacote (RUMBAUGH, JACOBSON e BOOCH, 2005).

Os pacotes são representados por desenhos semelhantes a uma pasta e as relações, por linhas tracejadas com uma seta ao final (RUMBAUGH, JACOBSON e BOOCH, 2005).

A Figura 14 mostra um exemplo de diagrama de pacotes para um subsistema de compra de tickets. Nota-se que é possível haver pacotes dentro de pacotes, no caso de esses pacotes possuírem características semelhantes. Além disso, há a dependência de pacotes externos para o funcionamento de classes dentro de um pacote, por exemplo, alguma classe do pacote de “seleção de assento” necessita algum atributo ou método de alguma classe do pacote de “banco de dados de assentos”.

Figura 14 - Diagrama de pacotes.

Fonte: (RUMBAUGH, JACOBSON e BOOCH, 2005).

Pode-se montar, também, diagramas de caso de uso para pacotes, como uma forma de organizar requisitos de uso (AMBLER, 2005). 2.3.2.5 Diagramas de Sequência

No diagrama de sequência, representa-se uma série de interações entre objetos, descrevendo-se a mensagem passada entre eles e a ordem (no tempo) em que elas são enviadas. Para isso, utiliza-se a dimensão vertical do diagrama para o tempo e a horizontal, para a participação dos objetos na interação (RUMBAUGH, JACOBSON e BOOCH, 2005).

Na Figura 15 mostra-se um exemplo de diagrama de sequência, novamente, para a compra de tickets. Nota-se a sequência de atividades que ocorre para a compra. Inicia-se a sequência com a solicitação do totem de atendimento, controlado por um usuário, passando-se a responsabilidade para o caixa. Após isso, os assentos disponíveis são mostrados e a responsabilidade retorna para o totem para a seleção. E assim por diante, até a conclusão da compra.

Figura 15 - Diagrama de sequência.

Fonte: (RUMBAUGH, JACOBSON e BOOCH, 2005).

A linha pontilhada na vertical representa a lifeline do objeto ao longo do tempo, ou seja, o que acontece durante a vida daquele objeto. A quantidade de tempo aumenta no eixo vertical de cima para baixo (RUMBAUGH, JACOBSON e BOOCH, 2005).

2.3.2.6 Diagramas de Comunicação

Assim como o diagrama de sequência, o diagrama de comunicação também mostra a interação entre os objetos, mas de maneira mais explícita (RUMBAUGH, JACOBSON e BOOCH, 2005), mostrando o papel de cada um deles na colaboração para a execução de alguma operação (AMBLER, 2005). Como não há uma dimensão de tempo, ao

contrário do diagrama de sequência, dá-se a noção de sequência utilizando-se números sequenciais no diagrama (RUMBAUGH, JACOBSON e BOOCH, 2005).

Utilizando-se o mesmo exemplo do diagrama de sequência, de compra de tickets, mostra-se um exemplo de diagrama de comunicação na Figura 16.

Figura 16 - Diagrama de comunicação.

Fonte: (RUMBAUGH, JACOBSON e BOOCH, 2005).

Nota-se, novamente, a existência de um totem de compras. A primeira interação começa no ato de uma requisição desse totem, indicada por um número 1, seguida por uma busca no banco de dados, número 2. Assim por diante, até retornar ao totem, no número 4, apresentando-o a oferta de assentos. A interação segue até a efetuação da compra.

2.3.2.7 Diagramas de Máquina de Estados

Por meio dos diagramas de máquina de estados, pode-se representar o comportamento dinâmico do programa, a partir de certo

estado, provocado por eventos. Com isso, prevê-se os rumos do programa quando esse é submetido a um evento (AMBLER, 2005).

Um estado pode ser definido por um conjunto de valores para os objetos em determinado período, que possuem um comportamento idêntico (RUMBAUGH, JACOBSON e BOOCH, 2005). Ou seja, para determinado estado, por exemplo, um estado “A”, o comportamento dele a um evento “X” será sempre igual.

No diagrama, desenha-se o estado em um retângulo com bordas arredondadas. As transições entre estados representam-se por setas e as condições de transição apresentam-se junto às setas (RUMBAUGH, JACOBSON e BOOCH, 2005). Na Figura 17, mostra-se um exemplo de diagrama de estados.

Figura 17 - Diagrama de estados.

Fonte: (RUMBAUGH, JACOBSON e BOOCH, 2005).

Nota-se, no exemplo, que há um estado inicial de “Aguardo”. Esse estado aguarda um evento, que pode ser de valor da ordem recebida “maior do que 25” ou “menor do que 25”. Para cada caso, ocorre a transição para um estado diferente. Espera-se chegar ao estado de “Processar Ordem”.

2.3.2.8 Diagramas de Atividades

Os diagramas de atividades mostram uma sequência de atividades realizadas em um programa. Esses diagramas fornecem suporte para ilustrar tanto comportamentos condicionais quanto paralelos das atividades (FOWLER e SCOTT, 2000). Faz-se isso por meio de um grafo de nodos e fluxos, mostrando o fluxo de controle no decorrer do programa executado (RUMBAUGH, JACOBSON e BOOCH, 2005). Desse modo, lendo-se o diagrama de cima para baixo, pode-se compreender os passos de computação para atingir determinado resultado.

Nesse tipo de diagrama, representam-se as atividades por um retângulo de bordas arredondadas e os fluxos de controle, por setas. Além disso, pode-se haver pontos de sincronização, que podem ser do tipo join ou fork, ambos representados por uma barra horizontal. Nos pontos do tipo join, aguarda-se o encerramento das atividades que se conectam na região superior da barra, antes de dar início à atividade conectada na região inferior dela. O inverso dos pontos do tipo join são os do tipo fork, nos quais, a partir de uma atividade conectada na parte superior da barra, executam-se outras atividades em paralelo, conectadas na parte inferior dela (RUMBAUGH, JACOBSON e BOOCH, 2005).

Na Figura 18 mostra-se um exemplo de um diagrama de atividades. Além dos elementos citados anteriormente, há também um losango entre algumas atividades. Essa forma indica que a passagem por aquela atividade para a próxima é condicional, ou seja, há um ponto de decisão do programa, que precisa respeitar as condições daquele ponto para ter prosseguimento (AMBLER, 2005).

O exemplo da Figura 18 se trata do processamento de uma ordem. O círculo preto preenchido representa o início do processo. Após a configuração inicial da ordem, há um ponto de decisão, verificando se é uma “ordem única” ou se é uma “inscrição”. Para cada caso, há um fluxo de programa diferente. É importante ressaltar que, caso os dois fluxos de código voltem a se cruzar novamente, um novo símbolo condicional deve ser colocado para juntar os fluxos. Isso ocorre no segundo losango do exemplo da Figura 18. O círculo preto preenchido com um círculo de raio maior ao seu redor indica o fim do processo.

Figura 18 - Diagrama de atividades.

Fonte: (RUMBAUGH, JACOBSON e BOOCH, 2005). 2.3.2.9 Diagramas de Componentes

Um componente pode representar um sistema físico ou uma parte de um sistema que possua uma lógica. Tem-se que o comportamento de um componente pode ser descrito de maneira concisa e suas interfaces com outros componentes também. Desse modo, por meio de um diagrama de componentes, pode-se compreender o papel daquele componente no sistema, suas interfaces com o mundo externo a ele, ou seja, com outros componentes e o sistema, mas não se compreende detalhes de sua implementação. Desse modo, pensando-se num sistema como um todo, poder-se-ia trocar um componente por outro que possua a mesma

funcionalidade e as mesmas interfaces (RUMBAUGH, JACOBSON e BOOCH, 2005).

Os componentes podem possuir interfaces que eles suportam, assim como eles necessitam de interfaces para poder funcionar. Pode-se pensar nessas interfaces como uma relação de dependência entre múltiplos componentes (RUMBAUGH, JACOBSON e BOOCH, 2005).

No diagrama, as interfaces suportadas representam-se por um círculo fechado e as interfaces necessárias, por um círculo semiaberto. Portas são representadas por um quadrado e as interfaces devem estar atreladas a uma porta (RUMBAUGH, JACOBSON e BOOCH, 2005). Mostra-se um exemplo de diagrama de componentes na Figura 19. Figura 19 - Diagrama de componentes.

Fonte: (RUMBAUGH, JACOBSON e BOOCH, 2005).

Um componente pode ser feito de outros componentes, que também possuem interfaces. Nota-se, no exemplo da Figura 19, que o componente “Sistema de Viagens” é feito com diversos outros componentes conectados internamente. Há um console com o usuário, como entrada de dados, e como saída, tem-se a realização da reserva. 2.3.2.10 Diagramas de Implementação

O diagrama de implementação mostra uma visão do sistema como um todo, em termos de componentes de hardware e software. Usa-se esse tipo de diagrama para analisar dependências que o sistema possa possuir

e prever possíveis problemas de instalação, por exemplo, definindo uma estratégia de implementação (AMBLER, 2005).

Nesse diagrama, pode-se ver o arranjo físico de nodos, ou seja, recursos computacionais, representados por um paralelepípedo. Por exemplo, no diagrama da Figura 20, mostra-se um nodo “servidor”, que se comunica com o nodo “cliente”. Os nodos podem conter artefatos, que são as entidades físicas, no caso do exemplo, um arquivo “.jar”. Porém, podem ser artefatos do tipo banco de dados, páginas da WEB, executáveis, entre outros (RUMBAUGH, JACOBSON e BOOCH, 2005). Figura 20 - Diagrama de implementação.

3 METODOLOGIA

No presente capítulo, descrever-se-á o desenvolvimento deste trabalho, considerando-se as principais etapas da execução: análise de requisitos, modelagem do software, definição de design e interações com o usuário do software, desenvolvimento do front-end e do back-end.

Nas seções referentes ao desenvolvimento, apresentar-se-ão tanto as condições do trabalho anteriormente elaborado, quanto as contribuições deste trabalho.