1. System Architecture CS 560

2. 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

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 3

4. Models for System architecture 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 4

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. 5

6. System components 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” 6

7. Components as replaceable elements 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 7

8. Nodes 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 8

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

10. Deployment diagram 10

11. Component diagram: Interfaces 11

12. Application Programming Interface (API) 12 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.

13. Architectural Styles An architectural style is a system architecture that recurs in many different applications.  Examples:  Piping input/output  Client/server  Repositories  Model/View/Controller 13

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

15. 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, components can act as both client and server. 15

16. 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. 16

17. 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 17

18. 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 Example:  The Domain Name System (DNS) 18

19. 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. 19

20. 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 20

21. Architectural style Example: Components Web server with data store 21

22. System Design Example: Data intensive systems 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) 22

23. System Design Example: Data intensive systems 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. 23

24. 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 architecture 24