Software design
McGill ECSE 321
Intro to Software Engineering
Radu Negulescu
Fall 2003
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 2
About this m...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 3
Basic concep...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 4
Modularity
T...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 5
Cohesion
“Si...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 6
Strong cohes...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 7
Example of s...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 8
Decoupling
“...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 9
Loose coupli...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 10
Example of ...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 11
Example of ...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 12
Improving m...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 13
Example of ...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 14
Design proc...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 15
Overview of...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 16
System-leve...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 17
Object desi...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 18
Design goal...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 19
Design goal...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 20
Performance...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 21
Performance...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 22
Design trad...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 23
Software ar...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 24
Basic defin...
WKURZV
WKURZV
WKURZV
WKURZV
6HUYOHW([FHSWLRQ6HUYOHW([FHSWLRQ6HUYOHW([FHSWLRQ6HUYOHW([FHSWLRQ ,2([FHSWLRQ,2([FHSWLRQ,2([FHSWLRQ,2([FHSWLRQ
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 25
Defining th...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 26
Layers and ...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 27
Common arch...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 28
Repository ...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 29
Repository ...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 30
Model-view-...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 31
Model-view-...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 32
Client-serv...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 33
Client-serv...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 34
Peer-to-pee...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 35
Pipe-and-fi...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 36
Centralized...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 37
Event-drive...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 38
Broadcast e...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 39
Broadcast e...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 40
Using event...
McGill University ECSE 321 © 2003 Radu Negulescu
Introduction to Software Engineering Software design—Slide 41
Thread-base...
Upcoming SlideShare
Loading in …5
×

Intro to Software Engineering - Software Design

1,088 views

Published on

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

Intro to Software Engineering - Software Design

  1. 1. Software design McGill ECSE 321 Intro to Software Engineering Radu Negulescu Fall 2003
  2. 2. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 2 About this module Software should be designed not just for performance, but also for maintainability! Why? • Save on maintenance costs Post-release defect removal Minor adjustments • Save on verification costs Higher pre-release fault detection and removal rate • Save on development costs Lower fault injection rate • Facilitate teamwork Software that is more maintainable is also easier to understand Design for maintainability requires special techniques • Message of the textbook’s cover picture?
  3. 3. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 3 Basic concept: modularity A software system should be split into modules • To facilitate future change By minimizing the scope of change • To avoid need for future change By containing change within isolated modules • To reduce development time and effort By simplifying the system By postponing design decisions until optimal time, and avoiding some expensive optimizations By allowing comprehension and reasoning on modules and interfaces
  4. 4. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 4 Modularity Two main criteria: • Cohesion: a measure of tightness of relationships within a module • Coupling: a measure of tightness of relationships among modules Tradeoff: • Strong cohesion: Focused modules More granularity • Loose coupling: Isolated modules Less granularity (to avoid split dependencies) • Optimum: around 7+-2 modules at each level of abstraction This holds for large modules (subsystems) and small modules (individual objects or routines) alike This is just an estimate, not an absolute rule
  5. 5. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 5 Cohesion “Single-minded functionality”: operations in a module should be strongly related Types of cohesion: (HIGH) • Functional: perform one function only • Communicational: use the same data • Sequential: an incomplete sequence of causally-related actions • Procedural: sequence of non-causally-related actions • Temporal: actions that are performed at the same time • Logical: decision branches • Coincidental: no discernable relationship (LOW)
  6. 6. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 6 Strong cohesion Heuristics • Partition the system according to dependency clusters • Isolate presentation, data management, and processing MVC architectures • Isolate control from work Focus on control-only or work-only High-cohesion “control-only” modules Dispatching events Startup and shutdown routines (delegate the individual tasks) • Isolate main functionality from auxiliary functionality Exception throwing Garbage collection • A complex name usually indicates poor cohesion Split “getAndSet” routines
  7. 7. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 7 Example of strong cohesion From [BD]: Alternative Decision Criterion subtasks * SubTask ActionItem DesignProblem Task assesses solvableBy resolvedBy based-on * * * implementedBy DecisionSubsystem RationaleSubsystem PlanningSubsystem
  8. 8. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 8 Decoupling “Aversion to interaction”: different modules should be detached Types of coupling: • Simple-data ("normal"): non-structured parameter list • Data-structure ("stamp"): structured parameter • Control: select a callee task by a flag parameter Logical cohesion • External: the program is tied to a particular device or environment => non-portable • Global-data ("common"): two routines access the same global data At least make it read-only • Pathological ("content"): use internal data of a different module E.g. via pointers
  9. 9. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 9 Loose coupling Heuristics: • Small interfaces: few parameters • Adapted interfaces: convenient for the callee • Flexible interfaces: convenient for many callers Orthogonality • Visible interfaces: no direct access to protected data • Avoid pathological coupling: pass parameters through interfaces float[][] A; x = det(A); • Avoid stamp coupling: decompose bundles of parameters into basic types or very-high-cohesion parameters (e.g. events) • Avoid external coupling: use IDEs that produce portable code • Avoid global-data coupling: In object-oriented programs, use “get” and “set” methods to read and modify object attributes
  10. 10. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 10 Example of loose coupling Adapted from [BD]: change from binary tree to linked list • Parse tree for a + b + c add1:Node add2:Node c:Nodeb:Node a:Node add:Node c:Nodeb:Nodea:Node Sharing through attributes class Node { Node left; Node right; String name; } Sharing through operations class Node { Enumeration getArguments(); String getName(); } Sharing through attributes class Node { Node next; String name; } Sharing through operations class Node { Enumeration getArguments(); String getName(); }
  11. 11. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 11 Example of bad modularity /* If 'direction' is 0, input n rows into array 'lines'; otherwise output n rows from array 'lines'. Pre: 0 <= n <= length(lines). */ in_out ( int n, /* number of rows, input or output */ int direction /* control flag: 0 = in, 1 = out */ ) { int i; for (i = 0; i < n; i ++) { if (direction == 0) { read one input row into lines[i]; } else { write lines[i]; } } } /* Read n lines of input. Output the lines in sorted order. Pre: 0 <= n <= length(lines). */ input_sort_echo( int n /* number of rows to be sorted */ ) { int i, j; in_out(n, 0); for (i = 0; i < n - 1; i ++) { for (j = i + 1; j < n; j ++) { if (lines[j] <= lines[i] alphabetically) { copy string lines[j] into string temp; copy string lines[i] into string lines[j]; copy string temp into string lines[i]; } } } in_out(n, 1); }
  12. 12. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 12 Improving modularity Global-data coupling: • Both routines access array lines • Fix: the access to array lines and string temp can be made explicit in the routine interfaces Logical cohesion: • The same routine (in_out) performs unrelated operations • Fix: split into an input routine and an output routine Communicational or temporal cohesion: • The same routine (input_sort_echo) controls the flow and does the sorting • Fix: call sorting as a sub-routine
  13. 13. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 13 Example of improved modularity /* Input n rows to 'lines'; Pre: 0 <= n <= length(lines). */ in( int n, /* number of rows to be input */ StringArray lines /* storage */ ) { int i; for (i = 0; i < n; i ++) { input lines[i]; /* read one row */ } } ... sort( int n, /* number of rows to be input */ StringArray lines /* ) { ... ... out( int n, /* number of rows to be input */ StringArray lines /* ) {... /* Read n rows and output them sorted. Pre: n >= 0 */ input_sort_echo( int n /* number of rows to handle */ ) { Declare and allocate StringArray lines; in(n, lines); sort(n, lines); out(n, lines); }
  14. 14. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 14 Design process Design: blackbox model full-detail (clearbox, whitebox, glassbox) • Choose among several alternatives Consider solutions permitted by the analysis model Heuristics, patterns Constraints, invariants Optimize design goals tradeoffs Select and prioritize goals: maintainability, usability, performance, etc. • Iterate through the design Why? Brainstorming and consolidation Prototypes to clear out technical risks Several levels of abstraction Several viewpoints, design goals Fixing defects Know where to stop Review criteria
  15. 15. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 15 Overview of software design System-level • Using the analysis model as a starting point, take high-level decisions to optimize the selected design goals Object-level • “Close the gap” between the architecture model and the deployment platform Detailed • Organize and build code in a way that supports change and reasoning Specialized design • UI design • Function-oriented design • Real-time, etc.
  16. 16. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 16 System-level design System-level design typically comprises the following activities: • Identifying design goals and constraints • Defining the architecture Decomposing the system into subsystems Selecting system-wide conventions and policies: Persistency Security Global control flow Boundary conditions: start-up, shut-down, error handling • Selecting reusable components, libraries, etc. • Mapping to hardware
  17. 17. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 17 Object design The following activities are typically performed at this level: • Identifying design objects: implementation-specific classes • Service specification: precisely describe interfaces • Component selection: find pre-made parts that are suitable for the functionality of the system • Object model restructuring: optimize maintainability Reduce multiplicity Implement binary associations as references Merge similar classes Collapse trivial classes into attributes Split complex classes • Object model optimization: optimize performance Use different algorithms / data structures Add or remove redundant associations Add derived attributes “Open up” the architecture
  18. 18. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 18 Design goals First thing: determine goals and priorities • Include viewpoints of several stakeholders • See [BD, sect.6.4.2] for a comprehensive list of software design goals • Relative importance varies depending on the nature of the application
  19. 19. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 19 Design goals End-user / customer / sponsor Developer / maintainer scope x low cost/effort x x low dev. time x x low defect rate x x modifiability x comprehensibility x x reliability x robustness x user-friendliness x documentation x x reusability x adaptability x portability x backward compatibility x performance x memory efficiency x
  20. 20. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 20 Performance measures Running time is not a single, well-defined measure • Consider all input data and internal non-determinism • Worst-case: maximum value E.g. car airbag controller: worst-case is critical Polling: time = (#sensors) * (time per sensor) + (alarm time) Interrupts: time = (interrupt path length) * (hub delay) + (alarm time) • Average-case : weighted by operation frequency (operational profile) E.g. text editor: average-case is more important than worst-case E.g. videophone image compression: both worst-case and average-case are important • Amortized: mean taken over an operating cycle E.g. the average number of bit flips in an n-bit number Answer: 2! (Why?)
  21. 21. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 21 Performance measures Many performance measures • Latency vs. throughput E.g., an IDE that does background compilation performs more work to improve average latency E.g., a web service might have a fixed limit on the response time (latency), and optimize the maximum number of simultaneous requests (throughput) • Memory requirements Data storage: scalability, garbage collection • Number of expensive operations (function calls, multiplications, etc.) • Number of accesses to communications, external storage, or I/O resources E.g. a trip planner might allow increased response time to minimize wireless communication time
  22. 22. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 22 Design tradeoffs Typical design tradeoffs: • Rapid development vs. scope • Performance vs. maintainability Orders of growth • Performance vs. portability • Backward compatibility vs. comprehensibility • Cost, delivery time vs. robustness, reusability Not to be confused with cost vs. other quality parameters • Space vs. speed Why operating systems, IDEs, etc. will fill up hard drives of any sizes? Not easily traded: • Quality vs. effort Low defect rate, maintainability, comprehensibility, documentation Early in the project: non-tradeable Late in the project: tradeable to a small extent • Delivery time vs. staffing Only early in the project Brooks’ law: adding people to a late project only makes it later
  23. 23. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 23 Software architecture Architectural design should address: • Subsystem decomposition • System-wide policies Data organization Control flow Communication protocols Error handling Mapping to hardware Security • NOT development methodology issues, such as object-orientation vs. function-orientation
  24. 24. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 24 Basic definitions Subsystems • Parts of a system • Can be developed and changed independently (more or less) • Example: UI evolves independently from business logic Services • A service provided by a subsystem = a set of operations of that subsystem that share a common purpose • Examples: download, upload, notification, management, … Interfaces • An interface of a subsystem = a black-box view of that subsystem As seen by an actor or by another subsystem • API: operations, signatures, and specifications Signature = parameter types, return type Example: doGet method of HttpServlet class SURWHFWHG YRLGSURWHFWHG YRLGSURWHFWHG YRLGSURWHFWHG YRLG GR*HWGR*HWGR*HWGR*HW+WWS6HUYOHW5HTXHVW+WWS6HUYOHW5HTXHVW+WWS6HUYOHW5HTXHVW+WWS6HUYOHW5HTXHVW UHTUHTUHTUHT +WWS6HUYOHW5HVSRQVH+WWS6HUYOHW5HVSRQVH+WWS6HUYOHW5HVSRQVH+WWS6HUYOHW5HVSRQVH UHVSUHVSUHVSUHVS
  25. 25. WKURZV
  26. 26. WKURZV
  27. 27. WKURZV
  28. 28. WKURZV 6HUYOHW([FHSWLRQ6HUYOHW([FHSWLRQ6HUYOHW([FHSWLRQ6HUYOHW([FHSWLRQ ,2([FHSWLRQ,2([FHSWLRQ,2([FHSWLRQ,2([FHSWLRQ
  29. 29. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 25 Defining the architecture Decomposition into subsystems • Heuristics Use variants of Abbott’s lexical rules: nouns, verbs Identify groups of objects involved in use cases Encapsulate functionally related classes - Facade pattern Isolate scope overlaps among use cases Create dedicated subsystems for moving data among subsystems Create a separate subsystem for the user interface Encapsulate legacy code - Adaptor pattern
  30. 30. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 26 Layers and partitions Different ways of decomposing the system: • Layering: each subsystem provides a level of abstraction Closed architecture: each layer can access services from the layer immediately below it. E.g. ISO OSI Open architecture: each layer can access services from any layers below it E.g. Motif toolkit for X11 • Partitioning: peer subsystems with as few dependencies as possible • Not a clear distinction between layering and partitioning A B C D E F G H
  31. 31. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 27 Common architectures Design the data first, then the control • During analysis, may assume objects run whenever needed • During design, the object behavior should be determined so that the object does indeed run whenever needed Types of data organization schemes: • Repository • Model-view-controller (“architecture”, “framework”, “pattern”) • Client/server • Peer-to-peer • Pipe-and-filter / data flow Types of control flow: • Centralized • Event-driven • Thread-based
  32. 32. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 28 Repository architecture Subsystems interact by sharing data in a central repository The repository may also implement control flow • Serialize concurrent accesses of processing subsystems • Activate subsystems depending on state of data (“blackboard”) E.g. DBMS, compilers [BD], various CAD tools LexicalAnalyzer SyntacticAnalyzer SemanticAnalyzer CodeGenerator SourceLevelDebugger SyntacticEditor ParseTree SymbolTable Compiler Repository Optimizer
  33. 33. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 29 Repository architecture Pros: • Decoupled subsystems; easy to add new ones Cons: • Repository may become a bottleneck • Strong coupling between each subsystem and the repository
  34. 34. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 30 Model-view-controller A.k.a. MVC Partition data representation (model), presentation (view), and control • One of the first design patterns: model state updates are reported to all views Refined to “observer pattern” (will see later) May use “Listener” objects in Java • Special case of the repository architecture, if the model is considered to be the data repository Controller Model subscriber notifier initiator * repository1 1 * View
  35. 35. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 31 Model-view-controller Pros: • Allows independent change of model, view, and controller • Allows subscription at runtime • Isolates variability, as the views are less stable than the model Cons: • The model may become a performance bottleneck
  36. 36. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 32 Client-server Servers provide services to clients • E.g. central database • E.g. communication systems Web server; DNS Mail server; news server; ... • Suitable for distributed systems that process large amounts of data Why?
  37. 37. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 33 Client-server Three-tiered architecture: Browser WebServer Servlet DataBase JDBC http request service query SQL query table result set string web page
  38. 38. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 34 Peer-to-peer Peer-to-peer: • Generalize client-server systems • Each subsystem can request and provide services E.g. a database that can also notify the application • More difficult to design Many possible interleavings of messages/service requests Many possible modes of failure in concurrent/distributed systems Deadlock Unfairness/starvation Livelock/divergence ...? Process1 Resource1 Resource2 Process2 1:req 5:req 3:req 4:ack 2:ack 6:req
  39. 39. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 35 Pipe-and-filter Filters: processing subsystems • Executing concurrently Pipes: associations between filters • Data transfer • Synchronization E.g. UNIX shell [BD] ps grep sort more
  40. 40. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 36 Centralized control Two types • Call-return (procedure-driven): sequential subroutine calls Rigid = easy to debug, but locks resources • Manager: one component is designated to control a concurrent system E.g.: a repository database that can signal changes Flexible = Better real-time response, efficiency More difficult to design = interleaving, modes of failure
  41. 41. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 37 Event-driven control Two types • Interrupt-driven Interrupts are serviced immediately (according to priority) Offers execution time bounds, hence good for real-time systems • Broadcast Events are broadcast to several listeners, who will handle them when they can Better modularity, but no time bounds Usually combined with the MVC architecture
  42. 42. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 38 Broadcast events example Events are key to implementing graphical user interfaces • The broadcast method of the source may be invoked automatically upon occurrence of an event Example: ActionEvents are emitted by Button objects addActionListener( ActionListener) removeActionListener( ActionListener) ... ActionListener actionPerformed( ActionEvent) MyListener actionPerformed( ActionEvent e) ActionEvent getActionCommand() getSource() e * 1 1 * 1 * Button
  43. 43. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 39 Broadcast events example Example: Mouse events are emitted by a Component object • Applets and other subclasses of Component inherit its methods • Mouse movement events are sent to a different listener (MouseMotionListener) MouseListener mouseClicked( MouseEvent) mousePressed( MouseEvent) ... MyListener MouseEvent Point getPoint() setPoint(Point) * 1 1 * 1 * mouseClicked( MouseEvent) mousePressed( MouseEvent) ... addMouseListener( MouseListener) addMouseMotionListener( MouseMotionListener) … Component ... Applet 1 * MouseMotionListener
  44. 44. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 40 Using events Events ensure communication between source and listener while effectively decoupling the functionality of source and listener • None needs to know the details of the other • The connection can be made and cancelled dynamically Event queues may be added to further decouple the timing of source and listener • Source and listener may operate at different rates
  45. 45. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 41 Thread-based control Thread-based • Several streams of execution that respond to different users, different stimuli, different events, etc. • Example: servlets Service method • Issue: mutual exclusion Communication through shared variables “synchronize”
  46. 46. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 42 Threads example class MyThread extends Thread { int k = 0; // the data managed by the Thread int m_id; // unique ID for each Thread public MyThread(int id) { m_id = id; } // print and update the data, i.e., integer k // invoked whenever the system executes the Thread public void run() { for(;;) { // forever System.out.println(Thread + m_id + : + k); k++; } } }
  47. 47. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 43 Thread-based control • May use queues to further decouple request generation from request handling * Stimulus Thread ** Event Stimulus Thread * Event queue Event * 1 * 1 Stimulus Thread * *
  48. 48. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 44 Using threads Threads are used for modularity, not performance • (Unless the OS scheduler is clever enough to map them to separate processors) • Decouple different user workflows Different users Different applications of same user • Tracking different actors • Mapping to different hardware • Avoid concurrency • Handle concurrency with mutual exclusion (synchronize)
  49. 49. McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Software design—Slide 45 References Modularity • BD 6.3.3 • McConnell 5.3, 5.4 System-level design • BD 6.3.1-6.3.5, 6.4.1-6.4.5, 6.4.8-6.4.10 Architectural options • BD 6.4.7

×