1 uml no projeto de componentes: 1 a parte diagrama de caso de uso real projeto de interface ...
TRANSCRIPT
![Page 1: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/1.jpg)
1
UML NO PROJETO DE COMPONENTES:1a PARTE
DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES
![Page 2: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/2.jpg)
2
I . DIAGRAMA DE CASOS DE USO REAL
Casos de uso são elaborados no levantamento de
requisitos, descrevendo o comportamento do sistema sem especifi car como esse comportamento será implementado.
![Page 3: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/3.jpg)
3
Como exemplo, vamos considerar o caso deuso Solicita cancelamento de f atura:
Solicita cancelamento de fatura
Cliente
![Page 4: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/4.jpg)
4
Solicita cancelamento de f atura Cenário principal: Solicitação de cancelamento integral da f atura realizada com sucesso 1. Cliente informa número da f atura 2. Sistema verifica a existência deste número 3. Sistema envia ao cliente os dados da f atura, contendo: a
data de emissão, status e valor pago 4. Cliente solicita o cancelamento integral da f atura 5. Sistema armazena a solicitação de cancelamento da f atura
e a data da solicitação 6. Sistema envia ao cliente a confi rmação do cadastramento
de sua solicitação e a inf ormação de que o seu pedido só será analisado quando a Empresa receber os livros relativos à f atura.
![Page 5: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/5.jpg)
5
Cenário alternativo: Solicitação já cadastrada 3. Sistema envia ao cliente os dados da fatura, contendo: a data de emissão, status, valor pago e a data em que f oi realizada a solicitação 4. Sistema comunica que a solicitação já f oi realizada Os passos seguintes não são realizados. _______________________________________________ Cenário alternativo: Fatura não encontrada 3. Sistema comunica ao cliente que não encontrou a f atura. Os passos seguintes não são realizados. ____________________ ___________________________ Cenário alternativo: Solicitação suspensa pelo cliente ao longo do processo 4. Cliente desiste da solicitação 5. Sistema comunica que não realizou a operação. Os passos seguintes não são realizados.
![Page 6: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/6.jpg)
6
Agora, na etapa de Projeto, devem ser descritasclasses e outros elementos que trabalharão emconjunto para a implementação do comportamento decada caso de uso.
Na UML uma colaboração permite nomear umconjunto de classes e outros elementos que trabalhamem conjunto para f ornecer algum comportamento.
Colaborações podem ser usadas para:
- especificar a realização de casos de uso- especificar a realização de operações- modelar mecanismos da arquitetura do sistema.
![Page 7: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/7.jpg)
7
Solicita cancelamento de fatura
Cliente
Solicita cancelamento de fatura real
<<realize>>
Podemos criar um diagrama de caso de uso real,contendo casos de uso reais. Cada caso de uso real, umacolaboração, será ligado ao caso de uso elaboradodurante a análise através de uma associação comestereótipo realize.
Exemplo:
![Page 8: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/8.jpg)
8
Como exemplo, serão apresentadas a interf ace e o diagrama de classes elaborados para o caso de uso Solicita cancelamento de f atura real.
Vamos ver a seguir dois elementos que podem f azer parte da descrição de um caso de uso real: a interf ace homem-máquina, o diagrama de classes e a própria especifi cação do caso de uso, referenciando a interf ace homem-máquina.
![Page 9: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/9.jpg)
9
I I . I N T E R F A C E H - M ( e l a b o r a d a p a r a S o l i c i t aC a n c e l a m e n t o d e F a t u r a R e a l )
J a n e l a P r i n c i p a lA l t e r n a t i v a s :a ) Q u a n d o a o p ç ã o é v á l i d a
![Page 10: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/10.jpg)
10
0
Opção inválida
b) Q uando a opção é inválida
0
![Page 11: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/11.jpg)
11
J anelaSolicitaCancelamentoFatura
Opções:
a) Quando cadastramento realizado com sucesso
b) Quando solicitação já cadastrada
O seu pedido será analisado após o recebimento dos livros.
![Page 12: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/12.jpg)
12
c) Quando a fatura não existir
![Page 13: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/13.jpg)
13
A partir deste projeto de interface poderíamos elaborar a especificação do caso de uso real: Solicita cancelamento de fatura realCenário principal: Solicitação de cancelamento integral da fatura realizada com sucesso
1. Sistema apresenta a JanelaSolicitaCancelamentoFatura e solicita o número da fatura2. Cliente informa número da fatura3. Sistema verifica a existência deste número no Banco de Dados e recupera os dados da fatura4. Sistema apresenta os dados da fatura, contendo: a data de emissão, status e valor pago. 5. Sistema pergunta se o cliente deseja realmente realizar a solicitação. 6. Cliente solicita o cancelamento integral da fatura 7. Sistema armazena no Banco de Dados: a solicitação de cancelamento da fatura e a data da solicitação8. Sistema apresenta na tela a confirmação do cadastramento da solicitação e a informação de que o pedido só será analisado quando a Empresa receber os livros relativos à fatura.
![Page 14: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/14.jpg)
14
Cenário alternativo: Solicitação já cadastrada4. Sistema apresenta os dados da fatura, contendo: a data de emissão, status, valor pago e a data em que foi realizada a solicitação. 5. Sistema comunica que a solicitação já foi realizadaOs passos seguintes não são realizados. _______________________________________________Cenário alternativo: Fatura não encontrada
3. Sistema verifica a inexistência deste número no Banco de Dados e apresenta uma mensagem na tela, comunicando ao cliente este fato. Os passos seguintes não são realizados. ______________________________________________Cenário alternativo: Solicitação suspensa pelo cliente ao longo do processo6. Cliente desiste de solicitar o cancelamento integral da fatura 7. Sistema comunica que não realizou a operação. Os passos seguintes não são realizados.
![Page 15: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/15.jpg)
15
I I I . DI AGRAMA DE CLASSES (elaborado paraSolicita Cancelamento de Fatura Real)
ControladorDePedidos
obterFatura(numero : int) : Fatura_ProjcadastrarSolCancFatura(numero : int) : String
Fatura_ProjnumFatura : intdataEmissao : DatedataVencimento : DatevalorPago : doubledataPagamento : DatedataPedidoCancelamento : DatedataCancelamento : Datestatus : String
recuperarPelaPK(numFatura : int) : Fatura_ProjsolicitaCancelamento() : void
JanelaSolicitaCancelamentoFatura
exibir() : void
JanelaPrincipal
main(args : String[]) : void
![Page 16: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/16.jpg)
16
Descrição das operações:
main - Apresenta as opções do sistema e solicita que o usuário diga oque deseja f azer. Caso ele digite uma opção inválida o usuário écomunicado. Se a opção f or válida é executada a operaçãocorrespondente.
exibir - Solicita o número da f atura e verifica a existência dessenúmero através de obterFatura do ControladorDePedidos. Se afatura f or encontrada é exibida através das operações get da classeFatura_Proj . Se não f or encontrada a mensagem “Fatura nãoencontrada” é exibida. Verifica se já f oi solicitado o cancelamentoanteriormente. Se tiver sido emite uma mensagem de erro. Casocontrário, pergunta se o usuário confi rma o cadastramento dasolicitação de cancelamento. Se o usuário confi rmar, a solicitação écadastrada
![Page 17: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/17.jpg)
17
obterFatura – Obtém a f atura, através de recuperarPelaPK de Fatura. Se a f atura não f or encontrada retorna null.
cadastrarSolCancFatura – Obtém a fatura, através de
recuperarPelaPK de Fatura e caso a f atura seja encontrada chama solicitaCancelamento de Fatura e retorna a mensagem "Solicitação de cancelamento cadastrada com sucesso". Caso não seja encontrada retorna a mensagem "Fatura não encontrada". Caso a solicitação já tenha sido feita retorna a mensagem "Solicitação cadastrada anteriormente"
solicitaCancelamento – Escreve no banco de dados a data de
solicitação e o novo status recuperarPelaPK - Busca no banco de dados os dados
relativos à f atura atribuindo-os ao objeto umaFatura
![Page 18: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/18.jpg)
18
Obs: Cada operação poderia ser especificada de um
modo mais formal com o diagrama de atividades, já estudado na primeira parte do curso.
![Page 19: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/19.jpg)
19
I V. ELABORANDO O DI AGRAMA DE CLASSES
1. I dentifique todas as classes participantes da solução
No caso exemplo f oram incluídas as classes J anelaPrincipal, J anelaSolicitaCancelamentoFatura, ControladorDePedidos e Fatura_Proj .
Esta solução refl ete o f ato de se estar usando o estilo
arquitetural em camadas.
![Page 20: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/20.jpg)
20
2. Acrescente aos atributos informações que nãoforam descritas no modelo elaborado com aperspectiva conceitual
Sintaxe completa de um atributo:
[visibilidade] nome [ [multiplicidade] ] [:tipo] [= valor inicial] [{propriedade}]
Caso o diagrama seja utilizado por uma f erramentacom geração automática de código, devem seracrescentados detalhes completos dessasinformações.
![Page 21: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/21.jpg)
21
Visibilidade
A visibilidade de atributos pode ser pública, privadaou protegida (public, private ou protected). A seguir éapresentada a representação e o significado dessestermos:
+ public : Um atributo declarado como publicnuma classe é visível por todas as classes# protected: Um atributo declarado comoprotected numa classe é visível nas subclasses- private: Um atributo declarado como privateé visível apenas na classe na qual f oi declarado
![Page 22: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/22.jpg)
22
No caso da ferramenta utilizada para elaborar osdiagramas deste curso a notação utilizada é diferente:
private protected public
Axyz
![Page 23: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/23.jpg)
23
O significado dos termos public, protected e privatepode mudar dependendo da linguagem de programação.Em J ava, por exemplo, um método ou atributo protectednuma classe pode ser acessado por subclasses mastambém por qualquer outra classe que esteja no mesmopackage.
Considerando essas dif erenças, é importante aodescrevermos a visibilidade, seguir as regras dalinguagem a ser utilizada.
![Page 24: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/24.jpg)
24
Propriedades
Podem ser dos seguintes tipos:- changeable: o valor do atributo pode ser modificado sem
restrições- addOnly: quando o atributo tem multiplidade maior do que um,
poderão ser incluídos vários valores, mas estes não poderão serremovidos ou alterados.
- f rozen: o valor do atributo não poderá sof rer modifi cações umavez que o objeto tenha iniciado.
Quando não f or especifi cada é assumida a propriedade changeable.
Outra propriedade que pode ser incluída é:
- static: o valor de uma variável desse tipo não muda de uma classepara outra. É um valor da classe e não de um objeto em particular
![Page 25: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/25.jpg)
25
Exemplo: dataEmissão tem visibilidade privatee é do tipo Date.
Fatura_ProjnumFatura : intdataEmissao : DatedataVencimento : DatevalorPago : doubledataPagamento : DatedataPedidoCancelamento : DatedataCancelamento : Datestatus : String
recuperarPelaPK(numFatura : int) : Fatura_Projsoli ci taCancelamento() : void
![Page 26: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/26.jpg)
26
3. I nclua operações nas classes
Operação é um serviço que pode ser solicitado poralgum objeto da classe.
Como podemos observar no diagrama várias operaçõesforam incluídas.
Fatura_ProjnumFatura : intdataEmissao : DatedataVencimento : DatevalorPago : doubledataPagamento : DatedataPedidoCancelamento : DatedataCancelamento : Datestatus : String
recuperarPelaPK(numFatura : int) : Fatura_Projsoli ci taCancelamento() : void
![Page 27: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/27.jpg)
27
Obs:
As operações de acesso não foram incluídos.Operações de acesso são aquelas que obtêm (get) ouescrevem (set) o dado.
É recomendável que os atributos tenham visibilidadeprivada e que haja uma operação get e uma set para cadaatributo. Desta f orma o atributo será acessado fora daclasse somente através de operações, possibilitando oencapsulamento. Como teríamos muitas operações get eset elas não costumam ser incluídas nos diagramas declasse.
![Page 28: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/28.jpg)
28
4. Acrescente informações sobre os operações
A sintaxe da UML é a seguinte:
[visibilidade] nome [ (lista de parâmetros) ][:tipo-da-expressão-retornada] [{propriedade}]
![Page 29: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/29.jpg)
29
Visibilidade
A visibilidade de operações pode ser pública,privada ou protegida. A seguir é apresentada arepresentação e o signifi cado desses termos:
+ public : Uma operação declarada comopublic numa classe é visível por todas asclasses# protected: Uma operação declarada comoprotected numa classe é visível nas subclasses- private: Uma operação declarada comoprivate é visível apenas na classe na qual f oideclarada
![Page 30: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/30.jpg)
30
No caso da ferramenta utilizada para elaborar osdiagramas deste curso a notação utilizada é diferente:
private protected public
A
x()y()z()
![Page 31: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/31.jpg)
31
Em Cay S. HorstMann, Gray Cornell, Core J ava –Fundamentals, vol. 1, Sun Microsystems, 1999, são f eitas asseguintes considerações sobre a visibilidade em J ava:
- Os atributos de uma classe devem ser declarados comoprivate e os métodos são geralmente declarados como public.Qualquer atributo declarado como private não será visível poroutras classes e isto também vale para subclasses: umasubclasse não pode acessar os dados privados de suasuperclasse.
- Há, no entanto, situações em que se deseja que uma subclassetenha acesso a um método ou a um dado da sua classe pai.Neste caso, devemos declarar o método ou a variável comoprotected. Por exemplo, se o objeto dataContrataçao de umaclasse Empregado f osse declarado como protected em vez deprivate, então os métodos da classe Gerente (uma subclassede empregado) poderiam acessar este campo diretamente.
![Page 32: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/32.jpg)
32
- Na prática evite utilizar atributos protected. Suponha quevocê projetou uma classe com campos protected e que estaclasse esteja sendo utilizada por outros programadores.Estes programadores poderão derivar classes a partir dasua classe e, então, poderão acessar diretamente os camposdefinidos como protected. Você não poderá mudar aimplementação da sua classe sem incomodar os outrosprogramadores. I sto é contra o espírito da programaçãoorientada a objetos, que estimula o encapsulamento.
- Métodos do tipo protected f azem mais sentido. Uma classecomplexa pode declarar um método como protected e teriacomo vantagem que só a classe e as subclasses poderiamacessar este método.
![Page 33: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/33.jpg)
33
Parâmetros
Podem ser descritos zero ou mais parâmetros deacordo com a seguinte sintaxe:
[direção] nome: tipo [= valor-padrão]
Direção:- I n: um parâmetro de entrada que não será
modifi cado- Out: um parâmetro de saída que poderá ser
modifi cado- I nout: um parâmetro de entrada que poderá ser
modifi cado
![Page 34: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/34.jpg)
34
Propriedade
Exemplo de uma propriedade é:
Estática – determina que a operação é da classe e nãodo objeto.
![Page 35: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/35.jpg)
35
5 . A c r e s c e n t e a n a v e g a ç ã o
I n c l u í m o s u m a s e t a d e n a v e g a ç ã o e m u m a a s s o c i a ç ã o q u a n d od e s e j a m o s l i m i t a r a n a v e g a ç ã o a u m a ú n i c a d i r e ç ã o . S e m a s e t a d en a v e g a ç ã o a a s s o c i a ç ã o é c o n s i d e r a d a b i d i r e c i o n a l , c o m o n oe x e m p l o a s e g u i r :
ClientecódigoCPFnomeendereçotelef one [0..1]eMail [0..1]
1..*1 f az ->
PedidonumPedidodataEmissãonomePresenteado [0..1]endereçoEntregadataCancelamento [0..1]status
1..*1
![Page 36: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/36.jpg)
36
E s p e c i fi c a r a d i r e ç ã o a s e r s e g u i d a n ã o s i g n i fi c an e c e s s a r i a m e n t e q u e a n a v e g a ç ã o e m u m a d a s d i r e ç õ e s éi m p o s s í v e l . A i d é i a é q u e é p o s s í v e l , p a r t i n d o - s e d e u m ae x t r e m i d a d e , c h e g a r d i r e t a e m a i s f a c i l m e n t e a o s o b j e t o s d ao u t r a e x t r e m i d a d e , i s t o p o r q u e o o b j e t o d e o r i g e m d e v ea r m a z e n a r a l g u m a r e f e r ê n c i a a o s o b j e t o s d e d e s t i n o .
N o e x e m p l o a s e g u i r , m a i s f a c i l m e n t e s e r á e n c o n t r a d o oc l i e n t e q u e f e z u m d a d o p e d i d o , m a s p o d e - s e t a m b é m c o n h e c e ro s p e d i d o s d e u m c e r t o c l i e n t e .
ClientecódigoCPFnomeendereçotelef one [0..1]eMail [0..1]
1..*1
PedidonumPedidodataEmissãonomePresenteado [0..1]endereçoEntregadataCancelamento [0..1]status
![Page 37: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/37.jpg)
37
Uma associação com seta de navegação pode serinterpretada como uma visibilidade por atributo daorigem para a classe alvo.
Ao ser implementada numa linguagem orientada aobjetos, esta associação é normalmente traduzida dasseguintes f ormas, dependendo da multiplicidade:
- a classe origem terá um atributo que referenciauma instância da classe alvo
- a classe origem terá um atributo que referenciavárias instâncias da classe alvo
No exemplo anterior, a classe Pedido teria, ao serimplementada, um atributo do tipo Cliente.
![Page 38: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/38.jpg)
38
6. Acrescente relacionamentos de dependência
Este relacionamento, apresentado através de uma setatracejada, indica que um elemento tem conhecimento deoutro elemento. A dependência é um relacionamento entredois itens em que a alteração de um item pode af etar asemântica do outro.
Num relacionamento de dependência a seta tracejadaaponta o item do qual o outro depende.
![Page 39: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/39.jpg)
39
No diagrama de classes o relacionamento dedependência pode representar, por exemplo, que umaclasse usa outra como argumento na assinatura de umaoperação. Assim, se a classe utilizada for modificada, aoperação da outra classe pode ser af etada, pois aclasse utilizada pode, ao ser modifi cada, ter ainterf ace ou o comportamento alterado.
Uma situação deste tipo ocorre na classeControladorDePedidos: a operação ObterFaturaretorna um objeto da classe Fatura_Proj .
![Page 40: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/40.jpg)
40
ControladorDePedidos
obterFatura(numero : int) : Fatura_ProjcadastrarSolCancFatura(numero : int) : Str ing
Fatura_ProjnumFatura : intdataEmissao : DatedataVencimento : DatevalorPago : doubledataPagamento : DatedataPedidoCancelamento : DatedataCancelamento : Datestatus : String
recuperarPelaPK(numFatura : i nt) : Fatura_Projsoli ci taCancelamento() : void
![Page 41: 1 UML NO PROJETO DE COMPONENTES: 1 a PARTE DIAGRAMA DE CASO DE USO REAL PROJETO DE INTERFACE DIAGRAMA DE CLASSES ELABORANDO O DIAGRAMA DE CLASSES](https://reader036.vdocument.in/reader036/viewer/2022062411/5706386a1a28abb8239046ec/html5/thumbnails/41.jpg)
41
Outro exemplo: