An introduction to object-oriented modeling, explaining core concepts like objects, classes, attributes, operations, abstraction, encapsulation, inheritance, and polymorphism, along with UML notation for class and instance diagrams.
As information systems grow increasingly complex, traditional design methods often struggle to manage the scale of modern software. To combat this, engineers use Object Oriented Modelling, a method that breaks down a large, complex system into a number of smaller, co-operating components or subsystems. By designing each component separately, we can simplify the integration of large systems and facilitate the design of distributed systems.
Object Oriented Modelling Principles
The core philosophy of object-oriented design is to create components that are modular and reusable. For a system to be effectively modelled, its components should possess several desirable properties:
Defined Responsibility: Each component must have a clearly defined role.
Order-Driven Action: A component should act when requested by an "order" from another component.
Abstraction of Implementation: Other components should know what a component does, but they do not need to know how it does it.
Reusability: Components should be general enough to be used in different contexts, reducing the variety of unique components needed through inheritance.
Understanding Objects and Classes
In an application, we model entities as objects. These can be tangible entities, such as a student, a cycle, or a train ticket, or intangible entities, such as a bank account or a specific data structure.
Objects with similar meanings and purposes are grouped together into a Class. A single member of a class is referred to as an object instance.
Characteristics of Objects
Every object is defined by three fundamental characteristics:
Attributes: These are the data elements or properties of the object. For example, a Student object might have attributes like Name, ID Number, and Department.
State: This describes the current condition of the object at a specific time. For instance, a Ticket might have a state of reserved or waiting list, while a Student might be present or absent.
Operations: These are the actions or behaviors that can be performed on the object, such as Admit student or Cancel ticket.
UML Notation: Class and Instance Diagrams
To represent these concepts visually, the industry standard is the Unified Modelling Language (UML).
Class Diagrams
A Class Diagram represents the structure of a system by showing its classes, their attributes, and their operations (also known as methods). A standard UML class box is divided into three sections:
Top Section: The Class Name.
Middle Section: A list of Attributes.
Bottom Section: A list of Operations/Methods.
Instance Diagrams
While a class diagram shows the blueprint, an Instance Diagram shows a specific object created from that class, including its specific attribute values.
Operation Types
When implementing operations (methods) on objects, they generally fall into three categories:
Constructor: Used for creating new instances or deleting existing ones (e.g., add new vendor).
Query: Accessing the state of an object without changing its value; these have no side effects (e.g., find vendor address).
Update: Changing the value of one or more attributes, which affects the object's state (e.g., change address of vendor).
Core Object-Oriented Concepts
To achieve high-quality software design, four major concepts are employed:
Abstraction and Encapsulation
Abstraction involves picking only the necessary operations and attributes required to specify an object for a particular context.
Encapsulation (also known as information hiding) is the practice of hiding the implementation details of methods from the outside world. This allows a developer to modify how a method works internally without breaking other parts of the system, as long as the external interface remains the same.
The Contractor Analogy: Think of objects as contractors. A client hires a contractor to complete a job (the contract). The client knows what the result will be, but they do not need to know the specific tools or methods the contractor uses to get it done.
Inheritance, Generalisation, and Specialisation
Inheritance allows new classes to be created from existing ones by inheriting their attributes and operations. This facilitates two related processes:
Generalisation: Creating a more general class from specific ones (e.g., taking Eye Surgeon and generalizing it to Surgeon).
Specialisation: Creating specific subclasses from a general class (e.g., taking a Doctor class and creating subclasses like Surgeon or Physician).
Polymorphism
Polymorphism is the ability to manipulate objects of different classes using a common interface, knowing only their shared properties. For example, a system might have a generic admit command. This command would be interpreted differently by a Hospital class than by a School class, but the client can issue the same command to both.
Identifying Objects in an Application
One of the most critical steps in modelling is correctly identifying which entities should become objects.
The Noun-Verb Method
A simple starting point for identifying objects from a requirements specification is:
Identify Nouns: These are potential objects.
Identify Verbs: These are potential operations.
Criteria for Selection
Not every noun is an object. To avoid "bloating" the system, use these criteria:
Responsibility: The object must be able to perform assigned services.
Attributes: It must have relevant attributes that are necessary to perform its service, and these attributes must have non-null values.
Essentiality: The class must be essential to the functioning of the system.
Independence: Objects should be independent of the system's implementation.
Rejection Rule: If an entity's attributes do not change during the system's operation, it is likely an external entity and should be rejected as an internal object.
Exam Tip: When analyzing a word statement, always check if the "potential object" actually has operations performed on its attributes. If a noun (like a "Clerk") only performs actions on other objects' attributes, it is likely a controller or an actor, not the primary object of interest.
Worked Example: University Admission
In a scenario where applicants send applications to a registrar:
Applicant (Noun): Rejected. While they have attributes, no operations are performed on the applicant; they are merely the source of the application.
Application (Noun): Accepted. Operations (like scrutinize or admit) are performed using the application's attributes.
Department (Noun): Accepted. It has attributes and operations are performed using both its own attributes and the application's attributes.
This diagram illustrates a class application process, showing the interaction between an applicant, the class application system, and the class department.
Keep reading for free.
Create an account to finish this reading and make it part of your study routine.
