0% found this document useful (0 votes)
33 views25 pages

Week 1 Basics

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
33 views25 pages

Week 1 Basics

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 25

Object Oriented Analysis

and Design
Instructor: Ekrem BAŞER, PhD
Contact:[email protected]
Purpose of software

• What is the purpose of software?


• perform complex tasks/calculations
• ease complexity
• reduce human intervention
• reduce errors
• perform monotonous work,
• etc.
Software complexity
• Database systems
• Financial systems
• Air traffic controller
• Student information system

• The complexity is too great for one person to understand


• Complexity can never be eliminated; but it can be reduced
Reasons for software complexity
• Problem domain complexity
Some tasks are complex itself. Therefore it lends to the software.
• Nun-functional requirements: usability, cost, performance, etc.
These requirements add to the overall complexity.
Reasons for software complexity
•Communication between users and developers
may have vague idea of what they expect from the software
difficult for users to express their requirements
developers expect requirements in a specific format
both users and developers may lack domain experience
users get a better idea of the system only after seeing prototypes or
design documents
may request a change that is difficult to incorporate
Reasons for software complexity
•Change in requirements
As the software evolves, the requirements that users expect from the
software may change.
• Unpredictable behavior of software
• Developmental process
Big teams, geographical locations, communication/coordination
between developers
Resolving Complexity
• Human beings have a built-in mechanism for dealing with complexity
• Decompose each part into smaller parts till each part makes sense
individually
• Finally, integrate the parts to build the final system
• "divide et impera" — divide and rule
• Same principle is applied to programming languages
Algorithmic Decomposition
• Decomposes the problem into algorithms
• Each algorithm is part of a series of steps (part of overall process)
• Typically, a top-down approach
• start with a big picture
• break down into smaller chunks
• These steps lead to the final result (like a flow chart)
Example
• Write a software to help tutors prepare report card for their students
• The software will
• Accept student details (name, class, rollno)
• Accept test details (semester/unit)
• Accept subject name and score
• Calculate total score
• Calculate average score
• Assign grade
• Display lowest & highest scoring subjects(based on some threshold
Decompose

InputStudentlnfo
InputTestInfo
InputSubjectInfo
Prepare report card Accept calculate display
Decompose Decompose Calculate
AssignGrade
DisplayDetails
Execution
Prepare report card

Input Calculate Display

StudentInfo Assign Grade

SubjetInfo

TestInfo
Disadvantages
• Development based on the high-level specification
Often changes over time
parts have to be rewritten
• Algorithms are very specific to the application, thus, difficult to reuse
• Difficult to add new features
algorithms are tightly wired to work together
• Data is treated with low significance
data is shared between algorithms
unintentional modification can lead to disastrous results
• Focus on operations
no idea about the entity on which operation is performed
overall understanding of the application becomes complicated
Object Oriented Decomposition
• Humans can also abstract complexity and focus only on necessary
details
• unwanted details are ignored
• deal with relevant details only
• leads to simple entities in the problem domain

OS Filesystem type
Storage Battery type
Battery Camera aperture
Networks Image format
Screen size Color space
Camera
Object Oriented Decomposition
• Recognize relationship between these entities
some entities may be generalized
• Understand how they interact and coordinate
• The coordination gives rise to the functionality of the system
Object Oriented Decomposition
• Uses bottom-up design
• The system is decomposed as a set of autonomous, but cooperative agents
• These agents are objects and represent key abstractions in the problem
domain
designed with detail
• Each object has its own behaviour
• Models some object in the real world
• The objects coordinate with each other
coordination gives rise to functionality of the system
send messages to each other
Object Oriented Decomposition
Object A Object F

Object E
Object B

Messages

Object C Object D
Object Oriented Decomposition

Reportcard Student Test Subjects


Generate
Get details ComputeAverage GetMarks
GetGrade
Advantages
• Follows separation of concerns
each entity has its own responsibility
addresses the complexity through organization
• System is made of objects that represent real-life entities
• Maps closely to real-world problems
• Data has high importance
part of the object, not visible externally
• Enables generalization of objects
promotes reuse of common functionality
leads to smaller systems
• Evolve incrementally over a period of time
Object Definition
• An object represents an individual, identifiable item, unit or entity,
either real or abstract, with a well defined role in the problem domain
• Model some part of reality
• Exists in space and time
• Can be invented as outcome of a design process
• Has well-defined behaviour and a definite purpose
• Collaborate with other objects to provide a higher-level behaviour
Characteristics
• An object has the following characteristics:
• state
• identity
• behaviour
• The structure and behaviour of similar objects are specified in a class
• object is an instance of such class
• a class is the blueprint for objects
• Forms the building block of an application
State
• Properties and their values constitute the state of an object
• Appear as attributes of an object
• fields, member variables, etc
• Can be of two types
• static — fundamental attributes that don't change
• dynamic — attributes that change as a result of operation
performed on the object
Example – Speaker system
Static Dynamic
• Power • Volume
• No. of speakers • Bass
• Connectivity • Treble
• Color
• Brand
• etc
Identity
• Response of the object during interaction
• Part of the responsibility of an object
• Arises due to binding between attributes and operations
• operations will internally change the state of the object
• this culminates into the behaviour of the object • Appear as operations
(member functions, methods)
• Examples
• speaker system - Change Volume, ChangeBass, ChangeTreble,
EqualizeLoudness
• cellphone - SendText, Dial, AcceptCall, Connect
Behaviour
• Response of the object during interaction
• Part of the responsibility of an object
• Arises due to binding between attributes and operations
• operations will internally change the state of the object
• this culminates into the behaviour of the object
• Appear as operations (member functions, methods)
• Examples
• speaker system — CitangeVolume, ChangeBass, ChangeTrebie,
EqualizeLoudness
• cell phone — SendText, Dial, AcceptCall, Connect
Examples
• Bank account
• Credit card
• File on a hard drive
• Employee

You might also like