1. Topic 7Summer 2003 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. Topic 7Summer 2003 2 Today’s Lecture l Architecture – the story continues l Intro to Design

3. Topic 7Summer 2003 3 Model - View - Controller (MVC) Model - application data and its behavior Controller - user input Model ViewController UpdatesManipulates User SeesUses View - display of model One model can be associated with multiple views.

4. Topic 7Summer 2003 4 Model View Controller l Special case of the Repository Model – the Model is central l 3 logical parts l The Model maintains the domain knowledge l A Controller which manages the sequences of user interactions l The View the UI display l The View is independent

5. Topic 7Summer 2003 5 MVC Pros/Cons l Advantages Maintains consistency Multiple views l Disadvantages Performance bottleneck

6. Topic 7Summer 2003 6 Event-driven systems l Driven by externally generated events where the timing of the event is outwith the control of the sub- systems which process the event l 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 l Other event driven models include spreadsheets and production systems

7. Topic 7Summer 2003 7 Broadcast Model Examples debugging systems (listen for particular breakpoints) database management systems (for data integrity checking) graphical user interfaces broadcast medium agent announce event announce event listen for event listen for event broadcast medium

8. Topic 7Summer 2003 8 Broadcast model l Effective in integrating sub-systems on different computers in a network l Sub-systems register an interest in specific events. When these occur, control is transferred to the sub- system which can handle the event l Control policy is not embedded in the event and message handler. Sub-systems decide on events of interest to them l However, sub-systems don’t know if or when an event will be handled

9. Topic 7Summer 2003 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. Topic 7Summer 2003 10 Selective broadcasting

11. Topic 7Summer 2003 11 Interrupt-driven control Interrupts have handler’s memory location

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

13. Topic 7Summer 2003 13 Interrupt Driven (Pros/Cons) l Pros Very Fast Responses l 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. Topic 7Summer 2003 14 Modular decomposition l Breaking it down… Smaller than subsystems l Another structural level where sub-systems are decomposed into modules l 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 l If possible, decisions about concurrency should be delayed until modules are implemented

15. Topic 7Summer 2003 15 Pipe & Filter (Data Flow Model) Example: Compilers: Lexical Analysis -> parsing -> semantic analysis -> code generation filter pipe

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

17. Topic 7Summer 2003 17 Pipe & Filter l 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 l 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. Topic 7Summer 2003 18 Pipes & FiltersPros/Cons l Pros good for transforming data streams without user intervention Intuitive (I/O) l Cons However, this architecture is not well suited for a system of complex interactions between components. Not really suitable for interactive systems

19. Topic 7Summer 2003 19 Invoice processing system Pipe & Filter Example

20. Topic 7Summer 2003 20 Object Models Data hiding (internal data representations are not visible to clients) object method invocation method invocation method invocation method invocation

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

22. Topic 7Summer 2003 22 Invoice processing system

23. Topic 7Summer 2003 23 Object Models Pros/Cons l Pros Can decompose problems into sets of interacting agents Easily modified (loose coupling) Reusability l Cons objects must know the identity of objects they wish to interact with Difficult to represent complex entities as objects

24. Topic 7Summer 2003 24 Domain-specific architectures l Architectural models which are specific to some application domain l 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. Topic 7Summer 2003 25 Domain-specific Architectures l Generic “Bottom-up” – built from existing systems l Reference “Top-Down” – Abstract representations »May not reflect the architecture of existing systems

26. Topic 7Summer 2003 26 Generic models l 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 l Generic compiler model may be organised according to different architectural models

27. Topic 7Summer 2003 27 Compiler model

28. Topic 7Summer 2003 28 Language processing system

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

30. Topic 7Summer 2003 30 OSI reference model Application

31. Topic 7Summer 2003 31 Key points l The software architect is responsible for deriving a structural system model, a control model and a sub-system decomposition model l Large systems rarely conform to a single architectural model l System decomposition models include repository models, client-server models and abstract machine models l Control models include centralised control and event-driven models

32. Topic 7Summer 2003 32 Key points l Modular decomposition models include data-flow and object models l 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. Topic 7Summer 2003 33 A Professional View Requirements Code Architecture Plans, blueprints, detailed drawings, instructions for specialists, time estimates, material requirements estimates, permits, etc.

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

35. Topic 7Summer 2003 35 Design Fundamentals - Questions l Software is multi-person How can each programmer work independently of the others? l 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. Topic 7Summer 2003 36 Design Fundamentals - Answers l 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 l 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. Topic 7Summer 2003 37 A Good Design… l …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. Topic 7Summer 2003 38 A Bad Design… l …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. Topic 7Summer 2003 39 Design l 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?” l Module design Detailed design of a component Focus on the internals of a component Focus on computational properties »“How does it work?”

40. Topic 7Summer 2003 40 Architectural Design l A simple diagram is not enough It is only a start l 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 l Always requires multiple iterations Cannot do it right in one shot Use the fundamental principles