Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

question in uml preassessment test

 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I just now took the preassessment test for test 486. Can anybody tell me what is the correct answer for the following questions??
1) Valid reasons for grouping classes into the same package are that, the classes:
a)are related by aggregation.
b)are worked on by the same group of developers.
c)are related by specialization.
d)support the same high-level services.
(2 answers are right)

I marked a and c
2)Which of the following are true about software architecture?
a)Two tier software architectures do not scale to as many clients as three+ tier architectures.
b)Two tier architectures lead to more reuse than three+ tier architectures.
c)Thin clients are restricted to GUI parts
d)Technologies such as CORBA, RMI, DCOM, and Servlets allow multiple clients to work with the same server-based business objects.
(1 is right)
I marked a
3)An Observer is a design pattern where dependent objects "register" with another "server" object so that they are notified of changes to the server object. The server object isn't specifically aware of its dependents, but only knows to notify them of changes to its state. Which of the following uses an Observer pattern to maintain the correct separation of model and view in a layered software architecture?
a)GUI components register with business components so that they can update their views when the underlying model objects change.
b) GUI components register with other GUI components so that can be notified of user changes to the state of the system.
c) Business components register with GUI components so that the GUI components know who to ask for updates to their state.
d) Business components register with other business components so that they can enforce business rules based on state change.
(1 is right)
I marked a)
Thanks
Madhu


 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1)c and d
2)a
3)a
 
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I do not agre with item "a" in question 1.
I would say the answer should be
1) b and d
Could someone explain?
Thanks,
Adrian
 
Ranch Hand
Posts: 67
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Adrian Ferreira:
I do not agre with item "a" in question 1.
I would say the answer should be
1) b and d
Could someone explain?
Thanks,
Adrian


Adrian et al. -
As always, search the archives for Sandeeps 'LONG POST' which covers the correct answers for many mock questions.
For an explanation...
Packages are a model management concept, for organising your classes and other model elements. Many of the guidelines that apply to good 'class' design, also apply to package design - low coupling, high cohesion, stability etc etc.
So - the main idea is to group class that are 'strongly related' into the same package. If you look through the options:
a)are related by aggregation - aggregation implies some relationship, but this is not strong enough to place them in the same package. A person has a bank account, but you would probably place them in separate pkgs (I'm generalising here).
b)are worked on by the same group of developers - packages can be a good way of organising the team structure. You can often assign developers to work on particular packages. Furthermore, Larman gives an example of separating volatile elements into a separate pkg, to produce more stable pkgs. However, it is very unlikely that you would do the reverse - use the structure of your team to dictate the pkg structure.
c)are related by specialization - probably a good rule of thumb. Classes that specialise more general concepts are strongly related. That doesn't mean that you will always place them together, but it can be a useful guideline.
d)support the same high-level services - again, on a general level, this is probably a good heuristic. Classes that support the same service are probably strongly related.
As always YMMV, and these are only guidelines.
regards,
paul.
 
Adrian Ferreira
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul,
Thanks for your time and good explanation.
Adrian
 
straws are for suckers. tiny ads are for attractive people.
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic