Let the customer talk--find what the system needs to Do...(later can think how the system will do)
U need to imagin and relised how the system actually work to get better requirements..
Ask the questions to identify actually what they need..,.........
want to imagin by listing the steps for each tasks one by one.......
1. List out the steps for a task(for one task may be 7 steps to complete the task)
2. Write down the ALTERNATE PATHS for each steps which may be affect for that task
3.
Use cases
Use case is what the system does to accomplish agoal...
List of steps that the system has to do work correctly...
usecase is for specially accomplishing one perticular goal...
For each goal required seperate use cases..
We can easily realise soround stuffs of task by creating use cases(Ex-door want to close automatically)...therwise never can it properly..
We can use use cases for explain the system to customer or Boss...
want to maintain as simple with everyday language..
Use cases
1. Every use case must have a clear value to the system(mean usecase help to the achive the goals)
2. Every use case must have definite starting and ending point..
3. Every use case have a external initiator...it may be out side the system.
Ex-
1. clear value - Todd at the bed, dog out side the .....no warries...
2. External Initiator-dog barks for to be let out
3. stoping point -The door shut automatically
AFTER WANT TO CHECK REQUIREMENT LIST AND USE CASES TO CHECK WHETHER ALL THE REQUIRMENTS HAS COVERED OR NOR...
Compare the requirements to apply foe each use case steps....
With Requiremnts and Use cases and after comparing and finalising it , can start the coding.................
First implement main uce cases and second vertion do for the alternate paths...
Also checking on use cases we can identify correct requirements..............
Make sure ur requirements cover all the steps in the use cases for ur system..
Use use cases to find out about things ur customer forget to tell u......
Use cases will reveal any incomplete or missing requirements that might have to add to ur system....
page 139 hv definitions in a box...............
================================================================================
Analysys Unit 4-----------------------------------------------------------------------
Textual Analysis(nouns=classes/verbs=methods) is what to focus on, not just classes want to create.......
1. Identify the problem
2. Use cases can use to let you show , customers, managers and other developers how the system works in real world COntext....
3. Create use cases.Good use case must clearly and accuratly explains what a system does..
4. Consider use cases that have hv nouns(person,place,thing..)..
5. List all the nouns(dont't duplicate any).
6. probably allthe nouns may be classes in the system........................
7. But nouns which are not include to the system is not become classes..Like=:Owner,Outside
8. Recheck NOUN LISt extract from use case again.
9. With a good use case complete, textual analysis is a quick and easy way to figure out claases in the system..
Actually textual analysis is tell you what to focus not just what the classes should create...
some use case noune may not become to classes, but want to consider those at the desiging time....
Action(verb of a use case) may be a class
no-------- some related things which are not nouns at the use case may be classes to the system, so want to think on that...
use case nounce will be classes
use case verbs will be methods of classes
*** Try to use objects for most og the cases
*** Try to make method delegation its make loosly coupling systems
A solid Line=: association(by reference,extension,inheritence)..
name of the attribute and multiplicity in the source class is written at the target end of the line.
Redrawing a class diagram is very easy than rewriting coding....so drawing class diagrams is better for analysing....
class diagrams great way to show overview of the system..
but dont show everything....
Probs of class diagrams..
Limited type information
don't tell how to code a method.
class diagram is only give a overview.
GOOD DESIGN-Unit 5-----------------------------------------------------------------------
If we hv same type number og objects(Guiter and Mandolean), we can think obout super class and sub class(instruments/mandolean and Guiter)
after want to abstract(inherit) that super class(we hv specefic notation arrow for inheritance)
Abstract classes are placeholders for actual implementation classes
we cla not inataintiate a abstract(super) class, only we can cdfine sub class of super class
Abstract classes defin behaviours....Sub classes implement those behaviours...
whenever U find common behavoiurs in two or more places, Try to absract that behavoiurs in to a class , and then reuse that behaviour in the common class...
Abstract class can associate with another abstract class..
super class or sub class can associate with any enum types like classes
Aggregation (Square with line)+: one thing is made up of another thing..
Line with uncolored arrow head is generalisation..its for extending/inheriting..it is the generalisation..
Remove all the duplicate coding using abstract classes and encapsulation....
check U hv applied OO principles....
Check Ur design is loosly coupled...
Check Ur system can esily extend...
To check a software whethre it is well-designed , u try to change it, if it is very easy, then system is well-designed....
Interface is a good concept for make extendable softwares...
We can use interface for inherit common behaviours to number of sub classes from a super class just like inheriting a class..
Encapsulation helps for protect your classes from unnessesary changes...
*** In classes there are two types of methods...one is stable methods, otherone is vary methods...
Means...we hv to change some methods very reraly..But some methods hv to chnge very frequently....
So in this kind of situation,...We use encapsulation for un stable methods...Using INTERFASE...
EACH CLASS HAS ONLY ONE REASON TO CHANGE.....
Each class has only One reason to change.................
*****For each valuble task make diferenet classes...that is GOOOOOOODDDDDDDDDDDDDDD........
class with methods fro= start,stop ,carWash,Driver,Mechanics..is Not good..
make it 4 classes like automobile for start and stop, carWash,Driver,Mechanics...like this way...
Try to sperate coomon properties..this leads to encapsulation.....
================================================================================
Good Design.. 5(2)-----------------------------------------------------------------------
For changing part of a system , try to use java collection ........like Maps
then u reduce number of sub classes......
take use of enum..........
----------------------------------------------------------------------------------
***
requirements are translated though analysis to a good design?
What are the best practices that can be applied in doing so?
how to write use case as a means to capture requirements,
object oriented analysis
and applying fundamental patterns to create good object oriented designs.
Generalized Responsibility Assignment Software Patterns (GRASP Patterns) that are primitive,
but powerful concepts that can be applied in creating good object oriented designs.