Objects by Design Forums Here you can view your subscribed threads, work with private messages and edit your profile and preferences Registration is free! Calendar Find other members Frequently Asked Questions Search Home  
Objects by Design Forums : Powered by vBulletin version 2.3.5 Objects by Design Forums > Main Forums > UML Certification Review Questions > package identification
  Last Thread   Next Thread
Author
Thread Post New Thread    Post A Reply
shreedev
Junior Member

Registered: May 2001
Location:
Posts: 24

package identification

One more question for review.
#11) valid reasons for grouping classes into same package are that, the classes:

a) are related by aggregation.
b) are worked by the same group of developers.
c) are related by specialisation.
d) support same high-level of services.

select 2 answers.

My answer is a) and d) please post your suggestions.

Thanks and Regards,

__________________
sridhar

Report this post to a moderator | IP: Logged

Old Post 07-11-2001 12:37 PM
shreedev is offline Click Here to See the Profile for shreedev Click here to Send shreedev a Private Message Find more posts by shreedev Add shreedev to your buddy list Edit/Delete Message Reply w/Quote
shreedev
Junior Member

Registered: May 2001
Location:
Posts: 24

sorry -- didn't mention reasons

Here I mention the Reasons for my answers.
For a)
we can group the classes involved in the same usecase, which are aggregates (combined ) to complete the goal.
For d)
practicaly now we are grouping classes based on the services -- web (client) and domain(business).

Thanks and Regards,

__________________
sridhar

Report this post to a moderator | IP: Logged

Old Post 07-11-2001 02:08 PM
shreedev is offline Click Here to See the Profile for shreedev Click here to Send shreedev a Private Message Find more posts by shreedev Add shreedev to your buddy list Edit/Delete Message Reply w/Quote
SZ
Administrator

Registered: Apr 2001
Location: New York
Posts: 492

I would say that the answers are b) and c).

Answer a) seems inappropriate because:

Aggregation in the UML class diagram context is a form of association whereby a containing class contains another class. This does not imply grouping of the two classes in the same package at all, although they may happen to be in the same package.

For example, here is a class Employee:

public class Employee {
PhoneNumber homePhone;
PhoneNumber workPhone;
}

Here the Employee class contains (aggregates) two attributes of class PhoneNumber. This class PhoneNumber may be in a different package altogether, perhaps a utility package.

Answer d) is inappropriate because high-level of services is too broad of a category. The business domain, as you suggest, may have hundreds of classes which are divided into different packages based on, if nothing else, the need to partition the code into smaller, logical groupings.


Let's look at answer c) first:

Specialization is a term which refers to subclassing. If a class Square is derived from a class Shape, this is a form of specialization. It is appropriate to create a package to contain classes which are all instances of specialization (sub-classes) of a common ancestor (super-class).

Answer b) makes sense more from a practical standpoint.

It makes sense to group developers such that they work on separate packages, even one developer per package, because in practice each package can be developed and black-box tested in isolation from other packages in the system. I have done this on large projects very successfully. The reason this works in practice is from a theoretical point because a properly designed set of classes in a package should demonstrate coherence and a relatively low level of coupling. When this works well, at the point when integration testing begins, the system should come together fairly quickly if not right away. Those who have experienced this know the feeling.

Report this post to a moderator | IP: Logged

Old Post 07-13-2001 01:33 PM
SZ is offline Click Here to See the Profile for SZ Click here to Send SZ a Private Message Visit SZ's homepage! Find more posts by SZ Add SZ to your buddy list Edit/Delete Message Reply w/Quote
shreedev
Junior Member

Registered: May 2001
Location:
Posts: 24

Answer is C and D

Hi,
The reason for the answers
for C)
In practical and from books I found that we group the classes which related by functional and dependency-- ex. javax.ejb.entity package -- which are all related to entityEJB functions -- is specialised -- when considering java.
for D)
In practical and from books I found that we group the classes based on highlevel services -- com.noble.common.web.-- web package is VIEW in MVC architecture.

Thanks and Regards,

__________________
sridhar

Report this post to a moderator | IP: Logged

Old Post 07-16-2001 12:17 PM
shreedev is offline Click Here to See the Profile for shreedev Click here to Send shreedev a Private Message Find more posts by shreedev Add shreedev to your buddy list Edit/Delete Message Reply w/Quote
SZ
Administrator

Registered: Apr 2001
Location: New York
Posts: 492

I would have to say that this is one of those ambiguous questions that we are trying to nail down.

I can see your reasoning for D) but am not sure why this is better than B).

The following guidelines from Larman's book, 22.5 Identifying Packages might help:

"Group elements that provide a common service (or family of related services), with relatively high coupling and collaboration, into a package."

"At some level of abstraction the package will be viewed as highly cohesive--it has strongly related responsibilities."

"In contrast, the coupling and collaboration between elements of different packages will be relatively low."

Report this post to a moderator | IP: Logged

Old Post 07-18-2001 04:10 AM
SZ is offline Click Here to See the Profile for SZ Click here to Send SZ a Private Message Visit SZ's homepage! Find more posts by SZ Add SZ to your buddy list Edit/Delete Message Reply w/Quote
robinluce
Junior Member

Registered: Jul 2001
Location:
Posts: 2

My two cents.
b and d.

d: because, the goal is to provide a clear interface.
b: because, most of the development communications are intrateam; again, reflective of the clean interface with the other packages.

__________________
Robin

Report this post to a moderator | IP: Logged

Old Post 07-26-2001 07:58 PM
robinluce is offline Click Here to See the Profile for robinluce Click here to Send robinluce a Private Message Visit robinluce's homepage! Find more posts by robinluce Add robinluce to your buddy list Edit/Delete Message Reply w/Quote
pfexa
Junior Member

Registered: Aug 2001
Location: Berlin / Germany
Posts: 16

D looks really good
For the second answer I vote for C specialization

Specialization can be (mis-)used for many purposes,
e.g. deriving from some java.util.* class
(i.e. from a completely different package) but I think
that this not what is meant here.

I think the author means a base class and its "implementing" classes - such constructs are always strongly coupled and I
would not not separate them in different packages ...

Report this post to a moderator | IP: Logged

Old Post 08-29-2001 02:00 PM
pfexa is offline Click Here to See the Profile for pfexa Click here to Send pfexa a Private Message Find more posts by pfexa Add pfexa to your buddy list Edit/Delete Message Reply w/Quote
kasparlund
Junior Member

Registered: Nov 2001
Location:
Posts: 2

Smile package identification

Hi
this forum is a great way to prepare for the certification

I would chose the following answer:
c) are related by specialisation: because other developers using the package will know that everything related to a certain type of functionality is located in the same package and its subpackages.

d) support same high-level of services: because this helps limit the impact of future requirements changes to as few packages as possible.

-------------------------------------------------------------------------------
I believe that c and d are the "right" answers and that a and b often are consequence of c and d as follows:

"b) are worked by the same group of developers" I believe that you organize groups of developers according to packages. Not the opposite

Concerning the answer "a) are related by aggregation.". I for one is not driven by the aggregation aspect. I would however not be surprised that the results of answer d to some extend were an organization according to aggregation.

Report this post to a moderator | IP: Logged

Old Post 11-03-2001 02:33 PM
kasparlund is offline Click Here to See the Profile for kasparlund Click here to Send kasparlund a Private Message Find more posts by kasparlund Add kasparlund to your buddy list Edit/Delete Message Reply w/Quote
Stephen Hosking
Member

Registered: Nov 2001
Location:
Posts: 54

A good question

(B) Definitely.
(D) Almost certainly.

All are good candidates for packages.

(A) Aggregation can be a very good candidate for a package, WHEN the aggregation is a COMPOSITION. Otherwise not, as pointed out by others.

(B) Yes, the development team should be structured according to packages, not vice versa. But this often does not happen. Fact. Live with it. In that case, the needs of the the development team override the logic of the architecture. OO User Guide "For a system being developed by a geographically distributed team, you might use packages as your unit of configuration management". Also "Classes are things used to organize the things in your problem or solution; packages are things used to organise the things in your model".

(C) Specialisation is often a good candidate for packaging, but...

(D) Support same high level services is used more often. I commend the person who looked at the Java API, and determined (C). Right method, but wrong result. I did some random searching at the API, and the first three packages I looked at had the Classes grouped because they support the same high level services, but came from distinctly different Class heirarchies. Have a look at java.awt.

Overall, I think a good method to approach questions is to think about:

1. What have we done in a similar situation in projects (and did it work!)
2. What does Java do.

(A good question. (B) really makes you think about the ideal vs. practical aspects of OO development)

Report this post to a moderator | IP: Logged

Old Post 11-25-2001 10:57 PM
Stephen Hosking is offline Click Here to See the Profile for Stephen Hosking Click here to Send Stephen Hosking a Private Message Find more posts by Stephen Hosking Add Stephen Hosking to your buddy list Edit/Delete Message Reply w/Quote
itgal
Junior Member

Registered: Nov 2001
Location: Los Angeles, CA
Posts: 9

The answer is C & D.

c) are related by specialization.
d) support same high-level of services.

Refer to Craig Larman's book page 349-352.

To partition the conceptual model into packages, place elements together that:

1. are in the same subject area - closely related by concept or purpose.
2. are in a type hierarchy together
3. participate in the same use cases
4. are strongly associated

The benefit of organizing elements into packages is that it chuncks detailed elements into larger abstractions-supporting a higher-level view and viewing a model in simple groupings.

------------
IT GAL

Report this post to a moderator | IP: Logged

Old Post 12-04-2001 11:21 AM
itgal is offline Click Here to See the Profile for itgal Click here to Send itgal a Private Message Find more posts by itgal Add itgal to your buddy list Edit/Delete Message Reply w/Quote
Stephen Hosking
Member

Registered: Nov 2001
Location:
Posts: 54

I now think (c) is better than (b)

I have had another look at the quote from the UML User Guide about using packages as a unit of configuration management for a geographically distributed team (p. 178). They seem to be talking about having a second package structure specifically for configuration management, in addition to the normal architectural package structure. This is an unusual use of packages, not discussed by other authors (I think), so it is likely that the question is referring to the architectural grouping of classes into packages. In that case (b) is wrong, (c) is right.

The section from Larman quoted by IT Gal looks convincing.

As before, (d) is the other correct choice.

Report this post to a moderator | IP: Logged

Old Post 12-22-2001 08:30 AM
Stephen Hosking is offline Click Here to See the Profile for Stephen Hosking Click here to Send Stephen Hosking a Private Message Find more posts by Stephen Hosking Add Stephen Hosking to your buddy list Edit/Delete Message Reply w/Quote
garth
Junior Member

Registered: Mar 2002
Location:
Posts: 20

Cool

In the second edition of larman the page that is being refered to is 425.
I agree as well c and d.

Report this post to a moderator | IP: Logged

Old Post 03-23-2002 07:38 PM
garth is offline Click Here to See the Profile for garth Click here to Send garth a Private Message Find more posts by garth Add garth to your buddy list Edit/Delete Message Reply w/Quote
Gary
Junior Member

Registered: Aug 2002
Location:
Posts: 2

because we may provide different implementation to same abstract concept.(This is what the one of beauty of the object oriented technology-polymorphism).

For this reason, we could not group all the implementations and the abstract concept in the same package.

My opinion is that specialization is not the reason we put two classes in the same package. on the contrasy, I perfer to seperate the interface and implementation(specialization) in the different packages.

According to Bob Martin(objectmentor.com),

There are 3 reasons for packaging:
1) basic release unit.
2) basic change unit.
3) basic reuse unit.

Report this post to a moderator | IP: Logged

Old Post 08-26-2002 03:40 PM
Gary is offline Click Here to See the Profile for Gary Click here to Send Gary a Private Message Find more posts by Gary Add Gary to your buddy list Edit/Delete Message Reply w/Quote
GVR
Junior Member

Registered: Aug 2002
Location: FL
Posts: 20

grouping of classes..

I would pick 'C' and 'D.

As you define the use cases for a system, there would be a time when one would like to organize and manage the use cases and this would naturally lead to some logical grouping, which invariably turns out to be a grouping based on the system/subsystem. These logical groupings are basically the packages.

There could be multiple subsystems/packages/classes within packages, all working towards a common goal or to support a common lgh level of service.

Report this post to a moderator | IP: Logged

Old Post 08-28-2002 03:24 PM
GVR is offline Click Here to See the Profile for GVR Click here to Send GVR a Private Message Find more posts by GVR Add GVR to your buddy list Edit/Delete Message Reply w/Quote
All times are GMT. The time now is 07:33 PM. Post New Thread    Post A Reply
  Last Thread   Next Thread
Show Printable Version | Email this Page | Subscribe to this Thread

Forum Jump:
Rate This Thread:

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are ON
[IMG] code is OFF
 

< Contact Us - Objects by Design >

Powered by: vBulletin Version 2.3.5
Copyright ©2000 - 2017, Jelsoft Enterprises Limited.
Copyright 1999-2005, Objects by Design, Inc.