ICS 52: Introduction to Software Engineering

1
ICS 52 Introduction to Software Engineering

• Lecture Notes for Summer Quarter, 2003
• Michele Rousseau
• Topic 7
• Partially based on lecture notes written by
  Sommerville, Frost, Easterbrook. Duplication of
  course material for any commercial purpose
  without the written permission of the lecturers
  is prohibited

2
Todays Lecture

• Architecture the story continues
• Intro to Design

3
Model - View - Controller (MVC)
Model - application data and its behavior
User
Sees
Uses
Controller - user input
View
Controller
View - display of model
Updates
Manipulates
One model can be associated with multiple views.
Model
4
Model View Controller

• Special case of the Repository Model the Model
  is central
• 3 logical parts
• The Model
• maintains the domain knowledge
• A Controller
• which manages the sequences of user interactions
• The View
• the UI display
• The View is independent

5
MVC Pros/Cons

• Advantages
• Maintains consistency
• Multiple views
• Disadvantages
• Performance bottleneck

6
Event-driven systems

• Driven by externally generated events where the
  timing of the event is outwith the control of the
  sub-systems which process the event
• Two principal event-driven models
• Broadcast models. An event is broadcast to all
  sub-systems. Any sub-system which can handle the
  event may do so
• Interrupt-driven models. Used in real-time
  systems where interrupts are detected by an
  interrupt handler and passed to some other
  component for processing
• Other event driven models include spreadsheets
  and production systems

7
Broadcast Model
announce event
agent
agent
listen for event
broadcast medium
broadcast medium
agent
agent
announce event
listen for event

• Examples
• debugging systems (listen for particular
  breakpoints)
• database management systems (for data integrity
  checking)
• graphical user interfaces

8
Broadcast model

• Effective in integrating sub-systems on different
  computers in a network
• Sub-systems register an interest in specific
  events. When these occur, control is transferred
  to the sub-system which can handle the event
• Control policy is not embedded in the event and
  message handler. Sub-systems decide on events of
  interest to them
• However, sub-systems dont know if or when an
  event will be handled

9
Broadcast Pros/Cons

• Interesting properties (Pros)
• announcers of events dont need to know who will
  handle the event
• Supports re-use, and evolution of systems (add
  new agents easily)
• Disadvantages
• Components have no control over ordering of
  computations

10
Selective broadcasting
11
Interrupt-driven control
Interrupts have handlers memory location
12
Interrupt-driven systems

• Used in real-time systems
• fast response to an event is essential
• There are known interrupt types with a handler
  defined for each type
• Each type is associated with a memory location
  and a hardware switch causes transfer to its
  handler
• Allows fast response but complex to program and
  difficult to validate

13
Interrupt Driven (Pros/Cons)

• Pros
• Very Fast Responses
• Cons
• Complex to program
• Difficult to validate
• Difficult to change
• of interrupts limited by hardware constraints
• However can map several events into 1 interrupt

14
Modular decomposition

• Breaking it down
• Smaller than subsystems
• Another structural level where sub-systems are
  decomposed into modules
• Two modular decomposition models covered
• data-flow model (pipe filter)
• decomposed into functional modules which
  transform inputs to outputs
• object model
• decomposed into interacting objects
• If possible, decisions about concurrency should
  be delayed until modules are implemented

15
Pipe Filter (Data Flow Model)
pipe
pipe
filter
filter
pipe
pipe
filter
filter
pipe
pipe
pipe
filter
pipe
filter
pipe

• Example
• Compilers
• Lexical Analysis -gt parsing -gt semantic analysis
  -gt code generation

16
Pipe Filter

• Filters are Subsystems
• Filters communicate via streaming data(Pipes)
• A filter receives data from its input pipe
• processes it
• sends it to its output pipe
• A pipe essentially connects any one filter output
  to any other filter input.
• Any given filter would only have knowledge of its
  input data format and not any other filter.
• one-way, sequential processing

17
Pipe Filter

• Interesting properties
• filters dont need to know anything about what
  they are connected to
• filters can be implemented in parallel
• behavior of the system is the composition of
  behavior of the filters
• specialized analysis such as throughput and
  deadlock analysis is possible
• Variants of this approach are very common.
• When transformations are sequential, this is a
  batch sequential model which is extensively used
  in data processing systems

18
Pipes Filters Pros/Cons

• Pros
• good for transforming data streams without user
  intervention
• Intuitive (I/O)
• Cons
• However, this architecture is not well suited for
  a system of complex interactions between
  components.
• Not really suitable for interactive systems

19
Invoice processing system
Pipe Filter Example
20
Object Models
method invocation
method invocation
object
object
object
object
method invocation
object
method invocation

• Data hiding (internal data representations are
  not visible to clients)

21
Object models

• Structure the system into
• loosely coupled objects
• well-defined interfaces
• Objects call on services (methods) from other
  objects
• Object-oriented decomposition is concerned with
  identifying
• object classes
• their attributes
• their operations
• When implemented, objects are created from these
  classes and some control model used to coordinate
  object operations

22
Invoice processing system
23
Object Models Pros/Cons

• Pros
• Can decompose problems into sets of interacting
  agents
• Easily modified (loose coupling)
• Reusability
• Cons
• objects must know the identity of objects they
  wish to interact with
• Difficult to represent complex entities as
  objects

24
Domain-specific architectures

• Architectural models which are specific to some
  application domain
• Two types of domain-specific model
• Generic models
• abstractions from a number of real systems and
  which encapsulate the principal characteristics
  of these systems
• Reference models
• more abstract, idealised model. Provide a means
  of information about that class of system and of
  comparing different architectures

25
Domain-specific Architectures

• Generic
• Bottom-up built from existing systems
• Reference
• Top-Down Abstract representations
• May not reflect the architecture of existing
  systems

26
Generic models

• Compiler model is a well-known example although
  other models exist in more specialised
  application domains
• Lexical analyser converts input token into
  internal form
• Symbol table holds names and types used
• Syntax analyser builds syntax tree
• Syntax tree internal structure of program
• Semantic analyser uses info from Symbol table
  and syntax tree to check semantic correctness
• Code generator uses syntax tree to generate
  machine code
• Generic compiler model may be organised according
  to different architectural models

27
Compiler model
28
Language processing system
29
Reference architectures

• Reference models are derived from a study of the
  application domain rather than from existing
  systems
• May be used ..
• As a basis for system implementation
• to compare different systems.
• It acts as a standard against which systems can
  be evaluated
• OSI (open systems interconnection) model is a
  layered model for communication systems

30
OSI reference model
Application
31
Key points

• The software architect is responsible for
  deriving a structural system model, a control
  model and a sub-system decomposition model
• Large systems rarely conform to a single
  architectural model
• System decomposition models include repository
  models, client-server models and abstract machine
  models
• Control models include centralised control and
  event-driven models

32
Key points

• Modular decomposition models include data-flow
  and object models
• Domain specific architectural models are
  abstractions over an application domain. They may
  be constructed by abstracting from existing
  systems or may be idealised reference models

33
A Professional View
Requirements
Architecture
Code
Plans, blueprints, detailed drawings,
instructions for specialists, time estimates,
material requirements estimates, permits, etc.
34
Architecture, in Software and Building

• Requirements user signs off on the big picture
  and some but, realistically, not all, details.
• Implementation plan time frame, number of
  workers, their skills and availability.
• Detailed cost estimate.
• Modularize divide task into smaller parts.
• Interface with existing buildings / neighborhood
  / related software systems.
• Important design decisions that are invisible to
  the user type of girders, type of algorithm,
  language, database system.

35
Design Fundamentals - Questions

• Software is multi-person
• How can each programmer work independently of the
  others?
• Software is multi-version
• How can software be designed so that it is easy
  to modify?
• Planned modifications
• Corrective maintenance (fix flaws)
• Adaptive maintenance (adjust to changing world)
• Perfective maintenance (add features)

36
Design Fundamentals - Answers

• Modularity, for three reasons
• decompose a complex system into less complex
  sub-systems divide and conquer
• (re-)use existing modules
• understand the system in pieces
• What makes a good module?
• High cohesion all internal parts are closely
  related.
• Low coupling modules rely on each other as
  little as possible
• Each module hides its internal structure.

37
A Good Design

• is half the implementation effort!
• Rigor ensures all requirements are addressed
• Separation of concerns
• Modularity allows work in isolation because
  components are independent of each other
• Abstraction allows work in isolation because
  interfaces guarantee that components will work
  together
• Anticipation of change allows changes to be
  absorbed seamlessly
• Generality allows components to be reused
  throughout the system
• Incrementality allows the software to be
  developed with intermediate working results

38
A Bad Design

• will never be implemented!
• Lack of rigor leads to missing functionality
• Separation of concerns
• Lack of modularity leads to conflicts among
  developers
• Lack of abstraction leads to massive integration
  problems (and headaches)
• Lack of anticipation of change leads to redesigns
  and reimplementations
• Lack of generality leads to code bloat
• Lack of incrementality leads to a big-bang
  approach that is likely to bomb

39
Design

• Architectural design
• High-level partitioning of a software system into
  separate modules (components)
• Focus on the interactions among parts
  (connections)
• Focus on structural properties (architecture)
• How does it all fit together?
• Module design
• Detailed design of a component
• Focus on the internals of a component
• Focus on computational properties
• How does it work?

40
Architectural Design

• A simple diagram is not enough
• It is only a start
• Additional decisions need to be made
• Define the primary purpose of each component
• Define the interface of each component
• Primary methods of access/use
• As complete as possible
• Always requires multiple iterations
• Cannot do it right in one shot
• Use the fundamental principles