Académique Documents
Professionnel Documents
Culture Documents
4
Aula 01: Analise e Projeto Orientado a Objetos ........................................................................... 6
Introduo ............................................................................................................................. 6
Contedo................................................................................................................................ 7
Modelagem orientada a objetos e processo RUP ....................................................... 7
Tipos de nfase .................................................................................................................. 8
Atividades de anlise ......................................................................................................... 8
UML: diferentes perspectivas .......................................................................................... 9
Processos iterativos e incrementais ............................................................................. 10
RUP (Rational Unified Process) ...................................................................................... 12
Arquitetura do sistema ................................................................................................... 16
Decomposio do sistema ............................................................................................ 18
Arquitetura em camadas ................................................................................................ 18
Arquitetura MVC (model, view and controller) ........................................................... 20
MVC: camadas.................................................................................................................. 21
MVC: funcionamento do padro .................................................................................. 22
MVC: vantagens e desvantagens .................................................................................. 23
Quadro comparativo ....................................................................................................... 23
Aprenda Mais....................................................................................................................... 24
Referncias........................................................................................................................... 25
Exerccios de fixao ......................................................................................................... 25
Chaves de resposta ..................................................................................................................... 30
Introduo ........................................................................................................................... 86
Contedo.............................................................................................................................. 87
Diagramas de componentes ......................................................................................... 87
Componentes ................................................................................................................... 88
Interfaces ........................................................................................................................... 89
Componentes e interfaces ............................................................................................. 90
Diagrama de implantao .............................................................................................. 93
N ....................................................................................................................................... 94
Caminhos de comunicao (conexes)...................................................................... 95
Exemplos de diagrama de implantao ...................................................................... 95
Referncias........................................................................................................................... 97
Exerccios de fixao ......................................................................................................... 98
Chaves de resposta ................................................................................................................... 103
Conteudista ............................................................................................................................... 105
Introduo
Nesta aula, sero apresentados conceitos relevantes para dar embasamento s
atividades de anlise e projeto orientado a objetos.
O desenvolvimento orientado a objetos demanda que, nas atividades de
anlise, tenhamos a preocupao com o que o sistema far, enquanto nas
atividades de anlise o foco ser em como fazer.
A UML (Unified Modeling Language), como ferramenta de modelagem para
Contedo
Modelagem orientada a objetos e processo RUP
Anlise e projeto orientados a objeto
As atividades de anlise de um sistema tm por objetivo entender o domnio do
problema enfatizando a sua investigao e as necessidades dos usurios do
sistema, que, por sua vez, demandaro os requisitos do sistema, ou seja, aquilo
que o sistema precisa fazer para atender a essas necessidades.
A anlise visa definir o que o sistema deve fazer. Durante a anlise, a nfase
est em encontrar e descrever as entidades do domnio do problema que sejam
relevantes ao sistema que se pretende construir.
Atividades de projeto enfatizam uma soluo conceitual que satisfaa os
requisitos e no a implementao em si. As atividades de projeto so realizadas
visando ao uso de determinadas tecnologias, e demonstram como o sistema
deve fazer.
Ateno
Na anlise, nos preocupamos em fazer a coisa certa, j no
projeto focamos em faa certo a coisa. A anlise omite
aspectos de como fazer e proporciona um panorama geral da
funcionalidade do sistema.
Tipos de nfase
A anlise orientada a objetos foca em encontrar ou descrever os objetos do
domnio do problema.
J o projeto orientado a objetos prioriza a definio dos objetos do software e
a forma como eles colaboram para atender aos requisitos definidos pela
anlise.
Em ltima instncia, durante a implementao ou programao, os objetos do
projeto so implementados, ou seja, desenvolvidos em uma linguagem de
programao orientada a objetos.
Atividades de anlise
As atividades de anlise denotam a soluo conceitual dada ao problema,
mas sem considerar aspectos da implementao, tais como a linguagem a ser
utilizada
sistema
gerenciador
de
banco
de
dados.
Preocupa-se
Ateno
importante ressaltar que diagramas podem ser modelados
inicialmente sob uma perspectiva e, posteriormente, refinados e
modelados sob outras perspectivas, como, por exemplo, o
diagrama de classes. Na fase de anlise, o diagrama conceitual
de classes pode ser derivado do diagrama de casos de uso,
retratando as classes de negcio (tambm chamadas de classes
de entidade).
Na fase de projeto, o mesmo diagrama de classes pode ser
10
11
de
tcnicas,
mtodos
procedimentos
para
garantir
12
Process.
Detalhes do processo RUP
O RUP guiado ou orientado por casos de uso da UML:
1. Os requisitos so modelados sob a forma de casos de uso;
2. Durante anlise, projeto e implementao, os casos de uso so
modelados e realizados;
3. Durante os testes, aferido se o sistema realiza o que est
definido nos casos de uso;
4. Os
casos
de
uso
so
usados
para
planejamento
13
escopo
viabilidade
(econmica,
14
15
Arquitetura do sistema
O que ?
Em linhas gerais, a arquitetura do sistema abrange as decises sobre a
organizao do software, que incluem:
Definio da estrutura (elementos estruturais) e interface do software;
16
Ateno
Sejam elas lgicas ou fsicas, as decises a serem tomadas para
definir uma arquitetura incluem:
Decomposio do sistema em partes ou subsistemas;
Escolha de uma estrutura de comunicao e controle entre as
partes dos subsistemas;
Definio entre as interfaces entre as partes dos subsistemas;
Determinao de oportunidades e estratgias para reuso.
17
Decomposio do sistema
A decomposio do sistema pode ser efetivada de duas formas, no
excludentes: em camadas ou parties, conforme imagem a seguir.
Arquitetura em camadas
Frequentemente, o desenvolvimento em camadas tem sido usado na tentativa
de separar cdigo, facilitar a manuteno e fomentar o reuso. Inicialmente, no
existia essa ideia; o sistema era monoltico e misturava cdigo de interface
com a lgica e o acesso e armazenamento dos dados, ou seja, todas as
funcionalidades eram misturadas em uma nica camada.
Depois, evolumos para duas camadas, na medida em se desenvolviam em
separado os cdigos para acesso e armazenamento de dados processo
chamado de persistncia. O objetivo dessa separao era manter o uso de
diversos aplicativos acessando a mesma base de dados. Ainda assim, o cdigo,
que em sua maioria continha funcionalidades de interface com usurio e lgica
do negcio, continuava confuso, de difcil entendimento e manuteno, pois
permanecia em uma nica camada.
Na medida em que aplicativos da internet comearam a ser desenvolvidos, essa
estrutura teve que evoluir para uma arquitetura de trs camadas, pois era
muito lento esperar que os componentes da camada de interface + lgica do
18
19
20
MVC: camadas
O modelo MCV (model, view and controller) possui as seguintes camadas:
Modelo de negcio (model) contm as regras do negcio e os dados
necessrios. Encapsula os dados e o comportamento, sem preocupao da
forma como mostr-los. o corao da aplicao, sendo responsvel por tudo
que a aplicao vai fazer em termos de armazenamento, manipulao e
gerao dos dados.
Viso (view) responsvel pela interao com usurio e pela apresentao
das vises dos dados do negcio, sem qualquer preocupao em como os
dados foram obtidos. Controla e mapeia as aes.
Controle (controller) faz a intermediao entre as camadas de viso e
modelo comandando o fluxo de obteno, encaminhamento e apresentao dos
dados. Por meio do controle define-se o comportamento da apresentao,
interpretando-se aes do usurio e mapeando-se chamadas do modelo.
21
22
Quadro comparativo
Tecendo um comparativo entre o modelo em camadas, especificamente o de
trs camadas e o modelo MVC, temos a expor que:
23
Aprenda Mais
Material complementar
Para saber mais sobre o assunto, acesse e leia os contedos dos sites
indicados:
http://www-01.ibm.com/software/br/rational/
http://www.ibm.com/developerworks/rational/library/content/03Ju
ly/1000/1251/1251_bestpractices_TP026B.pdf
http://www.uml.org/
24
Referncias
BEZERRA, Eduardo. Princpios de anlise e projeto de sistemas com
UML. 2. ed. Campus, 2006. [Captulo 1.]
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML: guia do usurio. 2. ed. Rio de
Janeiro: Elsevier, 2005. [Captulos 1 e 2.]
FOWLER, M. UML essencial: um breve guia para a linguagem-padro de
modelagem de objetos. 3. ed. Porto Alegre: Artmed, 2005.
Exerccios de fixao
Questo 1
No que se refere s atividades de anlise e projeto orientado a objetos, assinale
a nica alternativa errada.
a) A fase de anlise visa determinar como as coisas sero implementadas.
b) A fase de projeto enfatiza os objetos de software e a forma como eles
sero interligados.
c) A fase de anlise foca no desenvolvimento do modelo de negcios e,
para tal, usa o modelo de casos de uso da UML.
d) Na anlise, preocupamo-nos em fazer a coisa certa, e, no projeto,
focamos em fazer certo a coisa.
e) Na fase de anlise, desenvolvemos o diagrama conceitual de classes com
as classes do negcio. Na fase de projeto, refinamos esse modelo de
classes com a incluso de novos elementos.
Questo 2
No que se refere s perspectivas dos diagramas UML, analise as alternativas a
seguir.
I. Os diagramas especficos da perspectiva conceitual so diagramas de casos
de uso e diagramas de pacotes.
ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL
25
Questo 3
Sobre o RUP (Rational Unified Process), assinale a nica alternativa errada.
a) iterativo e incremental.
b) Centrado e guiado por casos de usos da UML.
c) Baseado na arquitetura do software a ser desenvolvido.
d) Destina-se
sistemas
implementados
sob
qualquer
paradigma:
Questo 4
Sobre a estrutura do modelo RUP, analise as assertivas.
I. Cada fase e segmentado em iteraes.
II. Cada fase pode ter, no mximo, duas iteraes.
ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL
26
Questo 5
Analise as duas assertivas a seguir e a relao entre elas.
I. O modelo RUP baseado em casos de uso.
... porque...
II. Durante anlise, projeto e implementao, os casos de uso so modelados e
realizados.
Com base em seu entendimento, assinale a resposta correta quanto
assertividade de cada uma e sobre a relao entre elas.
a) As duas assertivas esto corretas, e a segunda justifica a primeira.
b) As duas assertivas esto corretas, e a segunda no justifica a primeira.
c) As duas assertivas esto erradas.
d) A assertiva I est correta, e a assertiva II est errada.
e) A assertiva I est errada, e a assertiva II est correta.
Questo 6
27
Questo 7
O projeto de arquitetura do software compreende a arquitetura fsica e lgica.
Com base nesse conceito, analise as assertivas a seguir.
I. A arquitetura lgica corresponde decomposio hierrquica do sistema em
mdulos lgicos ou subsistemas.
II. A arquitetura lgica definida atravs do diagrama de pacotes.
III. A arquitetura fsica corresponde decomposio do sistema em mdulos
fsicos.
IV. A arquitetura fsica definida pelo diagrama de componentes e de
implantao da UML.
Com base em sua anlise, assinale a nica alternativa correta.
a) Esto corretas apenas II e III
b) Esto corretas apenas I, II e III
c) Esto corretas I, II , III e IV
d) Esto corretas apenas I e IV
e) Esto corretas apenas I e II
28
Questo 8
No que se refere ao modelo de arquitetura de software em camadas, assinale a
nica alternativa errada.
a) As principais motivaes para a diviso em camadas so: separar cdigo
(negcio, da interface), facilitar a manuteno e fomentar o reuso.
b) Trs o nmero mximo de camadas possveis.
c) O modelo em trs camadas surgiu com o advento da internet, pois era
demorado esperar que os componentes da camada de interface e lgica
do negcio fossem carregados na mquina do cliente.
d) A arquitetura de trs camadas contempla as camadas de apresentao,
lgica do negcio e persistncia.
e) Sistemas pequenos no precisam ser desenvolvidos em camadas.
Questo 9
Sobre o modelo MVC (model, view and controller), analise as assertivas a
seguir.
I. Seu principal objetivo separar o cdigo da apresentao (interfaces e
relatrios) da lgica do negcio (da aplicao).
II. A principal motivao o desenvolvimento, hoje, demandar interfaces para
diferentes dispositivos mas a lgica da aplicao a mesma.
III. O modelo MVC no se preocupa com persistncia.
IV. O modelo MVC idntico ao modelo em trs camadas.
Com base em sua anlise, assinale a nica alternativa correta.
a) Esto corretas apenas I, II e III
b) Esto corretas I, II, III e IV
c) Esto corretas apenas I, II e IV
29
Questo 10
Analise as duas assertivas a seguir e a relao entre elas.
O modelo MVC no aconselhvel a pequenas aplicaes.
... porque...
II. Demanda mais complexidade e maior tempo de anlise e modelagem do
sistema.
Com base em sua anlise, assinale a resposta correta quanto assertividade de
cada uma e sobre a relao entre elas.
a) As duas assertivas esto corretas, e a segunda justifica a primeira.
b) As duas assertivas esto corretas, e a segunda no justifica a primeira.
c) As duas assertivas esto erradas.
d) A assertiva I est correta, e a assertiva II est errada.
e) A assertiva I est errada, e a assertiva II est correta.
Questo 1 - A
Justificativa: Na fase de anlise, deve-se definir o que fazer. O como fazer
definido na fase de projeto do processo de desenvolvimento do software.
Questo 2 - A
Justificativa: O diagrama de sequncia no representa a perspectiva de
implementao, e sim o diagrama de implantao.
30
Questo 3 - D
Justificativa: O modelo RUP destina-se exclusivamente ao desenvolvimento de
sistemas sob o paradigma orientado a objetos.
Questo 4 - A
Justificativa: Cada fase pode ter N iteraes, dependendo do tamanho do
projeto. A cada iterao, pode-se demandar tantas disciplinas quantas forem
necessrias fase e iterao.
Questo 5 - E
Justificativa: O modelo RUP modela os casos de uso na disciplina de anlise e
os realiza nas disciplinas de projeto e implementao, e, por esse motivo, est
baseado em casos de uso.
Questo 6 - E
Justificativa: A definio do que o sistema deve fazer responsabilidade das
atividades de requisitos e anlise, no sendo uma deciso para definio da
arquitetura.
Questo 7 - C
Justificativa: Todas as assertivas definem corretamente o que se faz e que
diagramas da UML so usados.
Questo 8 - B
Justificativa: Em tese, no h limites para o nmero mximo de camadas. H
modelos hoje usando mais de trs camadas.
Questo 9 - A
Justificativa: O modelo em camadas e o modelo MVC no so a mesma coisa. O
modelo MCV, por exemplo, no se preocupa com a persistncia; j o modelo
em trs camadas sim. Logo, a diviso dos cdigos nas camadas diferenciado.
31
Introduo
O desenvolvimento em camadas vem sendo usado fortemente pelos
desenvolvedores de software, na tentativa de obter produtos mais coesos,
menos acoplados, mais reutilizveis e de manuteno menos problemtica.
A arquitetura lgica de um sistema a ser desenvolvido envolvem decises
estratgicas que envolve dentre outros aspectos: a escolha da modularizao
do sistema, da estrutura de comunicao e controle entre os subsistemas, a
escolha da estratgia de persistncia, oportunidades de reuso de software, bem
como atendimento a requisitos de desempenho, custo, mobilidade, uso de
padres.
A definio da arquitetura da aplicao, envolve o conhecimento de conceitos
como coeso, acoplamento, princpios para reuso do software, bem como o de
padres de arquitetura de software, a exemplo do modelo MVC (Model, View
32
Contedo
Arquitetura lgica
Conforme estudamos na aula 1, a arquitetura lgica corresponde
decomposio hierrquica do sistema em mdulos lgicos ou subsistemas, bem
como a especificao da interface e dependncia entre esses mdulos. Com o
uso da UML, a arquitetura lgica definida atravs do diagrama de pacotes
como parte do modelo de projetos. Ento, vamos definir o conceito de
arquitetura lgica:
Arquitetura lgica a organizao, em geral, de casos de uso, classes e/ou
componentes em pacotes, subsistemas e camadas. lgica, pois, nesse
momento, no h, ainda, comprometimento de como esses elementos sero
implantados. Estudamos tambm na aula 1 o desenvolvimento em camadas,
cuja finalidade organizar a aplicao visando a uma diviso de cdigo
eficiente que favorece a manuteno e o reuso do software. Uma arquitetura
lgica no precisa ser organizada em camadas, mas isso torna-se muito
comum.
33
Acoplamento e coeso
O acoplamento diz respeito dependncia entre as partes, a forma como
esto relacionadas ou acopladas. Partindo do prprio conceito de sistema,
temos que sistema um conjunto de partes independentes, cada qual
realizando seu trabalho, que juntas colaboram para um objetivo maior, em
comum. Ou seja, as partes devem ser independentes ou pouco dependentes.
O acoplamento mede o grau de interdependncia entre as partes. Dessa forma,
os sistemas devem ser organizados para ter baixo acoplamento ou baixa
dependncia.
O alto acoplamento entre as partes pode gerar:
Dificuldade de alterao no sistema, uma vez que existe dependncia
entre as partes. A alterao em uma parte pode demandar reflexos em outras
partes que dela dependem.
Dificuldade de reutilizao, uma vez que depende da presena de outras
partes.
34
Dificuldade de manuteno.
35
36
37
Ateno
Cabe ressaltar que o diagrama de pacotes pode ser usado em
qualquer fase do processo de modelagem do sistema e tem por
objetivo organizar os modelos. Muitos j iniciam modelando os
casos de uso em pacotes; mas o uso mais comum a diviso em
pacotes, na fase de projeto, quando o diagrama conceitual de
38
39
Classes conceituais
Craig Larman, em seu livro Utilizando UM e Padres, discute trs formas de
descobrir as classes conceituais inerentes a um modelo de domnio.
1. Reusar o modificar modelos existentes;
2. Usar uma lista de categorias de classes conceituais;
3. Identificar substantivos ou frases nominais.
Caso queiram aprofundar-se nas demais tcnicas, recomendo a leitura do livro.
Aqui abordaremos a terceira, que pressupe a elaborao do diagrama e
descries dos casos de uso previamente.
Como identificar classes analisando substantivos ou frases nominais nas
especificaes de casos de uso, especialmente, pelo modelo completo de
especificao de caso de uso?
Consideremos uma iterao do processo RUP e o caso de uso Vender
produtos referente venda em uma loja, conforme diagrama e especificaes
a seguir.
40
Casos de usos
Ator(es): caixa, cliente.
Pr-condio: produtos devidamente cadastrados.
CASO DE USO: VENDER PRODUTOS
Cenrio principal
1. Caixa inicia uma nova venda.
2. Caixa informa identificao do cliente.
3. Sistema localiza cliente.
4. Para cada item da venda so feitos tais passos:
4.1. Caixa informa identificador do item de venda.
4.2. Sistema localiza item de venda em produtos.
4.3. Sistema mostra nome do produto, valor unitrio obtido de produtos.
4.4. Sistema calcula e mostra total parcial da venda.
5. Sistema calcula e exibe o total da venda e os impostos.
6. Caixa informa forma de pagamento.
7. Conforme forma de pagamento:
DIN: Extends pagar dinheiro.
CHQ: Extends pagar cheque.
CAR: Extends pagar carto.
8. Sistema registra dados da venda.
9. Sistema imprime o recibo da venda.
Cenrios alternativos
3.1. a) Cliente no cadastrado:
1. Extends cadastrar cliente.
2. Sistema retorna ao passo 2 do cenrio principal.
4.2. a) Item de venda no localizado:
1. Sistema informa O item de venda no est cadastrado.
41
42
Exemplos
Transaes de negcios:
So fundamentais.
Inicie
com
esse
de etc.
classes.
Transaes de linhas de item:
As transaes, em geral, vm
descritas com linhas de item.
Prossiga
identificando
Itens de venda.
esse
grupo de classes.
43
Produto.
Caixa,
cliente,
loja,
vendedor,
partes
envolvidas
na
transao.
Local da transao, local do servio.
Loja, aeroporto.
Instrumentos financeiros.
Registro
de
finanas,
contrato.
crdito.
trabalho,
44
45
46
47
5) A venda pode ser realizada por apenas um cliente. E o cliente pode realizar
nenhuma (0) ou vrias vendas (*).
6) O pagamento pode ser (1) ou no (0) em dinheiro, da mesma forma que o
pagamento pode ser (1) ou no (0) em carto. E o pagamento tambm pode
ser (1) ou no (0) em cheque.
48
49
Ateno
A ltima imagem do diagrama de classes seria uma verso final
do Diagrama Conceitual de Classes, considerando o universo de
casos de uso da iterao corrente de um suposto processo RUP
aplicado a um sistema de gesto de uma loja.
Um ltimo comentrio refere-se corretude de um modelo
conceitual de classes. Em tese, no existe modelo de domnio
correto, na medida em que um entendimento do problema sob
a tica de quem modelou. Deve, claro, representar a realidade e
ser, antes de tudo, um modelo de comunicao entre usurios e
desenvolvedores.
50
Referncias
LARMAN, C. Modelos de domnio. In: LARMAN, C. Utilizando UML e
padres: uma introduo anlise e ao projeto orientados a objetos e ao
desenvolvimento iterativo. 3. ed. Bookman, 2007.
Exerccios de fixao
Questo 1
No que se refere s atividades de anlise e projeto orientado a objetos, assinale
a nica alternativa errada.
a) A fase de anlise visa determinar como as coisas sero implementadas.
b) A fase de projeto enfatiza os objetos de software e a forma como eles
sero interligados.
c) A fase de anlise foca no desenvolvimento do modelo de negcios e,
para tal, usa o modelo de casos de uso da UML.
d) Na anlise, preocupamos em fazer a coisa certa, e, no projeto,
focamos em faa certo a coisa.
e) Na fase de anlise, desenvolvemos o diagrama conceitual de classes com
as classes do negcio. Na fase de projeto, refinamos esse modelo de
classes com a incluso de novos elementos.
Questo 2
No que se refere s perspectivas dos diagramas UML, analise as alternativas a
seguir.
I. Os diagramas especficos da perspectiva conceitual so diagramas de casos
de uso e diagramas de pacotes.
II. Os diagramas especficos da perspectiva de especificao so, por exemplo,
diagramas de componentes.
51
Questo 3
Sobre o RUP (Rational Unified Process) assinale a nica alternativa errada.
a) iterativo e incremental.
b) Centrado e guiado por casos de usos da UML.
c) Baseado na arquitetura do software a ser desenvolvido.
d) Destina-se
sistemas
implementados
sob
qualquer
paradigma:
Questo 4
Sobre a estrutura do modelo RUP analise estas assertivas:
I. Cada fase segmentada em iteraes.
II. Cada fase pode ter no mximo duas iteraes.
III. A cada iterao podemos demandar duas ou trs disciplinas, sejam de
engenharia ou de apoio.
ANLISE ORIENTADA A OBJETOS E PROJETO ARQUITETURAL
52
Questo 5
Analise as duas assertivas a seguir e a relao entre elas.
I. O modelo RUP baseado em casos de uso.
... porque...
II. Durante a anlise, projeto e implementao, os casos de uso so modelados
e realizados.
Com base em sua anlise, assinale a resposta correta quanto assertividade de
cada uma e sobre a relao entre elas.
a) As duas assertivas esto corretas, e a segunda justifica a primeira.
b) As duas assertivas esto corretas, e a segunda no justifica a primeira.
c) As duas assertivas esto erradas.
d) A assertiva I est correta, e a assertiva II est errada.
e) A assertiva I est errada, e a assertiva II est correta.
Questo 6
Assinale a alternativa incorreta no que se refere ao modelo conceitual de
classes.
53
Questo 7
No que se refere anlise de classes, aos relacionamentos e atributos para
constar no diagrama de classes, analise as assertivas abaixo.
I. Devemos considerar todos os tipos de relacionamentos possveis no modelo
conceitual de classes.
II. Devemos considerar as classes de software no modelo conceitual de classes.
III. Devemos considerar apenas atributos relevantes para o domnio do
problema, tendo cuidado com atributos derivados.
IV. Devemos representar atributos-chave, tal qual fazemos no modelo
relacional de dados.
a) Esto corretas apenas II e III.
b) Esto corretas apenas I, II e III.
c) Esto corretas I, II , III e IV.
d) Est correta apenas III.
e) Esto corretas apenas I e II.
Questo 8
Assinale a nica alternativa correta.
54
Questo 9
Analise se cada assertiva verdadeira ou falsa:
I. Devemos representar no modelo conceitual os relacionamentos de agregao
e composio.
II. Temos, necessariamente, que apresentar os atributos derivados no
diagrama conceitual de classes.
III. O diagrama conceitual de classes um modelo de domnio.
IV. Classes de persistncia no devem ser consideradas em modelos conceitual
de classes.
Com base em sua anlise, assinale a nica alternativa correta, que mostra a
sequncia correta de V ou F.
a) I-F; II-F; III-V; IV-V.
b) I-F; II-F; III-V; IV-F.
c) I-F; II-V; III-V; IV-V.
d) I-V; II-F; III-V; IV-V.
e) I-F; II-F; III-F; IV-V.
55
Questo 10
Analise as duas assertivas a seguir e a relao entre elas.
I. O modelo conceitual de classes refinado a cada iterao, quando um
conjunto de requisitos considerado.
... porque...
II. O diagrama conceitual de classes no considera as classes de projeto.
a) As duas assertivas esto corretas, e a segunda justifica a primeira.
b) As duas assertivas esto corretas, e a segunda no justifica a primeira.
c) As duas assertivas esto erradas.
d) A assertiva I est correta, e a assertiva II est errada.
e) A assertiva I est errada, e a assertiva II est correta.
Questo 1 - A
Justificativa: Na fase de anlise, deve-se definir o que fazer. O como fazer
considerado na fase de projeto do processo de desenvolvimento do software.
Questo 2 - A
Justificativa: O diagrama de sequncia no representa a perspectiva de
implementao, e sim o diagrama de implantao.
Questo 3 - D
Justificativa: O modelo RUP destina-se exclusivamente ao desenvolvimento de
sistemas sob o paradigma orientado a objetos.
56
Questo 4 - A
Justificativa: Cada fase pode ter N iteraes, dependendo do tamanho do
projeto. A cada iterao, pode-se demandar tantas disciplinas quantas forem
necessrias fase e iterao.
Questo 5 - A
Justificativa: O modelo RUP modela os casos de uso na disciplina de anlise,
realiza-os nas disciplinas de projeto e implementao e, por esse motivo, est
baseado em casos de uso.
Questo 6 - E
Justificativa: O diagrama conceitual de classes no apresenta mtodos, pois
nesse modelo nenhuma operao definida.
Questo 7 - D
Justificativa: I falsa, pois devemos considerar apenas as associaes;
II falsa, pois devemos considerar apenas as classes do domnio, chamadas
classes de entidade que sejam relevantes para a representao do problema;
III correta;
e IV falsa, porque no existe o modelo de chave no modelo de classes (cada
classe tem apenas os atributos que lhe pertencem efetivamente).
Questo 8 - A
Justificativa: A segunda afirmativa falsa, pois o diagrama conceitual no
mostra mtodos; a terceira afirmativa falsa, pois as classes de software no
so apresentadas no modelo conceitual, sendo representadas no diagrama de
classes de projeto; a quarta tambm falsa, pois devemos representar
atributos; e, por fim, o conceito de diagrama conceitual de classe independe do
tamanho do projeto, e sim do processo usado no desenvolvimento do software.
Questo 9 - B
57
Introduo
A fase ou disciplina de anlise est voltada identificao e anlise dos
requisitos dos diversos usurios dos sistemas, ou seja, voltada ao entendimento
e modelagem do problema do negcio ao qual o sistema est relacionado.
O modelo de casos de uso est intimamente relacionado aos requisitos
funcionais do sistema e modelo conceitual de classes para evidenciar as classes
relacionadas ao problema. Alm das classes, so identificados alguns atributos
que caracterizam a entidade do negcio.
A fase ou disciplina de projeto visa adicionar detalhes ao modelo de classes, de
forma que esse passe a representar aspectos de projeto. Tal ao possibilita a
definio da arquitetura do sistema, seus componentes e a relao entre eles.
Nesta aula, focaremos a transio da anlise para o projeto, mostrando os
refinamentos necessrios ao modelo de classes e considerando as interaes
58
Contedo
Projeto do software
A fase ou disciplina de projeto de software visa especificar como o software vai
funcionar, sendo ele voltado a uma arquitetura e a um ambiente fsico
especfico. O projeto visa estabelecer alternativas de soluo, de forma que os
requisitos funcionais sejam atendidos e que sejam tambm respeitadas as
restries definidas pelos requisitos no funcionais.
Conforme definido em Princpios de anlise e projeto de sistemas com
UML, de Eduardo Bezerra, as principais atividades realizadas durante o projeto
de software so:
Persistncia de objetos.
Padres de software.
Projeto da arquitetura.
Projeto de algoritmos.
59
60
Projeto da arquitetura
A arquitetura lgica, conforme j citamos em nossas aulas, diz respeito
diviso do software em camadas, incluindo aqui o modelo MVC e o modelo em
camadas de apresentao, domnio, persistncia etc. O diagrama de pacotes
o modelo disponibilizado pela UML para representao da arquitetura lgica.
A arquitetura fsica diz respeito localizao fsica dos componentes de
Persistncia de objetos
Diz respeito forma como os objetos so armazenados de forma persistente,
em geral em banco de dados, que podem ser relacionais, objetos relacionais ou
de objetos.
Quando a persistncia ocorre em bancos de dados relacionais ou objeto
relacional, deve-se elaborar estratgia de migrao do modelo de classes para
o modelo relacional ou objeto relacional.
61
Projeto de algoritmos
Consiste na definio da lgica e das estruturas de dados necessrias
definio dos algoritmos contidos nos mtodos das classes.
Conforme a complexidade dos algoritmos, podem ser definidos formalmente,
com textos ou ainda informalmente.
UML disponibiliza diagrama de atividades com a finalidade de expressar
algoritmos complexos ou que tenham aes em paralelo.
Padres de Projeto
Padres de software tm sido bastante usados em projetos de software na
tentativa de desenhar sistemas mais consistentes, com maior reuso.
Os padres so usados nas fases e disciplinas de anlise e de projeto.
Interaes
Os diagramas de interao so extremamente valiosos, pois vamos entender e
raciocinar em detalhes sobre quais mensagens enviar, para quem e em
que ordem. Podemos, nesse momento, refletir tambm sobre quais objetos
realmente precisam existir, quais as responsabilidades de cada um e como
62
63
Cliente
+ Procurar Cliente (Ident Cliente : int) : boolean
64
por
outros
mais
65
mtodos
descobertos
pelos
diagramas
de
interao
66
Incluso
da
navegabilidade
(seta
chegando
na
classe
EnderecoFornc):
Conforme elemento apresentado, tambm obtido pela elaborao e anlise
dos diagramas de interao. A navegabilidade indica a direo da interao, ou
seja, no exemplo visto, apenas objetos da classe FornecedorE podem enviar
mensagem a objetos da classe EndereoFornc.
Na imagem a seguir, vemos a representao da classe Fornecedor em um
diagrama de classes de projeto, derivado do modelo conceitual de classes e
contendo detalhes de projeto.
67
68
69
70
71
retornos
so
repetidos,
conforme
indicado
na
72
Padres de projeto
Um padro de software uma soluo para um problema recorrente, dentro
de um contexto especfico. A ideia conceber solues a partir de outras j
vivenciadas, similares, que foram documentadas e, principalmente, aprovadas.
Um padro de software, de forma geral, aumenta a produtividade na medida
em que o projetista no precisa reinventar a roda.
A soluo apontada pelo padro serve de ponto de partida para o problema
com o qual o projetista se depara.
So formas de reuso abstratas, na medida em que descrevem a essncia da
soluo de problemas comuns e recorrentes.
Padres no so classes e nem componentes, mas ajudam na construo
desses, orientando a melhor forma de agrupamento dos elementos, baseado
em experincias anteriores.
Existem padres para solues de anlise e de projeto.
uma forma de transferncia de conhecimento: os mais experientes criam os
padres, e os mais novos fazem uso.
Biblioteca de classes
Corresponde a uma coleo de classes que possuem uma determinada
finalidade.
uma forma de reuso mais concreta por meio da qual classes j prontas
podem ser usadas.
Exemplo: os ambientes das plataformas JAVA e .NET disponibilizam
bibliotecas de classes reutilizveis.
Componentes
So uma unidade de software que pode ser usada na construo de
diferentes sistemas.
Compreendem um conjunto de objetos que colaboram para oferecer servios,
mas tambm podem requisitar servios.
73
Responsabilidades
Uma das formas mais clssicas de pensar sobre projeto de objetos em um
74
Observe que:
A classe PedidoE responsvel por criar Itens Pedido (responsabilidade de
fazer).
A classe PedidoUE responsvel por conhecer o seu total (responsabilidade
de conhecer). Sobre essa responsabilidade, para conhecer o seu total, a classe
faz uso do mtodo Obter TotalPed (), mas no o faz isso sozinha. Ela precisa
de colaborao da classe Itens Pedido atravs do mtodo Obter Sub Total
Ped (), pois quem conhece o total de cada linha de item do pedido a prpria
classe Itens Pedido.
Padres GRASP
Existem padres de projetos que ajudam na atribuio de responsabilidades,
fundamentando o raciocnio que deve ser aplicado para tal. Padres GRASP
(general responsibility and assignment software patterns padres gerais de
atribuio de responsabilidade em projeto) definem nove princpios, nove
75
Nome: CREATOR.
Problema: quem CRIA o objeto X?
Soluo (conselho): atribuir classe B a responsabilidade de criar um
objeto da classe A, se uma das afirmativas abaixo for verdade.
- B contm A ou B agrega A de forma composta (composio).
- B registra A.
- B usa A.
- B contm os dados iniciais de A.
Vamos observar a aplicao desse padro no pequeno estudo de casos que
fizemos na seo anterior. Veja que a classe PedidoE cria objetos de Itens
Pedido, conforme mtodo <<Create>>; Criar ItemPed (Num Pedido).
Observe que no diagrama de classes isso se reflete no relacionamento de
composio entre PedidoE e Itens Pedido.
76
77
78
Referncias
BEZERRA, E. Princpios de anlise e projeto de sistemas com UML. 3. ed.
Elsevier, 2015.
LARMAN, C. Utilizando UML e padres: uma introduo anlise e projeto
orientados a objetos e ao desenvolvimento iterativo. 3. ed. Bookman, 2007.
Exerccios de fixao
Questo 1
No que se refere s atividades de projeto orientado a objetos, assinale a nica
alternativa errada.
a) Anlise dos requisitos e modelo conceitual de classes.
b) Modelagem das interaes e identificao de responsabilidades das
classes.
c) Projeto de arquitetura do software.
d) Projeto de persistncia dos dados.
e) Projeto de interface grfica do usurio.
79
Questo 2
Leia as afirmativas a seguir referentes s atividades inerentes ao projeto de
objetos.
I. O diagrama conceitual de classes j traz as classes completas nas quais
teremos a definio dos atributos.
II. Refinamento das classes, com insero de classes de software (de projeto).
III. Insero de mtodos nas classes, com atribuies de responsabilidades.
Com base em sua anlise, assinale a nica alternativa correta.
a) Esto corretas apenas II e III
b) Est correta apenas I
c) Esto corretas I, II e III
d) Esto corretas apenas I e II
e) Esto corretas apenas I e III
Questo 3
Sobre os relacionamentos entre classe, assinale a nica alternativa falsa.
a) A navegabilidade indica a direo em que um objeto pode enviar
mensagens a outro objeto.
b) No diagrama conceitual de classes, em geral, representa-se o
relacionamento entre classes usando a associao.
c) Na fase ou disciplina de projeto, devemos analisar possveis mecanismos
de herana entre as classes.
d) Na fase ou disciplina de projeto, ainda no devemos representar
relacionamento de composio entre as classes, o que somente ser
representado na implementao do cdigo.
80
Questo 4
Sobre o diagrama de sequncia, analise as assertivas a seguir.
I. O diagrama de sequncia mostra como os objetos colaboram para a
realizao de um cenrio de uso (parte de um caso de uso).
II. Toda mensagem que chega a um objeto no diagrama de sequncia
representa uma operao da classe, ou seja, um mtodo na classe que recebe
a mensagem.
III. Novos mtodos descobertos na elaborao do diagrama de sequncia
demandam atualizao frequente do diagrama de classes.
Com base em sua anlise, assinale a alternativa correta.
Questo 5
Analise as duas assertivas a seguir e a relao entre elas.
I. No modelo de classes de projeto podemos incluir novos atributos nas classes.
... porque...
II. No modelo conceitual de classes no representamos atributos.
81
Questo 6
Assinale a alternativa incorreta quanto s formas de reutilizao.
a) Padres de projeto representam reuso de solues recorrentes.
b) Biblioteca de classes representa solues em nvel de implementao.
c) Componentes representam reaproveitamento de cdigo.
d) O desenvolvimento baseado em componentes consiste na construo de
componentes que possam ser usados em diversos contextos, em
diversos sistema.
e) Padro de projeto consiste num reuso imediato e pode ser comprado de
empresas desenvolvedoras.
Questo 7
No que se refere anlise de classes, relacionamentos e atributos para constar
no diagrama de classes, analise estas assertivas:
I. O padro especialista da informao diz que a responsabilidade deve ser
atribuda classe que conhece a informao.
82
II. O padro create ajuda a descobrir os objetos que criam outros e indica
relacionamento de composio.
III. O padro acoplamento alto visa atribuir responsabilidade de forma que o
acoplamento permanea elevado.
a) Esto corretas apenas II e III
b) Esto corretas apenas I, II e III
c) Esto corretas I, II , III e IV
d) Est correta apenas III
e) Esto corretas apenas I e II
Questo 8
Assinale a nica alternativa incorreta no que se refere ao padro create.
a) Atribuir classe B a responsabilidade de criar um objeto da classe A, se
B agrega A de forma composta.
b) Atribuir classe B a responsabilidade de criar um objeto da classe A, se
B registra A.
c) Atribuir classe B a responsabilidade de criar um objeto da classe A, se
B usa A.
d) Atribuir classe B a responsabilidade de criar um objeto da classe A, se
B contm dados iniciais de A.
e) Atribuir classe B a responsabilidade de criar um objeto da classe A, se
A usa B.
Questo 9
Qual o problema resolvido pelo padro controlador?
83
Questo 10
Analise as duas assertivas a seguir e a relao entre elas.
I. Padres de projeto so uma forma de explicitar o conhecimento.
... porque...
II. Formaliza solues de anlise ou projeto j encontradas por profissionais
mais experientes.
a) As duas assertivas esto corretas, e a segunda justifica a primeira.
b) As duas assertivas esto corretas, e a segunda no justifica a primeira.
c) As duas assertivas esto erradas.
d) A assertiva I est correta, e a assertiva II est errada.
e) A assertiva I est errada, e a assertiva II est correta.
Questo 1 - A
Justificativa: Anlise dos requisitos e modelagem conceitual de classes so
atividades da fase ou disciplina de projetos.
84
Questo 2 - A
Justificativa: O diagrama conceitual de classes, em geral, apresenta apenas os
nomes dos atributos; e, na fase ou disciplinas de projeto, acrescentamos
visibilidade e tipo de dados a fim de refin-lo.
Questo 3 - D
Justificativa: Na fase ou disciplinas de anlise, em geral, os relacionamentos
so representados por associaes. J no modelo de classes de projeto ou
classes de software, pode-se representar, se til for, todos os tipos de
relacionamento entre classes.
Questo 4 - B
Justificativa: I verdade; II verdade; e III verdade.
Questo 5 - D
Justificativa: O modelo RUP modela os casos de uso na disciplina de anlise e
os realiza nas disciplinas de projeto e implementao e, por esse motivo, est
baseado em casos de uso.
Questo 6 - E
Justificativa: Padres no so concretos e no so comercializados, tal como
componentes e classes prontas.
Questo 7 - E
Justificativa: O padro chama-se acoplamento baixo e visa garantir que as
classes tenham baixo acoplamento.
Questo 8 - E
Justificativa: A responsabilidade deve ser atribuda a B, se B usa A e no o
contrrio, como diz o enunciado.
Questo 9 - A
85
Introduo
Nesta aula, trataremos da arquitetura fsica do software desenvolvida sob o
paradigma da orientao a objetos, especificamente com auxilio da UML,
denominada modelo de implementao, que, por sua vez, decomposto em
dois diagramas: componentes e implantao.
O diagrama de implantao visa mostrar a arquitetura fsica dos ns (de
processamento), onde o sistema ser executado, e as conexes entre eles; ou
seja, apresenta infraestrutura, servidores e demais dispositivos necessrios ao
funcionamento do sistema.
O diagrama de componentes mostra a diviso do sistema em componentes de
software e a relao entre eles. A juno dos dois diagramas, que opcional,
permite-nos saber o poder de processamento e capacidade de memria e
discos dos ns envolvidos, na medida em que definimos componentes que
rodaro em cada um.
86
Objetivo:
1. Discriminar o diagrama de componentes e seus elementos;
2. Discriminar o diagrama de implantao e seus elementos;
3. Relacionar os diagramas de componentes e implantao;
4. Aplicar, atravs de exemplos, a construo e integrao entre os diagramas
de componentes e implantao.
Contedo
Diagramas de componentes
O que so e o que fazem?
87
Componentes
A UML define componente como:
88
Ateno
O desejo que o componente possa ser independente e
intercambivel.
Em um sistema baseado em componentes, cada componente
tem uma finalidade, ou seja, presta um servio e para tal
demanda o uso de outros componentes.
A imagem a seguir mostra a representao do componente na UML. O
componente tem um nome: Componente.
Interfaces
Interfaces so elementos que definem um conjuntos de operaes que outros
elementos, como classes ou componentes, devem implementar.
Em diagramas de componentes, existem dois tipos de interfaces:
Interfaces
fornecidas:
descrevem
os
servios
oferecidos
outros
89
Ateno
Um mesmo componente pode tanto fornecer como requerer
interfaces. O relacionamento entre os componentes e as
interfaces a essncia dos sistemas.
Componentes e interfaces
O usurio do servio de um componente deve conhecer bem a sintaxe das
interfaces do componente. Analogamente ao exemplo dado inicialmente, as
interface so as conexes possveis entre o receiver do home theater e os
dispositivos (projetor, caixas, DVD, TV etc.).
Para usarmos um DVD precisamos saber as possveis conexes (HDMI, DVI
etc.). Para usar um componente precisamos saber as possveis interfaces.
Existem duas maneiras de representar o relacionamento entre componentes e
interface, conforme as duas imagens a seguir.
Na representao abaixo, o componente que usa a interface se conecta ao
outro componente por meio do relacionamento de dependncia.
90
91
92
Diagrama de implantao
Mostra o layout fsico de um sistema, revelando quais partes do software so
executadas em quais partes do hardware (FOWLER). Enfoca a estrutura fsica
sobre a qual o software vai executar. Define como as mquinas estaro
conectadas e atravs de quais protocolos se comunicaro.
93
N
Um n, em um diagrama de implantao, representa um recurso computacional
de
um
sistema,
como
servidores,
impressoras,
terminais
remotos,
Podemos
representar
em
diagramas
de
implantao
existncia
de
Ateno
A possibilidade de representar os componentes que vo executar
em um n positiva, no sentido de possibilidade de definio da
configurao do n, tanto em termos de capacidade de
94
processamento
como
de
memria
principal
memria
secundria (discos).
95
96
Ateno
Por fim, cabe ressaltar que o diagrama de implantao deve
fazer parte dos manuais para instalao e operacionalizao dos
sistemas (BEZERRA, 2015).
Referncias
BOOCH, G; RUMBAUGH, J; JACOBSON, I. UML: guia do usurio. 2. ed. Rio de
Janeiro: Campus, 2006.
BEZERRA, E. Princpios de anlise e projeto de sistemas com UML. 3. ed.
Elsevier, 2015.
LARMAN, C. Utilizando UML e padres: uma introduo anlise e projeto
orientados a objetos e ao desenvolvimento iterativo. 3. ed. Bookman, 2007.
97
Exerccios de fixao
Questo 1
No que se refere ao diagrama de componentes, assinale a alternativa errada.
a) Mostra os componentes e sua localizao fsica em termos de ns e onde
se encontram
b) Mostra os componentes do sistema
c) Mostra as relaes entre eles
d) Apresenta as interfaces requeridas
e) Apresenta as interfaces fornecidas
Questo 2
No que se refere ao diagrama de componentes e seus elementos, assinale a
alternativa correta.
I. Uma interface fornecida apresenta os detalhes para que um componente
possa usar o servio fornecido por outro.
II. Um componente um elemento modular e substituvel.
III. Um componente s pode ter uma interface oferecida.
Com base em sua anlise, assinale a nica alternativa correta.
a) Esto corretas apenas II e III
b) Est correta apenas II
c) Esto corretas I, II e III
d) Esto corretas apenas I e II
e) Esto corretas apenas I e III
98
Questo 3
Assinale a alternativa que apresenta o correto elemento associado ao seguinte
conceito: representa uma parte modular de um sistema que encapsula seu
contedo e cuja manifestao substituvel dentro de um ambiente.
a) Objeto
b) Interface requerida
c) Classe
d) Componente
e) Software
Questo 4
Sobre o diagrama de componentes, analise as assertivas.
I. O diagrama de componentes deve ser usado em integrao com o diagrama
de casos de uso na modelagem do domnio do problema.
II. O usurio do servio de um componente deve conhecer bem a sintaxe de
suas interfaces.
III. Os componentes podem relacionar-se por relacionamentos de dependncia.
Com base em sua anlise, assinale a alternativa correta.
a) Est correta apenas I
b) Esto corretas I, II e III
c) Esto corretas apenas I e II
d) Esto corretas apenas II e III
e) Esto corretas apenas I e III
99
Questo 5
Analise as duas assertivas a seguir e a relao entre elas.
I. O diagrama de componentes possui ao menos uma interface fornecida.
... porque...
II. Um componente deve manter-se independente e isolado dos demais.
Com base em sua anlise, assinale a resposta correta quanto assertividade de
cada uma e sobre a relao entre elas.
a) As duas assertivas esto corretas, e a segunda justifica a primeira.
b) As duas assertivas esto corretas, e a segunda no justifica a primeira.
c) As duas assertivas esto erradas.
d) A assertiva I est correta, e a assertiva II est errada.
e) A assertiva I est errada, e a assertiva II est correta.
Questo 6
Assinale a alternativa que completa a seguinte afirmativa: Segundo Fowler, o
diagrama de _____________ mostra o layout fsico de um sistema, revelando
quais partes do software so executadas em quais partes do hardware.
a) Componentes
b) Atividade
c) Pacote
d) Sequncia
e) Implantao
100
Questo 7
No que se refere ao diagrama de implantao, analise as assertivas.
I. Ns e caminhos de conexo so dois dos elementos do diagrama.
II. Os ns podem ser servidores, estaes, impressoras, mquinas leitoras de
digitais.
III. Os caminhos de comunicao sempre sero o protocolo TCP/IP, j que o
caminho sempre ser sob a internet.
a) Esto corretas apenas II e III
b) Esto todas corretas
c) Est correta apenas III
d) Esto corretas apenas I e II
e) Esto corretas I e III
Questo 8
Sobre os diagramas de implantao da UML (unified modeling language), teis,
especialmente, na fase de projeto de software, incorreto afirmar:
a) direcionado para a distribuio, entrega e instalao das partes que
formam o sistema fsico.
b) um conjunto de ns conectados, no qual um n nica e
exclusivamente uma estao ou servidor.
c) Envolvem a topologia do sistema, descrevendo a estrutura do hardware.
d) Pode ser integrado ao diagrama de componentes, mostrando que
componentes executam em que n.
101
Questo 9
A UML uma linguagem que possibilita a modelagem nas diversas fases de um
processo de desenvolvimento de software. Na fase de projeto, definidos a
arquitetura e componentes do software, ganham destaque os diagramas de
componentes e de implantao. Com base nesses dois diagramas, analise as
assertivas a seguir.
I. O diagrama de implantao modela os aspectos fsicos do sistema,
mostrando a organizao do hardware.
II. O diagrama de componentes mostra as dependncias entre os elementos do
hardware que sustentaro o software.
III. O ideal que um componente desenvolvido possa ser usado em vrios
sistemas.
Assinale a nica opo correta, com base em sua anlise das assertivas.
a) Apenas as assertivas I e III esto corretas
b) Apenas a assertiva III est correta
c) Apenas a assertiva I est correta
d) Apenas as assertivas I e II esto corretas
e) Apenas as assertivas II e III esto corretas
Questo 10
Um diagrama de implantao define aspectos fsicos do sistema, onde cada n
representa
um
dispositivo
fsico
com
memria
ou
capacidade
de
102
Questo 1 - A
Justificativa: O diagrama que mostra a localizao fsica o diagrama de
implantao. O diagrama de componentes mostra os componentes, o
relacionamento entre eles e suas interfaces.
Questo 2 - B
Justificativa: I falsa, pois uma interface fornecida descreve os servios
oferecidos a outros componentes;
II verdade;
III falso, pois um componente pode ter tantas interfaces quantas forem
necessrias.
Questo 3 - D
Justificativa: Esse o conceito de componente, a ideia de sistemas baseados
em componentes e integrao entre eles atravs de interfaces bem definidas.
Questo 4 - D
Justificativa: I falso, pois diagramas de componentes descrevem a arquitetura
do software e suas partes, que so os componentes;
II verdade; e
III verdade.
Questo 5 - D
Justificativa: I verdade;
II falsa, pois um componente deve integrar-se aos demais, sendo usurio do
servio de outros e/ou oferendo servio aos outros.
103
Questo 6 - E
Justificativa: o diagrama de implantao que mostra o layout fsico do
ambiente onde o sistema vai executar.
Questo 7 - D
Justificativa: I verdade;
II verdade;
III falsa, pois nem todo caminho de comunicao ser sob o protocolo
TCP/IP, e nem todo caminho ser sob a internet. Por exemplo, entre um
computador e uma impressora poder ser o caminho Porta USB.
Questo 8 - B
Justificativa: Muitos outros elementos podem ser n, cujo conceito um
recurso computacional de um sistema.
Questo 9 - A
Justificativa: I verdade;
II falsa, pois o diagrama de componentes mostra apenas dependncia de
software;
III verdade, pois essa a essncia de um componente.
Questo 10 - A
Justificativa: 1. Sim, possvel.
2. Seria til para conhecermos as demandas de processamento do software que
rodaro em cada n e, assim, definirmos a capacidade de processamento,
memria e disco de cada n.
104
105