UML Unified Modeling Language Rosana Cristina Colombo Dionysio Nelson Sadala Tavares Aprender é a única coisa de que a mente nunca se cansa, nunca tem medo e nunca se arrepende LEONARDO DA VINCI (Pintor, escultor, cientista, arquiteto,engenheiro e músico) 1452-1519
SUMÁRIO 1 UML (LINGUAGEM DE MODELAGEM UNIFICADA)... 4 2 DIAGRAMA DE CASO DE USO... 6 2.1 ELEMENTOS DO DIAGRAMA DE CASO DE USO... 6 2.1.1 Ator... 6 2.1.2 Caso de Uso... 7 2.1.3 Associação... 7 2.1.4 Especialização/Generalização... 8 2.1.5 Relacionamento include (inclusão)... 8 2.1.6 Relacionamento extend (extensão)... 9 2.2 DOCUMENTAÇÃO DO CASO DE USO... 9 3 DESENHANDO UM DIAGRAMA DE CASO DE USO...10 3.1 PASSO 1...10 3.2 PASSO 2...10 3.3 PASSO 3...11 3.4 PASSO 4...12 3.5 PASSO 5...13 4 DIAGRAMA DE ATIVIDADES...15 4.1 NOTAÇÃO DO DIAGRAMA DE ATIVIDADES...15 4.1.1 Atividades...15 4.1.2 Transições (Controle de Fluxo)...15 4.1.3 Condição de guarda...15 4.1.4 Decisões...16 4.1.5 Conectores...16 4.1.6 Início e fim...17 4.1.7 Concorrência...17 4.2 EXEMPLOS...18 4.2.1 Diagrama de Atividade - Fazer Pedido...18 4.2.2 Diagrama de Atividade Manter...19 4.2.3 Diagrama de Atividade Consultar...20
INTRODUÇÃO
1 UML (Linguagem de Modelagem Unificada) A UML (Unified Modeling Language) ou Linguagem de Modelagem Unificada é uma linguagem visual utilizada para modelar sistemas computacionais. Essa linguagem tornou-se, nos últimos anos, a linguagem padrão de modelagem de software adotada internacionalmente pela indústria de Engenharia de Software. A UML é a ferramenta ideal para conceber, compreender, testar, validar, arquitetar e ainda identificar todos os possíveis comportamentos do sistema. A UML não é uma linguagem de programação e sim uma linguagem de modelagem, cujo objetivo é auxiliar os engenheiros de software a definir as características do software, tais como seus requisitos, seu comportamento, sua estrutura lógica, a dinâmica de seus processos e até mesmo suas necessidades físicas em relação ao equipamento sobre o qual o sistema será implantado. A UML é independente tanto de linguagem de programação quanto de processos de desenvolvimento. Isso quer dizer que a UML pode ser utilizada para a modelagem de sistemas, não importa qual a linguagem de programação será utilizada na implementação do sistema, ou qual a forma (processo) de desenvolvimento adotada. Embora a concepção da UML tenha sido influenciada por vários métodos de análise e projeto orientados a objeto, há particularmente três notações das quais a UML é derivada: OOD (Projeto Orientado a Objetos) Grady Booch OMT ( Técnica de Modelagem de Objetos) James Rumbaugh OOSE (Engenharia de Software Orientada por Objetos) Ivar Jacobson Em 1997, a OMG (Object Management Group) tornou a UML uma linguagem de modelagem padrão para aplicações orientadas a objeto. A UML utiliza vários diagramas de modelagem, onde o objetivo é fornecer múltiplas visões do sistema a ser modelado. Cada diagrama analisa o sistema sob determinada ótica. Assim tem-se: Diagramas da UML Casos de Uso Classes Objetos Interação Transições de Estados Atividades Implementação Diagrama de Seqüência Diagrama de Colaboração Diagrama de Componente Diagrama de Implantação Figura 1 Diagramas definidos pela UML É importante destacar que, embora cada diagrama tenha sua utilidade, nem sempre é necessário modelar um sistema utilizando todos os diagramas, pois alguns deles possuem funções muito específicas (GUEDES, 2005, p.7). No decorrer desta apostila, serão descritos e exemplificados os diagramas de Caso de Uso e de Atividades.
Diagrama de Classes Definir o que é persistência.
2 Diagrama de Caso de Uso Esse diagrama procura demonstrar o comportamento externo do sistema, procurando apresentar o sistema através de uma perspectiva do usuário, demonstrando as funções e serviços oferecidos e quais usuários poderão utilizar cada serviço. O diagrama de Caso de Uso (Use Case) é um elemento gráfico usado para modelar o modo como as pessoas esperam usar um sistema. O diagrama descreve quem serão os usuários relevantes, os serviços que eles exigem do sistema e os serviços que eles precisam oferecer ao sistema. Casos de Uso são utilizados para identificar as regras do negócio e são uma excelente forma de entender o ponto de vista do usuário simplesmente pelo fato de que modela o que ele precisa executar. Internamente, um caso de uso é uma seqüência de ações que permeiam a execução completa de um comportamento esperado para o sistema, ou seja, possibilita identificar os fatores críticos de sucesso do sistema. O diagrama de Caso de Uso pode ser aplicado a muitos tipos de desenvolvimento, incluindo sistemas manuais, mas é usado mais comumente para sistemas e subsistemas. Um caso de uso representa quem faz o que com o sistema, sem considerar o comportamento interno do sistema, ou seja, não deve se preocupar com o como das funções. Um caso de uso modela um objetivo que o sistema precisa realizar a fim de que tenha sucesso. Acima de tudo, um diagrama de Caso de Uso deve ser simples, porém não pode ser incompleto. Resumindo, os casos de uso têm por objetivo: Descrever um conjunto de atividades de um sistema sob o ponto de vista de seus atores; Decidir e descrever os requisitos funcionais do sistema; Fornecer uma descrição clara e consistente do que o sistema deve fazer; Delimitar o contexto de um sistema. Identificar um caso de uso, portanto, envolve: Descobrir um ator (alguém que influencia ou é influenciado pelo sistema); Verificar para esse ator ações das quais ele participaria; Agrupar tais ações de forma que possuam um nome em comum (geralmente um verbo no infinitivo) 2.1 Elementos do diagrama de Caso de Uso Seis elementos de modelagem compõem o diagrama de Caso de Uso: atores, casos de uso, associações, relacionamentos e <<extend>>, e generalização. 2.1.1 Ator Um papel desempenhado por uma pessoa, sistema, dispositivo ou mesmo uma empresa, que possui interesse na operação bem-sucedida do sistema. O termo ator refere-se a um tipo de usuário, onde esses usuários são pessoas que utilizam o sistema. Porém os usuários podem ser outros sistemas, dispositivos ou ainda empresas que trocam informações. Um ator é um papel que uma entidade, externa ao sistema, desempenha em relação ao sistema. Vários tipos de ícones podem representar o papel de ator no sistema. Veja alguns exemplos: <<actor>> Sistema RH <<actor>> Entrada satélite
Figura 2 Formas de representação de atores 2.1.2 Caso de Uso Engenharia TI Finanças Identifica um comportamento-chave do sistema. Sem esse comportamento, o sistema não preencherá os requisitos do ator. Cada caso de uso expressa um objetivo que o sistema precisa alcançar e/ou um resultado que ele precisa produzir. O foco está na finalidade e não na implementação. As seqüências de ações realizadas por um caso de uso são as interações com os atores, e não os processos internos. Realizar Venda Figura 3 Forma de representação do caso de uso Realizar Venda Existem dois tipos de casos de uso: os primários e os secundários. Os casos de uso primários são aqueles que representam os objetivos principais do sistema. Exemplos: Realizar Venda, Matricular Aluno, etc. Os casos de uso secundários são aqueles que não trazem benefícios diretos para os atores, mas que são necessários para que o sistema funcione adequadamente. Exemplo: manutenção de cadastros. 2.1.3 Associação Identifica uma interação entre atores e casos de uso. O relacionamento é representado por uma linha entre um ator e um caso de uso. Cada associação torna-se um diálogo que deve ser explicado em uma narrativa de caso de uso. Diferentes atores podem acessar o mesmo caso de uso. O fato de um ator estar associado a um caso de uso significa que esse ator interage (troca informações) com o sistema. Um ator pode se relacionar com mais de um caso de uso do sistema. Fazer Pedido Figura 4 Forma de representação de associação
2.1.4 Especialização/Generalização Identifica um relacionamento de herança entre os atores ou entre casos de uso. Este relacionamento é uma forma de associação entre Casos de Uso/ Atores com características semelhantes, apresentando pequenas diferenças entre si. Privado Corporativo CliPrivPref CliPrivPadrão CliCorpPref CliCorpPadrão Figura 5 Forma de representação de generelização/especialização 2.1.5 Relacionamento include (inclusão) O relacionamento de inclusão existe somente entre casos de uso. Este relacionamento é utilizado quando existe uma situação ou rotina comum a mais de um Caso de Uso. Quando isso ocorre, a documentação dessa rotina é colocada em um Caso de Uso específico para que outros Casos de Uso utilizem-se desse serviço, evitando-se descrever uma mesma seqüência de passos em vários Casos de Uso. Identifica um caso de uso reutilizável, que é incorporado incondicionalmente na execução de outro caso de uso. Os relacionamentos de Inclusão indicam uma obrigatoriedade, ou seja, quando um determinado Caso de Uso possui um relacionamento de Inclusão com outro, a execução do primeiro obriga também a execução do segundo. Veja o exemplo: Gerar contas a receber Realizar Venda Baixar estoque Figura 6 Forma de representação de inclusão
2.1.6 Relacionamento extend (extensão) Este relacionamento é utilizado para descrever cenários opcionais ou excepcionais de um Caso de Uso, que somente ocorrerão se uma determinada condição for satisfeita. Identifica um caso de uso reutilizável, que interrompe condicionalmente a execução de outro caso de uso para aumentar sua funcionalidade. Dessa forma, quando um ator opta por executar a seqüência de interações definidas no caso de uso extend, este caso de uso é executado. Após sua execução, o fluxo de interações volta ao caso de uso anterior. A seta é desenhada da extensão para o caso de uso em execução. À medida que o caso de uso evolui e novas extensões são desenvolvidas, o caso de uso básico não precisa ser alterado a cada extensão nova ou revisada. O caso de uso que chama verifica uma condição para determinar se a extensão deve interromper o caso de uso que chama. Manter Fornecedor <<extend>> Se o fornecedor não for encontrado Ponto de extensão: Manter Fornecedor Manter Produto Usuário Figura 7 Forma de representação de extensão 2.2 Documentação do Caso de Uso A documentação de um Caso de Uso costuma descrever por meio de uma linguagem simples a função do Caso de Uso, destacando quais Atores interagem com o mesmo, quais etapas devem ser executadas pelo Ator e pelo sistema para que o Caso de Uso execute sua função, quais parâmetros devem ser fornecidos e quais restrições e validações o Caso de Uso deve possuir. Uma narrativa de caso de uso é um documento escrito que explica um caso de uso em um comportamento do sistema, com início, meio (diálogo) e fim (término). A narrativa do caso de uso normalmente inclui os seguintes elementos: Nome do Caso de Uso Título do Caso de Uso, da qual deve ser único. Atores Principal e Secundário Nome dos atores (papéis) que participam do Caso de Uso. Resumo Breve descrição do Caso de Uso, ou seja, qual o objetivo principal do Caso de Uso. Pré-condições Assim como as suposições, as pré-condições descrevem um estado do sistema que precisa ser verdadeiro antes que possa usar o caso de uso. Mas, ao contrário das suposições, essas condições são testadas pelo caso de uso antes de fazer algo mais. Se as condições não
forem verdadeiras, o caso de uso não será executado. Por exemplo: o cliente deve estar identificado no sistema. Fluxo Principal (Cenário Principal) O cenário do caso de uso refere-se a uma descrição passo a passo da interação entre o usuário (um ator ou outro caso de uso) e o caso de uso em execução. O fluxo principal descreve o que normalmente acontece quando o caso de uso é realizado. Fluxo Alternativo (Cenário Alternativo) Esses fluxos podem ser utilizados para descrever o que acontece quando o ator faz uma escolha alternativa, diferente da descrita no fluxo principal, para alcançar seu objetivo. Fluxos alternativos também podem ser utilizados para descrever situações de escolha exclusivas entre si (em que há diversas alternativas e somente uma deve ser realizada) (BEZERRA, 2002. p.67). Uma dúvida que pode existir durante a descrição de um caso de uso é se um determinado comportamento deve ser descrito como um fluxo alternativo ou como caso de uso de extensão. Pode-se considerar o seguinte: um fluxo alternativo descreve o comportamento alternativo para a execução do fluxo principal. Ao contrário, uma extensão descreve um comportamento que funciona como uma interrupção em relação ao caso de uso principal. Pós-condições Descrevem o estado que o sistema alcança após o caso de uso terminar. Regras de Negócio (Restrições/Validações) Contém as consistências que devem ser validadas durante o processo. As restrições são muitas vezes chamadas de Regras de Negócio. Exemplos: Um professor só pode estar lecionando disciplinas para as quais esteja habilitado; Senhas devem ter, no mínimo, seis caracteres, entre números e letras. 3 Desenhando um diagrama de Caso de Uso Para facilitar a criação de um diagrama de Caso de Uso, seguem alguns passos e exemplos. 3.1 Passo 1 Identifique aqueles que usarão o sistema de maneira direta, ou seja, identifique os atores. 3.2 Passo 2 Fornecedor Funcionário Escolha um desses atores e defina a visão dele, ou seja, o que ele quer do sistema cada um desses desejos torna-se um caso de uso. Fazer pedido Efetuar pagamento
Manter Produto Consultar Produto Consultar Fornecedor Consultar Consultar Cidade Efetuar Compra Manter Cidade Figura 8 Visões dos atores Funcionário Manter Fornecedor Manter 3.3 Passo 3 Observe se o caso de uso em questão possui alguma ligação com outro ator além do já especificado. Se acaso for necessário duplicar os atores, isso é possível. Realizar Venda Funcionário Manter cidade Manter cliente Consultar cidade Consultar cliente Funcionário Manter fornecedor Consultar fornecedor Efetuar pagamento Manter produto Fazer Pedido Consultar produto Figura 9 Ligações entre casos de uso e atores Fornecedor
3.4 Passo 4 Verifique relações de include e extend entre os casos de uso. Efetuar baixa Funcionário Realizar Venda Manter cidade <<extend>> Manter cliente <<extend>> <<extend>> Consultar cidade Funcionário Manter fornecedor Consultar cliente Consultar fornecedor <<extend>> Manter produto Efetuar pagamento Fazer Pedido Consultar contas a receber Consultar produto Fornecedor Figura 10 Relações de include e extend entre os casos de uso
3.5 Passo 5 Faça a documentação para cada caso de uso. Realizar Venda Atores: e Funcionário Resumo: O funcionário efetua uma venda para o cliente Pré-condições: O funcionário está identificado pelo sistema Fluxo Principal: 1. O funcionário abre uma nova venda 2. O sistema gera automaticamente um número para a venda e insere a data 3. O sistema apresenta uma lista de nomes de clientes para que o funcionário selecione ou o funcionário abre Consultar s 4. O sistema apresenta uma lista de nomes de funcionários, onde é escolhido o nome que está efetuando a venda. 5. O funcionário salva a venda 6. O funcionário seleciona os produtos e insere as quantidades 7. O funcionário finaliza a venda, onde o sistema chama automaticamente os casos de uso Baixar Estoque e Gerar Parcelas 8. Se o funcionário desejar continuar a cadastrar vendas, o caso de uso volta ao passo 1; caso contrário o caso de uso termina. Fluxo Alternativo (1) O funcionário cancela a venda. Fluxo Alternativo (6) Se não há quantidade suficiente do produto para a venda o sistema informa e fornece a possibilidade da digitação de outra quantidade. Fluxo Alternativo (7) O funcionário somente salva a venda. Pós-condições: Venda registrada no sistema Regras de Negócio (Restrições/Validações): O campo número da venda deverá ser gerado automaticamente pelo sistema. Os campos cliente, funcionário e endereço são obrigatórios. Caso o usuário deixe uma dessas informações em branco, o sistema deverá emitir uma mensagem de obrigatoriedade de inserção dessas informações. Para cada produto selecionado, o sistema deverá trazer automaticamente o preço de venda do produto e calcular o valor total. Manter Atores: e Funcionário Resumo: O funcionário efetua a manutenção (inclusão, exclusão, alteração e consulta) do cliente Pré-condições: O funcionário está identificado pelo sistema Fluxo Principal: 1. O funcionário requisita a manutenção de clientes. 2. O sistema apresenta as opções que podem ser realizadas (inclusão, alteração, exclusão e consulta) de um cliente. 3. O funcionário escolhe uma das opções apresentadas 4. Se o funcionário optar por continuar a manutenção, o caso de uso retorna ao passo 2; caso contrário, o funcionário fechará a manutenção. Fluxo Alternativo (1): O funcionário cancela a manutenção de clientes. Fluxo Alternativo (3): Se o funcionário optar por inclusão
O funcionário abre Consultar Se cliente encontrado, o funcionário cancela a inclusão; caso contrário a) O sistema gera automaticamente o número do funcionário b) O funcionário entra com os dados do cliente e seleciona a cidade na lista apresentada pelo sistema c) O funcionário salva o cadastro Se o funcionário optar por exclusão O funcionário abre Consultar Se cliente não encontrado, o funcionário cancela a exclusão; caso contrário: a) O funcionário seleciona o cliente e requisita ao sistema a exclusão b) Se o cliente puder ser excluído, o sistema executa a remoção; caso contrário, o sistema avisa a impossibilidade de exclusão. Se o funcionário optar por alteração O funcionário abre Consultar Se cliente não encontrado, o funcionário cancela a alteração; caso contrário: a) O funcionário seleciona o cliente e altera seus dados b) O sistema salva as alterações Se o funcionário optar por consulta O funcionário abre Consultar Pós-condições: cliente inserido, alterado, consultado ou excluído. Regras de Negócio (Restrições/Validações): O campo código deverá ser gerado automaticamente pelo sistema Os campos código e cidade são obrigatórios. Consultar Atores: Funcionário Resumo: O funcionário realiza a consulta de clientes Pré-condições: O funcionário está identificado pelo sistema Fluxo Principal: 1. O funcionário abre a consulta de clientes 2. O sistema disponibiliza várias opções de filtro 3. O funcionário escolhe uma das opções 4. Se o funcionário optar por continuar a consulta, o caso de uso volta ao passo 2; caso contrário, o funcionário finaliza a consulta. Fluxo Alternativo (1): O funcionário cancela a consulta Fluxo Alternativo (3): Se o funcionário escolher consultar por nome O funcionário entra com o nome a ser localizado O sistema apresenta os dados obtidos Se o funcionário escolher consultar por cidade O funcionário entra com a cidade O sistema apresenta os dados obtidos Pós-condições: Apresentação das informações Regras de Negócios (Restrições/Validações): 1. Os clientes devem ser visualizados em ordem alfabética.
4 Diagrama de Atividades O diagrama de Atividades normalmente é visto como parte da visão funcional de um sistema, pois descreve processos lógicos, ou funções. Cada processo descreve uma seqüência de tarefas e decisões que controlam quando e como elas são realizadas. O Diagrama de Atividades é o diagrama com maior ênfase ao nível de algoritmo da UML e provavelmente um dos mais detalhistas. Este diagrama apresenta muitas semelhanças com os antigos fluxogramas utilizados para desenvolver a lógica de programação e determinar o fluxo de controle de um algoritmo. Um diagrama de atividades para um caso de uso explica como o ator interage com o sistema para realizar o objetivo do caso de uso, incluindo regras, informações trocadas, decisões toadas e produtos de trabalho criados. 4.1 Notação do diagrama de Atividades 4.1.1 Atividades Uma atividade é uma etapa de um processo, onde algum trabalho está sendo realizado. Esta etapa pode ser a realização de um cálculo, a localização de uma informação, a verificação de dados, etc. A atividade é representada por um retângulo arredondado, contendo texto em forma livre. Uma atividade na UML é um estado com apenas uma ação. Consultar 4.1.2 Transições (Controle de Fluxo) Um diagrama de Atividades é uma série de atividades ligadas por transições, setas conectando cada atividade. Normalmente a transição ocorre porque a atividade foi concluída. A UML vê cada transição como uma mudança de estado, uma mudança de uma atividade (estado de ação) para a seguinte. O controle de fluxo é representado por uma reta contendo uma seta apontando para a próxima atividade. Consultar Produto Alterar Produto 4.1.3 Condição de guarda Em alguns casos a transição só deve ser efetuada quando certas operações acontecerem. Neste caso é utilizada a condição de guarda, onde a condição precisa ser verdadeira antes que se possa seguir para a próxima atividade. Exemplo: o usuário não pode fechar o formulário antes de cancelar ou salvar uma venda em aberto. Abrir uma Venda [Cancelar ou Salvar a venda] Finalizar Programa
4.1.4 Decisões Uma estrutura de decisão é utilizada quando o usuário tem a opção de seguir para mais de uma atividade possível. Esta estrutura é representada por um losango, onde uma seta sai do losango para cada valor possível da condição testada. Cada opção é identificada por meio de uma condição de guarda, onde cada condição precisa ser mutuamente exclusiva, de modo que somente uma opção seja possível em qualquer ponto de decisão. Realizar saque Verificar saldo Mostrar a mensagem Saldo insuficiente [Não] Existe saldo suficiente na conta do cliente para cobrir o saque? [Sim] Dar baixa na conta 4.1.5 Conectores São basicamente atalhos para o fluxo, utilizados quando existe uma distância relativamente grande entre as atividades que o fluxo precisa ligar. A A
4.1.6 Início e fim A UML também oferece ícones para iniciar e terminar um diagrama de atividades. Pode haver mais de um ponto final em um diagrama de Atividades, ou então pode ser desenhado todas as setas para o mesmo ponto final. Os ícones são demonstrados na figura abaixo: Ponto inicial Ponto final Pode haver mais de um ponto final em um diagrama de Atividades ou também se podem desenhar todas as setas do diagrama para um mesmo ponto final. 4.1.7 Concorrência A concorrência descreve vários processos sendo executados simultaneamente. A barra de bifurcação mostra uma transição iniciando várias transições. A barra de sincronização mostra várias transições terminando e uma nova transição assumindo. Para mostrar a bifurcação ou sincronização, a UML utiliza uma barra simples. Veja: Bifurcação Sincronização Bifurcação Sincronização Figura 11 Formas de representação de concorrência
4.2 Exemplos 4.2.1 Diagrama de Atividade - Fazer Pedido Gerar nova venda Exibir lista de clientes [não encontrado] [não encontrado] Exibir lista de funcionários Incluir produtos [se continuar] [senão] Salvar Venda
4.2.2 Diagrama de Atividade Manter Apresentar opções Verificar opção [se encontrado] [se cadastrar] Consultar [senão] [senão] [senão] [se exclusão] [se alteração] Consultar cliente Incluir [se encontrado] Excluir Consultar cliente [se encontrado] Consultar cliente Alterar
4.2.3 Diagrama de Atividade Consultar Apresentar opções Verificar opção de filtro Consultar por nome [por nome] [por cidade] Consultar por cidade Apresentar dados
REFERÊNCIAS BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: Elsevier, 2002. GUEDES, G.T.A. UML 2. Guia de consulta rápida. São Paulo: Novatec Editora, 2005. MATOS, A.V. Unified Modeling Language UML: Prático e descomplicado. Rio de Janeiro: Erica, 2002 PENDER, Tom. UML, a Bíblia. Rio de Janeiro: Elsevier, 2004.