CS 360 Lecture 8

 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

 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

 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

 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

 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

 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

 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

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

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

 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

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

13

14

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.

 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

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

 Example:  An 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

 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

 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

 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

 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

 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

 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

 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

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

28

 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

 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

 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

 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

 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