CISC 323 Intro to Software Engineering Example: Marks management - PowerPoint PPT Presentation

✄ ✆ ✆ ☎ ☎ ✂ ✂ ✁ ✁ � Client-Server Architectural Style CISC 323 Intro to Software Engineering Example: Marks management system Topic 7: Software Architecture Subtopics: • Client-Server • Pipe and Filter • Layers • Event-based, Implicit Invocation Components: Servers and clients • Repository Constraints: • Data Abstraction and Object Orientation requests only sent by clients • Case studies: instrumentation software, mobile responses only sent by servers robotics (time permitting) 2 CISC 323, Winter 2004, Software Architecture Client-Server: Connectors/Interaction Client-Server: Domain Typically, Client-Server most appropriate when it is natural to implement a set of services in a fixed, central Server Client 1 Client 2 location listen for connections Peer-to-peer connect send message special case of client-server system connect each component can be both a client and a server to send reply disconnect the other components send message disconnect stop listening Source: Object-oriented Software Engineering. Lethbridge and Laganiere. 2001 3 4 CISC 323, Winter 2004, Software Architecture CISC 323, Winter 2004, Software Architecture

✑ ☛ ✒ ✡ ✏ ✠ ✏ ✓ ✎ ☛ ✌ ✑ ☞ ✍ ✌ ✍ ✌ ✌ ✠ ✓ ✡ ✒ ✝ ✞ ✑ ✞ ✑ ✒ ✟ ✞ ✑ ✠ ✓ ✡ ✑ ✠ ☞ Client-Server: Properties Client-Server: More Examples In general and if used appropriately and implemented Client-server systems are very common correctly, Examples: high cohesion and low coupling WWW high readability and reusability Clients: Browsers Potential problem areas: Servers: Web servers Email Modifiability Clients: Programs to read and write email (Outlook, mail, pine, change to server may require changes to all clients Eudora) Availability Servers: “Mail-drop” machine that if server goes down, whole system may stop working holds incoming email until contacted by client Performance forwards outgoing email connection between client and server may be bottleneck Database systems Security Clients: Application program using database (e.g., through JDBC) communication may be eavesdropped Server: Database management system (e.g., DB2) 5 6 CISC 323, Winter 2004, Software Architecture CISC 323, Winter 2004, Software Architecture Architectural Styles: Roadmap Pipes and Filters Architecture Style Client-Server (done) Components Set of data filters Pipe and Filter (next) Connectors/interaction Layered Systems Data is passed from one filter to the next via pipes Event-Based, Implicit Invocation Constraints Repositories Data is passed in sequence from one filter to the next Data Abstraction and Object Organization Filters Pipes 7 8 CISC 323, Winter 2004, Software Architecture CISC 323, Winter 2004, Software Architecture

✚ ✙ ✘ ✛ ✛ ✛ ✖ ✗ ✗ ✖ ✖ ✜ ✔ ✕ ✕ Pipe and Filter: Example Step 1 in Compiling: Scanning Turn program text into a sequence of tokens Compiler architecture Tokens: Compilers map program text (e.g., Java text files) represent keywords of language (e.g., if , while , s tatic ) into executable code (e.g., Java byte code, or may store/contain values (e.g., tInt stores integers) “.exe” file containing INTEL x86 code) For example: This is too complex to do all at once. To simplify if (x==3) { … } structure, pipe and filter architecture often used 32 * (2 + 100) might become program executable Semantic Code Scanner Parser text Analyzer Generator code tIf tLeftP tIdentifer “x” tEqEq tInt 3 tRightP tLeftB … tRightB tInt 32 multiply lparen tInt 2 plus tInt 100 rparen 9 10 CISC 323, Winter 2004, Software Architecture CISC 323, Winter 2004, Software Architecture Step 2 in Compiling: Parsing Step 2 in Compiling: Parsing (Cont’d) Check syntax of input … For instance, the Java program For example, if (x == 10) y = 2; else z = z + 4; in Java, the following programs generate syntax errors gets parsed into the following tree: if {x==10} … // {…} instead of (…) while (true) {x = x+1} // ; missing if (x=1) {…} if … by building parse tree == = = x 10 y 2 z + z 2 11 12 CISC 323, Winter 2004, Software Architecture CISC 323, Winter 2004, Software Architecture

★ ★ ★ ★ ✧ ✥ ✩ ✦ ★ ✩ ✩ ✧ ✣ ✦ ✢ ✩ ✤ ✣ ✢ ★ Steps 3 and 4 in Compiling: Semantic Compiling as Pipe and Filter Analysis and Code Generation Architecture Semantic analysis Check context-sensitive syntax program Scanner text E.g., variables have been declared, types are ok tokens Parser Code generation parse Create native code from parse tree Semantic tree Analyzer parse Code executable tree code Generator 13 14 CISC 323, Winter 2004, Software Architecture CISC 323, Winter 2004, Software Architecture Pipe and Filter: Domain Pipe and Filter: Properties In general and if used appropriately and implemented The Pipe and Filter style is most appropriate correctly, when high cohesion and low coupling high readability and reusability The problem can be naturally divided into a Potential problem areas: sequence of processing steps over some data Modifiability change may impact several filters stream Performance The format of the data being passed can be connection between filters may be bottleneck Availability described in a simple and precise manner if one filter goes down, whole system may stop working Security communication may be eavesdropped 15 16 CISC 323, Winter 2004, Software Architecture CISC 323, Winter 2004, Software Architecture

✮ ✬ ✭ ✭ ✬ ✫ ✬ ✬ ✫ ✪ ✫ ✬ ✪ Properties of Pipe and Filter: Example: Adding an Optimizer to the Modifiability Compiler Modifications to system may impact three areas Change filter: program Scanner For example, implement faster scanning algorithm text Change localized to filter itself, which is good tokens Parser Change format of data passed between filters: parse For example, add a new token or change parse tree format Semantic tree Expensive, since (at least) two filters impacted by change Analyzer Add a new filter : parse Code executable inexpensive if data format not impacted tree code Generator Therefore, Pipe and Filter offers good modifiability if data format stable 17 18 CISC 323, Winter 2004, Software Architecture CISC 323, Winter 2004, Software Architecture Example: Adding an Optimizer to the Example: Adding an Optimizer to the Compiler (Cont’d) Compiler (Cont’d) Source-level optimizer improves source code For example, program Scanner text x = 3; y = x+1; if (y+1 < 10) {c1} else {c2} is improved to tokens Parser Source-level parse x = 3; y = 4; c1 Optimizer tree parse Code-level optimizer improves executable code Semantic tree parse Analyzer tree executable Code code Generator 19 20 CISC 323, Winter 2004, Software Architecture CISC 323, Winter 2004, Software Architecture

✲ ✴ ✴ ✰ ✰ ✰ ✯ ✳ ✲ ✱ ✴ Example: Adding an Optimizer to the Properties of Pipe and Filter: Compiler (Cont’d) Performance Some opportunity for parallel processing program Run each filter on a different processor Scanner text Only works if filters work incrementally, that is, if tokens Parser Source-level parse tree Optimizer filters are not obliged to wait for preceding filter to parse Semantic tree parse Analyzer complete its work before starting themselves tree Performance gains will only be significant if parallel executable Code code Generator filters each perform significant work executable Code code Optimizer 21 22 CISC 323, Winter 2004, Software Architecture CISC 323, Winter 2004, Software Architecture Properties of Pipe and Filter: Properties of Pipe and Filter: Performance (Cont’d) Performance (Cont’d) Simple model to analyze parallel performance: Some optimizations may be lost by strict p 1 p 2 p n-1 decomposition into filters f 1 f 2 … f n There may be some overhead of creating Let t 1 ,…t n be time to compute each filter f 1 ,…f n similar data structures from streams provided Let s 1 ,…s n-1 be time to move data over pipes p 1 ,…p n-1 by pipes Then execution time in the sequential case is n n-1 E.g., ∑ t i + ∑ s i i=1 i=1 parser creates parse tree Simplifying assumption: all filters and execution time in turns parse tree into token stream to send over pipe are able to start processing data at the parallel case is the same time. semantic analyzer recreates parse tree from token stream n-1 max t i + ∑ s i n Can you think of cases where this might not be true? i=1 i=1 23 24 CISC 323, Winter 2004, Software Architecture CISC 323, Winter 2004, Software Architecture