Object-Oriented Programming Concepts Quiz

Object-Oriented Analysis and Design with UML

• Object orientation employs real-world concepts in software development.
• Objects are easier for people to understand.
• A better communication medium exists among specialists.
• Data and processes are not separated.
• Code reusability is enhanced.
• Object orientation is a mature and well-proven approach.
• Most modern programming languages are object-oriented.

Objectives

• Understand the concept of object orientation in software design.
• Explain how software design can be represented as interacting objects managing their own state and operations.
• Describe the activities involved in the object-oriented design process.
• Understand the function of various UML diagrams.

What is an Object? (Part 1 of 2)

• An object is a noun (anything with identity, animate or inanimate).
• Objects have attributes (e.g., student matriculation number, course title, car's brand).
• Objects also exhibit behavior (e.g., student promotion, course registration, car movement).

What is an Object? (Part 2 of 2)

• In object-oriented software development, real-world objects are represented in the code.
• Objects become independent modules with their own data and processes.
• Object properties like name, age, sex can be updated later to include details like height and origin.
• Object roles change depending on the context (e.g., person in hospital, student, doctor).

How Objects are Represented

• The object's name is underlined.
• Attributes represent its knowledge or data.
• Operations describe its behavior or methods.

Key Concepts of Object Orientation

• A class is a template for building objects; object instances evolve from a class.
• A person object has attributes like name, address, and date of birth.
• Operations include changing name, computing age, and changing address.
• A class encapsulates characteristics common to a group of objects.
• Every object is an instance of a class.
• Classes are denoted similarly to objects, except the class name is not underlined and begins with a capital letter; it tends to be short and singular.
• Relationships among objects via association, inheritance, composition, and aggregation.

Relationships

• Relationships connect objects.
• Association is a loose connection between objects (e.g., driver, passenger, and car).
• Aggregation is an "is part of" relationship where objects are grouped together (e.g., house and rooms).
• Composition is a strong "is part of" relationship (e.g., chair and seat, back, and legs).
• Inheritance is a relationship where subclasses inherit attributes and behaviors from superclasses (e.g., car and sports car, car and saloon).

Links Between Objects

• The connections between objects are called links.
• Links can also be attributes, and their labels indicate the attribute's name (e.g., a customer has an address, and a name attribute).

Multiplicity

• Multiplicity specifies the minimum and maximum occurrences of an object/class related to another object/class (e.g., one car can have 0 to 1 or 1 to 1 carburetors).
• For example, a car may have 1 or 0 carburetors. Zero to n means any number up to an unlimited amount, such as a car having zero or more seats.

UML Categories

• UML consists of about 13 types of diagrams representing the structural and behavioral aspects of a system.
• Structural diagrams emphasize what must exist in the system.
• Behavioral diagrams emphasize events and flows of what must happen within the system.

Hierarchy of UML Diagrams

• A diagram hierarchy exists for UML diagrams.

UML Structural Diagrams

• Class diagrams depict object structure and relationships.
• Component diagrams illustrate physical architecture, components, and connections.
• Deployment diagrams show the hardware and software (processors, devices) in the system's architecture.

UML Behavioral Diagrams

• Use case diagrams depict interactions between external agents and the system; They show actors, use cases, and relationships.
• Activity diagrams and object flow diagrams represent activities, object states, state transitions, and events.
• Collaboration/communication diagrams display objects, relationships, and message exchanges.
• Sequence diagrams illustrate objects, relationships, and message exchanges chronologically.
• State diagrams show states, state transitions, and events.

Overview of Process in OOAD & Key Questions

• Requirement gathering phase: Use case scenario, use case diagrams.
• System analysis phase: Class diagrams.
• System design phase: System architecture and component diagrams.

Requirements Gathering Phase

• Business modeling involves understanding the software's operating context.
• System requirements modeling defines the software's capabilities and non-functional specifications.

System Analysis Phase

• Analysis involves understanding the system's entities, properties, and relationships.

Analysis Phase

• Identify relevant classes.
• Document the class diagram.
• Identify class relationships and multiplicity.
• Draw class diagrams.
• Identify class attributes.
• Ensure agreement with use cases.

Step 1: Identify Classes

• Candidate classes can be identified from the requirement models.
• Important tips include using nouns from use cases.

Step 2: Identify Relationships

• Identification of relationships among these classes.
• Possible types of relationships include inheritance, association, aggregation, and composition.

Book Reference

• Object-Oriented Analysis and Design Understanding System Development with UML 2.0 by Mike O'Docherty.