Object-Oriented Programming Concepts

Systems Analysis & Design Methods

• This is a textbook titled Systems Analysis & Design Methods, seventh edition, by Whitten & Bentley.

Taiz University - Systems Analysis and Design

• The course materials are from Taiz University, College of Engineering and Information Technology.
• Subject: Systems Analysis and Design
• Chapter 10: Object-Oriented Analysis and Modeling Using the UML
• Academic year: 2025/2024
• Instructor: Fadi Mofeed, S.E

Objectives

• Define object modeling and explain its benefits.
• Explain the basic concepts and constructs of object modeling.
• Define the Unified Modeling Language (UML) and its various types of diagrams.
• Transform business requirements into system analysis use-case models.
• Design activity diagrams.
• Identify objects, classes, and relationships.
• Construct class diagrams.

Introduction to Object Modeling

• Object-oriented analysis (OOA) is an approach used to:
  • Reuse or adapt existing objects for new uses.
  • Create new or modified objects.
• OOA focuses on defining the static structure and dynamic behavior models of an information system, instead of defining data and process models.
• Object modeling is a technique for identifying objects within a system and their relationships.

Introduction to the UML

• UML (Unified Modeling Language) is a set of modeling conventions used to specify or describe software systems in terms of objects.
• UML is a notation, not a method, for developing systems.

Objects & Attributes

• An object is something that can be seen, touched, or sensed.
• It has data (attributes) and can perform actions (behavior).
• Objects include people, places, things, and events.
• Attributes are the data that represent the characteristics of interest about an object. Examples: employee, customer, instructor, student; warehouse, office, building, room; product, vehicle, computer, videotape; order, payment, invoice, application, registration, reservation

Objects & Object Instances

• An object instance is a specific example of an object.
• Each instance has specific values for the attributes of the object.
• Example data about a customer: customer number, last name, first name, home phone, street, city, state, zip code.
• Example data for an order: order number, order date, shipping method, shipping cost, total cost.

Behavior & Encapsulation

• Behavior describes what an object can do, which corresponds to functions acting on its attributes. Also known as methods, operations, or services.
• Encapsulation is the packaging of several items together into one object. So both attributes and behavior of an object are packaged together.
• The only way to access or change an object's attributes is through the object's behaviors.

Object Classes

• An object class is a set of objects sharing common attributes and behavior (sometimes called a "class").

Representing Object Classes in the UML

• Shows the difference between an object instance and a class.

Inheritance

• Inheritance is the concept where methods or attributes defined in a class can be inherited or reused by another class.
• Often depicted as class hierarchies or "is a" relationships.
  • Example: A Teacher is a Person, and a Student is a Person.

Generalization/Specialization, Supertype, and Subtype

• Generalization/specialization is a technique to create classes from common attributes and behaviors of other classes.
• A supertype is a class that has attributes and behaviors common to one or more class subtypes. It's also called the abstract or parent class.
• A subtype inherits attributes and behaviors from the supertype and has unique attributes and behaviors. It is also called a child class or concrete class.

UML Representation of Generalization/Specialization

Illustrates "is-a" relationship graphically.

Object/Class Relationships

• An object/class relationship is a natural business association between one or more objects and classes.
• UML refers to this line as an association.
• The verb phrase describes the association. Example: A customer places one or more orders.
• An association is bidirectional.

Association

• Multiplicity must be defined in both directions of an association.
  • Example: "A customer can place zero or more orders, and each order is placed by one customer."
• Associations define what one object “needs to know” about the other.

UML Multiplicity Notations

• UML notation for showing multiplicity in associations.

Aggregation

• Aggregation is a relationship where a larger "whole" class contains one or more smaller "part" classes.
• The relationship is characterized by the phrases "whole-part" and "is part of."
• Aggregation is shown in a diagram with a hollow diamond connecting to the whole object class. UML 2.0 has dropped this notation.

Composition

• Composition is an aggregation where the "whole" class is responsible for the creation and destruction of its parts.
• If the whole class is destroyed, the part classes are destroyed, too.
• Multiplicity is only specified for the "part" class in composition diagrams.

Messages

• Message is another term for communication (the act of one object invoking another object's method to request information or action).

Polymorphism

• Polymorphism is the concept that different objects can respond in different ways to the same message.
• Overriding describes how a subclass (subtype) inherits attributes or behaviors from its supertype but also uses its own attributes or behaviors.

UML 2.0 Diagrams

• Describes use case, activity, class, object, state, composite, sequence, communication, timing, interaction overview, component, deployment, and package diagrams.

The Process of Object Modeling

• Modeling the system's functions.
• Finding and identifying business objects.
• Organizing the objects and their relationships.

Modeling the Functions of the System

• Use-case modeling: documents functional requirements using business requirements.
• Goal to quickly document business events (use cases) to define and validate requirements.
• Object modeling refines use cases to include more detail.

Construction the Analysis Use-Case Model

• Steps involve identifying, defining, and documenting new actors, new use cases, reuse possibilities, and refining the use-case model.
• Use different steps for finding new actors, use-cases based on open issues, assumptions, and reuse possibilities

Construction of System Analysis Use-Case Narratives

• System analysis use cases describe interactions between the user and the system; high-level but without implementation details.
• Also referred to as system use cases.
• One or more system analysis use cases may evolve from a single business use case.

Revised System Use-Case Model Diagram (UML)

A diagram of the use-case model from the perspective of the software system.

Use-Case Narrative

• Describes a specific use case and its related requirements.

Use-Case Narrative (cont.)

• Provides detailed descriptions about actor actions and the system responses to aid in design.

Modeling Use-Case Activities

• Activity diagrams are similar to flowcharting. They show the sequential flow of activities in a business process or use case.
• Can depict activities occurring in parallel.
• Diagrams can be used during both analysis and design.

Activity Diagram Notations

• Discusses graphical symbols for initial node, actions, flow, decision, merge, fork, and join.

Activity Diagram with Partitions

• Diagram shows partitioned sections for different participants (actors)

Activity Diagram Notations (cont.)

• Discusses subactivity indicator, connector, and swim lanes notations.

Guidelines for Constructing Activity Diagrams

• Guidelines for building activity diagrams, including initial nodes, partitions, and steps.

Drawing System Sequence Diagrams

• System sequence diagrams visually depict how an actor and the system interact in a specific use case scenario. Diagrams are useful during the logical design stage.

System Sequence Diagram Notations

• Introduces notations of actors, systems, lifelines, and activation bars.

System Sequence Diagram Notations (cont.)

• Expands on the notations related to input and output messages, receiver actor, and frames.

Guidelines for Constructing System Sequence Diagrams

• Includes guidelines for identifying scenarios, creating system and actor lifelines, modeling inputs and outputs, and incorporating frames for optional steps.

Finding and Identifying the Business Objects

• Use case reviews to discover nouns representing business entities or events.
• Deciding whether an object (noun) is relevant to the system from a scope perspective.

Partial Use-Case Narrative

• Shows an example of a partially written use-case narrative with highlighted nouns to identify potential objects.

Potential Object List

• A list of potential objects.

Cleaning Up List of Candidate Objects

• Examines the list to determine whether potential objects are relevant or should be included in the final set of objects.

Proposed Object List

• List of selected objects.

Organizing the Objects and Identifying their Relationships

• Discusses identifying object associations, generalization/specialization relationships, and aggregation/composition relationships.
• Defines object association matrix for analysis.

Object Association Matrix

• Lists objects and the kinds of relationships between them.
• Examples include a club member placing an order, an order containing a product, and products relating to one order.

Generalization/Specialization Hierarchies

• Illustrates graphically hierarchical relationships among object classes, showing types of customers.

Class Diagram

• Explains class diagrams as a way to represent a system’s static object structure.

Class Diagram (cont.)

• Differentiates between class attributes and database attributes.

Class Diagram (cont. 2)

• Discusses the differences/importance of object-class attributes versus data entity attributes when constructing a class diagram.

Class Diagram (cont. 3)

• A detailed example of a class diagram with objects, relationships, and attributes (members, member orders, products).

This quiz tests your knowledge on key concepts in object-oriented programming and UML, including relationships between classes, aggregation, composition, and polymorphism. It explores the various UML diagrams and their purposes, ensuring a comprehensive understanding of object/class interactions.