Panorama da notação UML

Transcrição

1 Panorama da notação UML A notação UML (Unified Modeling Language linguagem de modelagem unificada) evoluiu desde que foi adotada a primeira vez como um padrão em Uma revisão maior para o padrão foi feita em 2003, então a atual versão para o padrão é UML 2. As versões anteriores do padrão são referidas como UML 1.x. A notação UML tem crescido substancialmente ao longo dos anos, e suporta muitos diagramas. Diagramas UML A notação UML suporta os seguintes diagramas para desenvolvimento de aplicações: Diagrama de casos e usos Diagrama de classe Diagrama de objeto Diagrama de comunicação Diagrama de sequência Diagrama de máquina de estado Diagrama de atividade Diagrama de estrutura composta Diagrama de desenvolvimento Diagrama de casos e usos Um ator inicia um caso de uso. Um caso de uso define uma sequência de interações entre o ator e o sistema. Um ator é retratado como uma figura em forma de vara ou vareta no diagrama de caso de uso. O sistema é retratado como uma caixa. Um caso de uso é retratado como uma elipse dentro da caixa. Associações de comunicação conectam atores com os casos de uso no qual eles participam. Relacionamentos entre casos e uso são definidos por significados de relacionamentos de inclusão e extensão.

2 Classes e objetos Classes e objetos são retratados como caixas na notação UML, como mostra a figura abaixo. A caixa classe sempre mantém o nome da classe. Opcionalmente, os atributos e operações de uma classe também podem ser retratados. Quando todos os três são retratados, o topo do compartimento da baixa mantém o nome da classe, o compartimento do meio contém os atributos, e o compartimento de baixo contém as operações. Para distinguir entre uma classe (o tipo) e um objeto (uma instância do tipo), um nome de objeto é mostrado sublinhado. Um objeto pode ser retratado na íntegra com o nome do objeto separado por dois pontos do nome da classe por exemplo, umobjeto : Classe. Opcionalmente, os dois pontos e o nome da classe podem ser omitidos, deixando apenas o nome do objeto por exemplo, umobjeto. Outra opção é omitir o nome do objeto e retratar apenas o nome da classe depois dos dois pontos, como em : Classe. Classes e objetos são retratados em vários diagramas UML. Diagramas de classe Em um diagrama de classe, classes são retratadas como caixas, e o relacionamento estático (permanente) entre elas são retratados como linhas que conectam as caixas. Os três tipos principais de relacionamentos entre classes que são suportados: associações, relacionamento completo/parcial, e relacionamentos de generalização/especialização, como mostrado na figura abaixo. Um quarto relacionamento, relação de dependência, é frequentemente usado para mostrar como pacotes são relacionados.

3 Associações Uma associação é um relacionamento estático estrutural entre duas ou mais classes. Uma associação entre duas classes, que se refere como uma associação binária, é retratado como uma linha ligando as duas caixas de classe, por exemplo a linha que conecta a caixa da ClasseA com a caixa da ClasseB na figura abaixo. A multiplicidade de uma associação especifica como muitas instâncias de uma classe pode se relacionar com uma única instância de outra classe. A multiplicidade de uma associação pode ser exatamente (1), opcional (0..1), zero ou mais (*), um ou mais (1..*), ou especificado numericamente (m..n), onde m e n tem valores numéricos. Hierarquias de agregação e composição Hierarquias de agregação e composição são relacionamentos todo/parte. O relacionamento de composição (mostrado por um losango preto) é uma forma mais forte do relacionamento todo/parte que o relacionamento de agregação (mostrado por um losango vazado). O losango toca a caixa da classe de agregada ou composta (toda classe).

4 Hierarquia de generalização/especialização A hierarquia de generalização/especialização é um relacionamento de herança. Uma generalização é retratado como uma seta unindo a subclasse (filho) para a superclasse (pai), com a ponta da seta tocando a caixa da superclasse. Visibilidade Visibilidade refere-se se um elemento da classe é visível de fora da classe, como retratado na figura abaixo. Retratar visibilidade é opcional no diagrama de classe. Visibilidade pública, indicado com um símbolo de +, significa que o elemento é visível fora da classe. Visibilidade privada, indicado com um símbolo de, significa que o elemento é visível somente dentro da classe que a define e é assim, oculta da outras classes. Visibilidade protegida, indicado com um símbolo de #, significa que o elemento é visível de dentro da classe que a define e dentro de todas as subclasses da classe. Diagramas de interação A UML tem dois tipos principais de diagramas de interação, que retrata como os objetos interagem: o diagrama de comunicação e o diagrama de sequência. Nesses diagramas de interação, objetos são retratados em caixas retangulares. Contudo, nomes de objetos não são sublinhados. Diagramas de comunicação Um diagrama de comunicação, que foi chamado de diagrama de colaboração na UML 1.x, mostra como objetos de cooperação interagem dinamicamente com cada outro por envio e recebimento de mensagens. O diagrama retrata a organização estrutural do objeto que interage. Objetos são mostrados como caixas, e linhas unindo as caixas representam a interconexão dos objetos. Setas adjacentes rotuladas para segmentos de círculo indicam o nome e direção da transmissão de mensagens entre os objetos. A sequência de mensagens passada entre os objetos é numerada. A notação para diagramas de comunicação é ilustrada na figura abaixo. Uma iteração (repetição) opcional é indicada por um asterisco (*), que significa que uma mensagem é enviada

5 mais de uma vez. Uma condição opcional significa que a mensagem é enviada somente se a condição for verdadeira. Diagrama de sequência Uma maneira diferente de ilustrar uma interação entre objetos é mostrá-los no diagrama de sequência, que retrata interação com objetos dispostos na sequência de tempo, como mostrado na figura abaixo. Um diagrama de sequência é um diagrama bidimensional no qual os objetos que participam na interação são retratados horizontalmente e a dimensão vertical representa o tempo. A partir de cada caixa de objeto está uma linha vertical tracejada, referido como lifeline. Opcionalmente, cada lifeline tem uma barra de ativação (não mostrada), retratada com uma linha dupla contínua, que mostra quando o objeto é a execução. O ator é normalmente mostrado na extremidade esquerda da página. Setas horizontais rotuladas representam mensagens. Somente a fonte e destino da seta são relevantes. A mensagem é enviada do objeto fonte para o objeto de destino. Aumenta o tempo do topo da página para a base. O espaço entre as mensagens não é relevante.

6 Diagramas de estado de máquina Na notação UML, o diagrama de estado de transição se refere como um diagrama de estado de máquina. Na notação UML, estados são representados por caixas arredondadas, e transições são representadas por arcos que se conectam as caixas arredondadas, como mostrado na figura abaixo. O estado inicial do gráfico de estado é retratado por um arco originário de um pequeno círculo preto. Opcionalmente, o estado final pode ser retratado por um pequeno círculo preto dentro de um círculo branco maior, algumas vezes referido como olho de boi. Um gráfico de estado pode ser hierarquicamente decomposto tal que um estado composto é desmembrado em subestados. Na representação do arco o estado de transição, a notação Evento [condição]/ação é usado. O evento causa o estado de transição. A condição opcional booleana deve ser verdadeira (true), quando o evento ocorre, para a transição realizarse. A ação opcional é realizada como um resultado da transição. Opcionalmente, um estado pode ter qualquer um dos seguintes: Uma ação de entrada, realizada quando o estado é entrado. Uma ação de saída, realizada na saída do estado. A figura acima retrata um estado composto. Um estado decomposto dentro de subestados sequenciais A1 e A2. Neste caso, o gráfico de estado está em apenas um estado por vez; que é, primeiro subestado A1 é entrado e então o subestado A2. A figura abaixo retrata estado composto B decomposto dentro de regiões ortogonais BC e BD. Nesse caso, o gráfico de estados está em cada região ortogonal, BC e BD, ao mesmo tempo. Cada subestado ortogonal é ainda mais decomposto dentro dos subestados seqüenciais. Desse modo, quando a combinação B é inicialmente inserido, cada um dos subestados B1 e B3 é também inserido.

7 Pacotes Em UML, um pacote é um grupo de elementos do modelo por exemplo, para representar um sistema ou subsistema. Um pacote é retratado por um ícone de pasta, um retângulo grande com um pequeno retângulo anexado em um canto, como mostra a figura abaixo. Pacotes podem também ser aninhados com outros pacotes. As relações possíveis entre pacotes são relacionamentos de dependência e generalização/ especialização. Pacotes podem ser usados para conter classes, objetos, ou casos e usos. Diagramas de desenvolvimento Um diagrama de desenvolvimento mostra a configuração física do sistema em termos de nós físicos e conexões físicas entre os nós, tal como conexões de rede. Um Nó é mostrado como um cubo, e a conexão é mostrada como uma linha que une os nós. Um diagrama de desenvolvimento é essencialmente um diagrama de classe que se concentra nos nós do sistema. A figura abaixo mostra dois exemplos de diagramas de desenvolvimento. No primeiro exemplo, os nós são conectados via uma rede de longa distância (WAN); no segundo, eles são conectados via uma rede local (LAN). No primeiro exemplo, o nó cliente ATM (que tem um nó para cada ATM) é conectado ao servidor Bank que tem um nó. Opcionalmente, os objetos que encontram-se no nó podem ser retratados no cubo nó. No segundo exemplo, a rede é mostrada como um cubo nó. Esse modelo de notação é usado quando mais que dois nós de computador são conectados por uma rede.

8 Exercícios Questões de múltipla escolha: para cada questão escolha uma das respostas. 1. Como um ator é retratado no diagrama de usos e casos? (a) Um oval (b) Uma figura na forma de vara (c) Uma caixa (d) Uma linha tracejada 2. Como um caso de uso é retratado no diagrama de casos e usos? (a) Um oval (b) Uma figura na forma de vara (c) Uma caixa (d) Uma linha tracejada 3. Como uma classe é retratada no diagrama de classe? (a) Uma caixa com um compartimento (b) Uma caixa com um ou dois compartimentos (c) Uma caixa com um, dois ou três compartimentos (d) Um oval 4. Como uma associação é retratada no diagrama de classe? (a) Uma linha sólida ligando duas caixas de classe (b) Uma linha tracejada ligando duas caixas de classe (c) Um losango tocando a caixa de classe alta (d) Uma seta tocando a caixa de classe alta 5. Como a visibilidade pública é retratada para um elemento de classe ou um diagrama de classe? (a) Sinal de + (b) Sinal de (c) Sinal de #

9 (d) Sinal de * 6. Quais são os dois tipos de diagramas de interação UML? (a) Diagrama de classe e diagrama de sequência (b) Diagrama de sequência e diagrama de comunicação (c) Diagrama de classe e diagrama de comunicação (d) Gráfico de estado e diagrama de comunicação 7. O que um diagrama de interação retrata? (a) Objetos e links (b) Classes e relacionamentos (c) Objetos e mensagens (d) Estados e eventos 8. O que um diagrama de gráfico de estado retrata? (a) Objetos e links (b) Classes e relacionamentos (c) Objetos e mensagens (d) Estados e eventos 9. O que é um pacote UML? (a) Uma caixa (b) Um grupo de classes (c) Um grupo de casos e usos (d) Um grupo de elementos do modelo 10. O que um diagrama de desenvolvimento retrata? (a) A configuração física do sistema em termos de classes físicas e conexões físicas entre as classes. (b) A configuração física do sistema em termos de objetos físicos e conexões físicas entre os objetos. (c) A configuração física do sistema em termos de nós físicos e conexões físicas entre os nós. (d) A configuração física do sistema em termos de computadores físicos e redes físicas de computadores. Bibliografia Software modeling and design: UML, use cases, patterns, and software architectures Hassan Gomaa USA: Cambridge University Press, 2011 Software systems architecture: working with stakeholders using viewpoints and perspectives Nick Rozanski, Eoin Woods USA: Pearson Education, Inc., 2005 Software Engineering Reviews and Audits Boyd L. Summers USA: Taylor and Francis Group, LLC, 2011