CS 5150 Software Engineering Lecture 13 System Architecture

CS 5150 Software Engineering Lecture 13 System Architecture and Design 1 CS 5150 1

Administration CS 5150 2

CS 5150: Software Engineering Usability (continued) CS 5150 3

Changes in user interface design Examples of change: 1995 to 2009 CS 5150 4

1990 CS 5150 5

1995 CS 5150 6

2003 CS 5150 7

2003 CS 5150 8

2009 CS 5150 9

1995 CS 5150 10

2006 CS 5150 11

1995 CS 5150 12

2003 CS 5150 13

1995 CS 5150 14

2006 CS 5150 15

CS 5150: Software Engineering System Architecture and Design CS 5150 16

System Architecture and Design The overall design of a system: • • • Computers and networks (e. g. , monolithic, distributed) Interfaces and protocols (e. g. , http, ODBC) Databases (e. g. , relational, distributed) Security (e. g. , smart card authentication) Operations (e. g. , backup, archiving, audit trails) Software environments (e. g. , languages, source control tools) CS 5150 17

UML: System and Subsystem Modeling Subsystem model A grouping of elements that specifies what a part of a system should do. Component (UML definition) "A distributable piece of implementation of a system, including software code (source, binary, or executable) but also including business documents, etc. , in a human system. " A component can be thought of as an implementation of a subsystem. CS 5150 18

UML Diagrams and Specifications For every subsystem, there is a choice of diagrams Choose the diagrams that best model the system and are clearest to everybody. In UML every diagram must have supporting specification The diagrams shows the relationships among parts of the system, but much, much more detail is needed to specify a system explicitly. For example, to describe an Applet, at the very least, the specification should include the version of the protocols to be supported at the interfaces, the options (if any), and implementation restrictions. CS 5150 19

UML Notation: Component & Node orderform. java A component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. Server A node is a physical element that exists at run time and represents a computational resource, e. g. , a computer. CS 5150 20

Components and Replaceability Components allow system to be assembled from binary replaceable elements • A component is physical -- bits not concepts • A component can be replaced by any other component(s) that conforms to the interfaces • A component is part of a system • A component provides the realization of a set of interfaces CS 5150 21

Components and Classes Components represent physical things. They may live on nodes. Classes represent logical abstractions. They may be grouped into packages. Classes have attributes and operations directly. Components have operations that are reachable only through interfaces. CS 5150 22

Example: Simple Web System Web browser CS 5150 Web server • Static pages from server • All interaction requires communication with server 23

UML Notation: Deployment Diagram Personal. Comp Web. Browser Dept. Server Web. Server components CS 5150 24

UML Notation: Application Programming Interface (API) API is an interface that is realized by one or more components. Web. Server Get CS 5150 Post 25

UML Notation: Interfaces Web. Browser Web. Server HTTP dependency realization interface CS 5150 26

Architectural Styles An architectural style is system architecture that recurs in many different applications. See: Mary Shaw and David Garlan, Software architecture: perspectives on an emerging discipline. Prentice Hall, 1996 CS 5150 27

Architectural Style: Client/Server Web example: Serving static pages Firefox client Apache server The control flows in the client and the server are independent. communication between client and server follows a protocol. In a peer-to-peer architecture, the same component acts as both a client and a server. CS 5150 28

System Architecture Example: Extensibility in Web Browsers Web browsers provide a flexible user interface through an extensible architecture Protocols: HTTP, WAIS, Gopher, FTP, etc. , proxies Data types: helper applications, plug-ins, etc. Executable code: Server-side code, e. g. , servlets, CGI Java. Script at client Java applets Style sheets: CSS, etc. CS 5150 29

Web User Interface: Application Server Data Web browser Server • Server-side code can configure pages, access data, validate information, etc. • All interaction requires communication with server CS 5150 30

Architectural Style: Three Tier Architecture Presentation tier Application tier Database tier Web example: Serving dynamic pages Each of the tiers can be replaced by other components that implement the same interfaces CS 5150 31

UML Notation: Interface Diagram These components might be located on a single node Apache Tomcat Browser HTTP CS 5150 My. SQL ODBC 32

Three tier architecture: Broadcast searching User interface service Databases This is an example of a multicast protocol. The primary difficulty is to avoid troubles at one site degrading the entire system (e. g. , every transaction cannot wait for a system to time out). CS 5150 33

Web User Interface: Java. Script Web browser html Java Script CS 5150 Data Server • Java. Scripts can validate information as typed • • Some interactions are local Server interaction constrained by web protocols 34

UML Notation: Package Java. Script A package is a general-purpose mechanism for organizing elements into groups. Note: Some authors draw packages with a different shaped box: Java. Script CS 5150 35

Example: Web Browser Web. Browser HTMLRender Each package represents a group of objects. Java. Script HTTP CS 5150 36

Web User Interface: Applet Any server Applets Web browser CS 5150 Web server • Any executable code can run on client • Client can connect to any server 37

Applet Interfaces XYZInterface XYZServer Web. Browser Web. Server HTTP CS 5150 38

Architectural Style: Pipe Example: A three-pass compiler Lexical analysis Parser Code generation Output from one subsystem is the input to the next. CS 5150 39

Architectural Style: Repository Input components Transactions Repository Advantages: Flexible architecture for data-intensive systems. Disadvantages: Difficult to modify repository since all other components are coupled to it. CS 5150 40

Architectural Style: Repository with Storage Access Layer Repository Input components This is sometimes called a "glue" layer Storage Access Transactions Data Store Advantages: Data Store subsystem can be changed without modifying any component except the Storage Access. CS 5150 41

Examples of Systems Architecture for Distributed Data: Replication Several copies of the data are held in different locations. Mirror: Complete data set is replicated Cache: Dynamic set of data is replicated (e. g. , most recently used) With replicated data, the biggest problems are concurrency and consistency. CS 5150 42

Examples of Systems Architecture for Distributed Data: Distributed Caches The Domain Name System First attempt to resolve www. cs. cornell. edu server 1 2 3 CS 5150 cornell. edu server cs. cornell. edu server 43

Examples of Systems Architecture for Distributed Data: Distributed Caches The Domain Name System Better method local DNS server 1 almaden. ibm. com cornell. edu Local ece. cmu. edu cache ibm. com acm. org. edu CS 5150 . edu server 2 cornell. edu server 3 cs. cornell. edu server 44

Examples of Systems Architecture for Distributed Data: Distributed Caches The Domain Name System For details of the actual protocol read: Paul Mockapetris, "Domain Names - Implementation and Specification". IETF Network Working Group, Request for Comments: 1035, November 1987. http: //www. ietf. org/rfc 1035. txt? number=1035 CS 5150 45

Examples of Systems Architecture for Distributed Data: Intermittent Connectivity This is an example of an epidemic protocol. Such protocols are especially useful in networks with intermittent connectivity, e. g. , mobile computing. Example: Usenet The biggest problem is ensuring that the data is distributed effectively. CS 5150 46