Software Design Models & Event-Driven Systems Overview

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. Today’s 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 - display of model View Controller 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 Examples debugging systems (listen for particular breakpoints) database management systems (for data integrity checking) graphical user interfaces agent listen for event broadcast medium broadcast medium agent listen for event announce event agent

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 don’t know if or when an event will be handled

9. Broadcast Pros/Cons Interesting properties (Pros) announcers of events don’t 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 handler’s 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) Example: Compilers: Lexical Analysis -> parsing -> semantic analysis -> code generation pipe pipe filter filter pipe pipe filter filter pipe pipe pipe filter pipe filter pipe

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 don’t 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 Data hiding (internal data representations are not visible to clients) method invocation method invocation object object object object method invocation object method invocation

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