SOFTWARE ENGINEERING

THE OBJECT MODEL

AHMED EZZAT LABIB
HELWAN UNIVERSITY
 TOPICS

• OBJECTS AND METHOD CALLS

• INTERFACES

• MODELLING IN SOFTWARE DEVELOPMENT

• UNIFIED MODELING LANGUAGE

• OBJECT RELATIONSHIPS

• PROCESS/ALGORITHM –ORIENTED VS. OBJECT ORIENTED APPROACHES

 OBJECTS, CALLING & ANSWERING CALLS

elmer.areCoprimes( Prime factorization:

905, 1988 905 = 5  181
) 1988 = 2  2  7  71

Result:
YES!

Stu Elmer
Prime factorization of 905:
5181 (2 distinct factors)
Prime factorization of 1988:
22771 (4 factors, 3 distinct)
Two integers are said to be coprime or relatively prime if they have no common factor other than 1 or,
equivalently, if their greatest common divisor is 1.
OBJECTS DON’T ACCEPT ARBITRARY CALLS

Acceptable calls are defined by object “methods”

(a.k.a. Operations, Procedures, Subroutines, Functions)

Object:
method-1: method-2: method-3:
ATM machine
Accept card Read code Take selection

1234
5678
12345

1
4 2
7 5 3
8 6
0 9
 OBJECT INTERFACE
Interface defines method “signatures”
Method signature: name, parameters, parameter types, return type

Interface
method-1 Object hides its state
(attributes). The attributes
method-2 are accessible only through
the interface.

method-3
 CLIENTS, SERVERS, MESSAGES

Client
Client Object
Object Server
Server
Object
Object

Message

• Objects send messages by calling methods

• Client object: sends message and asks for service

• Server object: provides service” and returns result

 INTERFACES

• AN INTERFACE IS A SET OF FUNCTIONAL PROPERTIES (SERVICES) THAT

A SOFTWARE OBJECT PROVIDES OR REQUIRES.
• METHODS DEFINE THE “SERVICES” THE SERVER OBJECT
IMPLEMENTING THE INTERFACE WILL OFFER
• THE METHODS (SERVICES) SHOULD BE CREATED AND NAMED BASED
ON THE NEEDS OF CLIENT OBJECTS THAT WILL USE THE SERVICES
• “ON-DEMAND” DESIGN—WE “PULL” INTERFACES AND THEIR
IMPLEMENTATIONS INTO EXISTENCE FROM THE NEEDS OF THE CLIENT,
RATHER THAN “PUSHING” OUT THE FEATURES THAT WE THINK A CLASS
SHOULD PROVIDE
 OBJECTS ARE MODULES

Software Module

Inputs State Outputs

(e.g., force) (represented by (e.g., force)
state variables,
e.g.,
momentum,
mass, size, …)
 MODULES VERSUS OBJECTS
Modules are loose groupings of subprograms and data
“Promiscuous”
access to data often
Subprograms results in misuse
(behavior)

Data
(state)

Software Module 1 Software Module 2 Software Module 3

Objects encapsulate data

Attributes
/data
Methods (state)
(behavior)

Software Object 1 Software Object 2 Software Object 3

 MODELLING IN SOFTWARE DEVELOPMENT
• MODELING: IS A WAY OF THINKING ABOUT THINGS AND IDEAS IN THE 'REAL WORLD'.
• A MODEL, IN TERMS OF SOFTWARE DEVELOPMENT, IS AN ABSTRACT REPRESENTATION OF A
SPECIFICATION, A DESIGN OR A SYSTEM, FROM A PARTICULAR POINT OF VIEW.
• IT IS A SIMPLIFICATION OF REALITY, CREATED IN ORDER TO UNDERSTAND AN ASPECT OF THE
SYSTEM IN QUESTION.
• A ‘GOOD MODEL’ IS AN ABSTRACTION THAT ALLOWS THOSE INVOLVED TO CONCENTRATE
ON THE ESSENTIALS OF A COMPLEX PROBLEM BY EXCLUDING NON-ESSENTIAL DETAILS WHILE
CAPTURING THOSE OF INTEREST.
• IN SOFTWARE DEVELOPMENT, MODELS ARE:
• A WAY OF UNDERSTANDING THE PROBLEMS INVOLVED.
• AN AID TO COMMUNICATE ESPECIALLY BETWEEN DEVELOPERS.
• A COMPONENT OF THE METHODS USED IN DEVELOPMENT ACTIVITIES SUCH AS ANALYSIS AND DESIGN.
 MODELLING IN SOFTWARE DEVELOPMENT
AGILE MODELLING
• AGILE MODELLING IS SCOTT AMBLER’S APPROACH TO LIGHTER MODELLING (AMBLER, 2002).
• IT PROPOSES A SET OF VALUES, PRINCIPLES AND PRACTICES TO HELP SOFTWARE DEVELOPERS
BECOME AGILE MODELLERS.
• A TYPICAL ACTIVITY OF AN AGILE MODELLER IS TO STAND UP WITH OTHERS IN FRONT OF A
WHITEBOARD, SKETCH A FEW MODELS, DISCUSS THESE SKETCHES, AND THEN DISCARD THEM
IF THEY SERVE NO FURTHER NEED.
• THERE ARE ALSO TOOLS TO HELP IN THE CREATION OF MODELS FROM EXISTING SOFTWARE.
• THEY CAN BE USED TO DOCUMENT A PIECE OF CODE THAT HAS NOT BEEN MODELLED
THROUGHOUT DEVELOPMENT.
 MODELLING IN SOFTWARE DEVELOPMENT
• IT IS BETTER TO USE STANDARD NOTATION IN MODELING THROUGHOUT SW DEVELOPMENT
PROCESS (MODELING LANGUAGE).
• A MODELING LANGUAGE IS BASED ON DIAGRAMS AND THEIR CONSTRUCTION, MEANING
AND USE.
• THERE ARE TWO RULES WITHIN A DIAGRAM BASED MODELING LANGUAGE:
1. SYNTAX: DETERMINE WHAT DIAGRAMS EXIST AND WHAT SYMBOLS ARE USED FOR.
2. SEMANTIC: WHAT THESE SYMBOLS MEAN.
• THE MODELING LANGUAGE YOU SELECT MUST:
1. ALLOWS TO EXPRESS MANY FACETS OF THE SUBJECT.
2. HELPS YOU TO RESOLVE MISUNDERSTANDING RATHER THAN INTRODUCING NEW ONES.
3. IS EASY TO LEARN AND USE.
4. IS SUPPORTED BY TOOLS.
5. IS USED WIDELY AND ACCEPTED IN INDUSTRY.
 UNIFIED MODELING LANGUAGE
UML
• THE UNIFIED MODELING LANGUAGE (UML): IS A STANDARD MODELING LANGUAGE,
WHICH IS DIAGRAMMATIC, BUT ALSO ALLOWING DEVELOPERS TO ADD TEXT, AND IS
EASY TO USE, EFFICIENTLY EXPRESSIVE, UNAMBIGUOUS, WIDELY USED AND
SUPPORTED BY TOOLS.
• USING A STANDARD MODELING LANGUAGE IS IMPORTANT:
1. IT HELPS WHEN NEW PEOPLE JOIN A PROJECT.
• IT REDUCES THE TIME NEEDED TO ENABLE THEM TO BECOME PRODUCTIVE TEAM MEMBERS.
2. IT IS LIKELY THAT PROJECT COMPONENTS WILL HAVE BEEN CONSTRUCTED USING THAT
LANGUAGE.
• THIS MAKES THE SOFTWARE EASIER AND CHEAPER TO MAINTAIN.
 UML NOTATION FOR CLASSES

Software Interface Implementation

Software Class
«interface»
Inheritance
BaseInterface
relationship:
ClassName BaseInterface
+ operation()
is implemented
# attribute_1 : int by two classes
Three compartments: # attribute_2 : boolean
# attribute_3 : String
1. Classifier name
+ operation_1() : void
+ operation_2() : String Class1Implement Class2Implement
2. Attributes
+ operation_3(arg1 : int)
+ operation() + operation()
3. Operations
 OBJECT RELATIONSHIPS (1)

• Composition: using instance variables that are references to other objects

• Inheritance: inheriting common properties through class extension

Base Class A Class A Class B
+ operation() + operation() + operation()

Composition
Derived Class B
B acts as “front-end” for A and uses services of A
+ operation()
(i.e., B may implement the same interface as A)

Inheritance
 OBJECT RELATIONSHIPS (2)

• BOTH INHERITANCE AND COMPOSITION EXTEND THE BASE

FUNCTIONALITY PROVIDED BY ANOTHER OBJECT
• INHERITANCE: CHANGE IN THE “BASE” CLASS PROPAGATES TO
THE DERIVED CLASS AND ITS CLIENT CLASSES
• BUT, ANY CODE CHANGE HAS A RISK OF UNINTENTIONAL
INTRODUCING OF BUGS.
• COMPOSITION: MORE ADAPTIVE TO CHANGE, BECAUSE
CHANGE IN THE “BASE” CLASS IS EASILY “CONTAINED” AND
HIDDEN FROM THE CLIENTS OF THE FRONT-END CLASS
 CLASS REPRESENTATION

AN AGGREGATION RELATIONSHIP IS USUALLY REPRESENTED AS A

DATA FIELD IN THE AGGREGATING CLASS. FOLLOWS:

public class Name { public class Student { public class Address {

... private Name name; ...
} private Address address; }

...
}

Aggregated class Aggregating class Aggregated class

Composition Aggregation

1 1 1..3 1 17
Name Student Address
 UML NOTATION FOR INHERITANCE
What are the members of each class in the below class diagram?

SuperClass

Subclass

Subclass

Inheritance
UML
notation
 OBJECT-ORIENTED VERSUS
PROCESS-ORIENTED APPROACHES

System

1
2
3
4
5
X
Y
Key
Key unlock() Lock
Lock turnOn() Light
Light
(b) Checker
Checker Ctrl
Ctrl Ctrl
Ctrl

Valid No
key
?

(a) Yes unlock() turnOn()

Unlock the
Key
Key Lock
Lock Light
Light
lock (c) Checker
Checker Ctrl
Ctrl Ctrl
Ctrl

Turn the
light on

Process oriented Object oriented

 OBJECT VS. PROCESS-ORIENTED (1)

• PROCESS-ORIENTED IS MORE INTUITIVE BECAUSE IT IS PERSON-

CENTRIC
• THINKING WHAT TO DO NEXT, WHICH WAY TO GO

• OBJECT-ORIENTED MAY BE MORE CONFUSING BECAUSE OF

LABOR-DIVISION
• THINKING HOW TO BREAK-UP THE PROBLEM INTO TASKS,
ASSIGN RESPONSIBILITIES, AND COORDINATE THE WORK
• IT’S A MANAGEMENT PROBLEM…
 OBJECT VS. PROCESS-ORIENTED (2)

• PROCESS-ORIENTED DOES NOT SCALE TO COMPLEX, LARGE-SIZE PROBLEMS

• INDIVIDUAL-CENTRIC

• LARGE SCALE PROBLEMS REQUIRE ORGANIZATION OF PEOPLE INSTEAD OF

INDIVIDUALS WORKING ALONE

• OBJECT-ORIENTED IS ORGANIZATION-CENTRIC
• BUT, HARD TO DESIGN WELL ORGANIZATIONS…
 HOW TO DESIGN WELL OO SYSTEMS?

• THE KEY TOPIC OF THIS COURSE!

• DECISIVE METHODOLOGICAL FACTORS:
• TRACEABILITY
• TESTING
• MEASUREMENT
• SECURITY
 TRACEABILITY
Requirements Use Cases Concepts/Objects Source Code

UC-1 CO-1 Code-1

Req-1
CO-2 Code-2
UC-2

CO-3 Code-3

UC-M CO-S Code-W

Req-K

UC-N CO-T Code-X

Requirements
Engineering Use Cases OOA/OOD Implementation
(Section 2.2) (Section 2.3) (Sections 2.4 & 2.5) (Section (2.7)

• The ability to trace the history of each requirement in a software

development process is known as traceability.
• It should be possible to trace the evolution of the system, step-by-step, from
individual requirements, through design objects, to code blocks.
 TESTING (1)

• TEST-DRIVEN DEVELOPMENT (TDD)

• EVERY STEP IN THE DEVELOPMENT PROCESS MUST START WITH A

PLAN OF HOW TO VERIFY THAT THE RESULT MEETS A GOAL

• THE DEVELOPER SHOULD NOT CREATE A SOFTWARE ARTIFACT (A

SYSTEM REQUIREMENT, A UML DIAGRAM, OR SOURCE CODE) UNLESS
THEY KNOW HOW IT WILL BE TESTED

But, testing is not enough…

➢ TO BE CONTINUE,,,