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

2. 2 CS 501 Spring 2006 Administration BOOM Wednesday, Duffield Atrium 4-6

3. 3 CS 501 Spring 2006 Quiz 2, Question 1 Question 1 At the end of your CS 501 project, you mount your programs and documentation on GForge. The project team gives the client an unrestricted license to use the project for the client's purposes but not to distribute it to others. A year later, two members of your team start a company, selling a product that is based on your CS 501 system.

4. 4 CS 501 Spring 2006 Quiz 2, Question 1 (a)They would like to keep the specification of the system secret. For this purpose they remove the system from GForge. Can they claim legal protection of the specification as trade secret? No. The presumption is that by placing it on the GForge for a year, trade secret protection was lost, unless the GForge site is securely protected and, from the very start, everybody who saw the specification was required to keep it secret.

5. 5 CS 501 Spring 2006 Quiz 2, Question 1 (b)The company extends the system with a new component. Can they protect the specification of the new component as trade secret? If so, what procedure should they follow? Yes, by creating procedures to keep the specification secret, e.g., by restricting access and by ensuring that everybody who has access understands the necessity of keeping it secret. (c) Can the company require the CS 501 client to pay to use the new component? Yes. Unless the license from the project team to the client says otherwise.

6. 6 CS 501 Spring 2006 Quiz 2, Question 1 (d)Some time later, another member of the CS 501 project team complains that he was never consulted about the company using the software from the project. He asks for a share of the profits. What should the company do? Best answer: Ask a lawyer. This is a serious complaint, which might cause problems for the company unless it is resolved. Less good answer: Other members of the team are joint owners of the copyright and have a right to share in the profits unless they have signed a license agreement with the members of the company. (This may be the advice that a lawyer will give, but the situation is too complex not to seek professional advice.)

7. 7 CS 501 Spring 2006 Quiz 2, Question 2 An actor is a user of a system in a particular role. OnlineShopper is a role User is too vague to be useful Mary is an individual, not a role A use case is a a task that an actor needs to perform with the help of the system. PlaceOrder is a user task (and a use case) Search the Catalog is part of this use case Borrow book BookBorrower

8. 8 CS 501 Spring 2006 System Architecture and Design The overall design of a system: Computers and networks (e.g., monolithic, distributed) Interfaces and protocols (e.g., http, sql) 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)

9. 9 CS 501 Spring 2006 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.

10. 10 CS 501 Spring 2006 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.

11. 11 CS 501 Spring 2006 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.

12. 12 CS 501 Spring 2006 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.

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

14. 14 CS 501 Spring 2006 UML Notation: Deployment Diagram WebBrowser PersonalComp WebServer DeptServer

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

16. 16 CS 501 Spring 2006 UML Notation: Interfaces WebBrowserWebServer HTTP dependency interface realization

17. 17 CS 501 Spring 2006 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

18. 18 CS 501 Spring 2006 UML Notation: CGI Interface Diagram CGIScript HTTP Apache CGI SQL MySQL These components might be located on a single node.

19. 19 CS 501 Spring 2006 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

20. 20 CS 501 Spring 2006 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

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

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

23. 23 CS 501 Spring 2006 Applet Interfaces WebBrowserWebServer HTTP XYZServer XYZInterface

24. 24 CS 501 Spring 2006 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.

25. 25 CS 501 Spring 2006 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.

26. 26 CS 501 Spring 2006 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)

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

28. 28 CS 501 Spring 2006 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.,

29. 29 CS 501 Spring 2006 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

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

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

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

33. 33 CS 501 Spring 2006 Interfaces to DataInput DataInput RawData EditCheckError UpdateError DataforCheck

34. 34 CS 501 Spring 2006 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

35. 35 CS 501 Spring 2006 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

36. 36 CS 501 Spring 2006 Online Inquiry: Use Cases CustomerServer AnswerCustomer NewTransaction >

37. 37 CS 501 Spring 2006 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

38. 38 CS 501 Spring 2006 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)

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

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

41. 41 CS 501 Spring 2006 Stock Broker: Interface Diagram CustomerDB ProductDB OnLineTR BatchTR

42. 42 CS 501 Spring 2006 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. *