Designing Architectures

Designing

• Different Views– Designing is an art– You cant learn– You can learn from watching it

• Designing is: – a methodological subject everyone can study– Examining existing and create new designs– A creativity

Goal of the Chapter

• Present different approaches for designing

• Learn basic concepts of designing

• Fundamental conceptual design tools

Stages of Design Process

• Feasibility stage: identifying a set of feasible concepts for the design as a whole

• Preliminary design stage: selection and development of the best concept.

• Detailed design stage: development of engineering descriptions of the concept.

• Planning stage: evaluating and altering the concept to suit the requirements of production, distribution, consumption and product retirement.

Potential Problems

• User not able to find all requirements successfully

• For complex systems process of performing first stage by individual person decreases the success ratio

• The standard approach does not directly address the situation where system design is at risk or failure

• As complexity increases or the experience of the designer is not sufficient, alternative approaches to the design process must be adopted

6

Alternative Design Strategies

• Standard– Linear model described above

• Cyclic– Process can revert to an earlier stage

• Parallel– Independent alternatives are explored in parallel

• Adaptive (“lay tracks as you go”)– The next design strategy of the design activity is decided at the end

of a given stage• Incremental

– Each stage of development is treated as a task of incrementally improving the existing design

7

Architectural Conception

• Use fundamental design tools: abstraction and modularity. – But how?

• Inspiration, where inspiration is needed. Predictable techniques elsewhere. – But where is creativity required?

• Applying own experience or experience of others.

8

The Tools of “Software Engineering 101”

• Abstraction– Abstraction(1): look at details, and abstract “up”

to concepts– Abstraction(2): choose concepts, then add

detailed substructure, and move “down”• Example: design of a stack class

• Separation of concerns

9

Abstraction and the Simple Machines

• What concepts should be chosen at the outset of a design task? – One technique: Search for a “simple machine” that serves as an

abstraction of a potential system that will perform the required task

– For instance, what kind of simple machine makes a software system embedded in a fax machine?

• At core, it is basically just a little state machine.

• Simple machines provide a plausible first conception of how an application might be built.

• Every application domain has its common simple machines.

10

Simple MachinesDomain Simple Machines

Graphics Pixel arraysTransformation matricesWidgetsAbstract depiction graphs

Word processing Structured documentsLayouts

Process control Finite state machines

Income Tax Software Hypertext SpreadsheetsForm templates

Web pages HypertextComposite documents

Scientific computing MatricesMathematical functions

Banking SpreadsheetsDatabasesTransactions

11

Separation of Concerns

• Separation of concerns is the subdivision of a problem into (hopefully) independent parts.

• The difficulties arise when the issues are either actually or apparently intertwined.

• Separations of concerns frequently involves many tradeoffs

• Total independence of concepts may not be possible.• Key example from software architecture: separation

of components (computation) from connectors (communication)

12

The Grand Tool: Refined Experience

• Experience must be reflected upon and refined.• The lessons from prior work include not only the

lessons of successes, but also the lessons arising from failure.

• Learn from success and failure of other engineers– Literature– Conferences

• Experience can provide that initial feasible set of “alternative arrangements for the design as a whole”.

13

Patterns, Styles, and DSSAs

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Domain-Specific Software Architectures

• Knowledge gained through the experience about how to structure complete application within a particular domain

• Definition: – Domain specific software architecture is a

combination of • Reference architecture• Library of reusable components for that architecture

which contains reusable chunks and• The method of reusing & configuring components to

work within that reference architecture

15

Domain-Specific Software Architectures

• A DSSA is an assemblage of software components– specialized for a particular type of task (domain),– generalized for effective use across that domain, and– composed in a standardized structure (topology) effective for

building successful applications.• Since DSSAs are specialized for a particular domain they are only of

value if one exists for the domain wherein the engineer is tasked with building a new application.

• DSSAs are the pre-eminent means for maximal reuse of knowledge and prior development and hence for developing a new architectural design.

• Example: – Buildings have same structure of floors and rooms but

interior structure differs according to customer requirement

– Every product of any company has similarities– Windows– Microsoft office applications– Facebook gamesThese similarities (reported or not) are DSSASometimes developers don’t document it but from their

previous experience its there in their mind

Domain-Specific Software Architectures

17

Architectural Patterns

• An architectural pattern is a set of architectural design decisions that are applicable to a recurring design problem, and parameterized to account for different software development contexts in which that problem appears.

• Architectural patterns are similar to DSSAs but applied “at a lower level” and within a much narrower scope.

18

State-Logic-Display: Three-Tiered Pattern

• Application Examples– Business applications – Multi-player games – Web-based applications

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

19

Model-View-Controller (MVC)

• Information manipulated by program and user interaction are made independent

• Objective: Separation between information, presentation and user interaction.

• Three elements: Model, View, Controller

MVC

Model: encapsulate information used by application

View: encapsulate information chosen and necessary for graphical display

Controller: encapsulate logic necessary for maintaining consistency between model and view

21

Model-View-Controller

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

• When a model object value changes, a notification is sent to the view and to the controller. – Thus, the view can update itself and the controller

can modify the view if its logic so requires. • Example:

– World wide web: • Browser is viewer • HTML code is controller• Web resources is model

Model-View-Controller (MVC)

Java’s swings framework

• Sometimes view and controller are merged together as they as closely related

• Example: java’s swings framework combines view and controller as they are closely related

24

Sense-Compute-Control(Sensor- controller-actuator)

Objective: Structuring embedded control applications

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

25

Example Sense-Compute-Control

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

26

Architectural Styles • An architectural style is a named collection of

architectural design decisions that:– are applicable in a given development context– constrain architectural design decisions that are specific to

a particular system within that context– elicit beneficial qualities in each resulting system …

• A primary way of characterizing lessons from experience in software system design

• Useful in determining everything from subroutine structure to top-level application structure

27

Benefits of Using Styles• Design reuse

– Well-understood solutions applied to new problems• Code reuse

– Shared implementations of invariant aspects of a style• Understandability of system organization

– A phrase such as “client-server” conveys a lot of information• Interoperability

– Supported by style standardization• Style-specific analyses

– Enabled by the constrained design space• Visualizations

– Style-specific depictions matching engineers’ mental models

Simple Styles

1. Traditional, language-influenced styles– Main program and

subroutines– Object-oriented

2. Layered – Virtual machines– Client-server

3. Data-flow styles– Batch sequential– Pipe and filter

4. Shared memory– Blackboard– Rule based

5. Interpreter– Interpreter– Mobile code

6. Implicit invocation– Event-based– Publish-subscribe

7. Peer-to-peer8. “Derived” styles

– C2– CORBA

Simple Styles

Traditional, language-influenced styles

• Styles coming from languages1. Main program & subroutines: C, fortain, pascal

or basic. Main program and subroutines are present which work as components and procedure call works as component to connect these components

2. Object oriented: world of objects. Life of object depend upon its use. The concept of Static and dynamic relationship among the objects is important to understand this type of style.

Layered

• Simple and familiar to traditional use of programming languages c or java

• Architecture is separated into ordered layers• Program within one layer can obtain services

from layer below it1. Virtual machine2. Client - Server

• Virtual machine– layer can provide services to layer above it.– Strict virtual machine, limits the access of services

only to immediately above layer– Non strict virtual machine all the above layers can

access the services– Example: Operating System, networking protocols

• User application resides at layer 1• Directory & file manipulation services resides at layer 2• Disk driver, volume management services at layer 3

Layered

• Client server– Two layered virtual machine with network

connection– Multiple mutually independent clients access

services provided by same server– Example: Bank ATM (automated teller machine)

Layered

Dataflow

• Flow or movement of data between independent processing elements

1. Batch sequential:– One of the oldest – Large problems were subdivided into smaller components

that could communicate by the transfer of magnetic tape

2. Pipe and filter– Streams of character data are passed from one filter

program to another– Filters operate concurrently

Shared State (shared memory)

• Multiple components have access to same data store and communicate through that data store

• Concept of Global variable in C can be compared with this

• In shared state style center of design attention is explicitly on these shared repositories and hence they are well ordered and carefully managed

• Types: 1. Blackboard 2. Rule-based/expert system

1. Blackboard:– Artificial intelligence application– One shared resource is present and is used and modify

by several clients– One black board used by several experts

2. Rule based/ Expert systems– Highly specialized type of shared memory– Database that contains facts and production rules– User interface component have two modes: one of

entering facts and other entering queries

Shared State (shared memory)

Interpreter

• Distinctive characteristic is dynamic and on-the-fly interpretation of commands.

• Commands are explicit statements created just before execution or encoded in human readable and editable text

• Interpretation proceeds with initial execution state, First command is executed (take user input). Execution of the first command at current state may modify state (db) and then proceeding for the next command. Execution of 1st command may affect identification of 2nd command

• Two types:1. Basic Interpreter

– Rule based style– Involves numerous primitive operations– Sounds complicated but most familiar

Interpreter

2. Mobile code– Enables code to be transmitted to remote host

for interpretation– Reasons can be:

• Lack of resources• Lack of computing power • Large data set remotely located

– Example: grid computing

Interpreter

– Mobile code can be classified as • Code on demand : state and resources are present n

downloads code from remote places• Remote evaluation: lack of resources• Mobile agent: has code and state but some of

resources are located remotely thus initiator moves to remote place

Interpreter

Implicit Invocation

• Calls invoked indirectly & implicitly as a response to the notification or an event

• Types: publish-subscribe, event based1. Event based:

• Independent components communicate solely by sending events through event-bus connectors.

• Like human body continuously receives events through the senses, react on some and ignore some events, components receives events through event bus.

• Example : financial market. Customers want to know the coast. It gets displayed on continuously

Publish-subscribed

2. Publish-subscribed: • Publisher periodically creates information and subscriber

obtains a copy or information of its existence• Simple publish-subscriber : publisher maintains a list of

subscribers to whom the procedure call is issued whenever the information is available

• Subscribers register their interest with publisher. They can also unsubscribe to remove their name from the publisher’s list

• For large scale network based programs, more sophisticated set of services is needed. For example: Advertisements. To this people can subscribe.

• Example: online job posting service

Peer to Peer

• This style consists of network of loosely coupled autonomous peers, each peer acting both as a client and a server.

• Peers communicate using network protocol• p2p decentralizes data and control unlike client and

server where it is centralized• This style is limited to network algorithm used to

query the system and the network bandwidth available

• Example: skype (chatting)

Complex Styles

• More complex styles arisen from efforts to exploit design knowledge gained from substantial experience

• Complexity reflects a) provision of greater benefits and b) specialization to certain application context

• Examples: – C2– Distributed objects

C2

• C2 means Components and Connectors• C2 grew from desire to obtain benefits from Model

view controller pattern in distributed and heterogeneous platforms

• Concepts of Layered and Event Based architectural styles were added

• It was designed to support GUI• But found beneficial in variety of applications more

beneficial for domain outside GUI than within it

Benefits of C2(1)

• Substrate independence:– Substrate means platform– It provides ease in modifying the application with

new platform– Other cases O.S and UI are coded inside the

components which makes it platform dependent• Accommodating Heterogeneity

– Components written in different and many programming languages

– Multiple varying hardware platforms

• Support for product line – Ease of substituting one component for another to achieve

similar but different application• Ability to design in model view controller style

– Very strong separation between model and user interface• Natural support for concurrent components• Support for n/w distributed applications

– Communication protocol details are kept out of the component and kept confined to connectors

• These benefits are present in simple style also but contribution of C2 is to combining appropriate styles to get coherent comprehensive approach

Benefits of C2(2)

C2 Constraints(1)

• Topology:– Application is C2 style are layered network of concurrent

components hooked by message-routing connectors– C2 depends entirely on implicit invocations there is no

direct component to connector communication– Component is connected to connector only in one way:

top of component to bottom of connector– Components to each other are also connected in same

way: top of one component to bottom of another– This maintains layered topology and hence promotes

substrate independence

• Message-based communication: – all communication between components is achieved by

exchanging messages– Message is either a request or a notification

• Message flow & substrate independence– Requests may flow only upwards in an architecture– Notification flows only in downwards in an architecture– Limited visibility results into substrate independence– Components do not know which components are

present beneath it

C2 Constraints(2)

• Interface– Each component has top and bottom domain– Top domain specifies set of notifications

component can react to and set of requests it can emits

– Bottom domain specifies set of requests to which it can respond to and set of notifications it can emits

C2 Constraints(3)

Distributed Objects

• Adaptation of several simple styles• Object oriented style provides fundamental

vocabulary• Style is developed in client server style to

provide the notion of distributed objects• For communication pipe and filter style is

adapted• Example of this style is CORBA