Uma visão mais clara da UML Sumário

Transcrição

1 Uma visão mais clara da UML Sumário 1 Método Análise de requisitos Diagramas de Casos de Uso Ator Casos de Uso (Use Case) Cenário Relacionamentos Associações Associações Normais Associação Recursiva Associação Ternária Agregação Generalizações Generalização Normal Generalização Restrita Exemplo Prático: Sistema de Vendas Exercício: Referências Bibliográficas

2 1 Método A UML não é um método é uma linguagem de modelagem designada para especificar, visualizar, construir e documentar um sistema. A linguagem de modelagem é a notação que o método utiliza para expressar projetos enquanto que o processo indica quais passos seguir para desenvolver um projeto. A especificação da UML consiste de duas partes: Semântica: especifica a sintaxe abstrata e a semântica dos conceitos de modelagem estática e dinâmica de objetos; Notação: especifica a notação gráfica para a representação visual da semântica. A UML suporta o desenvolvimento iterativo e incremental. Desenvolvimento iterativo e incremental é o processo de desenvolvimento de sistemas em pequenos passos. Uma iteração é um laço de desenvolvimento que resulta na liberação de um subconjunto de produtos que evolui até o produto final percorrendo as seguintes atividades: Análise de requisitos Análise Projeto Implementação Teste O detalhamento de cada etapa destas atividades define o método de desenvolvimento de sistemas. 2 Análise de requisitos Esta etapa se caracteriza pela definição do comportamento do sistema, ou seja, como o sistema age ou reage, descrevendo o relacionamento entre o ambiente e o sistema. Deve ser uma definição de necessidades do usuário e não uma proposta de solução. O usuário deve indicar os requisitos prioritários para o sistema. O grupo de análise deve identificar as necessidades do usuário. Decisões do projeto impostas não são características essenciais do domínio do problema. A análise de requisitos compõe-se dos seguintes diagramas: Diagrama de caso de uso; Diagrama de sequência; Diagrama de colaboração. Para realizar a análise de requisitos, primeiramente deve-se: Identificar objetivo e características do sistema; Identificar os requisitos essenciais; Descrever as necessidades do usuário; 2

3 Elaborar diagrama de caso de uso; Elaborar diagrama de sequência; Elaborar diagrama de colaboração. UML é uma linguagem visual para especificação (modelagem) de sistemas orientados a objeto. A UML privilegia a descrição de um sistema seguindo três perspectivas: Os diagramas de classes - (Dados estruturais); Os diagramas de casos de uso (Operações funcionais); Os diagramas de seqüência, atividades e transição de Estados (Eventos temporais). 2.1 Diagramas de Casos de Uso Os casos de uso de um projeto de software são descritos na linguagem UML através de Diagramas de Casos de Uso (Use Case). Diagrama de "Use Case": É um diagrama usado para se identificar como o sistema se comporta em várias situações que podem ocorrer durante sua operação. Descrevem o sistema, seu ambiente e a relação entre os dois. Os componentes deste diagrama são os atores, os "Use Case" e os relacionamentos. Casos de uso e Relacionamentos. Ainda pode-se usar as primitivas Pacotes e Notas Ator Representa qualquer entidade que interage com o sistema durante sua execução essa interação se dá através de comunicações (troca de mensagens). Um ator pode ser uma pessoa (usuário, secretaria, aluno...), um dispositivo (impressora, máquina...), hardware (placa de modem, scaner...), softwares (sistema de bd, aplicativos...), etc. Algumas de suas características são descritas abaixo: Ator não é parte do sistema. Representa os papéis que o usuário do sistema pode desempenhar. Ator pode interagir ativamente com o sistema. Ator pode ser um receptor passivo de informação. Ator pode representar um ser humano, uma máquina ou outro sistema. Representação: Figura 1: Use Case OBS: Atores representam, na verdade, papeis desempenhados por pessoas, dispositivos ou outros quando interagem com o sistema. Um ator cujo identificador seja ALUNO não representa um aluno, mais sim um aluno qualquer, uma pessoa que esteja interagindo com o sistema na qualidade de aluno. 3

4 2.1.2 Casos de Uso (Use Case) Como foi exemplificado acima, é uma sequência de ações que o sistema executa e produz um resultado de valor para o ator. Modela o dialogo entre os atores e o sistema; é um fluxo de eventos completos. Algumas de suas características são descritas abaixo: Um "Use Case" modela o diálogo entre atores e o sistema. Um "Use Case" é iniciado por um ator para invocar uma certa funcionalidade do sistema. Um "Use Case" é fluxo de eventos completo e consistente. O conjunto de todos os "Use Case" representa todas as situações possíveis de utilização do sistema Cenário Nome = Verbo + Substantivo (indicação de ação) O cenário é um fluxo de evento descrito textualmente. Exemplo: Sacar dinheiro: 1. O use case inicia quando o Cliente insere um cartão no CA. Sistema lê e valida informação do cartão 2. Sistema pede a senha. Cliente entra com a senha. Sistema valida a senha. 3. Sistema pede seleção do serviço. Cliente escolhe Sacar dinheiro. 4. Sistema pede a quantia a sacar. Cliente informa. 5. Sistema pede seleção da conta (corrente, etc). Cliente informa. 6. Sistema comunica com a rede para validar a conta, senha e o valor a sacar. 7. Sistema pede remoção do cartão. Cliente remove. 8. Sistema entrega quantia solicitada. Na descrição do que o sistema faz através de fluxos de eventos completos, surgem caminhos alternativos, casos diferentes a considerar, efeitos/valores diferentes a produzir. Para isso exitem os Sub-fluxos de Eventos, sua abordagem visa o reuso de fluxo de eventos (sub-fluxos). Por exemplo: Seja o use case Validar usuário Figura 2: Exemplos de Use cases Fluxo principal: O use case inicia quando o sistema pede ao Cliente a senha. Cliente entra 4

5 com senha. Sistema verifica se a senha é válida. Se a senha é válida, sistema confirma e termina o use case. Fluxo excepcional: Cliente pode cancelar a transação a qualquer momento pressionando a tecla ESC, reiniciando o use case. Nenhuma modificação é feita na conta do Cliente. Fluxo excepcional: Se Cliente entra com senha inválida, o use case reinicia. Design by contract: um tipo alternativo de cenário. Design by contract (DBC) baseia-se na noção de um contrato entre um cliente e um fornecedor para a realização de um serviço. O conceito central do DBC é a asserção (uma asserção é uma expressão booleana que nunca deverá ser falsa). Tipicamente as asserções são automaticamente testadas durante a fase de debug. O DBC identifica três tipos de asserções: pré-condições condições que se devem verificar para a invocação de um dado serviço ser válida; pós-condições condições que se devem verificar após a execução de um serviço; invariantes asserções que se devem verificar durante o tempo de vida da entidade a que se aplicam. A partir da versão 1.4 o Java passou a ter asserts que podem ser utilizados para definir prée pós-condições no entanto não suporta invariantes). Exemplo: O use case para fazer um telefonema: Use Case: Fazer Telefonema Pré-condição: Telefone ligado e em descanso Comportamento normal: 1. Utilizador marca número e pressiona OK 2. Telefone transmite sinal de chamada 3. Utilizador aguarda 4. Telefone estabelece ligação 5. Utilizador fala 6. Utilizador pressiona tecla C 7. Telefone desliga chamada Comportamento Alternativo: 3. Telefone Transmite sinal de ocupado 4. Utilizador pressiona tecla C 5. Telefone cancela chamada Comportamento Alternativo: 3.Telefone cancela chamada 5

6 Pós-condição: Telefone ligado e em descanso Relacionamentos Os relacionamentos ligam as classes/objetos entre si criando relações lógicas entre estas entidades. Os relacionamentos podem ser dos seguintes tipos: Os relacionamentos possíveis são: 1- Inclusão: Se um caso de uso inicia ou inclui o comportamento de outro, dizemos que ele usa o outro. Ex: No caso de uso Comprar Item se o pagamento for feito com dinheiro podemos ter a inclusão PagarComDinheiro O relacionamento de inclusão em UML é ilustrado com uma linha de generalização com o rótulo <<include>>. Então para o exemplo do cliente com o use case Solicitar Pedidos de peças teríamos: As propriedades básicas da inclusão são : realizar uma decomposição funcional reduzir a complexidade de um caso de uso O caso de uso básico não pode executar sem a inclusão. Comportamento comum. 2- Extensão - Define pontos de extensão que adicionam comportamento a um caso de uso base descrevendo uma variação do comportamento normal. O caso de uso base pode ser executado mesmo sem a extensão. Ex: O caso de uso Comprar Produto pode apresentar a extensão Compra por um Cliente Regular. Abaixo temos o diagrama UML Figura 4: Caso de uso com Extensão 6

7 Os pontos de extensão são indicados na linha entre os casos de uso do sistema. 3- Generalização - Indica um caso de base que possui diferentes especializações e inclui comportamento ou sobrescreve o caso de uso base. O caso de uso Pagar fatura apresenta as generalizações: Pagamento com cartão e Pagamento com Cheque, conforme o diagrama Abaixo: Figura 5: Exemplo de Generalização Além disto temos também os relacionamentos entre atores onde um ator especializado pode acessar os casos de uso de um Ator base. Abaixo temos um exemplo onde o Ator gerente acessa os casos de uso do ator funcionário Figura 6: Exemplo de relacionamentos entre atores Os relacionamentos em um diagrama de casos de uso podem envolver dois atores e dois casos de uso ou um ator e um caso de uso e assim sucessivamente. O relacionamento é representado através de uma seta: Exemplo: Diagrama de Caso de Uso (Use Cases) para um sistema de Rede Social Escolar 7

8 Figura 1: Tipo de Relacionamento: Associações Uma associação representa que duas classes possuem uma ligação (link) entre elas, significando, por exemplo, que elas "conhecem uma a outra", "estão conectadas com", "para cada X existe um Y" e assim por diante. Classes e associações são muito poderosas quando modeladas em sistemas complexos Associações Associações Normais O tipo mais comum de associação é apenas uma conexão entre classes. É representada por uma linha sólida entre duas classes. A associação possui um nome (junto à linha que representa a associação), normalmente um verbo, mas substantivos também são permitidos. Pode-se também colocar uma seta no final da associação indicando que esta só pode ser usada para o lado onde a seta aponta. Mas associações também podem possuir dois nomes, significando um nome para cada sentido da associação. Para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos estão relacionados no link. O intervalo pode ser de zero para um (0..1), zero para vários (0..* ou apenas *), um para vários (1..*), dois (2), cinco para 11 (5..11) e assim por diante. É também possível expressar uma série de números como (1, 4, 6..12). Se não for descrita nenhuma multiplicidade, então é considerado o padrão de um para um (1..1 ou apenas 1). No exemplo acima vemos um relacionamento entre as classes Cliente e Conta Corrente que se relacionam por associação Associação Recursiva É possível conectar uma classe a ela mesma através de uma associação e que ainda representa semanticamente a conexão entre dois objetos, mas os objetos conectados são da mesma classe. Uma associação deste tipo é chamada de associação recursiva. 8

9 Associação Ternária Mais de duas classes podem ser associadas entre si, a associação ternária associa três classes. Ela é mostrada como uma grade losango (diamante) e ainda suporta uma associação de classe ligada a ela, traçaria-se, então, uma linha tracejada a partir do losango para a classe onde seria feita a associação ternária. No exemplo acima a associação ternária especifica que um cliente poderá possuir 1 ou mais contratos e cada contrato será composto de 1 ou várias regras contratuais Agregação A agregação é um caso particular da associação. A agregação indica que uma das classes do relacionamento é uma parte, ou está contida em outra classe. As palavras chaves usadas para identificar uma agregação são: "consiste em", "contém", "é parte de". É uma forma especializada de associação na qual um todo é relacionado com suas partes. Também conhecida como relação de conteúdo. É representada como uma linha de associação com um diamante junto à Classe agregadora. A multiplicidade é representada da mesma maneira que nas associações. 9

10 2.1.6 Generalizações A generalização é um relacionamento entre um elemento geral e um outro mais específico. O elemento mais específico possui todas as características do elemento geral e contém ainda mais particularidades. Um objeto mais específico pode ser usado como uma instância do elemento mais geral. A generalização, também chamada de herança, permite a criação de elementos especializados em outros. Existem alguns tipos de generalizações que variam em sua utilização a partir da situação. São elas: generalização normal e restrita. As generalizações restritas se dividem em generalização de sobreposição, disjuntiva, completa e incompleta Generalização Normal Na generalização normal a classe mais específica, chamada de subclasse, herda tudo da classe mais geral, chamada de superclasse. Os atributos, operações e todas as associações são herdados. Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numa hierarquia de classes que é um gráfico onde as classes estão ligadas através de generalizações. A generalização normal é representada por uma linha entre as duas classes que fazem o relacionamento, sendo que se coloca uma seta no lado da linha onde se encontra a superclasse indicando a generalização Generalização Restrita Uma restrição aplicada a uma generalização especifica informações mais precisas sobre como a generalização deve ser usada e estendida no futuro. As restrições a seguir definem as generalizações restritas com mais de uma subclasse: Generalizações de Sobreposição e Disjuntiva: Generalização de sobreposição significa que quando subclasses herdam de uma superclasse por sobreposição, novas subclasses destas podem herdar de mais de uma subclasse. A generalização disjuntiva é exatamente o contrário da sobreposição e a generalização é utilizada como padrão. 10

11 Generalizações Completa e Incompleta: Uma restrição simbolizando que uma generalização é completa significa que todas as subclasses já foram especificadas, e não existe mais possibilidade de outra generalização a partir daquele ponto. A generalização incompleta é exatamente o contrário da completa e é assumida como padrão da linguagem. 11

12 3 Exemplo Prático: Sistema de Vendas Fazer Pedido - versão 1 Cenário informal O caso de uso começa quando o cliente seleciona "fazer pedido". O cliente fornece seu nome e endereço. Se o cliente fornece apenas o CEP, o sistema coloca automaticamente o a cidade e o estado. O cliente fornece os códigos do produto. O sistema devolve as descrições e o preço de cada produto. O sistema calculará os valores totais para cada produto fornecido. O cliente fornece as informações sobre cartão de crédito. Em seguida, ele submete os dados ao sistema. O sistema verifica as informações fornecidas, marca o pedido como "pendente" e envia as informações de pagamento para o sistema de contabilidade e pagamento. Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e o número de pedido (NP) é dado ao cliente. Fazer Pedido - versão 2 Caso de uso primário Atores : Cliente Pré-condição: O usuário deve ter feito "log-in" e obtido autorização do sistema Fluxo de Eventos (caminho básico): 1.O caso de uso começa quando o cliente seleciona "fazer pedido". 2.O cliente fornece seu nome e endereço. 3.Se o cliente fornece apenas o CEP, o sistema coloca automaticamente o a cidade e o estado. 4.O cliente fornece os códigos do produto. (veja versão 3 alternativa) 12

13 5.O sistema devolve as descrições e o preço de cada produto. (Ponto de extensão - Produto em Oferta) 6.O sistema calculará os valores totais para cada produto fornecido. (Ponto de extensão - Cliente Especial) 7.O cliente fornece as informações sobre cartão de crédito. 8.O cliente submete os dados ao sistema. 9.O sistema verifica as informações fornecidas, marca o pedido como "pendente" e envia as informações de pagamento para o sistema de contabilidade e pagamento. 10.Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e o número de pedido (NP) é dado ao cliente. Pós-condição: O pedido deve ter sido gravado no sistema e marcado como confirmado. Fazer Pedido versão 3 (alternativa) Atores : Cliente Pré-condição: O usuário deve ter feito "log-in" e obtido autorização do sistema Fluxo de Eventos (caminho básico): 1. O caso de uso começa quando po cliente seleciona "fazer pedido". 2. O cliente fornece seu nome e endereço. 3. Se o cliente fornece apenas o CEP, o sistema coloca automaticamente o a cidade e o estado. 4. Enquanto o cliente quiser pedir itens faça 1. O cliente fornece código do produto 2. O sistema fornece a descrição e preço do produto 3. O sistema atualiza o valor total 5. O cliente fornece as informações sobre cartão de crédito. 6. O cliente submete os dados ao sistema. 7. O sistema verifica as informações fornecidas, marca o pedido como "pendente" e envia as informações de pagamento para o sistema de contabilidade e pagamento. 8. Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e o número de pedido (NP) é dado ao cliente. Produto em Oferta - versão 2 Estende 1. Fazer Pedido, antes do passo 5 Fluxo de Eventos Primário (caminho básico): 1 O sistema procura o valor do desconto para o produto 2 O sistema mostra o desconto do produto ao usuário 3 O sistema calcula o valor do desconto Cliente Especial - versão 2 Estende 1. Fazer Pedido, antes do passo 6 Fluxo de Eventos Primário (caminho básico): 1 O sistema procura o valor do desconto para o cliente 2 O sistema mostra o desconto ao cliente 3 O sistema atualiza o total, subtraindo o valor do desconto 13

14 4 O sistema atualiza o total, subtraindo o valor do desconto Pré-condição: Produto estar em oferta Pós-condição: Valor do desconto calculado Pré-condição: Cliente ser Cliente Especial Pós-condição: Valor do desconto total calculado e subtraído do total de compras Fazer Pedido - versão 5 (caso de uso estendido) Atores: Cliente Pré-condição: O usuário deve ter feito "log-in" e obtido autorização do sistema Fluxo de eventos primário: 1. O caso de uso começa quando po cliente seleciona "fazer pedido". 2. O cliente fornece seu nome e endereço. 3. Se o cliente fornece apenas o CEP, o sistema coloca automaticamente o a cidade e o estado. 4. Enquanto o cliente quiser pedir itens faça 1. O cliente fornece código do produto 2. O sistema fornece as descrição e preço do produto 3. O sistema atualiza o valor total 5. O cliente fornece as informações sobre cartão de crédito. 6. O cliente submete os dados ao sistema. 7. O sistema verifica as informações fornecidas, marca o pedido como "pendente" e envia as informações de pagamento para o sistema de contabilidade e pagamento. 8. Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e o número de pedido (NP) é dado ao cliente. Fluxo de eventos secundário: A qualquer momento antes de submeter, o cliente pode selecionar cancelar. O pedido não é gravado e o caso de uso termina. No passo 7, se alguma informação estiver correta, o sistema pede ao cliente para corrigir a informação. Pós-condição: O pedido deve ter sido gravado no sistema e marcado como confirmado. Extensões: Cliente Especial e Produto em Oferta USA (casos de uso "usados") Dar informação de produto Atualizar conta Requisitos Especiais: O sistema deve responder a qualquer comando do usuário em 1 segundo. 14

15 4 Exercícios 1. Qual é a notação da UML para um caso de uso? Qual é a notação da UML para um ator? Qual a notação utilizada na UML para o relacionamento de generalização? 2. Descreva a(s) diferença(s) entre os relacionamentos de inclusão, de extensão e de herança? 3. Construa um modelo de casos de uso para a seguinte situação fictícia: "Estamos criando um serviço de entregas. Nossos clientes podem nos requisitar a entrega de volumes. Alguns volumes são considerados de maior valor por nossos clientes, e, portanto, eles querem ter tais volumes segurados durante o transporte. Contratamos uma companhia de seguro para segurar volumes de valor". 4. Considere a seguinte narrativa do caso de uso Realizar Saque. Identifique os erros existentes nesta narrativa. Construa uma nova versão deste caso de uso que não contenha os erros encontrados. A operação de um caixa eletrônico tem início a partir de uma sessão em que o cliente seleciona a opção de realizar saque. O cliente então escolhe uma quantia a ser retirada, a partir de um conjunto de opções de quantia disponíveis. O sistema verifica se a conta correspondente tem saldo suficiente para satisfazer a requisição. Senão, uma mensagem adequada é reportada, o que acarreta na execução da extensão. Se há dinheiro suficiente, os números da conta e da agência do cliente são enviados ao banco, que aprova ou desaprova a transação. Se a transação é aprovada, a máquina libera a quantia correspondente e emite um recibo. Se a transação é desaprovada, a extensão Informar Falha é executada. O banco é notificado, independentemente de uma transação aprovada ter sido completada ou não pela máquina. Se a transação é completada, o banco realiza o débito na conta do cliente (Bjork, 1998). 15

16 5 Referências Bibliográficas 1. Macoratti.net. UML Conceitos Básicos. Disponível em: Acesso em: 10/04/ CAMPOS, José C., RIBEIRO, Antonio N. Desenvolvimento de Sistemas de Software. Disponível em: Acesso em: 10/04/