Whether you use software development mythology or not these are the entire point of object oriented analysis and design. What class does you need and what are they do? Lot of formal mythology has their own unique name for work through their process but although there are multiple processes to approach this, the ideas are very similar. We go through using five steps:-
- Gather Requirements
- Describe the App
- Identify the main object
- Describe the Interactions (between objects)
- Create class Diagram
We are going all of these more details on technics to each step later now discus basic concept.
- Gather Requirements:-
What is the app needs to do? What problem are you trying to solve? You focus it and you write it on a paper.
- Describe the App:-
You build simply narrative how people use the app. You are not trying to write a book but you are trying to describe specific technic for this including use case, use story. This may be inaccurate, may be incomplete, may be changed that’s ok we still do it.
You may or may not at this point also create a mockup or prototype of the user interface. Sometimes that is essential.
- Identify the main objects:-
This is the actually the starting point of identifying you actual classes. So you are trying to use stories, the descriptions you just wrote to pick up the most important idea, most important concepts, the most important things in our application, not everything we pick here will become a class but, lot of them will.
- Describe the Interactions:-
As you then formally the interaction between those objects, this also lets you start a better understanding the responsibilities of the different objects, the behaviors I need to have when they interact what they do and what order they need to do, this is call a sequence diagram.
- Create a Class Diagram:-
This is a visual representation of the classes you need and here we get to really specific about object orientation principal like inheritance, polymorphism.
But no point any of these you wrote code yet, the output is on paper, on index card, on white board it could be done using electronic tools but it is really better on paper for now. The main result you expect from the process is that Class Diagram – that is the most common way you write down the classes you need to make, the methods of the classes and the interaction between the different objects in your application. In an iterative approach to developing software this is not done once, you’ll continually re-visit refine these steps over weeks and month of development.