Registered: Apr 2001
Location: New York
Posts: 492

This is a great lead question (#1):

True or false. Ideally, all public methods in business model objects are defined directly or indirectly because of a use case requirement.

Let's analyze this interesting question closely.

Ideally - Is this a metaphysical question? Is this under utopian conditions?

all public methods - "all" is very inclusive and therefore a very strong statement. My understanding of public methods is that they are available to other classes. This might be a clue. What if anything could this have to do with use cases, which are meant to capture the user's interactions with a system?

business model objects - How about non-business model objects? Is the UML only used for business modeling?

directly or indirectly - Isn't everything indirectly connected in some way or another?

use case requirement - Aren't requirements a different artifact from use cases?

After all this, the reader must be befuddled. There is simply too much complexity in this question whereby every clause is loaded with interpretation. Is this intentional? What value is there in this?

Is this the type of question where you just flip a coin?

How would the question be worded if it were to be meaningful?

Sorry for elaborating so much but it is just this sort of thing that makes object-oriented design seem so unnecessarily esoteric.

Report this post to a moderator | IP: Logged

Registered: May 2001
Location:
Posts: 24

Lead Question -- Discussion

Dear SZ,
I also encounter this questions often. Hope the answer will be TRUE. because,

1) Business objects model is a realization of business usecase model.
2) Business usecase models are developed from business usecases which are from business requirements.
3) The relation between business objects are depicted through associations, which are leads to responsibility (operations) of the objects.
3) To satisfy (complete) a usecase or to fulfill a user goal, objects must interact with each other through public methods.

These are the reasons for my answer "TRUE".(Upto my knowledge)

Thanks and Regards,

__________________
sridhar

Report this post to a moderator | IP: Logged

Registered: Apr 2001
Location: New York
Posts: 492

Interesting. Question #5 is very similar, almost identical. One may draw certain inferences about the answer to the "lead question" from this question:


5) Which of the following are true about services resulting from use cases?

a) New requirements in use cases generally result in one or more public methods in a business domain class.

b) Private methods are required by the system's use cases.

c) Use cases drive the design of interaction diagrams, which in turn define public methods in model classes.

Multiple Select - Please select all of the correct answers (this question has 2 correct choices).


Now this is interesting. Since b) really makes no sense and the question has 2 correct choices, well that leaves a) and c).

Let's see a) -

new requirements in use cases - Again this mixing of requirements and use cases, which should be considered separate artifacts (see Larman).

generally result in one or more - Note that here the language is toned down a bit from the lead question which said all public methods.

public methods in a business domain class - Same leap as the lead question from use cases to public methods. Same fixation on business domains.

Let's see c) -

If you are familiar with Larman's UML Process, use cases do help produce system sequence diagrams which are a form of interaction diagram. And you can use the system sequence diagrams to identify public methods on domain objects.

So c) is actually a more formal and cleaner way of saying what I believe the lead question, as well as a) above, were both trying to say. In so many words...

What do you think??

Report this post to a moderator | IP: Logged

Registered: May 2001
Location:
Posts: 24

Lead question -- #2

I hope the answer mentioned and reasons are acceptable.
no more comment.

__________________
sridhar

Report this post to a moderator | IP: Logged

Registered: Jul 2001
Location:
Posts: 10

The main purpose of Use Cases is requirements elicitation. In which, ideally each requirement maps to a Use Case. Use Case adopts a goal oriented approach. i.e. Every Use Case is initiated by a Primary actor with a specific goal in mind. Therby is the realtion between requirements and Use Cases.
Now for the mapping between public methods and requirements. Ideally Business Objects or Components expose only those methods which are required externally. In Use Case terminology, only those methods which are required by an actor will be made public.
So the answer to the question

True or false. Ideally, all public methods in business model objects are defined directly or indirectly because of a use case requirement.

should ideally be true.

Report this post to a moderator | IP: Logged

Registered: Apr 2001
Location: New York
Posts: 492

I think hsrivatsa's comments make a lot of sense.
What does bother me is that requirements in the traditional sense (DOORS) are not so directly coupled with use cases. For example, the following may be requirements for a PDA:

1. Should have at least 32 MB RAM.
2. Should come in silver, blue, and black.
3. Should weigh less than 5 ounces.
etc...

These are very distinctly requirements but you wouldn't necessarily have use cases for these!

The other big problem is the statement:
only those methods which are required by an actor will be made public

An actor interacts with the system through the system interface. There may be a controller class which processes all interactions at the system boundary. Only it will call public methods on other classes as needed. So there is no direct correlation between use case and public methods.

Where does this discussion of use cases and public methods appear? As I stated earlier, Larman's process only makes sense when stated as in Question #5, c), which is much more formalistic.

Report this post to a moderator | IP: Logged

Registered: Jul 2001
Location:
Posts: 10

SZ the requirements you have mentioned come under a specific catergory called CONSTRAINTS(Usually response time and related requirements are captured in this section). Use Case captures only functional requirements because it's main intent is to simplify understanding and development process. So you really cannot expect Use Case to capture these "constraint" type of requirements.
As for the "public methods" query, a new requirement definetly needs a new method incorporated in the business component. There is no argument about that, right. And that method should be made public simple.
Whether that method is invoked directly by the end user or by an intermediate controller class that does not alter the situation at all. The Equation remains pretty much the same.

Report this post to a moderator | IP: Logged

Registered: Apr 2001
Location: New York
Posts: 492

OK, following your line of reasoning, could a new requirement introduced by a use case be implemented by an already existing public method of a class?

If so, then this proves my point using a backwards approach, which is that a new use case doesn't necessarily create a new public method on a class.

I much prefer to think of classes in the sense of Bertrand Meyer's OOSC2. Let his own words speak in the online essay OOSC2: The Use Case Principle. In this sense there is no formal bearing of use cases on the design of a class's interface. However, as he states, they can provide a useful validation mechanism for an object-oriented system. Please read.

Report this post to a moderator | IP: Logged

Registered: Jul 2001
Location:
Posts: 10

When you say requirement I am assuming a "functional requirement". Each Use Case has a step of actions. If there is any new functionality added to the scope, then I really think that atleast one new method will be added to any of the steps.
The fact that it could be optimised later on and 2-3 methods could be shrunk into one is an optimization activity, which I have not considered.

The Bottom line is that if a new functionality has been added to the system then I really don't think that any of the existing methods should take care of that functionality.
If you have read "Using UML" by Pohely Stevens. There is an entire chapter on how to derive at your classes from Use Case Descriptions using the "noun identification" technique. I personally have used it with great success and still am using the same methodology for drawing Class Diagrams.

Bertrand Meyer's statement is more of a precautionary statement than a forbiddance. Use Case is a pictorial and more clear representation of the System requirements. At the end of every software design the validation with requirements occurs, i.e. if the design is meeting the requirements adequately. So it does not surprise me if he writes that Use Case should be used for validating Design.

Report this post to a moderator | IP: Logged

Registered: Aug 2003
Location:
Posts: 3

From my explanation in "Best source for public method" discussion there is no sense in either question 1) nor 5)

5c) is incorrect statement because Interaction Diagrams may expose private methods thru self-call (internally) or thru delegation (thru protected or public method). I have not found anywhere restriction on visibility of operations in Interaction Diagrams.

Visibility (encapsulation) is design/architectural issue but not analysis one.

The sense of both questions and answers do not make any particular sense except of more thorugh realization of OOAD principles.

Last edited by Guenavan on 01-03-2004 at 02:18 PM

Report this post to a moderator | IP: Logged