Topic 7Summer 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

Topic 7Summer Today’s Lecture l Architecture – the story continues l Intro to Design

Topic 7Summer 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.

Topic 7Summer 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

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

Topic 7Summer 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

Topic 7Summer 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

Topic 7Summer 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

Topic 7Summer 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

Topic 7Summer Selective broadcasting

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

Topic 7Summer 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

Topic 7Summer 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

Topic 7Summer 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

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

Topic 7Summer 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

Topic 7Summer 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

Topic 7Summer 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

Topic 7Summer Invoice processing system Pipe & Filter Example

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

Topic 7Summer 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

Topic 7Summer Invoice processing system

Topic 7Summer 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

Topic 7Summer 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

Topic 7Summer 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

Topic 7Summer 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

Topic 7Summer Compiler model

Topic 7Summer Language processing system

Topic 7Summer 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

Topic 7Summer OSI reference model Application

Topic 7Summer 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

Topic 7Summer 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

Topic 7Summer A Professional View Requirements Code Architecture Plans, blueprints, detailed drawings, instructions for specialists, time estimates, material requirements estimates, permits, etc.

Topic 7Summer 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.

Topic 7Summer 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 )

Topic 7Summer 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.

Topic 7Summer 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

Topic 7Summer 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”

Topic 7Summer 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?”

Topic 7Summer 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