Hi All, I have just started preparing for this exam.I was bit confused while reading USE CASES.Let me explain it more clearly.. Use Case is all about functionality of a system.For different interactions of external users, what system needs to perform. Am i rt? This is a purely funactional approach.Then how come this fits Object Oriented Analysis and Design? I know Use cases are part Requirement Analysis and based on this further design will be done.I was unable to answer myself how Use cases help in Object Oriented Design and how a perticular Use case is converted into Objects.?Is it not mixing of Functional and Object Oriented Design? Hope i am clear in my question. Hope somebody will help me.Thanks
--------------<br />Prashant<br />SCJP-91%
Joined: Nov 19, 2001
This could be one way Use Cases -> Domain Model -> Interfaces -> Classes
There are only 10 types of people in this world; those who understand binary and those who dont<p>Varun Narula <br />SCJP, SCWCD, IBM-486 (UML)
Joined: Aug 05, 2001
Hi: Use case connect OOAD with reality. There is nothing wrong with Use case in OOAD. Use case is not the final product of the OOAD, it is just s step stone in the process, help people to understand the process and to understand each other. HTH.
Joined: Jul 11, 2001
Originally posted by Prashant Neginahal: Use Case is all about functionality of a system.For different interactions of external users, what system needs to perform. Am i rt?
This is a purely funactional approach.
Yes. That is because requirements *are* functional - the customer expects certain functions in the system to be build. She doesn't care about OO.
I was unable to answer myself how Use cases help in Object Oriented Design
They only tell you what the system is expected to do - they don't tell you how the system should do it. In fact, you could use absolutely the same Use Cases to build the system in a procedural/functional/declarative/whatever way.
and how a perticular Use case is converted into Objects?
There simply is no direct mapping. Use cases are about the problem; you use objects to build the solution to the problem. Than you can test wether your solution really solves the problem as defined by the Use Cases.
Is it not mixing of Functional and Object Oriented Design?
No, as Use Cases aren't about the design at all. Did that help?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Sep 02, 2001
Hi, Use Case are not part of OOAD. As far as I understands, UC is, 1: Requirement Analysis(capturing) tool. 2: Communication tool between domain expert and problem solver.
Notice that, I have not use the word developer in place of problem solver! This is done delibrately, because UC is an effecient way of capturing requiremnts and stating them clearly and briefly.There usage is so brought that they can be used in any Investigation done for capturing requirements, means not only in software engineering but also in business problems too and many more. Talking in object world, relationship between UC and objects comes in exist, when one tries to find domain conecpts/objects in the UC written document. There are ways of finding domain concepts/objects, in which one of the way is finding domain concepts/objects with the help of UC written document. One may say this approach is UC deriven objects. And as according to UP (Unified Proccess), UC's are the drivers of whole project. Bye, Viki. [ March 07, 2003: Message edited by: Vikrama Sanjeeva ]
Originally posted by Prashant Neginahal: Thank you all.
U R Wellocome! Bye, Viki.
Joined: Jan 29, 2003
Many good points there. Use cases are not object oriented. They just happened to have been invented (or named) by people doing OO. Before I learned the name, I called it "writing the user manual first" In Rational's 4+1 Views of architecture, use cases are the "plus one", sometimes drawn on top spanning the other four views. We like to say that everyone on the team, no matter what task they are doing, should have a use case in one hand. Ok, it's a mild exaggeration, but reminds everyone to work to requirements. If it's not in the use case, don't waste time building it.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi