How to find Classess 3

[vasudev123]

Hi All,

I am beginner to OOAD. Please do not feel bad if it is a dumb question.

Please suggest me easy process to identify classes for requirements. Other than identifying noun and noun phrases technique.

Thanks.

 

[grooke]

1. When talking to high level people, listen to the things they say the project is about. "We need a system to record Customer Contact!" There you are: Customer, Contact, Staff member(implied). This is often called a domain diagram. This uses 'Nouns' but at a high level and often implied. You are right, describing the system in detail and identifying nouns is a thankless task.

Incidently, your first use case is in there 'Record Customer Contact'. Then look at all the domain objects with the CRUD approach (What is meant by 'create', 'Read/display', 'Update' and 'Delete') for each domain objects. You will have half a dozen more use cases.

2. When you have a good list of use cases and a use case diagram, think each one through step at a time. There are standard templates that help this. Work out who does what to things. These 'things' are probably more business classes.

Make use case descriptions an 'interface' for the interaction of the user (actor) and the system.
User does A, System response with X
User does B, System responds with Y etc.

Write down any business rules that you cant place at the moment. These will ultimately be added to appropriate classes or associations as constraints. When you come to apply these to classes, you will again find classes you had missed.

3. Draw a sequence diagram. This finds classes that you didn't need to think about before. For example, if the user wants to remake a contact, they need their phone number. This may be shared with other contacts and so needs to be in a list of phone numbers associated with Custoerms. So now you have classes for Phone Numbers, Addresses, email addresses, and a list of these called a phoneBook or Address Book.

This raises other issues. Is the customer a person or a company; two subtypes of customer maybe; they are better as subtypes of 'Person' so that this class can also be used for your own staff.

Also, the Sequence diagram will force you to add 'methods' to the classes. You will change these later, but they are a good start.

4. All the time, you will have been adding the classes to a class diagram, that started life as the domain diagram. Looking at this, you will see lots of additional classes that make it more complete. Some people use this approach more than use cases and call it 'Domain Driven Analysis' instead of 'Use Case Driven Analysis'.

You will also see link classes that resolve many to many relationships and many others.

5. Then take each use case and create a class stereo-typed as 'Application Controller'. This takes the sequence diagram logic and uses it to work through the classes involved with that use case. Controllers will end up with a lot more in them than just these steps, but it is a start.

6. (This is a bit of poetic license) Then take all the use cases and draw an object collaboration diagram, showing all the screens and the order they are displayed in. Now each screen is a 'View' or 'Screen' object. Create a class that identifies the data that needs to be seen on the screen. Prototype it a 'Screen' identifying what needs entering, and placing screen controls in the 'methods' section. This is the start of your screen prototype, and is enough for quite a lot of thinking.

You now have a basic architecture with
Model (Business classes)
View (Screens)
Controller (Use Case controllers).
Then there are a million things you can do.

However, it gives you a lot of classes to start with.


Good luck.

Gil

 

[chiph]

Star for grooke.

vasudev123 -
You'll want a tool to track all this stuff. Good OOA/D graphical designers are Enterprise Architect from Sparx Systems, and MagicDraw.

They can be overwhelming at first, but if you follow the application design steps like grooke said, you should be OK. Don't go from one stage (Analysis) to another (Design) to another (Implementation) until you're absolutely sure there's nothing left to do in your current stage.

Chip H.


____________________________________________________________________
Donate to Katrina relief:

http://s1.amazon.com/paypage/PELYGQVJ8Q7IB/103-6821258-5919825

If you want to get the best response to a question, please read FAQ222-2244 first

 

[BobRodes]

Another star for grooke. A couple of little things to add:

1. What Gil is describing in his section 2 are often referred to as "use case scenarios." A use case scenario represents a single path through a use case diagram. Chart each possible path through your use case diagram as a use case scenario (any variation in the path constitutes a separate use case scenario). Now, each use case scenario can be represented as a sequence diagram.

2. Though I was unaware of the terms (thanks Gil), I generally find myself using a combination of "use case driven" and "domain driven" analysis.

3. There is a one to one correspondence between sequence and collaboration diagrams: they are different views of the same thing. Sequence diagrams show better what's happening at a given point in time, and collaboration diagrams show better which objects interact with which. So, a collaboration diagram also represents a use case scenario.

4. If in your sequence or collaboration diagram you find an object with a great deal of activity (lots of arrows pointing at it), consider building a statechart diagram to clarify the way that it interacts with associated classes.

Bob

 

[grooke]

Thanks for the feed back. I have a comment or two that I want to make in hindsight:

1. That was a rushed overview, and only covers a small fraction of the ways of approaching this problem. Every job is different. You need to try ideas and NOT necessarily follow a detailed method.

2. Like Bob, I nearly always end up using both 'use case' and 'domain' approaches. Usually one dominates and the other is used as a check on the first.

3. I have to confess. I dont get on with 'Collaboration' diagrams for the use cases and so only use sequence diagrams.

4. I have to confess. I use the collaboration diagrams as 'Navigation' Diagrams showing the user interface.

(Very Non-UML) I make each screen an 'object' in the diagram and the links show the ways of navigating between them; representing buttons, links etc. I can then enter the data I want to see on that screen, if that looks helpful; it usually finds one or two more business classes. (Viseo and Select are far better than Rose for drawing these, because they let you add several links on one arrow.)

However, it is NOT a typical collaboration diagram, which, as BOB says, is a topological equivalent (same thing drawn differently) of the sequence diagram.

5. Finally, in original comment 3, I referred to 'Subtypes of 'Person'': I meant 'Party'.

Make 'Company' and 'Person' subtypes of 'Party'. Now persons can have roles of 'staff' and 'Customer' and 'Customers' can be either 'Companies' or 'Persons'.

Gil

 

[BobRodes]

<I have to confess. I dont get on with 'Collaboration' diagrams for the use cases and so only use sequence diagrams.

Gil has a lot of company there. Most tools will automatically generate a collaboration diagram from an existing sequence diagram, or the reverse, so adding one into a collection of diagrams is trivial.

Gil, as for your number 4, it seems to me that you are in fact representing use case scenarios by your concept of "Navigation". If you represent your UI in terms of use cases, and then draw paths through the use cases, you would represent these paths by either sequence or collaboration diagrams, wouldn't you?

Bob

 

[grooke]

Yes! but! Screens and use cases should NEVER be equated. One use case may involve many use screens and one screen may serve many use cases. There are lots of other reasons for keeping them separate. Stopping user committees designing 'camels' is another.

Screens are definitely in the UI (View) and use cases are on the Business Class (Model) side of the Application Controller.

In a sense, you are right. If I decide that Screens are 'Sort of Use Cases', then I'm drawing the Collaboration diagram for that scenario. However, the triggers for each flow are the buttons and links on the screen, not methods called in the objects. OK, these buttons all fire discrete methods, but conceptually it is different. I encourage this differenct from ONLY modelling Use Cases as Sequence Diagrams and ONLY modelling Screens as object in Collaboration Diagrams.

I also do this on the Sequence Diagrams when you need to put in screens as objects. Some case tools provide a 'system boundary' line to put between the screens and the Business Classes. I think it is even better to put in a controller class between the two; this is of course, the 'Application Controller' representing the use case you are drawing. There are other advantages of doing this:
Robustness - it ensures you never break the rules
Architecture - It gives a good view of what the controller needs to do, from the application end. This then helps to decide how to design that controller.

Gil

 

[BobRodes]

I'm not sure I made something clear here. I draw a distinction between use cases and use case scenarios. A use case scenario is defined as a single path through a use case diagram. It would begin with an actor (say pushing a button) and end with a result. So no, I don't suggest that screens and use cases should be equated either. What I do suggest is that a single path through a use case diagram can be modeled as a sequence and/or collaboration diagram, and that it is often helpful to do so.

So Gil, what I was wondering is whether your "navigation" collaboration diagram can be perceived as a single path through a use case diagram. Furthermore, why can't the view be modeled in terms of use cases as well?

In case it's not completely clear, let me point out that I'm asking these questions out of curiosity, not to start an argument. While I have considerable theoretical background in UML, I don't have the practical experience that you seem to have. I suspect that's what makes our discussions interesting.

Bob

 

[grooke]

I find it very interesting to have someone with whom I can have such a conversation.

I think you might be right in some way. I've not looked at it the way you suggest.

There is a lot of commonality between a use case path and a navigation path. I think that a use case path MUST always have a navigation path to go along. The trouble I have is the other relation. Given use case paths, how do you identify them in the Navigation Diagram. Also, several paths may actually use the same Navigation path. In fact several use case could have several paths that all use the same Navigation Path.

I have always seen the difference and so kept the two diagrams different. They are NOT one for one as for the collaboration diagram and the sequence diagram.

Ah! I think I see it. A use case path is mapped as a sequence diagram which essentially maps a path through the buiness classes. My Navigation diagrams map a path through the screens. If all screens displayed all the data of one and only one class and was the only way of displaying that screen, then the two would be the same. As soon as a class needs or uses more than one screen, or a screen needs or uses more than one class, then they can/will differ.

I'll think some more. My Friday night drive is 3 hours long, so it will be a good time to think.

Gil

 

[chiph]

The two have different audiences:

Use case paths are what developers need, in order to write the code.

Screen navigation paths are what general business folk need in order to visualize what's going on. Developers can make use of them as well, but to a developer it's a high-level design document.

Chip H.


____________________________________________________________________
Donate to Katrina relief:

http://s1.amazon.com/paypage/PELYGQVJ8Q7IB/103-6821258-5919825

If you want to get the best response to a question, please read FAQ222-2244 first

 

[BobRodes]

I guess I'm not sure what you mean exactly by "navigation diagram." Does it mean something like "user pushes button x, and is presented with screen q, upon which he selects an item from listbox z, and is presented with a message saying 'mission accomplished,' user hits ok and is presented again with screen q." If so, that's equivalent to a use case scenario and can be modeled as a standard collaboration or sequence diagram.

Bob

 

[EdwardJS024]

How about, draw what comes to your mind. Use rectangles as things. Try to represent your thoughts visually by letting the "things" in the problem space talk to each other via cariations on connecting line shapes.

This natural way of putting the problem in front of you is the basis of UML. Once you have UML, you will eventually see classes forming in front of you, this is modeling the problem.

Example, if a busines rules states a student has-a collection of classes. That would be a student rectangle with a diamond shape arrow:

[Student]<>----->[Class]*

does that help?

 

[grooke]

I'll take these one at a time, despite the fact that they are all overlapping comment.

Chip.
My audience for UML is a lot wider than that:
[ul][li]Business folk should underatand the high level stuff[/li]
[li]Business/Systems Analysts/Architects should be given a more complete view[/li]
[li]Designers will need to copy/rework the analysis[/li]
[li]Screen designers have a strong interest.[/li]
[li]Developers use it directly, or the designer variant[/li]
[li]The Data Adminstrator will have a very direct interest in the models, either to generate their logical model or at least keep it in synch.[/li]
[li]Testers should be able to use the use cases almost directly as skeletal UATs, and need the othe diagrams to see how to construct system and integration tests.[/li]
[/ul]

Use case paths are what developers need, in order to write the code.

Almost everyone should be interested in these. Testers are probably the first. Then developers, screen designers (who are specialists developers) etc.

Screen navigation paths are what general business folk need in order to visualize what's going on

The screen designers are the most interested. Business folk get too carried away by trying to define camels, so I keep them away as much as possible; they are asked to validate the design. Testers have a major interest in which windows can open which windows and when; they not only test this, but then use it for their other testing. For some developers, these are of remote interest, but for the guys using Strutts, ASP, JSP, VB, C# etc they are their basic documents.

Bob,
1. Yes that is exactly what I mean.
2. No it is NOT the same as a use case diagram.

It is a mistake to mix business classes and screen. Sort of like, linking classes with UI objects without an intervening controller (Robustness Analysis and all that). Let us say we move a screen from the WEB to WAP. It wont fit, so we need to cut the display into bits. We are NOT changing the use cases, but we are changing the screens.

It is a mistake to mix business classes and screen.

Edward.
You are right, in a way. If I'm not writing strict UML, then I should NOT use UML nomenclature. But, I always stereotype the classes as <<Screen>> so I hope that that is enough. Sometimes, I use all the sections in the class icon: stereotype, name, attributes, for displayed data, and buttons and controls in the 'methods' section.

Note: I'm NOT doing this to identify use cases and classes. Normally, I decide on the screen navigation AFTER I have mapped these. It is only then that I begin to know what screens I want, what data they display and how they work together.


Thanks for the feedback. Its sort of makes me sit back and think deeply, which is good for my soul ;-)

Gil

 

[BobRodes]

<2. No it is NOT the same as a use case diagram.
We're having semantic problems here, Gil. A use case DIAGRAM is not the same as a use case SCENARIO. I'm saying scenario and I believe you're understanding me to mean diagram. They are two different concepts and the semantics are well-established. Googling on "uml use case scenario" reveals

http://www.bredemeyer.com/use_cases.htm

and

http://www.sparxsystems.com.au/resources/tutorial/use_case_model.html,

both of which describe the idea I'm trying to convey.

I don't see why use cases that deal with the view need to be modeled differently from use cases that deal with business logic, either. Furthermore, I don't see where you are not writing strict UML. Seems to me that you are.

Bob

 

[grooke]

Sorry, I meant 'use case' or 'use case scenario'.

My thesis is roughly this:
1. Use cases identify WHAT the user wants to do and NEVER HOW.
2. Screens are Classes determine HOW a user interacts
3. Hence Use cases should never refer to screens.

4. Sequence Diagrams and Collaboration Diagrams realise use cases, by mapping them to business classes. Adding Methods (or just messages) to Business Classes is what they are good at.
5. They may also map them to screens, but this is secondary. They may encourage ideas for screens, but they never actually define them.
6. I keep Screen design separate.

7. Screen design needs:
a. Ergonomic objectives, normally included in the non-function documentation. (Must use Ccompany colours, minimal training etc.)
b. Standards for the Look
c. Feel is mostly designed from the way people navigate between screens. To identify this I use 'Menu Trees', Navigation diagrams etc.

8. Navigation Diagrams show
a. 'Screens as rectangles.
b. In each rectangle, you add the data that is to be displayed or entered.
c. The controls that are needed to trigger operations and moves to other screens.
d. Associations between the screens (rectangles) that illustrate the effect of these controls.

9. A collaboration diagram does this very well, particularly in Viseo and Select, where several operations can be overlaid on the one association.

10. A real collaboration diagram would have a mix of classes, some screens, some controllers and some business objects, exactly as you would expect in a sequence diagram.
11. My Navigation diagram only has screens and their navigation paths. It shows all the screens associated with the whole (or a major subset) of the project on one diagram.
12 My Navigation Diagrams have NO controllers and NO Business classes.

My (unconventional) convention is that
a. Collaboration Diagrams always show Navigation Paths and
b. Sequence Diagrams always realise Use Cases.

My other (Unconventional) convention is
a. Activity diagrams with swim lanes are always Business Process Diagrams, used for identifying use cases
b. Activity Diagrams without swim lanes always expand the logic of some method.
c. I try to avoid all other use of Activity Diagrams.

I hope that clears up the confusion I caused.

Gil

 

[BobRodes]

Regarding your thesis: it's a perfectly fine way to go, as far as I'm concerned. I would observe, however, that the fact that the purpose of screens is to implement business rules doesn't automatically invalidate the idea that one may look at WHAT a screen does, and map that behavior using use case diagrams. As I see it, use case diagrams are useful for non-technical people, since they can be made to understand them with minimal training. Presenting a use case diagram to someone who will be using a screen is often a very useful device to get that user to come up with refinements. So, while your thesis again works for me, departure therefrom also works for me, since I don't take your major premise as a given. As such, I stand by my own point of view as valid too. A use case scenario represents a single "run time" instance of a use case, and can be diagrammed by a single sequence and/or collaboration diagram, and my example is valid given that it is valid to represent screen behavior with use case diagrams.

And for the record, I don't think you're causing any confusion. That's the fun of soft skills; there are as many right answers as there are people.

Bob

 

[grooke]

For the moment. Let me just ask how you deal with the '1xWeb requires 4xWaps' situation I outlined?

When I have a moment, I will outline a problem we have here; it is exactly what I fear from including screens.

What do they say? 'If you have 12 analysts you will have 13 different solutions!'

Gil

 

[BobRodes]

<'If you have 12 analysts you will have 13 different solutions!

Ain't that the truth. The nice thing is we all get to be right.

 

[BobRodes]

<'1xWeb requires 4xWaps' situation
Sorry, not sure what you mean.

 

[grooke]

I include detail of a web page in a use case.
I then have to swap the Web Page for four WAP pages, because they are so much smaller.
The use case has NOT changed, but I have to amend it.
Therefore, Specific display screens should NEVER be mentioned in a Use Case.

Gil