A esta linguagem será dada mais ênfase, já que e utilizada como comparativo com o complemento final do trabalho atual, a LUMS.
linguagem de diagramação ou notação para especificar, visualizar e documentar modelos de sistemas de software Orientados à Objeto e tem um uso limitado para outros paradigmas de programação. É um método de desenvolvimento, portanto ela não diz os passos iniciais ou como desenhar o sistema, mas ajuda a visualizar seu desenho e a comunicação entre objetos. Seu controle é feito pelo Grupo de Gerenciamento de Objeto (Object Management Group - OMG) e é um padrão da indústria para descrever graficamente um software.
A UML é composta por muitos elementos de modelo que representam as diferentes partes de um sistema de software. Os recursos da UML são usados para criar diagramas, que representam uma determinada parte, ou um ponto de vista do sistema. A seguir são citados os tipos de diagramas são suportados pelo Umbrello UML Modeller (FURLAN, 1998; RUMBAUGH, 1994):
• Diagrama de Caso de Uso;
• Diagrama de Classe; • Diagrama de Seqüência; • Diagrama de Colaboração; • Diagrama de Estado; • Diagrama de Atividade; • Diagrama de Componente; • Diagrama de Distribuição.
Figura 44 - Diagrama Use-Case. Fonte: SILVA, 2001.
O diagrama de use-cases da Figura 444 demonstra as funções de um ator externo de um sistema de controle bancário. Nele estão as Funções do administrador do banco. Este dia- grama se resume a determinar que funções devam ser suportadas pelo sistema modelado e não com a implementação de cada uma destas funções.
As classes se relacionam assim: associação (conectadas entre si), dependência (uma classe depende ou usa outra classe), especialização (uma classe é uma especialização de outra classe), ou em pacotes (classes agrupadas por características similares) (SILVA, 2001; FURLAN, 1998).
O diagrama de classes visto no exemplo da Fig. 45 demonstra a estrutura estática das classes de um sistema e nela está o que é gerenciado pela aplicação modelada. Ele representa que um cliente possui nenhum ou vários contratos de aluguel de veículos de uma companhia de aluguel. São vários tipos e modelos de veículos que podem ser alugados.
C o m p a h ia d e A lu g u e l d e V e íc u lo s C lie n t e 0 . . * 0 . .1 C a rro S p o r t C a m in h ã o C a r ro d e P a s s e io C o n t ra t o d e A lu g u e l 1 1 1 V e í c u lo A lu g a d o 1 0 .. * re f e re a p o s s u i p o s s u i T ip o s d e V e íc u lo s
Figura 45 - Diagrama de Classes. Fonte: SILVA, 2001.
A diferença do diagrama de classes com o diagrama de objetos (Fig. 46) é que o últi- mo mostra os objetos que foram instanciados das classes. O diagrama de objetos é como se fosse o perfil do sistema em certo momento de sua execução. Os diagramas de objetos não são tão importantes como os diagramas de classes Também são usados como parte dos dia- gramas de colaboração. Nele a colaboração dinâmica entre os objetos do sistema são mostra- dos (SILVA, 2001; FURLAN, 1998).
Figura 46 - Diagrama de Objetos. Fonte: SILVA, 2001.
tos de certa classe podem se encontrar e mostram também quais são os eventos dos sistemas que provocam essas mudanças e capturam o ciclo de vida dos objetos, subsistemas e sistemas. Ele mostra os estados que um objeto pode possuir e como os eventos (mensagens recebidas, timer, erros, e condições sendo satisfeitas) afetam estes estados ao passar do tempo. E é um complemento para a descrição das classes (FURLAN, 1998).
Uma transição de estado (o estado é mostrado como um retângulo com cantos arredondados) possui geralmente um evento ligado a ela. Se um evento é anexado a uma tran- sição mostrada como uma linha com uma seta no final de um dos estados, esta será executada quando o evento ocorrer. Se uma transição não possuir um evento ligado a ela, a mesma ocor- rerá quando a ação interna do código do estado for executada (se existir ações internas como entrar, sair, fazer ou outras ações definidas pelo desenvolvedor). Então quando todas as ações forem executadas pelo estado, a transição será disparada e serão iniciadas as atividades do próximo estado no diagrama de estados (FURLAN, 1998).
Figura 47 - Diagrama de Estado. Fonte: SILVA, 2001.
O diagrama de seqüência consiste em um número de objetos mostrado em linhas verti- cais e mostra a colaboração dinâmica entre os vários objetos de um sistema juntamente com seqüência de mensagens enviadas entre os objetos. O decorrer do tempo é visualizado obser- vando-se o diagrama no sentido vertical de cima para baixo. Possuem dois eixos: o eixo verti- cal, que mostra o tempo ou linha de vida, e o eixo horizontal, que mostra os objetos envolvi- dos na seqüência de certa atividade, com uma seta sólida que especifica se a mensagem é sín- crona, assíncrona ou simples. A mensagem que cria ou destrói um objeto é geralmente síncro- na. A concorrência também é observada, cada uma com sua linha de execução (thread). Se o sistema usa linhas concorrentes de controle, isto é mostrado como ativação, mensagens assín- cronas, ou objetos assíncronos
Figura 48 - Diagrama de Seqüência. Fonte: SILVA, 2001.
No diagramas de seqüências mostradas na Fig. 48 é representada a seqüência de exe- cução de impressão desde seu envio de um computador, passando pelo servidor de impressão, o qual envia para uma impressora livre e pronta, não estiver livre, o arquivo entra em uma fila de impressão. São as setas vazadas que indicam as mensagens enviadas de feedback para os diferentes objetos comunicando a fila, ou a impressão, da impressora para o servidor de im- pressão e este para o computador.
Pode-se escolher entre utilizar o diagrama de colaboração (ênfase for o contexto do sistema) ou o diagrama de seqüência (melhor quando o decorrer do tempo for importante). No diagrama de colaboração, além de mostrar a troca de mensagens dinâmica entre os objetos, também se mostra os objetos com os seus relacionamentos. A interação de mensagens é mos- trada em ambos os diagramas (FURLAN, 1998).
Figura 49 - Diagrama de Colaboração. Fonte: SILVA, 2001.
Na Fig. 49 se observa a ocorrência síncrona de acontecimentos, como a colocação de arquivos na fila de impressão enquanto outro está sendo impresso, mas isto dentro do proces- so de impressão. Também seria importante se fosse assim visualizado outros processos pode- riam estar ocorrendo enquanto acontecem as impressões. Ainda, todos estes diagramas pode- riam ser integrados. O que tornaria mais fácil o entendimento e leitura dos processos por que seria mais imediata a informação.
mostra o fluxo seqüencial das atividades.
Figura 50 - Diagrama de Atividade. Fonte: SILVA, 2001.
Na Fig. 50 como acontece a ação de um componente implementado no sistema. As- sim, quando um arquivo é enviado para imprimir é verificado o espaço para impressão, se es- tiver livre, é acionado o componente que mostra uma caixa de mensagem que avisa que a im- pressão está acontecendo, e após a o término é gerado um arquivo postscript que retira esta mensagem da tela. Se não tiver espaço para imprimir aparece um aviso disto, em seguida este processo de impressão termina.
FURLAN (1998) coloca que componentes são tipos, mas apenas componentes execu- táveis podem ter instâncias. Com o diagrama de componentes é facilmente visível detectar que arquivos .dll são necessários para executar a aplicação.
Figura 51 - Diagrama de Componente. Fonte: SILVA, 2001.
Na Fig. 51 são visualizados componentes, onde se podem definir interfaces que são vi- síveis para outros componentes. A interface é mostrada como uma linha partindo do compo- nente e com um círculo na outra extremidade. O nome é colocado junto do círculo no final da linha. Dependências entre componentes podem então apontar para a interface do componente que está sendo usada.
Na Fig 52 é representada a arquitetura física composta por componentes, que possuem a mesma simbologia dos componentes do diagrama de componentes, nodes, que significam objetos físicos que fazem parte do sistema. O diagrama de execução mostra a arquitetura físi- ca do hardware e do software no sistema (FURLAN, 1998; SILVA, 2001), que neste caso é uma máquina cliente numa LAN, uma máquina servidora, uma máquina servidora de Banco de Dados, seus protocolos de comunicação, etc., e conexões entre estes nodes e componentes que juntos compõem toda a arquitetura física do sistema.
Figura 52 - Diagrama de Execução. Fonte: SILVA, 2001.
Um fator importantíssimo é a reutilização, fator chave com o qual os modelos criados poderão facilmente ser reutilizados em outras aplicações. (FURLAN, 1998; SILVA, 2001)