Vitruvius BCE 20 Buildings should be Beautiful Stable
Vitruvius BCE 20 • Buildings should be: – Beautiful – Stable – Useful • Likewise architecture Spring 2017 (c) Ian Davis 1
Spring 2017 (c) Ian Davis 2
Slides available online • http: //www. softwarearchitecturebook. com/s vn/main/slides/ppt – 01_The_Big_Idea. ppt 02_Architectures_In_Context. ppt 03_Basic_Concepts. ppt 04_Designing_Architectures. ppt 05_Architectural_Styles. ppt 06_Styles_And_Greenfield_Design. ppt 07_Software_Connectors. ppt 08_Choosing_Connectors. ppt Spring 2017 (c) Ian Davis 3
Chapter 4: Architectural Conception • Early refinement and deduction process – Abstraction and simple machines • What style of software do you envision • The style will motivate the architecture – Excel (graph of relationships changes propagate) – Parser (push down automata) – Fax machine (finite state machine) – Avionics (read sensors, compute, change, repeat) Spring 2017 (c) Ian Davis 4
– Graphics (SVG, Pixels, Transforms, Widgets) – Word Processing (Structured docs, Layouts, Toolbars) – Control Processes (Finite State Machines) – Forms (Hypertext, Data validation, Form Template) – Web Pages (HTML, Javascript, Composition) – Scientific (Matrices, Math functions, Plotting) – Accounting (Spreadsheets, Database, Transactions) – And so on… Spring 2017 (c) Ian Davis 5
Simple Machines Domain Simple Machines Graphics Pixel arrays Transformation matrices Widgets Abstract depiction graphs Word processing Structured documents Layouts Process control Finite state machines Income Tax Software Hypertext Spreadsheets Form templates Web pages Hypertext Composite documents Scientific computing Matrices Mathematical functions Banking Spreadsheets Databases Transactions Spring 2017 (c) Ian 6 Davis
Separation of concerns • Components – What does what • Communication – How do the various parts communicate • External software – What are the interfaces / how to use it • User interfaces – What will it look like • Configurability / Security / etc. Spring 2017 (c) Ian Davis 7
Architectural Analysis in a Nutshell Spring 2017 (c) Ian 8 Davis Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Connectors Spring 2017 (c) Ian Davis 9
Procedure Calls Spring 2017 (c) Ian Davis 10
Event Connectors Spring 2017 (c) Ian Davis 11
Data Access Connectors Spring 2017 (c) Ian Davis 12
Linkage Connectors Spring 2017 (c) Ian Davis 13
Stream Connectors Spring 2017 (c) Ian Davis 14
Arbitrator Connectors Spring 2017 (c) Ian Davis 15
Adaptor Connectors Spring 2017 (c) Ian Davis 16
Distributor Connectors Spring 2017 (c) Ian Davis 17
Architectural Approaches Spring 2017 (c) Ian Davis 18
Hardware Architectures Spring 2017 (c) Ian Davis 19
Hardware Architecture • RISC machines emphasize a small fast instruction set as an important feature. • Complex instructions are implemented using this simple fast set. • Pipelined and multi-processor machines emphasize the configuration of architectural pieces of the hardware, and the overlapped flow of instruction and operation. Spring 2017 (c) Ian Davis
Hardware Architecture • Micro-coded machines employ a fast interpreter to translate from a rich end user instruction set, to the underlying instruction set. They can emulate many machine architectures. • Pentium incorporates all of the logic to perform dynamic memory allocation, page faults etc. within its hardware. Spring 2017 (c) Ian Davis
Network Architectures Spring 2017 (c) Ian Davis 22
Network Architecture • Networked architectures are achieved by abstracting the design elements of a network into nodes and connections. • Topology is the most emphasized aspect: – Star networks – Token ring networks – Ethernet • Unlike software architectures, in network architectures only few topologies interesting (c) Ian Davis 23 Spring 2017
Network Architecture • Synchronous versus asynchronous. • Unreliable versus reliable. • Re-use of software: eg: TCP/IP has TCP using the IP protocol to make unreliable communication, reliable. • Layered communications protocol. • ISO/OSI Ethernet Reference Model is a layered network architecture (c) Ian Davis 24 Spring 2017
Data Flow Architecture Spring 2017 (c) Ian Davis 25
Pattern: Pipes and Filters • Context – Data can arrive in different formats • Problem – Need to provide a series of ordered independent computations • Forces – Exploit existing programs / enforce data flow – Partition into step wise processes – Debug partitioned problem independently – Support parallelism Spring 2017 (c) Ian Davis 26
Pipe and Filter Architecture • Pipelines: Restricts topologies to linear sequences of filters. • Batch Sequential: A degenerate case of a pipeline architecture where each filter processes all of its input data before producing any output. (c) Ian Davis 27 Spring 2017
Pipe and Filter Examples • Unix Shell Scripts: Provides a notation for connecting Unix processes via pipes. – cat file | grep Erroll | wc -l • Traditional Compilers: Compilation phases are pipelined, though the phases are not always incremental. The phases in the pipeline include: – lexical analysis + parsing + semantic analysis + code generation (c) Ian Davis 28 Spring 2017
Sequential batch processes Spring 2017 (c) Ian Davis 29
Pipe and Filter Advantages • Easy to understand the overall input/output behavior of a system as a simple composition of the behaviors of the individual filters. • They support reuse, since any two filters can be hooked together, provided they agree on the data that is being transmitted between them. (c) Ian Davis 30 Spring 2017
Pipe and Filter Advantages (Cont’d) • Systems can be easily maintained and enhanced, since new filters can be added to existing systems and old filters can be replaced by improved ones. • They permit certain kinds of specialized analysis, such as throughput and deadlock analysis. • The naturally support concurrent execution. (c) Ian Davis 31 Spring 2017
Pipe and Filter Disadvantages • Not good for handling interactive systems, because of their transformational character. • Excessive parsing and unparsing leads to loss of performance and increased complexity in writing the filters themselves. (c) Ian Davis 32 Spring 2017
Abstract Layer Architectures Spring 2017 (c) Ian Davis 33
Domain Specific Software Architectures • (DSSA) – Reference Architecture for the domain – Libraries of tools for use within domain – Configuration of target solution • Game engines, 3 D visualisation, parsers, shells … – Takes the work out of the work – Hard to say how it works Spring 2017 (c) Ian Davis 34
Pattern: Layer • Context – Application has multiple layers of abstraction • Problem – Both high and low level issues to be addressed – Higher levels depends on lower levels • Forces – Localize changes to single components – Separate concerns into different components – Reusable logic easily accessible – Components cohesive but loosely coupled Spring 2017 (c) Ian Davis 35
OSI/Ethernet Layers • • Physical - Wire, USB, Bluetooth, RS 232. . . Data Link – ATM, SDLC … Network – IPv 4, IPv 6, Apple. Talk … Transport – UDP, TCP, DCCP … Session – Named Pipe, SOCKETS, Net. Bios, … Presentation – MIME, XDR, … Application – Telnet, FTP, HTTP, NSF, SMTP Spring 2017 (c) Ian Davis 36
Peer to Peer Spring 2017 (c) Ian Davis 37
RFC 3439 Layering of this type does have various conceptual and structuring advantages. However, in the data networking context structured layering implies that the functions of each layer are carried out completely before the protocol data unit is passed to the next layer. This means that the optimization of each layer has to be done separately. Such ordering constraints are in conflict with efficient implementation of data manipulation functions. One could accuse the layered model (e. g. , TCP/IP and ISO OSI) of causing this conflict. In fact, the operations of multiplexing and segmentation both hide vital information that lower layers may need to optimize their performance. For example, layer N may duplicate lower level functionality, e. g. , error recovery hop-hop versus end-to-end error recovery. In addition, different layers may need the same information (e. g. , time stamp): layer N may need layer N-2 information Spring 2017 (c) Ian Davis 38
Software Layer Architecture • Simple – divide and conquer • Clean – each layer is independent • Potential problems – Procedural implies tight binding of code – Synchronous (causes browser pause etc. ) – Lack of hierarchical flow (eg. Co-routines) – Encapsulation denies access to important detail – Interrupts and Exceptions (violate hierarchy) Spring 2017 (c) Ian Davis 39
The “Toaster” Model (c) Ian 40 Davis Spring 2017
- Slides: 40