UML: seus diagrams e suas abstrações parte I

Definição

A UML é uma linguagem de modelagem criada por um esforço conjunto de diversos profissionais a fim de se desenvolver um modelo padronizado para modelagem de sistemas orientados a objetos. A UML possui 14 diagramas, e estes estão classificados de acordo com o tipo de "visão" (ora estático ou dinâmico) do modelo do sistema. Para Maiores detalhes vejam a imagem abaixo.


Imagem retirada de Wikipedia.
















Não precisamos decorar todos os diagramas, então iremos focar nos que vão nos ajudar a modelar sistemas menos complexos. Apertem os cintos que nossa viagem esta apenas começando!

Caso de Uso: Abstraindo os requisitos do sistema

Diagramas de Caso de Uso descrevem o comportamento do Sistema, ele descreve O QUE o Sistema vai fazer e QUEM vai usa-lo não COMO, isto faz com que este diagrama possua um alto grau de abstração. Diagramas de Casos de Uso o mantém focado nos objetivos do seu cliente e não em detalhes de implementação.

Quando usar

É muito comum usarmos este diagrama em reuniões iniciais com as partes envolvidas no sistema (stakeholders) pois os diagramas de Caso de Uso são fáceis de se entender, possibilitando que você consiga identificar as necessidades do cliente ou demais stakeholders de forma simples e objetiva (quando bem usados é claro).

Elementos

Os principais elementos que encontramos em diagramas de Caso de Uso são:

Ator: Pode ser uma pessoa (gerente, atendente, você...), uma entidade (empresa, organização...) até um sistema (uma impressora, web service...) que têm um papel bem definido no sistema, e que também pode estar envolvido em um mais Casos de Uso.

Ator

Caso de Uso: Um Caso de Uso descreve um cenário onde ações são realizadas. Então, temos por definição que um Caso de Uso descreve uma parte do comportamento do sistema, e um monte deles o comportamente geral deste sistema. Ah e não se esqueçam, Casos de Uso podem se associar com outros Casos de Uso.

Caso de Uso

Associações: Descrevem o relacionamento entre Atores e Casos de Uso, ou Atores e Atores e entre Casos de Usos. Para não estender muito o post de hoje, vamos ver apenas os relacionamentos <<extends>> e <<Include>>.

• Extends: A grosso modo este relacionamento cria uma dependência entre o Caso de Uso base e o Caso de Uso que deriva dele. Isto permite que o Caso de Uso que deriva (extends) possa continuar as atividades do Caso de Uso base.
• Includes: Ao contrário do <<extends>> um relacionamento do tipo <<include>> simplesmente pode ser entendido como 'opcional' ou seja, se um Caso de Uso precisar usar o comportamento de outro Caso de Uso ele simplesmente o invoca! Basicamente uma chamada de função.

Limite do Sistema: Como o nome já diz, tudo que estiver dentro deste limite descreve o sistema em si. Lembre-se, Atores não são representados aqui, apenas Casos de Uso!

Limite/Fronteira do Sistema

Exemplo

Este exemplo é bem simples mesmo, afinal ainda estamos assimilando o conteúdo novo certo? Notem a imagem abaixo, temos um Ator, Anunciante, alguns Casos de Uso, relacionamentos e um Ator abstrato, Web Service.

Exemplo de Caso de Uso bem simples



















Aqui o Sistema permite ao Anunciante a Realizar Login e Cadastrar um novo Anuncio. Vejam os relacionamentos, o Caso de Uso Realizar Login têm dependência com Autenticar Usuário! Realizar Login só poderá concluir seu comportamento somente após Autenticar Usuário ter terminado o seu (comportamento).

Já com Cadastrar Anuncio, temos um relacionamento do tipo <<extends>> com um Web Service. Digamos que para este exemplo um Anuncio poderia ter um endereço que não o do Anunciante fazendo com que tivéssemos que acionar (invocar) um serviço de um Web Service (imagine solicitar um CEP para os Correios) desta forma, como poderíamos optar por ou usar o endereço do Anunciante, ou solicitar isto para outro Ator (Web Service).

Conclusão

Bom pessoal, espero que tenham gostado deste post, não está extraordinário mas se tiver ajudado alguém já valeu o esforço =)

Então nos vemos no próximo post? Okie dokie!