View
40
Download
0
Category
Preview:
DESCRIPTION
III. DESCRIÇÃO DE CASOS DE USO. Outro cenário alternativo :. Casos de uso e o RUP (Rational Unified Process) :. Exercício:. DIAGRAMA DE CASOS DE USO PERSPECTIVA CONCEITUAL 2ª PARTE. RELACIONAMENTOS ENTRE CASOS DE USO EXTENSÃO (EXTEND) INCLUSÃO (INCLUDE) GENERALIZAÇÃO - PowerPoint PPT Presentation
Citation preview
1
5. Descrever cada caso de uso incluindotudo o que acontece a partir da ocorrênciado evento que deu origem ao caso de uso
Exemplo:
Caso de uso Faz Pedido
2
Faz pedidoCenário principal: Venda realizada com sucesso por umnovo cliente1. Cliente informa dados pessoais (cpf , nome, endereço,
telefone e e-mail) e endereço de entrega2. Cliente informa a lista dos livros desejados e
respectivas quantidades3. Sistema armazena além dos dados f ornecidos pelo
cliente, a data de emissão do pedido e o preço cobradopor cada livro, já que pode ser dado algum desconto eo valor cobrado não será o de tabela
4. Sistema envia ao cliente a confi rmação da venda com onúmero de seu pedido, seu código, a lista dos itenspedidos com quantidade e preço de cada item e o preçototal do pedido.
3
Cenário alternativo: Venda realizada com sucesso por cliente já cadastrado 1.
Cliente inf orma seu código Sistema valida o código Sistema apresentada as inf ormações
relativas à última compra: nome, cpf , endereço, telef one, e-mail e endereço de entrega
Cliente atualiza seus dados Continua a partir do passo 2.
4
Cenário alternativo: Autorização de venda negada a um cliente já cadastrado 1.
Cliente informa seu código Sistema valida o código Sistema comunica que o cliente não poderá
f azer um pedido por ter dívidas pendentes. Os passos seguintes não são realizados.
5
Cada caso de uso deve ser descritoatravés de uma seqüência de passos,mostrando a interação entre o ator (ouatores) e o caso de uso.
Nesta descrição deve-se dizer como ocaso de uso inicia, como interage com osatores e as inf ormações que participamnesta comunicação.
O caso de uso Faz pedido poderia serdescrito da seguinte f orma:
III. DESCRIÇÃO DE CASOS DE USO
6
Faz pedido: I nicia quando um cliente emite um pedido. Eledeverá informar seus dados pessoais (cpf , nome, endereço,telefone e e-mail), caso seja um cliente novo. Quando f or umcliente antigo poderá dizer seu código que será validado. Ocliente deverá ainda informar os dados relativos ao pedido: alista dos livros desejados (I SBN) e respectivas quantidades.Deve ser armazenada a data de emissão do pedido e o valorcobrado por cada livro, já que pode ser dado algum desconto eo valor cobrado não será o valor de tabela. O cliente recebe aconfi rmação da venda com o número de seu pedido, seu códigoe todas as demais informações relativas ao pedido. O pedidonão será aceito caso o cliente tenha dívidas pendentes.
7
Essa descrição poderia ser melhor organizadaatravés da descrição com maior clareza dessespassos e da elaboração de cenários.
Um cenário é uma seqüência de passos quedescreve a comunicação entre o ator e osistema.
Poderíamos descrever o seguinte cenário, querelata os passos de uma venda realizada comsucesso por um novo cliente.
8
Faz pedidoCenário principal: Venda realizada com sucesso por umnovo cliente1. Cliente informa dados pessoais (cpf , nome, endereço,
telefone e e-mail) e endereço de entrega2. Cliente informa a lista dos livros desejados e
respectivas quantidades3. Sistema armazena além dos dados f ornecidos pelo
cliente, a data de emissão do pedido e o preço cobradopor cada livro, já que pode ser dado algum desconto eo valor cobrado não será o de tabela
4. Sistema envia ao cliente a confi rmação da venda com onúmero de seu pedido, seu código, a lista dos itenspedidos com quantidade e preço de cada item e o preçototal do pedido.
9
Em Faz pedido pode ocorrer do cliente játer realizado alguma compraanteriormente.
Assim, poderíamos descrever um outrocenário chamado de alternativo que f azref erência aos passos do cenário principal(só são descritos os passos do cenárioalternativo que são dif erentes do cenárioprincipal)
No cenário alternativo apresentado aseguir o passo 1 do cenário principal ésubstituído pelo que é descrito no cenárioalternativo e todos os demais passos sãoiguais.
10
Cenário alternativo: Venda realizada com sucesso por cliente já cadastrado 1.
Cliente inf orma seu código Sistema valida o código Sistema apresentada as inf ormações relativas
à última compra: nome, cpf , endereço, telef one, e-mail e endereço de entrega
Cliente atualiza seus dados Continua a partir do passo 2.
11
Cenário alternativo: Autorização de venda negada a um cliente já cadastrado 1.
Cliente inf orma seu código Sistema valida o código Sistema comunica que o cliente não poderá
f azer um pedido por ter dívidas pendentes. Os passos seguintes não são realizados.
Outro cenário alternativo:
12
Veja em anexo (arquivo rup_ucspec) como o RUP propõe a especificação de um caso de uso. O documento de especificação de casos de uso complementa a Especificação de Requisitos do Sof tware, um documento do RUP que pode ser visto em anexo (arquivo rup_src)
Casos de uso e o RUP (Rational Unified Process):
13
Descrever um cenário dos casos de uso do Sistema de robôs, utilizando template RUP
Exercício:
14
DIAGRAMA DE CASOS DE USO PERSPECTIVA CONCEITUAL
2ª PARTE RELACIONAMENTOS ENTRE CASOS DE USO
EXTENSÃO (EXTEND) INCLUSÃO (INCLUDE) GENERALIZAÇÃO
GENERALIZAÇÃO DE ATORES
ORGANIZANDO OS CASOS DE USO EM PACOTES
ELABORANDO O DIAGRAMA
NOTAÇÕES ALTERNATIVAS
15
I . RELACIONAMENTOS ENTRE CASOSDE USO
– EXTENSÃO (EXTEND)– I NCLUSÃO (I NCLUDE)– GENERALI ZAÇÃO
16
I .1 Relacionamento de Extensão (extend)
Utilizamos extensões quando há variações decomportamentos normais e desejamos utilizar umamaneira mais f ormal que os cenários para indicaressas variações e o ponto em elas ocorrem no casode uso.
17
Caso de uso Base
Caso de Uso Extensão
<<extend>>
Ponto deExtensão
18
Funcionário Fatura pedido
Cliente
Exemplo utilizando cenários:
A variação de comportamento normal pode serobservada no cenário Atraso na entrega de umitem do pedido do caso de uso Fatura pedido
19
Fatura pedidoCenário principal: f aturamento de pelo menos um item do pedido
1. Funcionário seleciona um pedido que não tenha sido integralmenteatendido (f aturado)
2. Sistema verifica a quantidade pendente (quantidadePedida -quantidadeAtendidaTotal) de cada item
3. Sistema cria uma f atura com o número da f atura, a data deemissão, a data limite de pagamento e a quantidade de cada item.
4. Sistema emite a f atura que deverá ser encaminhada ao clientejuntamente com os livros. A f atura deverá conter:- Número da f atura- Número do pedido- Data de emissão- Data de vencimento- Para cada item: a quantidade e o preço unitário cobrado
- Preço total
20
Obs: A quantidade f aturada de cada item está limitada ao
que há em estoque. Caso não possa ser f eito umatendimento completo neste momento, mais adiante,logo que haja o item em estoque, será criada uma novafatura.
Uma f atura f az ref erência a um e apenas um pedido.No entanto ela pode estar atendendo apenasparcialmente àquele pedido.
21
Cenário alternativo: Atraso, sem previsão de entrega, de um ou mais itens do pedido 2.
Sistema verifi ca a quantidade pendente (quantidadePedida - quantidadeAtendidaTotal) de cada item.
Sistema verifi ca que um ou mais itens pedidos não poderão ser entregues e que não há previsão de entrega.
Sistema comunica ao cliente descrevendo o número do pedido e os itens para os quais não há previsão de entrega.
Continua a partir do passo 3.
22
Comunica atraso
Funcionário
Fatura pedido
(verificação de itens pendentes)
<<extend>>
Cliente
Solução utilizando extensão:
23
Explicando o diagrama criado:
É criado um caso de uso B e estabelecido umrelacionamento entre o caso de uso original A e estenovo, que representa a extensão.
Este relacionamento é representado através de umaassociação com estereótipo extend.
BA
<<extend>>
24
Na descrição do caso de uso original (A) deve serindicado o ponto de extensão e o caso de usoestendido (B) irá acrescentar um comportamentoadicional exatamente neste ponto.
Estereótipo
Um recurso da UML que permite estender a linguagem. Possibilita a criação de novos elementos derivados de outros já existentes.
25
Fatura pedidoCenário principal: f aturamento de pelo menos um item do pedido
1. Funcionário seleciona um pedido que não tenha sido integralmenteatendido (f aturado)
2. Sistema verifica a quantidade pendente (quantidadePedida -quantidadeAtendidaTotal) de cada item(Extend – Comunicaatraso)
3. Sistema cria uma fatura com o número da f atura, a data deemissão, a data limite de pagamento e a quantidade de cada item.4. Sistema emite a f atura que deverá ser encaminhada ao cliente
juntamente com os livros. A f atura deverá conter:- Número da f atura- Número do pedido- Data de emissão- Data de vencimento- Para cada item: a quantidade e o preço unitário cobrado
- Preço total
26
Obs: A quantidade f aturada de cada item (livro) está
limitada ao que há em estoque. Caso não possa ser f eitoum atendimento completo neste momento, maisadiante, logo que haja o item em estoque, será criadauma nova f atura.
Uma f atura f az ref erência a um e apenas um pedido.No entanto ela pode estar atendendo apenasparcialmente àquele pedido.
27
Comunica atraso
Sistema verifica que um ou mais itens pedidosnão poderão ser entregues e que não há previsãode entrega.
Sistema comunica ao cliente o atrasodescrevendo o número do pedido e os itens paraos quais não há previsão de entrega.
28
Como um caso de uso pode ter vários pontos deextensão devemos indicar em cada associação oponto de extensão ref erenciado.
Comunica atraso
Funcionário
Fatura pedido
(verificação de itens pendentes)
<<extend>>
Cliente
29
I .2 Relacionamento de I nclusão (include)
Utilizamos relacionamentos de inclusão quandohá comportamentos similares em dois ou maiscasos de uso e não desejamos repetir a descriçãodesses comportamentos.
30
Caso de uso Base
Caso de Uso Inclusão
<<include>>
31
Exemplo sem inclusão:
Diminui quantidade de um item do pedido eSolicita cancelamento de pedido são doiscasos de uso em que podemos observar que umcomportamento é repetido: a validação donúmero do pedido.
Cliente
Solicita cancelamento de pedido
Diminui quantidade de um item do pedido
32
Diminui quantidade de um item do pedidoCenário principal: Quantidade diminuida
1. Cliente informa seu código2. Sistema valida código3. Cliente informa número do pedido4. Sistema verifica a existência do número do pedido5. Sistema envia ao cliente os dados relativos a seu pedido: a lista dos itens pedidos com quantidade e preço unitário de cada item e o preço
total do pedido a lista das faturas emitidas contendo para cada fatura:- Número da fatura- Número do pedido- Data de emissão- Data de vencimento- Para cada item: a quantidade e o preço unitário- Preço total6. Cliente informa o item a ser reduzido7. Sistema apresenta ao cliente a quantidade pendente (quantidade pedida –
quantidade faturada)8. Cliente informa a nova quantidade (no máximo a quantidade pendente)9. Sistema armazena a nova quantidade10. Sistema envia ao cliente a confi rmação da alteração realizada
33
Solicita cancelamento de pedidoCenário principal: Pedido cancelado por não haver fatura emitida
1. Cliente informa seu código2. Sistema valida código3. Cliente informa número do pedido4. Sistema verifi ca a existência do número do pedido5. Sistema envia ao cliente os dados relativos a seu pedido: a lista dos itens pedidos com quantidade e preço unitário de cada item e o preço total do
pedido a lista das faturas emitidas contendo para cada fatura:- Número da fatura- Número do pedido- Data de emissão- Data de vencimento- Para cada item: a quantidade e o preço unitário- Preço total6. Sistema cancela o pedido (não há nenhuma fatura emitida para ele) e armazena a data de
cancelamento7. Sistema envia ao cliente a confi rmação do cancelamento solicitado.
34
Solução utilizando inclusão:
Cliente
Solicita cancelamentode pedido
Valida pedido
Diminui quantidade de um item do pedido
<<include>>
<<include>>
35
Explicando o diagrama criado:
Um relacionamento de inclusão de um caso de uso Apara um caso de uso B é representado através deuma associação com estereótipo include e indica queuma instância do caso de uso A sempre conterá ocomportamento especifi cado por B.
O comportamento do caso de uso B é incluído noponto do caso de uso A indicado na especificação docaso de uso A.
BA
<<include>>
36
Diminui quantidade de um item do pedidoCenário principal: Quantidade diminuida
1. Cliente informa seu código2. Sistema valida código3. Cliente informa número do pedido4. Sistema valida número do pedido (include – Valida
pedido)5. Cliente informa o item a ser reduzido6. Sistema apresenta ao cliente a quantidade pendente
(quantidade pedida – quantidade f aturada)7. Cliente informa a nova quantidade (no máximo a
quantidade pendente)8. Sistema armazena a nova quantidade9. Sistema envia ao cliente a confi rmação da alteração
realizada
37
Solicita cancelamento de pedidoCenário principal: Pedido cancelado por não haver f atura emitida
1. Cliente informa seu código2. Sistema valida código3. Cliente informa número do pedido4. Sistema valida número do pedido (include – Valida pedido)5. Sistema cancela o pedido (não há nenhuma fatura emitida para
ele) e armazena a data de cancelamento
6. Sistema envia ao cliente a confirmação do cancelamentosolicitado.
38
Valida pedido
1. Sistema verifica a existência do número do pedido2. Sistema envia ao cliente os dados relativos a seu
pedido: a lista dos itens pedidos com quantidade e preço
unitário de cada item e o preço total do pedido a lista das f aturas emitidas contendo para cada
fatura:- Número da f atura- Número do pedido- Data de emissão- Data de vencimento- Para cada item: a quantidade e o preço unitário
- Preço total
39
I .3 Relacionamento de Generalização
Podemos usar a generalização quando temos um caso deuso que é semelhante a outro mas f az algo a mais.
Podemos representar essa variação através de cenáriosalternativos em um único caso de uso. No entanto, seconsiderarmos que vale a pena separar essa variaçãonum caso de uso, podemos utilizar o relacionamento degeneralização.
40
Exemplo utilizando cenários:
O pedido f eito por um cliente pode seroferecido como presente. Desta f orma teríamosem Faz pedido um cenário alternativo relativo aessa situação.
Cliente Faz pedido
41
Faz pedidoCenário principal: Venda realizada com sucesso por umnovo cliente1. Cliente informa dados pessoais (cpf , nome, endereço,
telefone e e-mail) e endereço de entrega2. Cliente informa a lista dos livros desejados e
respectivas quantidades3. Sistema armazena além dos dados f ornecidos pelo
cliente, a data de emissão do pedido e o preço cobradopor cada livro, já que pode ser dado algum desconto eo valor cobrado não será o de tabela
4. Sistema envia ao cliente a confirmação da venda com onúmero de seu pedido, seu código, a lista dos itenspedidos com quantidade e preço de cada item e o preçototal do pedido.
42
Faz pedido Cenário alternativo: Venda realizada com sucesso por um novo cliente para presentear 1.
Cliente inf orma dados pessoais (cpf , nome, endereço, telef one e e-mail)
Cliente informa dados do presenteado: nome e endereço de entrega
Continua a partir do passo 2.
43
Solução utilizando generalização:
Cliente Faz pedido
Faz pedido para presentear
44
Explicando o diagrama criado:
A generalização de um caso de uso B para um caso de uso Aindica que B é uma especialização de A e é representadocomo o exemplo a seguir.
A
B
45
A generalização é um relacionamento entre umelemento mais genérico (o pai) e um elemento maisespecífi co (o fi lho) que é totalmente consistentecom o primeiro elemento e acrescenta inf ormaçõesadicionais. É um relacionamento utilizado em casosde uso mas também em atores, classes e outroselementos.
Podemos descrever o caso de uso específi coreferenciando o cenário principal do caso de usogenérico (os passos modifi cados são descritos)
46
Faz pedidoCenário principal: Venda realizada com sucesso por umnovo cliente1. Cliente informa dados pessoais (cpf , nome, endereço,
telefone e e-mail) e endereço de entrega2. Cliente informa a lista dos livros desejados e
respectivas quantidades3. Sistema armazena além dos dados f ornecidos pelo
cliente, a data de emissão do pedido e o preço cobradopor cada livro, já que pode ser dado algum desconto eo valor cobrado não será o de tabela
4. Sistema envia ao cliente a confirmação da venda com onúmero de seu pedido, seu código, a lista dos itenspedidos com quantidade e preço de cada item e o preçototal do pedido.
47
Faz pedido para presentear
1. Cliente informa dados pessoais (cpf , nome,endereço, telefone e e-mail)
Cliente informa dados do presenteado:nome e endereço de entrega
Continua a partir do passo 2.
48
I I . GENERALIZAÇÃO DE ATORES
Caso seja necessário podemos utilizar o relacionamentode generalização entre atores.
A generalização de um ator C para um ator D indica que Cpode se comunicar com os casos de uso que se comunicamcom o ator D. A seta dirige-se do atorque é uma especializaçãopara o ator genérico.
C
D
49
Exemplo:
O gerente também poderia f aturar um pedido. Omesmo não ocorre como o funcionário, que não tempermissão para cancelar uma f atura.
Funcionário Fatura pedido
Gerente Avalia cancelamento de fatura
50
III. ORGANIZANDO OS CASOS DE USO EM PACOTES
Na UML os modelos podem ser organizados empackages (ou pacotes) de f orma que possamoscompreendê-los mais f acilmente.
O package é f ormado por um grupo de elementoscom um tema comum. Esses elementos podem serclasses, componentes, casos de uso e até mesmooutros pacotes.
51
Exemplo:
Poderíamos no caso exemplo, ter dois packages:Controle de pedidos e Controle de Livros
Controle de livros
Controle de pedidos
52
O diagrama de casos de uso apresentado a seguirpertence ao package Controle de pedidos, quecontém os casos de uso relacionados àadministração de pedidos e f aturamento
O package Controle de Livros conteria, porexemplo, casos de uso responsáveis por incluirum novo livro e por atualizar os preços dos livros
53Gerente
Funcionário
Solicita cancelamentode fatura
Paga fatura
Comunica atraso no pagamento
Avalia cancelamento de fatura
Fatura pedido
Diminui quantidade de um item do pedido
Solicita cancelamentode pedido
Cliente
Faz pedido
Casos de uso do package Controle de Pedidos
54
Utilidade do uso de packages quando estamos modelandoum grande sistema:
- possibilita a divisão do sistema em subsistemas
- f acilita o entendimento do sistema
- permite que informações sejam encontradas com maisfacilidade
55
1. I dentifi car os atores
Exemplo - Sistema de controle de pedidos:
Cliente Funcionário Gerente
IV. ELABORANDO O DIAGRAMA
56
2. I dentifi car os eventos externos aos quais o sistema deve responder
Eventos externos são eventos iniciados pelos atores. Um ator inicia o processo, apesar de poderem existir outros atores envolvidos. Os atores podem enviar dados, f azer
solicitações e receber inf ormações. Exemplos: Cliente f az pedido Cliente diminui a quantidade de um item do pedido Cliente paga f atura Cliente solicita cancelamento de pedido Cliente solicita cancelamento de f atura Funcionário f atura pedido Gerente avalia cancelamento de pedido
57
3. I dentifi car os eventos não iniciados pelos atores
Esses eventos podem ocorrer num momento jápré-estabelecido, como a geração de um relatóriosempre no primeiro dia útil do mês, ref erente ao mêsanterior.
Podem também ser eventos que ocorrem aqualquer momento, como o evento Atraso depagamento de f atura. A qualquer dia uma f atura podesof rer atraso.
Exemplo: Atraso de pagamento de f atura
58
4. Criar para cada evento um caso de usocorrespondente, estabelecendo osrelacionamentos entre os casos de uso e osatores
59Gerente
Funcionário
Solicita cancelamento de faturaPaga fatura
Comunica atraso no pagamento
Avalia cancelamento de fatura
Fatura pedido
Diminui quantidade de um item do pedido
Solicita cancelamento de pedido
Cliente
Faz pedido
60
5. Estabelecer, quando necessário, relacionamentosentre:
casos de uso atores
61Gerente
Funcionário
Comunica atraso
Valida pedido
Solicita cancelamento de fatura
Paga fatura
Comunica atrasono pagamento
Avalia cancelamento de fatura
Fatura pedido
(verificação de itens pendentes)
<<extend>> Diminui quantidade de um item do pedido
<<include>>
Solicita cancelamentode pedido
<<include>>
Faz pedido
Cliente
Faz pedido parapresentear
62
6. Descrever cada caso de uso incluindotudo o que acontece a partir da ocorrênciado evento que deu origem ao caso de uso
Exemplo:
Caso de uso Faz Pedido
63
Faz pedidoCenário principal: Venda realizada com sucesso porum novo cliente1. Cliente inf orma dados pessoais (cpf , nome,
endereço, telef one e e-mail) e endereço deentrega
2. Cliente inf orma a lista dos livros desejados erespectivas quantidades
3. São armazenadas a data de emissão do pedido e ovalor cobrado por cada livro, já que pode ser dadoalgum desconto e o valor cobrado não será o valorde tabela
4. Cliente recebe a confirmação da venda com onúmero de seu pedido, seu código e todas asdemais inf ormações relativas ao pedido.
64
Cenário alternativo: Venda realizada com sucesso por cliente já cadastrado 1.
Cliente informa seu código Código é validado São apresentadas as inf ormações relativas
à última compra: endereço, telefone, e-mail e endereço de entrega
Cliente atualiza seus dados Continua a partir do passo 2.
65
Cenário alternativo: Autorização de venda negada a um cliente já cadastrado 1.
Cliente informa seu código Código é validado Sistema comunica que o cliente não poderá
f azer um pedido por ter dívidas pendentes. Os passos seguintes não são realizados.
66
7. Organizar os casos de uso em packages
8. Revisão do modelo
Controle de livros
Controle de pedidos
67
V. NOTAÇÕES ALTERNATIVAS
Associações
Atores
68
Na UML a associação é representada por umalinha.
Outras alternativas vêm sendo utilizadas, como ade [Quatrani], que utiliza uma seta nasassociações entre atores e casos de uso,indicando quem está iniciando a comunicação.
Associações
69
Quando a seta tem o sentido ator - caso de uso
Signifi ca que o ator está iniciando a comunicação,requerendo algo do sistema
Exemplo:Caso de uso Faz pedido
Cliente Faz pedido
70
Quando a seta tem o sentido caso de uso-ator
Signifi ca que algo ocorreu no sistema sem ainterf erência de um ator e este f oi comunicado
Exemplo: Caso de uso Comunica atraso no pagamento
ClienteComunica atraso no pagamento
71
De acordo com a UML todos os atores envolvidos nocaso de uso devem ser representados no diagrama,desde que participem do caso de uso.
Há no entanto variações com relação a essa questão:[Fowler], por exemplo, sugere que se inclua somente
aquele ator que é realmente importante para o caso deuso.
Atores
72
Uma opção, de f orma a tornar o diagrama maissimples, é a seguinte:
- incluir somente aquele ator que é responsávelpor iniciar o caso de uso
- incluir aquele ator que é comunicado, quandoocorre algo no sistema
- outros atores envolvidos com o caso de uso sãomencionados na descrição do caso de uso
73
Avalia cancelamentode fatura
Gerente
Exemplo:Caso de uso Cancela Fatura.
O gerente autoriza ou não o cancelamento dafatura e envia um comunicado para o ator cliente,mas o cliente só é mencionado na descrição do casode uso.
74
Diagrama com as notações alternativas:
Gerente
Funcionário
Comunica atraso
Valida pedido
Solicita cancelamento de fatura
Paga fatura
Comunica atraso no pagamento
Avalia cancelamento de fatura
Fatura pedido
(verificação de itens pendentes)
<<extend>>Diminui quantidade de um item do
pedido
<<include>>
Solicita cancelamento de pedido<<include>>Faz pedido
Cliente
Faz pedido para presentear
75
Exercício:
Desenvolver o Diagrama de Casos de Uso Refatorado para o sistema de robôs da Petrobrás.
76
Exercício:
Desenvolver os cenários dos Casos de Uso para o sistema de robôs da Petrobrás.
77
REFERÊNCIAS
[Fowler] Fowler, Martin; Scott, Kendall; UML Distilled Second Edition – A Brief Guide to the Standard Object Modeling Language, Ed. Addison-Wesley, 1999.
[Quatrani] Terry Quatrani, Visual Modeling With Rational Rose 2000 and UML, Ed. Addison Wesley, 2000.
Recommended