COSC 3351 Software Design. Architectural Design (II) Edgar Gabriel. Spring Virtual Machine

Transcription

1 COSC 3351 Software Design Architectural Design (II) Spring 2008 Virtual Machine A software system of virtual machine architecture usually consists of 4 components: Program component: stores the program to be interpreted Data component: stores the information to be processed Interpretation engine: active component in the model. It takes the next instruction from the program component and updates the data component according to the instruction. Internal state store: stores the current state of the interpretation engine. Examples: rule-based system, interpreters, Java virtual machine 1

2 E.g. Java virtual machine Virtual Machine Class file Class loader Native Method Stack Heap Java Stack Method Area Execution Engine PC Registers Model-View-Controller Model-View-Controller is an architectural style not matched by any model discussed so far MCV decouples data access and logic from data presentation and user interaction, by introducing an intermediate component: the controller A model is an object representing data or even activity, e.g. a database table or even some plant-floor production-machine process. A view is some form of visualization of the state of the model. A controller offers facilities to change the state of the model. 2

3 Model-View-Controller (II) Though MVC comes in different flavors, control flow generally works as follows: The user interacts with the user interface in some way (e.g., presses a button). A controller handles the input event from the user interface, often via a registered handler or callback. The controller accesses the model, possibly updating it in a way appropriate to the user's action (e.g., controller updates user's Shopping cart) A view uses the model (indirectly) to generate an appropriate user interface (e.g., the view produces a screen listing the shopping cart contents). The view gets its own data from the model. The model has no direct knowledge of the view. The user interface waits for further user interactions, which begins the cycle anew. Model-View-Controller (III) 3

4 Combinations of Styles Most software systems are not built from a single style, but are combinations of different styles Hierarchical heterogeneous styles: use on architectural style at one level of abstraction E.g. use virtual machine style to abstract the Java Virtual machine Use call-and-return to design the execution engine Simultaneous heterogeneous styles: many software architectures can be interpreted as multiple styles E.g. a pipe-and-filter style program could also be interpreted as independent component style program Combinations of Styles (II) Locationally heterogeneous styles: grouping a subset of the components might lead to a different view/architectural style Often occurring as a result of software evolution, e.g. adding components or connectors 4

5 Case study: keyword frequency vector Goals: use different architectural styles to the same design problem Show the differences Specification: Count the number of occurrences of a word in a text Widely used for information retrieval Technique works better when small words ( a, is, the, ) are removed Different formats of the same word should be treated as one ( i.e. singular-plural, tenses, etc ) Main program with subroutine Data is stored in memory or file Main program controls the execution order of tasks (I) Input: get input text from a file (II) Delete small words (III) Reduce words to original format (IV) Count number of occurrences (V) Sort according to frequency (VI) Output Information between routines exchanged through shared data structures (global variables) 5

6 Main program with subroutine (II) Main Input Delete small words Reduce words to original format Count occurrences Sort Output List of small words Dictionary Shared data text Keyword frequency vector Abstract Data Types Encapsulate access and operations on data into abstract data types Three abstract Data types introduced here: Word ADT wit the methods Is-small Reduce Text ADT Setup: get text from input component Take-word Is-empty Keyword Frequency Vector ADT Add-word: call is-small-word. If no, call reduce on the word. If word exists in KFV, increase freq. counter by 1. else add it to list Is-empty Return-KWF: returns a keyword with highest frequency in KFV and deletes it from the KFV Initialize: 6

7 Abstract Data Types (II) Main Input Output Text: setup Text: takeword Text: isempty KFV: Initialize KFV: add- Word KFV: return- KWF KFV: isempty? List of small words Dictionary Word:is-small Word:reduce Implicit Invocation Computations are invoked every time data is modified Frequency vector constantly updated Main Input Extract Output Text: insert Text: delete Text: takeword Text: isempty KFV: addword KFV: delete- Word KFV: return- KWF KFV: isempty? List of small words Dictionary Word:is-small Word:reduce 7

8 Pipe-and-filter Computation decomposed into a number of filters Input-filter Delete-small-word-filter Reduce-word-filter Sort-words-alphabetically-filter Count-occurrences-filter Sort-KFV-filter Output-filter Analysis and comparison Lets consider the following quality attributes Modifiability: how difficult is it to modify the system after implementation to meet new requirements such as 1. Perform KFV functionality paragraph by paragraph 2. Change input-output representation 3. Change system functions, e.g. recognize synonyms Performance Reusability 8

9 Analysis and comparison (II) Main program with shared data Requirement 1: major change to the main file to handle the text paragraph by paragraph Difficult to create an interactive mode Requirement 2: Difficult to change internal data structures, since many routines are affected by that Requirement 3: straight forward to extend the dictionary functionality. However, might have side-effects on the delete small words function Good at performance Bad at reusability, since has a great number of assumptions in the components Analysis and comparison (III) Abstract Data Type Requirement 1: will require changes to the main program, and probably text and vector ADT E.g. not trivial to add the notion of sentences into the concept Requirement 2: changing input/output locally limited to those objects, relatively easy Requirement 3: fairly easy Performance: good at space, less efficient in time because more procedural calls than main program with shared data Components are more reusable than in main program with shared data 9

10 Analysis and comparison (IV) Implicit invocation: Requirement 1: similar to ADT Requirement 2: similar to ADT Requirement 3: similar to ADT Performance: difficult to control Reusability similar to ADT Analysis and comparison (V) Pipe-and-filter: Requirement 1: easy to change (new filter) Requirement 2: requires modifications in two filters Requirement 3: relatively easy Performance: large space requirements (each filter has its own storage) Reusability: good 10