1. Introduction to OOSD– UFCFC3-30-1 Lecture Notes Week 1
Introduction and Chapter 1 and 2

2. Introduction to Module Team
Module Tutors
Dr Mazhar H Malik
Contact: P.8,
Mr. Saqib Hussain
Contact: L4.4,

3. Outline of Lecture Introduction
Introduction to Object Oriented Programming
Object Oriented System Development Life Cycle
Object Oriented System Development Models
To Do List

4. Resources Required textbook Module materials
Introduction to Java Programming by Y. Daniel Liang, 10th Edition, Pearson (9th edition/international edition/brief version/pdf eBook would be OK if there are good deals but we will use 10th edition as reference).
Module materials
Blackboard

5. Resources Other resources Textbook site
Oracle online tutorials

6. Module Structure 3 hours of lecture 3 hours of practical
Main topics, illustrative programs
3 hours of practical
Tutorials, program exercises, class tests, group assignment
6 hours of self study
Textbook chapters, lecture slides, program examples, class test preparation, group assignment

7. Assessment Structure 5 in-class tests (50% of overall assessment)
Class tests will take place as part of five consecutive practical sessions (starting from Week 3).
Each class test will focus on the topics covered two weeks ago (e.g., 1st class test in Week 3 will focus on the topics that we have covered in the lecture in Week 1 and the practical sessions in Week 2).
Group assignment (50%)
Design, implement, test and document a substantial piece of software covering all aspects of this module.
The group assignment specification will be handed out in Week 4 with submissions in on Monday in Week 11 and demos in Week 12.
You would need to attend every lecture and practical session in order to learn and fully understand all the topics to be assessed in the class tests.
The structure and content of the class test will be very similar to the corresponding practical exercises. You would need to do those exercises with full understanding. 7

8. Basic OOP Concepts and Terms

10. Objects
Most basic component of OO design. Objects are designed to do a small, specific piece of work.
Objects represent the various components of a business system

11. Examples of Different Object Types
GUI objects
objects that make up the user interface
e.g. buttons, labels, windows, etc.
Problem Domain objects
Objects that represent a business application
A problem domain is the scope of what the system to be built will solve. It is the business application.
e.g. An order-entry system A payroll system A student system

12. Sample Problem Domain
Company ABC needs to implement an order-entry system that takes orders from customers for a variety of products.
What are the objects in this problem domain?
Hint: Objects are usually described as nouns.

13. Possible Objects for this Problem Domain
Customer
Order
Product

14. Classes and Objects Classes Objects
Define what all objects of the class represent
It is like a blueprint. It describes what the objects look like
They are a way for programs to model the real world
Objects
Are the instances of the class

16. Object Attributes and Methods
Classes contain two things:
Fields (attributes, data members, class variables):
Data items that differentiate one object of the class from another. e.g. employee name, student number
Characteristics of an object that have values
What are some possible attributes for the customer object?
Methods (behaviors):
Named, self-contained blocks of code that typically operate on the fields
Describe what an object can do
Can be thought of as the verbs in a problem domain
What are some possible methods for the customer object?

17. Object Interactions and Messages
Objects interact with other objects in a variety of relationships
e.g. one-to-one, one-to-many
Messages
The means by which objects interact
Example:
User initiates interaction via messages to GUI objects
GUI objects interact with problem domain objects via messages
Problem domain objects interact with each other and GUI objects via messages
GUI objects respond to user via messages

18. Encapsulation and Information Hiding
Objects have attributes and methods combined into one unit
Information Hiding
Hiding the internal structure of objects, protecting them from corruption
Identity
Unique reference for each object
Persistent objects
Defined as available for use over time

19. Inheritance and Polymorphism
One class of objects takes on characteristics of another class and extends them
Superclass  subclass
Generalization/specialization hierarchy
Also called an inheritance hierarchy
Result of extending class into more specific subclasses
This is an important concept!!

21. Inheritance and Polymorphism
literally means “many forms”
in Java means using the same message (or method name) with different classes
different objects can respond in their own way to the same message
e.g. toString()

23. Learning OO Development
Introducing Three-Tier Design
Objects that interact in OO system are separated into three categories of classes:
Problem domain classes
Specific to a particular business application
GUI classes
Define objects that make up the UI to the application
Data access classes
Work with DBMS to store/retrieve object information

24. Unified Modeling Language (UML)
Standard OOA&D modeling notation
Uses model-driven approach
Enables creation of graphical models of the system requirements and system design
Components include
Class diagrams
Use Case diagrams
Sequence diagrams
Statecharts

26. SDLC Model
A framework that describes the activities performed at each stage of a software development project.

27. Waterfall Model
Requirements – defines needed information, function, behavior, performance and interfaces.
Design – data structures, software architecture, interface representations, algorithmic details.
Implementation – source code, database, user documentation, testing.

28. Waterfall Strengths Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability
Good for management control (plan, staff, track)
Works well when quality is more important than cost or schedule

29. Waterfall Deficiencies
All requirements must be known upfront
Deliverables created for each phase are considered frozen – No flexibility
Can give a false impression of progress
Does not reflect problem-solving nature of software development – iterations of phases
Integration is one big bang at the end
Little opportunity for customer to preview the system (until it may be too late)

30. When to use the Waterfall Model
Requirements are very well known
Product definition is stable
Technology is understood
New version of an existing product
Porting an existing product to a new platform.

31. Incremental SDLC Model
Construct a partial implementation of a total system
Then slowly add increased functionality
The incremental model prioritizes requirements of the system and then implements them in groups.
Each subsequent release of the system adds function to the previous release, until all designed functionality has been implemented.

33. Incremental Model Strengths
Develop high-risk or major functions first
Each release delivers an operational product
Customer can respond to each build
Uses “divide and conquer” breakdown of tasks
Lowers initial delivery cost
Initial product delivery is faster
Customers get important functionality early
Risk of changing requirements is reduced

34. Incremental Model Weaknesses
Requires good planning and design
Requires early definition of a complete and fully functional system to allow for the definition of increments
Well-defined module interfaces are required (some will be developed long before others)
Total cost of the complete system is not lower

35. When to use the Incremental Model
Risk, funding, schedule, program complexity, or need for early realization of benefits.
Most of the requirements are known up-front but are expected to evolve over time
A need to get basic functionality to the market early
On projects which have lengthy development schedules
On a project with new technology

36. Spiral SDLC Model
Adds risk analysis, and 4gl RAD prototyping to the waterfall model
Each cycle involves the same sequence of steps as the waterfall process model

37. Spiral Quadrant Determine objectives, alternatives and constraints
Objectives: functionality, performance, hardware/software interface, critical success factors, etc.
Alternatives: build, reuse, buy, sub-contract, etc.
Constraints: cost, schedule, interface, etc.

38. Spiral Quadrant Evaluate alternatives, identify and resolve risks
Study alternatives relative to objectives and constraints
Identify risks (lack of experience, new technology, tight schedules, poor process, etc.
Resolve risks (evaluate if money could be lost by continuing system development

39. Spiral Quadrant Develop next-level product
Typical activites:
Create a design
Review design
Develop code
Inspect code
Test product

40. Spiral Quadrant Plan next phase
Typical activities
Develop project plan
Develop configuration management plan
Develop a test plan
Develop an installation plan

41. Spiral Model Strengths
Provides early indication of insurmountable risks, without much cost
Users see the system early because of rapid prototyping tools
Critical high-risk functions are developed first
The design does not have to be perfect
Users can be closely tied to all lifecycle steps
Early and frequent feedback from users
Cumulative costs assessed frequently

42. Spiral Model Weaknesses
Time spent for evaluating risks too large for small or low-risk projects
Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive
The model is complex
Risk assessment expertise is required
Spiral may continue indefinitely
Developers must be reassigned during non-development phase activities
May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration

43. When to use Spiral Model
When creation of a prototype is appropriate
When costs and risk evaluation is important
For medium to high-risk projects
Long-term project commitment unwise because of potential changes to economic priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and exploration)

44. To Do List Before Next Lecture
Read Lecture 1 slides.
Selectively read those sections in Chapters 1 and 2 that cover the topics in this lecture.