1 / 32

CS 5150 Software Engineering

CS 5150 Software Engineering. Lecture 13 System Architecture and Design 1. Administration. System Architecture and Design. The overall design of a system: • Computers and networks (e.g., monolithic, distributed) • Interfaces and protocols (e.g., http, ODBC)

lydia-gallagher
Download Presentation

CS 5150 Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Administration

  3. 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)

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

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

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

  7. Components and Replaceability Components allow system to be assembled from binaryreplaceable 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

  8. 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. Componentshave operations that are reachable only through interfaces.

  9. Example: Simple Web System Web server Web browser • Static pages from server • All interaction requires communication with server

  10. UML Notation: Deployment Diagram PersonalComp DeptServer WebBrowser WebServer components

  11. UML Notation:Application Programming Interface (API) API is an interface that is realized by one or more components. WebServer Get Post

  12. UML Notation: Interfaces WebBrowser WebServer HTTP dependency realization interface

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

  14. Architectural Style: Client/Server Web example: Serving static pages Apache server Firefox client 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.

  15. 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 JavaScript at client Java applets Style sheets: CSS, etc.

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

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

  18. UML Notation: Interface Diagram These components might be located on a single node Apache Tomcat Browser MySQL ODBC HTTP

  19. Three tier architecture: Broadcast searching User 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).

  20. Web User Interface: JavaScript Server Web browser html Data Java Script • JavaScripts can validate information as typed • Some interactions are local • Server interaction constrained by web protocols

  21. UML Notation: Package JavaScript A package is a general-purpose mechanism for organizing elements into groups. Note: Some authors draw packages with a different shaped box: JavaScript

  22. Example: Web Browser WebBrowser Each package represents a group of objects. HTMLRender JavaScript HTTP

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

  24. Applet Interfaces XYZInterface XYZServer WebBrowser WebServer HTTP

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

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

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

  28. Examples of Systems Architecture for Distributed Data: Replication 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.

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

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

  31. 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/rfc1035.txt?number=1035

  32. 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. The biggest problem is ensuring that the data is distributed effectively. Example: Usenet

More Related