Uma visão mais clara da UML

Sumário

1 Método.............................................................................................................................................2

2 Análise de requisitos.........................................................................................................................2

2.1 Diagramas de Casos de Uso......................................................................................................3

2.1.1 Ator....................................................................................................................................3

2.1.2 Casos de Uso (Use Case)...................................................................................................4

2.1.3 Cenário..............................................................................................................................4

2.1.4 Relacionamentos...............................................................................................................6

2.1.5 Associações ......................................................................................................................8

2.1.5.1 Associações Normais.................................................................................................8

2.1.5.2 Associação Recursiva.................................................................................................8

2.1.5.3 Associação Ternária...................................................................................................9

2.1.5.4 Agregação..................................................................................................................9

2.1.6 Generalizações................................................................................................................10

2.1.6.1 Generalização Normal.............................................................................................10

2.1.6.2 Generalização Restrita.............................................................................................10

3 Exemplo Prático: Sistema de Vendas..............................................................................................12

4 Exercício:.........................................................................................................................................15

5 Referências Bibliográficas...............................................................................................................16

1

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 ométodo utiliza para expressar projetos enquanto que o processo indica quais passos seguir paradesenvolver um projeto.

A especificação da UML consiste de duas partes:

• Semântica: especifica a sintaxe abstrata e a semântica dos conceitos de modelagemestá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 eincremental é 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 evoluiaté 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 desistemas.

2 Análise de requisitos

Esta etapa se caracteriza pela definição do comportamento do sistema, ou seja, como osistema age ou reage, descrevendo o relacionamento entre o ambiente e o sistema. Deve ser umadefinição de necessidades do usuário e não uma proposta de solução. O usuário deve indicar osrequisitos prioritários para o sistema.

O grupo de análise deve identificar as necessidades do usuário. Decisões do projetoimpostas 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

✔ 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 aobjeto. 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 deDiagramas de Casos de Uso (Use Case). Diagrama de "Use Case": É um diagrama usado para seidentificar como o sistema se comporta em várias situações que podem ocorrer durante suaoperação. Descrevem o sistema, seu ambiente e a relação entre os dois. Os componentes destediagrama são os atores, os "Use Case" e os relacionamentos. Casos de uso e Relacionamentos.Ainda pode-se usar as primitivas Pacotes e Notas.

2.1.1 Ator

Representa qualquer entidade que interage com o sistema durante sua execução essa interação sedá 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 podedesempenhar.

• 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:

OBS: Atores representam, na verdade, papeis desempenhados por pessoas, dispositivos ou outrosquando interagem com o sistema. Um ator cujo identificador seja ALUNO não representa umaluno, mais sim um aluno qualquer, uma pessoa que esteja interagindo com o sistema naqualidade de aluno.

3

Figura 1: Use Case

2.1.2 Casos de Uso (Use Case)

Como foi exemplificado acima, é uma sequência de ações que o sistema executa e produz umresultado de valor para o ator. Modela o dialogo entre os atores e o sistema; é um fluxo de eventoscompletos. 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 dosistema.

Nome = Verbo + Substantivo (indicação de ação)

2.1.3 Cenário

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çãodo 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, surgemcaminhos alternativos, casos diferentes a considerar, efeitos/valores diferentes a produzir. Para issoexitem 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

• Fluxo principal: O use case inicia quando o sistema pede ao Cliente a senha. Cliente entra

4

Figura 2: Exemplos de Use cases

com senha. Sistema verifica se a senha é válida. Se a senha é válida, sistema confirma etermina o use case.

• Fluxo excepcional: Cliente pode cancelar a transação a qualquer momento pressionando atecla 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 umfornecedor para a realização de um serviço.

• O conceito central do DBC é a asserção (uma asserção é uma expressão booleana quenunca 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 servá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 quese 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

Pós-condição: Telefone ligado e em descanso

2.1.4 Relacionamentos

Os relacionamentos ligam as classes/objetos entre si criando relações lógicas entre estasentidades. 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 ooutro.

Ex: No caso de uso Comprar Item se o pagamento for feito com dinheiro podemos ter ainclusã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 basedescrevendo uma variação do comportamento normal. O caso de uso base pode ser executadomesmo 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

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 incluicomportamento ou sobrescreve o caso de uso base.

O caso de uso Pagar fatura apresenta as generalizações: Pagamento com cartão e Pagamento comCheque, conforme o diagrama Abaixo:

Figura 5: Exemplo de Generalização

Além disto temos também os relacionamentos entre atores onde um ator especializado podeacessar 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 doiscasos 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

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 cadaX existe um Y" e assim por diante. Classes e associações são muito poderosas quando modeladasem sistemas complexos

2.1.5 Associações

2.1.5.1 Associações Normais

O tipo mais comum de associação é apenas uma conexão entre classes. É representada poruma linha sólida entre duas classes. A associação possui um nome (junto à linha que representa aassociaçã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 serusada 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 quantosobjetos 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 nenhumamultiplicidade, 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 quese relacionam por associação.

2.1.5.2 Associação Recursiva

É possível conectar uma classe a ela mesma através de uma associação e que aindarepresenta semanticamente a conexão entre dois objetos, mas os objetos conectados são damesma classe. Uma associação deste tipo é chamada de associação recursiva.

8

Figura 1: Tipo de Relacionamento: Associações

2.1.5.3 Associação Ternária

Mais de duas classes podem ser associadas entre si, a associação ternária associa trêsclasses. Ela é mostrada como uma grade losango (diamante) e ainda suporta uma associação declasse ligada a ela, traçaria-se, então, uma linha tracejada a partir do losango para a classe ondeseria feita a associação ternária.

No exemplo acima a associação ternária especifica que um cliente poderá possuir 1 ou maiscontratos e cada contrato será composto de 1 ou várias regras contratuais.

2.1.5.4 Agregação

A agregação é um caso particular da associação. A agregação indica que uma das classes dorelacionamento é uma parte, ou está contida em outra classe. As palavras chaves usadas paraidentificar 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

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 maisparticularidades. Um objeto mais específico pode ser usado como uma instância do elemento maisgeral. A generalização, também chamada de herança, permite a criação de elementosespecializados 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çãode sobreposição, disjuntiva, completa e incompleta.

2.1.6.1 Generalização Normal

Na generalização normal a classe mais específica, chamada de subclasse, herda tudo daclasse mais geral, chamada de superclasse. Os atributos, operações e todas as associações sãoherdados.

Uma classe pode ser tanto uma subclasse quanto uma superclasse, se ela estiver numahierarquia 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 orelacionamento, sendo que se coloca uma seta no lado da linha onde se encontra a superclasseindicando a generalização.

2.1.6.2 Generalização Restrita

Uma restrição aplicada a uma generalização especifica informações mais precisas sobrecomo a generalização deve ser usada e estendida no futuro. As restrições a seguir definem asgeneralizações restritas com mais de uma subclasse:

• Generalizações de Sobreposição e Disjuntiva: Generalização de sobreposiçãosignifica que quando subclasses herdam de uma superclasse por sobreposição,novas subclasses destas podem herdar de mais de uma subclasse. A generalizaçãodisjuntiva é exatamente o contrário da sobreposição e a generalização é utilizadacomo padrão.

10

• Generalizações Completa e Incompleta: Uma restrição simbolizando que umageneralização é completa significa que todas as subclasses já foram especificadas, enão existe mais possibilidade de outra generalização a partir daquele ponto. Ageneralização incompleta é exatamente o contrário da completa e é assumida comopadrão da linguagem.

11

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 eendereço. Se o cliente fornece apenas o CEP, o sistema coloca automaticamente o a cidade e oestado. O cliente fornece os códigos do produto. O sistema devolve as descrições e o preço decada produto. O sistema calculará os valores totais para cada produto fornecido. O cliente forneceas informações sobre cartão de crédito. Em seguida, ele submete os dados ao sistema. O sistemaverifica as informações fornecidas, marca o pedido como "pendente" e envia as informações depagamento para o sistema de contabilidade e pagamento. Quando o pagamento é confirmado, opedido é 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 oestado.

4.O cliente fornece os códigos do produto. (veja versão 3 alternativa)

12

5.O sistema devolve as descrições e o preço de cada produto. (Ponto de extensão - Produtoem 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 asinformações de pagamento para o sistema de contabilidade e pagamento.

10.Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e onú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 asinformações de pagamento para o sistema de contabilidade e pagamento.

8. Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e o númerode 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 oproduto2 O sistema mostra o desconto do produto aousuário3 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 ocliente2 O sistema mostra o desconto ao cliente3 O sistema atualiza o total, subtraindo o valordo desconto

13

4 O sistema atualiza o total, subtraindo o valordo 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 calculadoe 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 asinformações de pagamento para o sistema de contabilidade e pagamento.

8. Quando o pagamento é confirmado, o pedido é marcado como "confirmado" e o númerode 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 ainformaçã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

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 criandoum serviço de entregas. Nossos clientes podem nos requisitar a entrega de volumes. Algunsvolumes são considerados de maior valor por nossos clientes, e, portanto, eles querem tertais volumes segurados durante o transporte. Contratamos uma companhia de seguro parasegurar volumes de valor".

4. Considere a seguinte narrativa do caso de uso Realizar Saque. Identifique os errosexistentes nesta narrativa. Construa uma nova versão deste caso de uso que não contenhaos erros encontrados.

A operação de um caixa eletrônico tem início a partir de uma sessão em que o clienteseleciona a opção de realizar saque. O cliente então escolhe uma quantia a ser retirada, apartir de um conjunto de opções de quantia disponíveis.

O sistema verifica se a conta correspondente tem saldo suficiente para satisfazer arequisição. Senão, uma mensagem adequada é reportada, o que acarreta na execução daextensão. Se há dinheiro suficiente, os números da conta e da agência do cliente sãoenviados ao banco, que aprova ou desaprova a transação. Se a transação é aprovada, amá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 completadaou não pela máquina. Se a transação é completada, o banco realiza o débito na conta docliente (Bjork, 1998).

15

5 Referências Bibliográficas

1. Macoratti.net. UML Conceitos Básicos. Disponível em:http://www.macoratti.net/vb_uml2.htm. Acesso em: 10/04/2013.

2. CAMPOS, José C., RIBEIRO, Antonio N. Desenvolvimento de Sistemas de Software.Disponível em: http://sim.di.uminho.pt/disciplinas/dss/0708/AulaT_20071016.pdf. Acessoem: 10/04/2013.

16