UML - Unified Modeling Language (UML) é uma linguagem de modelagem de dados e seus relacionamentos baseados em requisitos dos agentes ou sistema. A UML não é uma metodologia de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicação entre objetos.
Objetivos da UML
Os objetivos da UML são: especificação, documentação, estruturação para sub-visualização e maior visualização lógica do desenvolvimento completo de um sistema de informação. A UML é um modo de padronizar as formas de modelagem.
O Futuro da UML
Embora a UML defina uma linguagem precisa, ela não é uma barreira para futuros aperfeiçoamentos nos conceitos de modelagem. O desenvolvimento da UML foi baseado em técnicas antigas e marcantes da orientação a objetos, mas muitas outras influenciarão a linguagem em suas próximas versões. Muitas técnicas avançadas de modelagem podem ser definidas usando UML como base, podendo ser estendida sem se fazer necessário redefinir a sua estrutura interna.
História
A UML tem origem na compilação das “melhores práticas de engenharia” que provaram ter sucesso na modelagem de sistemas grandes e complexos. Sucedeu aos conceitos de Booch, OMT (Rumbaugh) e OOSE (Jacobson) fundindo-os numa única linguagem de modelagem comum e largamente utilizada. A UML pretende ser a linguagem de modelagem padrão para modelar sistemas concorrentes e distribuídos.
A UML ainda não é um padrão da indústria, mas esse objetivo está a tomar forma sob os auspícios do Object Management Group (OMG). O OMG pediu informação acerca de metodologias orientadas a objetos que pudessem criar uma linguagem rigorosa de modelagem de software. Muitos líderes da indústria responderam na esperança de ajudar a criar o padrão.
Os esforços para a criação da UML tiveram início em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. Com o objetivo de unificar os métodos Booch e OMT, decorrido um ano de trabalho, foi lançado, em outubro de 1995, o esboço da versão 0.8 do Unified Process – Processo Unificado (como era conhecido). Nesta mesma época, Jacobson se associou à Rational e o escopo do projeto da UML foi expandido para incorporar o método OOSE. Nasceu então, em junho de 1996, a versão 0.9 da UML.
Finalmente em 1997, a UML foi aprovada como padrão pelo OMG (Object Management Group), um consórcio internacional de empresas que define e ratifica padrões na área de Orientação a Objetos.
Visão Geral da UML
Elementos de um CASO DE USO
De estrutura:
Classe
Objetos
Interface
Componente
Colaboração
Nó
De comportamento:
Casos de uso
Iteração
Máquina de estados
De agrupamento:
Pacote
Modelo
Subsistema
Framework
De anotação:
Notas
Relacionamentos
Agregação
Associação
Composição
Generalização
UML usa os seguintes conceitos:
Ator
Atividade
Interface
Package ou Pacote
Classe
Evento
CASO DE USO
Caso de Uso é uma técnica de modelagem de requisitos que descreve o que um sistema faz.
Deste modo, Caso de Uso é o envolvimento dos agentes com sistema para a realização de uma atividade necessária. Segundo Jacobson;
"um caso de uso é um documento narrativo que descreve a sequência de eventos de um ator que usa um sistema para completar um processo".
A ferramenta descreve como os usuários interagem com o sistema (as funcionalidades do sistema) , dando uma visão externa do sistema , indicando o conjunto de casos de uso necessário para se comunicar a funcionalidade e o comportamento do sistema para o cliente - agente(ator). No entanto, o caso de uso descreve o que o sistema faz, mas NÃO especifica como isso deve ser feito, e, geralmente é definido por um verbo, que simboliza uma ação.
Veja um Exemplo de diagrama de caso de uso...
No caso, vemos um atendente que vende CDs e um Gerente que Administra o estoque e também vende CDs.
No entanto, Atendente e Gerente o que são no diagrama ? Veremos os Atores/Agentes a seguir.
Atores
Os atores ou Agentes representam os papéis desempenhados por elementos externos ao sistema
• Ex: humano (usuário), dispositivo de hardware ou outro sistema (cliente)
Agentes são elementos que interagem com o sistema.
Representação Gráfica:
Mas, como foram identificados os atores no caso da loja de CDs, o primeiro passo para a confecção do diagrama de caso de uso é o domínio do ambiente espacial e operacional dos eventos existentes. Veja uma descrição de como os Agentes foram encontrados.
"– Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos. "
Desta forma, identificamos como Agentes o Atendente e o Gerente, e, note ainda que o Cliente não é agente para este caso já que não tem envolvimento com o Sistema.
Agora observe como foram encontrados os eventos - atividades - ações que o estudo de caso - caso de uso possui. Observe o trecho novamente que as ações estão lá, veja os casos do esquema...
"– Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao atendente, ou seja, ele também atende os clientes durante a venda dos discos."
Agora identificamos as ações, isto é, os casos de uso do sistema. Vamos representá-los sempre com os balões. Veja
Certo! Agora que temos os casos de uso (ações) e os agentes teremos que observar como eles se relacionam. Estes relacionamentos podem ser variados e possuem suas características próprias.
Relacionamento de Associação
Este tipo de relacionamento indica que há uma interação (comunicação) entre um caso de uso e um ator, no entanto, Associações NÃO representam fluxo de informação, apenas que eles podem se comunicar.Um ator pode se comunicar com vários casos de uso
Veja o Diagrama;
O gráfico indica um agente e sua relação com o caso de uso.
Vamos voltar ao exemplo da loja de Cds e ver como as relações de associação existem.
Agora temos o atendente que se relaciona com a venda de CDs, assim como o gerente e o gerente que se relaciona com a administração do estoque.
Relacionamento de Generalização
Generalização de Atores
Dizemos que houve generalização de Atores quando dois ou mais atores podem se comunicar com o mesmo conjunto de casos de uso ou um filho (herdeiro) pode se comunicar com todos os casos de uso que seu pai se comunica. No exemplo da loja de CD, o Gerente é o filho do Atendente e deste modo consegue fazer tudo o que o atendente faz.
Veja;
Generalização de Casos de Uso
Quando generalização acontece em caso de uso o caso de uso filho herda o comportamento e o significado do caso de uso pai, assim como o caso de uso filho pode incluir ou sobrescrever o comportamento do caso de uso pai. Pode ainda o caso de uso filho substituir o caso de uso pai em qualquer lugar que ele apareça. Note que Generalização de Caso de Uso deve ser aplicada quando uma condição resulta na definição de diversos fluxos alternativos.
Vamos acrescentar itens ao comportamento ao sistema em estudo - A Loja de Cds. Veja;
Novos requisitos:
– As vendas podem ser à vista ou a prazo. Em ambos os casos o estoque é atualizado e uma nota fiscal, entregue ao consumidor.
• No caso de uma venda à vista, clientes cadastrados na loja e que compram mais
de 5 CDs de uma só vez ganham um desconto de 1% para cada ano de cadastro.
• No caso de uma venda a prazo, ela pode ser parcelada em 2 pagamentos com um acréscimo de 20%. As vendas a prazo podem ser pagas no cartão ou no boleto. Para pagamento com boleto, são gerados boletos bancários que são entregues ao cliente e armazenados no sistema para lançamento posterior no caixa. Para pagamento com cartão, os clientes com mais de 10 anos de cadastro na loja ganham o mesmo desconto das compras a vista.
Veja o Diagrama de caso de uso com as novas informações.
Vender Cds a prazo ou a vista ainda é uma ação de Vender CDs e pode ser realizado pelo Atendente ou pelo Gerente.
Observe ainda mais generalizações dos relacionamentos de Vender a Prazo.
Agora as vendar de CDs podem ser a prazo ou a vista, e, quando a prazo podem ser Boleto ou Cartão.
Relacionamento de Dependência
Extensão:
Extensão como dependência de relacionamento é uma variação/extensão do comportamento do caso de uso base que é estendido e só é executado sob certas circunstâncias, separando partes obrigatórias de partes opcionais.
Considere o seguinte critério:
– No caso de uma venda à vista, clientes cadastrados na loja e que compram mais de 5 CDs de uma só vez ganham um desconto de 1% para cada ano de cadastro.
– No caso de uma venda a prazo para pagamento com cartão, os clientes com mais de 10 anos de cadastro na loja ganham o mesmo desconto das compras à vista.
Deste modo temos partes opcionais que serão realizadas somente em certa situação, causando a extensão do caso de uso para uma nova ação. Veja;
Agora vemos que quando o pagamento é a vista ou com o cartão (respeitando as condições) o calculo do desconto será realizado. EXTEND tem a linha da seta pontilhada, dizendo que aquela relação é condicional.
Relacionamento de Dependência
Inclusão
A inclusão é a relação utilizada para evitar repetição ao fatorar uma atividade comum a dois ou mais casos de uso, ou, quando um caso de uso pode incluir vários casos de uso
Considere;
Para efetuar vendas ou administrar estoque, atendentes e gerentes terão que validar suas respectivas senhas de acesso ao sistema.
Assim, ambos os usuários devem utilizar do sistema para alteração apenas logado.
Veja o diagrama.
Então temos os casos de uso <<include>> que são obrigatórios para se realizar as atividades de administrar o estoque ou vender cds.
Note que a linha também é marcada (pontilhada) devido a sua condição.
Porém o Caso de Uso não acaba por aqui. Ainda temos a descrição que pode ser detalhada ou resumida para elencar os procedimentos previstos pelos desenvolvedores. Veja um exemplo de descrição do Agente Atendente.
Pronto! Pronto!
Fontes:PUC - Rio
Nenhum comentário:
Postar um comentário