1. 1 CS 501 Spring 2008 CS 501: Software Engineering Lecture 13 System Architecture and Design I

2. 2 CS 501 Spring 2008 Administration Quizzes There are 4 quizzes, each with 2 questions. The final grade will be based on the best 6 questions out of 8. Uncollected answer books are at 301 College Avenue. Average grades: Quiz 1 Q1Quiz 1, Q2Quiz 2 Q1Quiz 2 Q2 7.6 6.2 6.8 8.0

3. 3 CS 501 Spring 2008 CS 501: Software Engineering Usability (continued)

4. 4 CS 501 Spring 2008 Evaluation Making sure that a system is usable before launching it. Iterative improvements after launch. Categories of evaluation methods: Analytical evaluation: without users Measurements on operational systems Empirical evaluation: with users

5. 5 CS 501 Spring 2008 Evaluation How do you measure usability? Usability comprises the following aspects: Effectiveness – the accuracy and completeness with which users achieve certain goals Measures: quality of solution, error rates Efficiency – the relation between the effectiveness and the resources expended in achieving them Measures: task completion time, learning time, clicks number Satisfaction – the users' comfort with and positive attitudes towards the use of the system Measures: attitude rating scales From ISO 9241-11

6. 6 CS 501 Spring 2008 Measurement Basic concept: log events in the users' interactions with a system Examples from a Web system Clicks (when, where on screen, etc.) Navigation (from page to page) Keystrokes (e.g., input typed on keyboard) Use of help system Errors May be used for statistical analysis or for detailed tracking of individual user.

7. 7 CS 501 Spring 2008 Evaluation based on measurements Analysis of system logs Which user interface options were used? When was was the help system used? What errors occurred and how often? Which hyperlinks were followed (click through data)? Human feedback Complaints and praise Bug reports Requests made to customer service

8. 8 CS 501 Spring 2008 Evaluation with Users Testing the system, not the users! Stages of evaluation with users: Preparation Sessions conduct Analysis of results User testing is time-consuming, expensive, and essential.

9. 9 CS 501 Spring 2008 Evaluation with Users Preparation Determine goals of the usability testing “Can a user find the required information in no more than 2 minutes?” Write the user tasks “Answer the question: how hot is the sun?” Recruit participants Use the descriptions of users from the requirements phase to detect potential users

10. 10 CS 501 Spring 2008 Usability Laboratory Concept: monitor users while they use system Evaluators User one-way mirror

11. 11 CS 501 Spring 2008 Evaluation with Users Sessions Conduct Conduct the session –Usability Lab –Simulated working environment Observe the user –Human observer(s) –Video camera –Audio recording Inquire satisfaction data

12. 12 CS 501 Spring 2008 Evaluation with users: Results analysis If possible, use statistical summaries. Pay close attention to areas where users –were frustrated –took a long time –could not complete tasks Respect the data and users' responses. Do not make excuses for designs that failed. Note designs that worked and make sure they are incorporated in the final product.

13. 13 CS 501 Spring 2008 Usability: Design Tensions in Networked Systems Client computers and network connections vary greatly in capacity Client software may run on various operating systems. It may be current or an earlier version. What assumptions do you make about the user's computer and Web browser? Designers wish to control client software, e.g., Web browsers, but users wish to configure their own environments. This can be a factor in accessibility, e.g., which part of the system determines the font size.

14. 14 CS 501 Spring 2008 System considerations of user interface design Personal computer cycles are there to be used Any network transfer involves delay Shared systems have unpredictable performance Data validation often requires access to shared data Mobile code poses security risks

15. 15 CS 501 Spring 2008 Usability and Cost Good usability may be expensive in hardware or special software development User interface development may be a major part of a software development project Programming environments provide powerful user interface toolkits Costs are multiplied if a user interface has to be used on different computers or migrate to different versions of systems Web browsers provide a general purpose user interface where others maintain the user interface software

16. 16 CS 501 Spring 2008 Changes in user interface design Examples of change: 1995 to 2007

17. 17 CS 501 Spring 2008 1990

18. 18 CS 501 Spring 2008 1995

19. 19 CS 501 Spring 2008 2003

20. 20 CS 501 Spring 2008 2003

21. 21 CS 501 Spring 2008 1995

22. 22 CS 501 Spring 2008 2006

23. 23 CS 501 Spring 2008 1995

24. 24 CS 501 Spring 2008 2003

25. 25 CS 501 Spring 2008 1995

26. 26 CS 501 Spring 2008 2006

27. 27 CS 501 Spring 2008 CS 501: Software Engineering System Architecture and Design

28. 28 CS 501 Spring 2008 System Architecture and Design The overall design of a system: Computers and networks (e.g., monolithic, distributed) Interfaces and protocols (e.g., http, ODBC) Databases (e.g., relational, distributed) Security (e.g., smart card authentication) Operations (e.g., backup, archiving, audit trails) Software environments (e.g., languages, source control tools)

29. 29 CS 501 Spring 2008 UML: System and Subsystem Modeling Subsystem model A grouping of elements that specifies what a part of a system should do. Component (UML definition) "A distributable piece of implementation of a system, including software code (source, binary, or executable) but also including business documents, etc., in a human system." A component can be thought of as an implementation of a subsystem.

30. 30 CS 501 Spring 2008 UML Notation: Component & Node orderform.java A component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. Server A node is a physical element that exists at run time and represents a computational resource, e.g., a computer.

31. 31 CS 501 Spring 2008 Components and Replaceability Components allow system to be assembled from binary replaceable elements. A component is physical -- bits not concepts A component can be replaced by any other component(s) that conforms to the interfaces. A component is part of a system. A component provides the realization of a set of interfaces.

32. 32 CS 501 Spring 2008 System Architecture Example: Extensibility in Web Browsers Web browsers provide a flexible user interface through an extensible architecture. Protocols: HTTP, WAIS, Gopher, FTP, etc., proxies Data types: helper applications, plug-ins, etc. Executable code: CGI scripts at server JavaScript at client Java applets Style sheets: CSS, etc.

33. 33 CS 501 Spring 2008 Web Interface: Basic Web server Web browser Static pages from server All interaction requires communication with server

34. 34 CS 501 Spring 2008 UML Notation: Deployment Diagram WebBrowser PersonalComp WebServer DeptServer

35. 35 CS 501 Spring 2008 UML Notation: Application Programming Interface (API) API is an interface that is realized by one or more components. WebServer GetPost

36. 36 CS 501 Spring 2008 UML Notation: Interfaces WebBrowserWebServer HTTP dependency interface realization

37. 37 CS 501 Spring 2008 Web User Interface: CGI Script Web browser Scripts can configure pages Scripts can validate information All interaction requires communication with server Data CGI Scripts Web server

38. 38 CS 501 Spring 2008 UML Notation: CGI Interface Diagram CGIScript HTTP Apache CGI ODBC MySQL These components might be located on a single node.

39. 39 CS 501 Spring 2008 Web User Interface: JavaScript Data CGI Scripts Web server Web browser JavaScripts can validate information as typed Some interactions are local Server interaction constrained by web protocols Java Script html

40. 40 CS 501 Spring 2008 UML Notation: Package A package is a general-purpose mechanism for organizing elements into groups. Note: Some authors draw packages with a different shaped box: JavaScript

41. 41 CS 501 Spring 2008 Example: Web Browser HTTP JavaScript HTMLRender Each package represents a group of objects. WebBrowser

42. 42 CS 501 Spring 2008 Web User Interface: Applet Any server Web servers Web browser Any executable code can run on client Client can connect to any server Applets

43. 43 CS 501 Spring 2008 Applet Interfaces WebBrowserWebServer HTTP XYZServer XYZInterface

44. 44 CS 501 Spring 2008 UML Diagrams and Specifications For every subsystem, there is a choice of diagrams Choose the diagrams that best model the system and are clearest to everybody. In UML every diagram must have supporting specification The diagrams shows the relationships among parts of the system, but much, much more detail is needed to specify a system explicitly. For example, in the Applet Interface slide, at the very least, the specification should include the version of the protocols to be supported at the interfaces, the options (if any), and implementation restrictions.

45. 45 CS 501 Spring 2008 Components and Classes Classes represent logical abstractions. They may be grouped into packages. Components represent physical things. They may live on nodes. Classes have attributes and operations directly. Components have operations that are reachable only through interfaces.

46. 46 CS 501 Spring 2008 System Design: Data Intensive Systems Examples Electricity utility customer billing (e.g., NYSEG) Telephone call recording and billing (e.g., Verizon) Car rental reservations (e.g., Hertz) Stock market brokerage (e.g., Charles Schwab) E-commerce (e.g., Amazon.com) University grade registration (e.g., Cornell)

47. 47 CS 501 Spring 2008 Example: Electricity Utility Billing Transaction Types Requirements analysis has identified several transaction types: Create account / close account Meter reading Payment received Other credits / debits Check cleared / check bounced Account query Correction of error etc., etc., etc.,

48. 48 CS 501 Spring 2008 Batch Processing Design Example: Electricity Utility Billing First attempt: Data input Master file Transaction Bill Each transaction is handled as it arrives.

49. 49 CS 501 Spring 2008 Criticisms of First Attempt Where is this first attempt weak? A bill is sent out for each transaction, even if there are several per day Bills are not sent out on a monthly cycle Awkward to answer customer queries No process for error checking and correction All activities are triggered by a transaction

50. 50 CS 501 Spring 2008 Batch Processing: Validation Data input Master file Edit & validation read only errors Batches of validated transactions Batches of incoming transactions

51. 51 CS 501 Spring 2008 UML Deployment Diagram: Batch Processing Validation MasterFile EditCheck ValidData DataInput RawData

52. 52 CS 501 Spring 2008 Batch Processing: Master File Update Master file update Bills Validated transactions in batches Sort by account errors Reports Instructions

53. 53 CS 501 Spring 2008 Interfaces to DataInput DataInput RawData EditCheckError UpdateError DataforCheck

54. 54 CS 501 Spring 2008 Benefits of Batch Updating All transactions for an account are processed together at appropriate intervals Backup and recovery have fixed checkpoints Better management control of operations Efficient use of staff and hardware

55. 55 CS 501 Spring 2008 Online Inquiry Master file read only Customer Service Customer Service department can read file, make annotations, and create transactions, but cannot change the master file. New transaction

56. 56 CS 501 Spring 2008 Online Inquiry: Use Cases CustomerServer AnswerCustomer NewTransaction >

57. 57 CS 501 Spring 2008 Data Intensive Systems Example: A Small-town Stockbroker Transactions Received by mail or over telephone For immediate or later action Complex customer inquiries Highly competitive market

58. 58 CS 501 Spring 2008 A Database Architecture Databases: Customer and account database Financial products (e.g., account types, pension plans, savings schemes) Links to external databases (e.g., stock markets, mutual funds, insurance companies)

59. 59 CS 501 Spring 2008 Real-time Transactions Customer & account database Products & services database External services Real-time transactions

60. 60 CS 501 Spring 2008 Real-time Transactions & Batch Processing Customer & account database Products & services database External services Real-time transactions Batch processing Data input

61. 61 CS 501 Spring 2008 Stock Broker: Interface Diagram CustomerDB ProductDB OnLineTR BatchTR External

62. 62 CS 501 Spring 2008 Practical considerations to include in Architecture and Specification Real-time service during scheduled hours with batch processing overnight Database consistency after any type of failure two-phase commit reload from checkpoint + log detailed audit trail How will transaction errors be avoided and identified? How will transaction errors be corrected? How will staff dishonesty be controlled? These practical considerations may be major factors in the choice of architecture. *