OOSD Module Introduction

1
OOSD Module Introduction

• The development of Software Engineering
• Lecture 1a Week 1
• Brian Farrimond

2
Objectives

• At the end of this session you should

• Be able to explain the module structure,
  assessment and learning activities
• Have awareness of claimed benefits and problems
  with OO methods.
• Have awareness of historical context of OO in
  methods development.
• Still be awake.

3
Module Structure
Hint All details are on the hopelive Web site

• Topics
• Schedule
• Assessment

4
OOSD Topics

• Systems
• Modelling systems
• Object Oriented models for systems
• Implementing models in Java
• can you spot the theme?

5
OOSD Schedule
6
OOSD Schedule
7
Assessment schedule
8
Assessment schedule
9
Assessment components
Backbone of your learning

• Portfolio questions
• Show a selection to tutor regularly
• Quizzes
• Short 15 mins

Regular check on your progress
10
Assessment components

• Quizzes and Portfolio Exercises 10
• Java Coursework (CW 1) 20
• SAD Coursework (CW 2) 20
• Feasibility study (CW 3) 20
• Report with preliminary models
• Two Class tests 30

11
Do you want a good grade?

• This is a 30 credits module
• 300 hours study
• 3 hours per week in class
• 9 hours per week self study

12
Developing software systemsThe Story so Far
OOSAD Booklet Chapter 2
13
In the beginning (1960s)

• Now the program was formless and empty without
  structure
• Systems were Late, over budget, full of bugs,
  didnt do what users wanted.
• - Poor Quality
• - The Software Crisis

Aagh!
14
The Evil enemy Complexity Size
?
I have a very small brain and I had better
learn to live with it - E. Dijkstra Constructio
n of software is the most complex ever
undertaken by humanity - Fred Brooks
IEEE Computer April 87.
15
Eat Elephants in small chunks - Beaumont 2001
16
Tablets of Stone..the 3 commandments
1. Modularity break it up into small parts 2.
Coupling / Encapsulation Few interconnections,
defined interface 3. Cohesion /
Abstraction Clearly defined task.
17
Structure- Software Engineering

• 1970s (flares, long hair Pink Floyd)
• Structured Programming
• Languages with procedures / subroutines
• Goto-less programming
• Structured Design
• Top-Down design, modules
• Structured Analysis
• systematic, top down approach eg SSADM
• Kermit the Frog.

18
Structured Methods

• Functional
• Concentrate on what the system does
• Modules are Tasks
• Data secondary
• Recipes!

• Data Driven
• Concentrate on Data inputs, outputs and
  transformation e.g. JSP
• Process derived from Data (secondary)
• Evolved to Data modelling, E-R, DBMS

Both methods Separate Code and Data
19
Outcomes Did it work?

• Some improvement, but
• Systems still late,
• Systems still over budget
• Difficult to modify
• New Emphasis on Quality Management
• Project management
• User Requirements / Prototype / RAD.

20
Formal Methods

• 1980s (Yuppies, Margaret Thatcher, Culture club)
• Focus on Quality led to Formal (Mathematical)
  specification languages. Logic could be used to
  reason prove correctness.
• E.g. Z, VDM, CSP, OBJ.
• Difficult to understand, expensive.

21
Object Orientation

• Mid 1980s
• A new paradigm (wow!).
• Booch, Rumbaugh, Jacobson, Schlaer-Mellor.
• 64 Flavours (Webster 1996)

OO is a religion, its the people who become
oriented towards objects - Stevens (2000)
22
Characteristics

• Objects / Classes
• modules which Combine Data and Behaviour
  (functionality). Well defined interfaces achieve
  encapsulation abstraction)
• Inheritance between classes
• Polymorphism
• Same messages to different objects, arguments of
  different types.

23
Claimed Benefits

• Naturalness
• Objects mirror real world, ease of learning,
  stability of structure, ease of maintenance and
  reuse.
• Reuse
• Through Inheritance (libraries of classes). Less
  chance of error , productivity, robustness,
  flexibility.

24
Is it justified?

• Naturalness
• ease of learning - no, Procedural easier
• Reuse
• Studies show productivity increase and
  significant reuse within an application domain,
  but much less across domains.
• There is no silver bullet (Brooks)

25
Issues with OO

• Persistance
• storing objects.
• Efficient Relational Data bases,
• OODB in their infancy.
• Large Inheritance hierarchies
• introduces complexity!

26
Summary

• Principles of combating complexity are universal
• modularity / loose coupling / high cohesion /
  abstraction / encapsulation.
• OO is a development from structured methods
• Objects / Classes encapsulate Data and behaviour
  rather than splitting them up.
• Inheritance is new, facilitates reuse
• OO is becoming dominant
• Advantages of productivity / reuse within a
  domain.
• Difficulties over persistence.