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.

SYSTEM ARCHITECTURE

CS 360

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

In practice, these aspects are interrelated and many aspects of the design emerge during the requirements phase of a project.

2

CREATIVITY AND DESIGNSoftware 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 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

MODELS FOR SYSTEM ARCHITECTUREOur 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

SUBSYSTEMS 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

SYSTEM COMPONENTSA 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 AS REPLACEABLE ELEMENTS Components allow systems to be assembled from replaceable elementsComponents can be replaced by other component(s) that conforms to the interfaces/specifications

The entire system is made of many componentsComponents provide the implementation and documentation of a set of requirements

8

COMPONENTS AND CLASSESClasses represent logical abstractions.

They have attributes(data) and operations (methods).

Components have operations that are reachable only through interfaces.

9

PACKAGESA package is a general-purpose mechanism for organizing elements into groups.

Note: Some authors draw packages with a different shaped box:

10

NODESA 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

EXAMPLE: SIMPLE WEB SYSTEM

Static pages requested from web serverAll interactions require communication with the server

HTTP TCP IP IEEE 802.x 12

DEPLOYMENT DIAGRAM

13

COMPONENT DIAGRAM: INTERFACES

14

APPLICATION PROGRAMMING INTERFACE (API)

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.

ARCHITECTURAL STYLESAn architectural style is a system architecture that recurs in many different applications.

Examples: Piping input/output Client/server Repositories Model/View/Controller Buffering

16

ARCHITECTURAL STYLE: PIPEExample:

A three-pass compiler

Output from one subsystem is the input of the next subsystem.

17

ARCHITECTURAL STYLE: CLIENT/SERVER

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

ARCHITECTURAL STYLE: REPOSITORY

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

ARCHITECTURAL STYLE: MODEL/VIEW/CONTROLLER

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

MODEL/VIEW/CONTROLLER: AUTONOMOUS LAND VEHICLE

21

TIME-CRITICAL SYSTEMS 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

TIME CRITICAL SYSTEM: ARCHITECTURAL STYLE - DAEMONA 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

ARCHITECTURAL STYLES FOR DISTRIBUTED DATAReplication:

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

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.

25

ARCHITECTURAL STYLE EXAMPLE: WEB SERVER WITH DATA STORE

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

ARCHITECTURAL STYLE EXAMPLE: THREE - TIER

WEB SERVER WITH DATA STORE

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

27

ARCHITECTURAL STYLE EXAMPLE: COMPONENTS

WEB SERVER WITH DATA STORE

28

SYSTEM DESIGN EXAMPLE: EXTENDING THE ARCHITECTURE OF THE WEBThe previous three tier architecture is just one way the basic architecture of the web can be extended.

Other ways:Protocols:

HTTP, DNS, TCP, ICMPData interactions:

APIs, plug-ins, frameworksExecutable code:

Server/client scriptsStyle sheets and dynamic markup:

CSS, XHTML, XML29

SYSTEM DESIGN EXAMPLE: DATA INTENSIVE SYSTEMSExamples 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

SYSTEM DESIGN EXAMPLE: DATA INTENSIVE SYSTEMSExample: 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

SYSTEM DESIGN EXAMPLE: DATA INTENSIVE SYSTEMSMany 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

CONTINUOUS OPERATIONMany 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