1. CS 360 Lecture 8

2.  The requirements describe the function of a system as seen by the client.  The software team must design a system that will meet the given requirements.  In this course, we look at the following aspects of design:  System architecture  Program design  Usability  Performance  Security  In practice, these aspects are interrelated and many aspects of the design emerge during the requirements phase of a project. 2

3.  Software development  Software developers have a variety of tools that can be applied in different situations.  Part of the art of software development is to select the appropriate tool for a given implementation.  Creativity and design  System and program design are a particularly creative part of software development.  Above all, strive for simplicity.  The aim is to find simple ways to implement complex requirements. 3

4.  System architecture is the overall design of a system  Computers and networks (monolithic, distributed)  Interfaces and protocols (http, IEEE 802.3)  Databases (relational, NoSQL)  Security (authentication, encryption)  Operations (backup, archiving)  At this stage of the development process, you should also be selecting:  Software environments (languages, database systems, APIs)  Testing frameworks 4

5.  Our models for system architectures are based on UML  For every system, there is a choice of models  Choose the models that best clearly describe the system  When developing a system, every diagram must have supporting documentation  Diagrams show the relationships among parts of the system, but much more detail is needed to explain system functionality.  For example, to specify a web plug-in, the documentation should include  Version of the protocols to be supported at the interfaces  Options (if any)  Implementation restrictions 5

6.  A subsystem is a grouping of elements that form part of a system.  Coupling is a measure of the dependencies between two subsystems.  If two subsystems are strongly coupled, it is hard to modify one without the other.  Cohesion is a measure of dependencies within a subsystem.  If a subsystem contains many closely related functions, it’s cohesion is high.  An ideal division of a complex system into subsystems has low coupling between subsystems and high cohesion within subsystems. 6

7.  A component is a replaceable part of a system that conforms to a set of interfaces.  Can be thought of as an implementation of a subsystem.  UML definition of a component:  “A distributable piece of a system, including code (source, binary, or exe.), but also includes documentation” 7

8.  Components allow systems to be assembled from replaceable elements  Components can be replaced by other component(s) that conforms to the interfaces/specifications  The entire system is made of many components  Components provide the implementation and documentation of a set of requirements 8

9.  Classes represent logical abstractions.  They have attributes(data)and operations (methods).  Components have operations that are reachable only through interfaces. 9

10.  A package is a general-purpose mechanism for organizing elements into groups.  Note: Some authors draw packages with a different shaped box: 10

11.  A node is a physical element that exists at run time and provides a computational resource.  Computer  Smartphone  Router/switch  System components may live on nodes 11

12.  Static pages requested from web server  All interactions require communication with the server  HTTP  TCP  IP  IEEE 802.x 12

13. 13

14. 14

15. 15 An API is a set of routines or protocols used in software applications. Expresses a software component in terms of operations, inputs, and outputs. Defines functionalities that are independent of implementation Allows API implementations to vary without compromising component interactions.

16.  An architectural style is a system architecture that recurs in many different applications.  Examples:  Piping input/output  Client/server  Repositories  Model/View/Controller  Buffering 16

17.  Example:  A three-pass compiler  Output from one subsystem is the input of the next subsystem. 17

18.  Example:  An E-mail system  The control flows in the client component and the server component are independent.  Communication between client/server follows specific protocols  HTTP, Sockets, etc.  In a peer-to-peer architecture (similar to the robotics project), components can act as both client and server. 18

19.  Example:  Storm data repository  Advantages: Flexible architecture for data-intensive systems  Disadvantages: Difficult to modify repository since many different components are connected to it. 19

20.  Example:  Control of UAV  Controller: sends commands to update the model’s state  Receives readings/environment data from the UAV  Sends control signals to the UAV  Model: stores data received from controller, state displayed in the view  Translates data to/from the UAV  Uses domain knowledge about UAV and flight  View: output to the user based on changes in the model  Displays information about the UAV to the user 20

21. 21

22.  A time-critical (real time) system is a software system whose correct functioning depends on  Quality of results produced  Time taken to produce results  A hard real time system fails if the results are not produced within required time constraints.  EX: fly-by-wire control system for an airplane must responds within specified time limits.  A soft real time system is degraded if the results are not produced within required time constraints.  EX: A network router is permitted to time out or lose a packet. 22

23.  A daemon is a background process generally used to help process requests to a larger system.  Example: Web server  Daemon listens at port 80 (background process, httpd)  When a message arrives:  Spawns a process to handle the message  Returns to listening at port 80 23

24.  Replication:  Several copies of the data are held in different locations.  Mirror: complete data set is replicated  Cache: subset of data is replicated (most recently used/fetched data)  With replicated data, the biggest problems are:  Concurrency: many users can access the data at the same time  Consistency: each user sees exactly the same data, including changes made by themselves and others  Example:  The Domain Name System (DNS) 24

25.  When an application wants a continuous stream of data from a source that delivers data in bursts  Software reads the bursts of data into a buffer  Application then reads data from the buffer  EX: TCP  Flow and congestion control windows (buffers) determine transmission rate. 25

26.  Advantage:  Server-side can configure web pages, data access, authentication/validation, etc.  Disadvantage:  All interactions with the website requires communication with the web server. 26

27.  Each of the tiers can be replaced by other components that implement the same interfaces 27

28. 28

29.  The previous three tier architecture is just one way the basic architecture of the web can be extended.  Other ways:  Protocols:  HTTP, DNS, TCP, ICMP  Data interactions:  APIs, plug-ins, frameworks  Executable code:  Server/client scripts  Style sheets and dynamic markup:  CSS, XHTML, XML 29

30.  Examples of data intensive systems:  Utility customer billing (BGMU)  Telephone call recording and billing (Verizon)  Car rental services (Hertz)  Stock market brokerage (Charles Schwab)  E-commerce (Amazon.com)  University grade registration (WKU Topnet) 30

31.  Example: Utility billing  Requirements analysis identifies several transaction types:  Create/close accounts  Meter reading  Payments received  Other credit/debt  Payment monitoring cleared/insufficient funds  Account query  Correction of errors  And more.. 31

32.  Many data intensive systems (used by banks, universities, etc.) are legacy systems.  May have been developed 40 years ago and continually modified.  Recent modifications may include interfaces for web, smartphones, etc.  Have migrated between many computers, across operating systems, different databases, etc.  Maintaining a coherent system architecture for such a legacy system is extremely difficult.  Yet, the complexity of building a completely new system is so great, it is rarely attempted. 32

33.  Many systems must operate continuously  Software updates occur while operating  Hardware is monitored and repaired  Uses alternative power supplies, duplicate networks, etc.  Administrators have remote access to system components  Example: Cloud Architecture  Virtual machines may be live migrated away from a failing server  Users are unaware of the migration  These functions must be designed into the fundamental architecture 33