Whats Object Modelling?
Object modelling is about creating a blue print of the software system that is to be constructed from objects.
There are many object modelling methodologies. Typically a modelling methodology consists of following three components
1. Process : The how to steps for gathering requirements and determining the abstraction to be modelled. There are many proceses out there. The one which has wider acceptance is Rational Unified Process – RUP. RUP is a software development methodology that contains analysis, design, project management, configuration & change management.
2. Notation : A graphical language to represent the model. There are many standards available for representing the model in graphical notations. A couple of them are
OMT – Object Modelling Technique (James Rumbaugh)
Booch Method – Grady Booch
Use Case as means for finalizing Requirements – Ivar Jabcobson.
UML – Industry Standard. (The above three guys contributed much to this standard)
3. Tool : A tool to help us to build the model.
Requirement Analysis using – "Use Case Modelling".
USE CASE is a narrative or graphical represenetation of a particular goal of a system. ie, the representation of
(1) who are all the users of the system,
(2) what services should the system provide
(3) when teh user(s) interacts with the system for a particular purpose, what is the desired outcome.
1. Use Cases capture only the functional requirements (like purpose of the system, users, look and feel etc.) of the system. ie goals of the system. They dont capture the technical requirements (like how the system should be implemented, whether it will use a particular technology etc).
Actors : Actors are the users of the system after its build. They can be end users, a computer system or anything. Note that a particular user can play multiple roles- example John can be a regular user of the system and can also be administartor of the system. In this case, there are two actors – regular user and administartive user. So, dont confuse actors with physical person. You need to identify all users(and roles) of the system. Once its identified, it can be represented in a graphical format using UML like below. Actors are represented as a sticky figure, the use case by an oval and the system boundry is represented by a rectange.
Note that there can be arrow heads in the line that connects the actor and the system. An Actor can provide information to the system, can consume information from the system or do both.
A use case represents a logical series of events begining with Actor's first contact with the System and ending with the achivement of actors goal of using the system. In a Use Case, an actor always initiates the process.The use case shown above is a highlevel one. It can be decomposed based on the system. For smaller systems, there can be usecase for each module, a larger system there can be an usecase for each functionality.
Classes identified can be classified like
1. Domain Classes – That represent the system
2. Implementation Classes – These classes are doesnt represent the system, but are required for implementation. For example collection class is an implementation class
3. Association Class – A class used to associate two classes. For example if there is a many to many relationship between two classe, then a third class called association class is introduced to make the relationship. (just like data modelling, we introduce a third table to refer a many to many relationship)
Sequence diagrams are UML diagrams for representing various scenarios of the system.
Graphical representation of how message should flow from one object to another in carring out a given scenario.