CS3006N Week 1

1
CS3006N Week 1

• James King

2
Programming in the Small

• One person does it all
• Design, implementation, debugging, testing,
  documentation
• Total creative freedom
• Total ability to make a completely un-modifiable,
  undocumented and impossible to understand mess
• Programmers job is to design and implement the
  algorithms to solve the problem they analysed
• Almost all commercial programs are simply too big
  for one person to write in a reasonable time.

3
Programming in the large

• 100,000 lines of code
• No one person is responsible for all the design,
  all the testing, all the implementation
• gt cant afford to make an unmanageable mess
• gt communication and documentation
• gt structure and models
• Problem is managing the complexity of the problem
  and solution and communication of the team

4
The Reality of Being a Commercial Programmer

• Few people today write programs from scratch
  modern programs are large and complex
• Most programming is about using other peoples
  modules or adding to an existing program
• Most programming is done in teams
• Most programmers have less freedom than they
  would like e.g. design is done by someone else
• Most programmers have to work on other peoples
  code and try to understand it, extend it, fix it.

5
This course is aboutManaging Complexity
6
What is an abstraction?

• An abstraction is a way of simplifying something
  complex by ignoring some details and highlighting
  others. Hopefully the abstraction is simpler than
  the complex thing.
• The trick is to pick the right abstraction so
  that useful information is retained and not
  useful information is ignored.
• For example if I want hot food I need to find a
  cooker. Any working cooker I can access will do.
  I am not interested in the manufacturer, shape,
  cost etc.

7
Abstraction

• For example the term cooker is an abstraction
• There are many real cookers such as microwave,
  gas, electric etc. Understanding how to use one
  helps understand how to use the others
• All cookers have the same basic functions and
  purpose
• We can use an existing abstraction to help us
  understand something new. E.g. a magic stove is a
  cooker powered by magic. Ok so it consumes a
  fuel, makes the food hot and must have control
  over the heating process just like all cookers
  even though we know nothing about it in reality

8
How do abstractions help?

• Abstraction helps fill this gap by introducing an
  intermediate stage.
• Now I have two smaller problems
• create the models
• Make use of the models

Use models to do achieve something
Abstraction models
Complexity
9
Abstractions

• Abstraction occur at many levels we can use a
  design abstraction such as UML. (which itself is
  a set of abstractions such as use cases)
• Implementation abstraction such as client server
  to structure the solution program

Program Structure (client server)
Problem
UML (use cases) (interaction diagrams etc)
10
Abstractions

• Of course you need the correct abstraction(s) or
  everything that follows will be flawed
• For example processors generate heat, switching
  on and off a computer controls how much heat the
  processor generates therefore a processor is a
  cooker! Or a cooker is a processor!
• Make sure you abstraction keeps and models the
  information you want to preserve and be aware of
  their limitations!
• E.g. the formal language Z assumes a computer
  with infinite memory, storage and CPU power

11
Encapsulation

• The process of combining elements to create a new
  entity.
• Elements are typically embedded in one another
• We can building up something from parts and use
  similar parts in multiple projects
• For example a microwave consists of a on off
  switch, a platter, a cyclotron, a power supply, a
  display, door etc
• The same switch could be used in other brands of
  microwave and could even be used in other
  products such as a kettle or TV

12
Encapsulation

• The process of combining elements to create a new
  entity.
• So take a

My brand Microwave
Switch from my brand TV
Power supply from my brand washing machine
Platter from my brand record player
13
Information Hiding

• We do it intuitively!
• Separation implementation from interface
• You can manipulate via the interface without
  regard to how the thing actually works.
• gt Basic way of managing complexity by ignoring
  it and making it someone else's problem
• For example I can interact with a microwave oven
  to get a meal cooked. But I cant fix one or make
  one! For safety reasons I am not even allowed to
  open it up and peek inside.

14
Information Hiding
Barrier to protect implementation details from
the outside world
Interface Well defined and documented
interface (timer) (door) (finished ping) (power
setting)

• Implementation
• Hidden from outside world
• Power transformer
• Microwave cage
• Rotating platform
• Cyclotron
• Etc etc

Outside world
Interaction
15
Parna's Principles

• "The developer of a software component must
  provide the intended user with the information
  needed to make effective use of the services
  provided by the component, and should provide no
  other information.
• The developer of a software component must be
  provided with all the information necessary to
  carry out the given responsibilities assigned to
  the component, and should be provided with no
  other information."
• David Parnas

16
Parna's Principles

• What does this mean?
• Should be able to change the implementation
  without effecting the outside world

Interaction (fixed)
Interface (fixed)
Implementation 1
Implementation 2
Outside world
Duties (fixed)
17
Modularity

• Breaking things up into smaller things
• Or
• Taking small things and gluing them together
• If you apply information hiding inside the
  implementation you get modularity
• A program becomes a set of modules each one with
  an interface and hidden implementation obeying
  parnas principles
• The modules use each others services and changes
  to one module should not effect another module

18
Modularity

• Now we need ways to structure the insides of our
  programs. This is the architecture how the
  modules fit together

Interaction (fixed)
Interaction (fixed)
Interface (fixed)
Module 1
Interface (fixed)
Module 2
Duties (fixed)
Duties (fixed)
19
How do we get Modularity?

• There are many methods
• Top down, look at the whole and break into parts.
  The decomposition below is functional
• A microwave heats food, so I need a heater, the
  heater needs an on off switch, temperature
  control and timer to control the total amount of
  heat applied.
• Etc

20
Top down
Microwave
Heater
Timer
Power Control
On/Off
We have a hierarchy (trees. very popular)
21
How do we get Modularity?

• There are many methods
• Bottom up, look at the bits we already have and
  tries to build something up by combining them to
  solve the problem. The decomposition below is
  functional
• I have various switches, temperature controls,
  heaters, etc which ones should I use to make a
  cooker?
• Etc

22
Top down
Timers
Power Controls
On/Off switches
Selection process
Combine into large units
We have a hierarchy (trees. very popular)
23
Middle out

• Apply top down and bottom up at the same time

Available solutions
Problem
Sub Problem
Sub Problem
Available solutions
Sub Problem
Available solutions
24
Cohesion

• Of course how you structure the program
  internally now becomes an issue
• As does deciding if the structure is good or bad
• Cohesion is a good thing it is making sure the
  each module performs a well specified task and is
  not simply a collection of miscellaneous stuff

25
Coupling

• Coupling is a bad thing it is the dependence of
  one module on the data inside another module
• Lots of coupling ties all the modules together in
  a interconnected tangle

26
Concurrency

• Another consequence of splitting a program up
  into some kind of modules is that each module can
  have an independent life
• For example in a microwave the display module can
  show a count down of the cooking time remaining
  while at the same time platter module rotates the
  food.
• Another example would be an online system that
  processes multiple requests at the same time
  requiring multiple database accesses e.g. google,
  airline booking system etc.

27
Validation and Verification

• Validation - Are we producing the right product?
• Verification - Are we producing the product
  right? Boehm

28
Validation

• There is no point implementing a specification of
  duties (design) which is wrong
• Validation is making sure the specification of
  the duties creates a design that actually meets
  the requirements of the users

Design (specifications of behaviour to solve
the problem)
Problem Need to warm food
Requirements to shape the solution of the
problem (from users ????)
29
Validation

• For example I want to heat food, thats my
  problem. Lets call the solution to the problem a
  cooker. I want a cooker to
• Requirements for a cooker
• Heat food
• Safe
• I want control of speed of cooking
• I want control over amount of cooking

30
Design of Cooker
OPPS I have designed a fridge
Temperature control
Temperature sensor
Freezing element
Timer
31
Verification
Testing!!! gt Design first program second

• Making sure the implementation does exactly what
  the specifications says its duties are

Implementation of duties
Actual Behaviour of the implementation (unknown!!
!!!)
Interaction
Specification of Duties (behaviour)
32
Verification

• Specification cooker will not switch on if the
  door is open (partially meets safety requirement)
• Test case
• Select 600W, insert food, DONT close the door,
  press on
• Expected result microwave does not switch on
• Actual result microwave switches on and cooks the
  user!
• Unsafe!
• Behaviour is incorrect and does not meet
  specification

33
Architecture

• How the modules fit together.
• There are many standard architectures such as
  pipe, monolithic, layered, client - server, all
  of these are reusable abstractions.

34
Client - Server Architecture

• Client server architecture is popular for
  internet and web applications

Server implements service
Interface
Client Wants a service performed
request
reply
35
Client - Server Architecture

• For example a web server
• The implementation is split into two modules,
  display and delivery
• There is coupling in the form of HTTP messages
  and cohesion in that they perform well defined
  tasks

network
Client Web browser Implements web page display
Web Server implements Web page delivery
Interface (HTTP)
request
Reply (HTML)
36
Client - Server Architecture

• There is information hiding because the user does
  not need to understand how the browser or web
  server works to browser the web
• There are abstractions because web browsing
  basically work the same on all browsers for
  example clicking on a link takes you to a new page

37
Client - Server Architecture

• Encapsulation occurs because the web server uses
  the services of the operating system to send
  messages across the network and the browser also
  uses the operating system to display text etc.
• Concurrency occurs because the web browser allows
  multiple users to make requests of it at the same
  time

38
Client - Server Architecture

• Parnas principles are obeyed because any web
  browser can work with any web server I.e.
  information hiding and modularity occur between
  the web browser and server.

39
Client - Server Architecture

• Advantages
• Data and program is separate from users machine
  good for weather forecast etc
• No need to install and update the web application
• Any web browser enabled machine will work without
  altering the web application

40
Client - Server Architecture

• If the network fails the web application will
  stop
• Server can be overloaded with requests
• Large requests or replies will overload the
  network and reduce performance