...

Visão de UML

by user

on
Category: Documents
2

views

Report

Comments

Transcript

Visão de UML
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 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
✔ 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.
2.1.1 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
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.
Figura 2: Exemplos de Use cases
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çã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
•
Fluxo principal: O use case inicia quando o sistema pede ao Cliente a senha. Cliente entra
4
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
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 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
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
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
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 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.
2.1.5.2
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
2.1.5.3
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.
2.1.5.4
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
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.
2.1.6.1
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.
2.1.6.2
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
•
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
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
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
Cliente Especial - versão 2
Estende 1. Fazer Pedido, antes do passo 5
Estende 1. Fazer Pedido, antes do passo 6
Fluxo de Eventos Primário (caminho básico):
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
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
4 O sistema atualiza o total, subtraindo o valor Pré-condição: Cliente ser Cliente Especial
do desconto
Pós-condição: Valor do desconto total calculado
Pré-condição: Produto estar em oferta
e subtraído do total de compras
Pós-condição: Valor do desconto calculado
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
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
5 Referências Bibliográficas
1. Macoratti.net.
UML
Conceitos
Básicos.
http://www.macoratti.net/vb_uml2.htm. Acesso em: 10/04/2013.
Disponível
em:
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. Acesso
em: 10/04/2013.
16
Fly UP