SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
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
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Kengkaj Sathianpantarit wrote:Nouns from use cases are just Class "candidates", we shouldn't create classes from all nouns in use cases.
There are many ways to identify classes but the question of this topic to how to identify from requirements.
And just plain use cases may be not enough, we may need to do Use-Case Analysis task like supplement use case description (add information to use case for finding classes). We can also identify classes from "behaviors" in use cases.
Actually, we can define classes not only from requirements, we can define from the "nature" of the domain we're working on (Domain-Driven Design). I prefer DDD rather than Requirement-Driven Design.
I don't design from requirements because requirements will change, but I design from domain, and domain is hardly to change. Anyway, this is off topic.
jacob deiter wrote:
How the domain is differ from requirement?
As per my understanding, domain is the business for which software to be build?
Requirement is, what the user of the application expect from the application
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
James Clark wrote:
Designs based on anything other than business and non-functional requirements typically produce buggy or unusable software, and result in failed projects.
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Kengkaj Sathianpantarit wrote:
James Clark wrote:
Designs based on anything other than business and non-functional requirements typically produce buggy or unusable software, and result in failed projects.
I might not be clear enough. Doing DDD doesn't mean we will completely ignore requirements, we are still interested in requirements, but we focus more on domain concepts. How can we tell that we have "right" requirements, if we don't know (or don't care) about domain concepts?
And even if everybody agrees on the requirements, it doesn't mean that the requirements are "right", it just means everybody agrees on something which can be wrong. And requirements will be changed, even if today the requirements are right, tomorrow it mightn't.
I recommend everybody who is interested in software design to read Domain-Driven Design. From my experience in applying DDD, several times when requirements have changed/added I don't need to change any design, it's not because I know the future, but it's because the design driven by domain can cover unknown requirements.
"several times when requirements have changed/added I don't need to change any design, it's not because I know the future, "
but it's because the design driven by domain can cover unknown requirement
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional