System Architecture CS 560 Lecture 8

Project Design 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

Creativity and Design Software development Creativity and design A major part of software development is to select the appropriate language/API/Framework for a given requirement. 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.

System architecture System architecture is the conceptual model that defines structure, behavior, and views of a system. Computers and networks (monolithic, distributed) Interfaces and protocols (HTTP, IEEE 802.3, ODBC) Databases (relational, NoSQL) Security (authentication, encryption) Operations (backup, archiving, replication) At this stage of the development process, you should also be selecting: Software environments (languages, database systems, APIs) Test cases

Models for System architecture Models for system architectures are based on UML When developing a system model, 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 supporting documentation should include: Version of the protocols to be supported at the interfaces Options (if any) Implementation dependencies/restrictions

Subsystems Ideal division of a complex system into subsystems: A subsystem is a grouping of elements that form part of a system. Ideal division of a complex system into subsystems: Low coupling between subsystems. High cohesion within subsystems. 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. Number of required interfaces and data passed between subsystems. Cohesion is a measure of dependencies within a subsystem. High cohesion if a subsystem contains many closely related functions.

System components (documentation) 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. Set of closely related functions. UML definition of a component: “A distributable piece of a system, including code (source, binary, etc.), but also includes documentation”

Components as replaceable elements Components allow systems to be assembled from replaceable elements Can be replaced by other component(s) that conforms to the interfaces/specifications. Provide the implementation and documentation of a set of requirements. The entire system is made of many components. //Sort Component x //input: obj[] //ouput: sorted obj[] Public SortObjs(obj[] E) …sorting alg //Sort Component y //input: obj[] //ouput: sorted obj[] Public SortObjs(obj[] E) …sorting alg …10x faster than Sort Component x

Components and Classes (documentation) Classes represent logical abstractions. They have attributes(data) and operations (methods). Components have operations that are reachable only through Interfaces. http requests, GPIO port, memory location, socket, etc.

Packages (Documentation) Package is a namespace used to group together elements that are related and might change together. Used to organize elements into groups to provide a better structure for system models. The members of the package may be shown within the boundaries of the package. In this case the name of the package should be placed on the tab.

Nodes (Documentation) A node is a physical element (or virtualized environment) that exists at run time and provides a computational environment and resources. Computer Smartphone Router/switch Embedded System Virtual Machine Docker Container

Nodes Nodes are associated with deployments of packaged elements and components. Can be interconnected with communication paths. Ex: application and database on different nodes need to communicate. Communication paths between the nodes define how these processes communicate. Communication Path

Example: Simple web system Static pages requested from web server All interactions require communication with the server DNS, HTTP TCP IP IEEE 802.x

Deployment diagram (Documentation)

Component diagram: Interfaces (Documentation)

Architectural Styles (Documentation) An architectural style is a system architecture that recurs in many different applications. Examples: Input/output data pipeline Client/server Repositories Buffering

Architectural Style: Pipe Example: A three-pass compiler Output from one subsystem is the input of the next subsystem.

Architectural Style: Client/server Example: An E-mail system Communication between client/server follows specific protocols. HTTP, Sockets, etc. In a peer-to-peer architecture, components can act as both client and server.

Architectural Style: Repository Example: Storm data repository Advantages: Flexible architecture for data-intensive systems Disadvantages: Difficult to modify repository since many different components can be connected to it.

Time-critical systems A time-critical (real time) system is a software system whose correct functioning depends on Time taken to produce results Quality of results produced 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.

Time Critical system: Architectural Style - Daemon A daemon is a background process generally used to help process requests for 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

Architectural styles for distributed data 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 on local and/or replicated systems. Example: The Domain Name System (DNS)

Architectural style: Buffering 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.

Architectural style Example: Components Web server with data store

System Design Example: Extending the architecture of the web 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

Continuous Operation 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 system architecture.

Exam 0 Exam: six questions, one to omit, graded out of five. Each question equally weighted (25% each) Detailed answers must be legible (marked incorrect if I can’t read your answer) Answer quality/detail will determine your score for each question Possible multiple section questions; a, b, c, .. Two hours to complete the exam in class Content on exam 0: First seven lectures Chapters 1, 2, 4, 5, 6, 7, 22, and 23 Supplemental reading Suggested reading: Your group’s project documentation