Introduction To Software Architecture

Introduction to Software Architecture Venu Madhava Gunda

Contents 1

Introduction .......................................................................................................................................... 3

2

Architectural Elements/principles ........................................................................................................ 3

3

Architectural Description Language ...................................................................................................... 3

4

Designing the Architecture ................................................................................................................... 4

5

Architectural view of software development ....................................................................................... 4

6

Basic Architecture Design Process ........................................................................................................ 4 6.1

Architectural View......................................................................................................................... 5

6.2

Architectural Styles/Pattern ......................................................................................................... 5

6.2.1

Pipe and Filter ....................................................................................................................... 7

6.2.2

Object Oriented Organization ............................................................................................... 7

6.2.3

Layer Architecture................................................................................................................. 8

6.2.4

Three tier Architecture.......................................................................................................... 8

6.2.5

Service Orient Architecture: ................................................................................................. 9

6.2.6

Resource Oriented Architecture ......................................................................................... 11

6.3

Difference between OOA, SOA and ROA .................................................................................... 11

1 Introduction Software architecture is an abstraction of the run time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture. Software architecture is gives the well understanding of behavior of System in abstract level. Monolithic Application (Module Architecture)

Object Oriented Approach (Classes)

Service Oriented Approach (Components)

Resource Oriented Architecture (Resources)

2 Architectural Elements/principles Architectural Elements is defined by configuration of architectural elements – components, connectors, and data constrained in their relationships in order to achieve a desired set of architectural properties. Component: An abstract unit of software instructions and internal state that provides a transformation of data via its interface. Connectors: It is an abstract mechanism that mediates communication, co ordination or co operation among components. Data: It is an element of information that is transferred from component, or received by a component, via connector.

3 Architectural Description Language It is a language used to describe the Architectural Description Languages. An ADL is a Languages that provides features for the explicit specification and modeling of a software System’s conceptual architecture, including minimum: components, component interfaces, connectors and architectural configurations. Some ADLs Darwin Unicon AADL Wright Acme xADL DAOP-ADL

4 Designing the Architecture While developing/designing architecture, we need to consider following Principles Data Architectural Interface boundaries Focus on Transactions Design the concurrency, multiplicity and channelization

5 Architectural view of software development It composed of 4 phases Pre Design Phase: The architect is concerned mostly with forming and understanding the enterprise context in which an application will exist. This is represented by a model that depicts the system as an entity within a community of other entities, such as other software systems and human users. A domain analysis Phase: The application requirements are analyzed and structured. In particular, the requirements are those around the problem domain but not specific to the domain of software itself, such as user interface or HCI-related requirements A schematic design Phase: The architect begins to develop the solution models such as identifying the modules of the system and the design rules that establish the boundaries between modules. Modules are discrete units of design work that rely on shared information and also have hidden information. A Design Development Phase: The design development phase focuses on refining the architectural description and selecting among alternative designs.

6 Basic Architecture Design Process It contains four steps Understand the problem: The first step is arguably the most crucial because it affects the quality of the design that follows. Without a clear understanding of the problem, it is not possible to create an effective solution Identify design elements and their relationships: In this step, we identify design elements and their interdependencies. In the early phases of the design project, we perform a naive functional decomposition of the application, which establishes a baseline for future design tasks and design transformation Evaluate the architecture design: This step involves assessing the architecture for conformance to architectural quality attribute requirements. The functional behavior of the application cannot be ideally tested from an architectural decomposition. However, many other quality attributes can be assessed by inspecting the design or by implementing prototypes of the architecturally significant component interactions. Transform the architecture design: This step involves the application of design operations to transform the architecture design into a new design that addresses the quality attribute

requirements better than the previous design. The phase may be repeated multiple times and even performed recursively.

6.1 Architectural View Software architecture is commonly organized in views, which are analogous to different types of blueprints made in building architecture. Views are instance of View Points, where view point exists to describe the architecture in question from the perspective of a given set of stake holders and their concerns. Kruchten defined the software architecture into a model. It is called 4+1 model. It comprises the Logical View: It is an object model of the design. Ex: UML Use Case Diagram Development View: It describes the static organization of the software in its development environment Process view: It captures the concurrency and synchronization aspects of design. Physical view: It describes the mapping of the software onto the hardware and distributed aspects.

6.2 Architectural Styles/Pattern An architectural style is a coordinated set of architectural constraints that restricts the roles/ features of a architectural elements and the allowed relationships among those elements within any architecture that conforms to that style Application is broadly divided into three categories: Standalone/Software Application Distributed Software Application

While using the Architectural Styles you have to first determine what type of application you are going to design. Here List of important Architectural Styles that everybody follows: Pipes and Filters Monolithic (Based on Modules) Object Oriented Architecture (Slightly less to Monolithic Layered Architecture (Three tier model architecture) Black Board Client – Server Service Oriented Architecture Resource Orient Architecture (REST :Representational State Transfer) Other Architectural Styles: Data Base Centric Architecture Distributed Computing Event Driver Architecture Front End and back end Implicit invocation Peer to Peer Plugins Structured (Module based) Software component Space Based architecture Shared nothing architecture Rule Evaluation

6.2.1

Pipe and Filter In a Pipe and Filter style each component has a set of inputs and a set of outputs. A component reads streams of data on its inputs and produces streams of data on its outputs, delivering a complete instance of the result in standard order.

6.2.2

Object Oriented Organization In this style data representations and their associated primitive operations are encapsulated in abstract data type or objects. Component of this model this style are objects, instance of Object types. Two important aspects of this style are 1. That an object is responsible for preserving the integrity of its representation 2. That representation is hidden from other objects.

6.2.3

Layer Architecture A layered system is organized hierarchically, each layer providing service the layer above it and serving as a client to the layer below. In these systems the components implement a virtual machine at some layer in a hierarchy.

6.2.4

Three tier Architecture Three tier architecture is a client Server architecture in which the user interface, functional process logic, computer data storage and data access are developed and maintained independent modules, most probably separate platforms (UI Layer) Presentation Tier: This is the top most level of the application. The presentation tier displays information related to such services as browsing, purchasing etc., (Middle Layer) Application Tier (Business Logic/Logic Tier): The logic tier is pulled out from the presentation tier and, as its own layer. It controls an application’s functionality by performing detailed processing. (Lowe Layer) Data Tier: This tier consists of Database Servers. Here information is stored and retrieved. This tier keeps data neutral and independent from application servers or business logic. Giving data its own tier also improves scalability and performance.

Difference between the 3 –Tier Architecture and Model View Control Architecture: 3- Tier Architecture

Model View Control Architecture Pattern Client never communicates Client communicates directly directly with the data tier with the data tier It is a linear It is Triangular 6.2.5

Service Orient Architecture: Web services are software systems designed to support interoperable machine-to-machine interaction over a network. This interoperability is gained through a set of XML-based open standards, such as WSDL (Web Services Description Language), SOAP (Simple Object access Protocol), and UDDI (Universal Description Discovery and Integration). These standards provide a common approach for defining, publishing, and using web services. SOA is an architectural style for building software applications that use services available in a network such as the web. It promotes loose coupling between software components so that they can be reused. Service Oriented Architecture as a group of services that communicate with each other. The process of communication involves either simple data passing or two or more services coordinating some activity. Intercommunication implies the need for some means of connecting two or more services each other. The World Wide Web Consortium (W3C) for example refers to SOA as 'A set of components which can be invoked, and whose interface descriptions can be published and discovered'.

The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification. SOA uses the find-bind-execute paradigm as shown in Figure 1. In this paradigm, service providers register their service in a public registry. This registry is used by consumers to find services that match certain criteria. If the registry has such a service, it provides the consumer with a contract and an endpoint address for that service.

Figure 1: SOA's Find-Bind-Execute Paradigm

SOA-based applications are distributed multi-tier applications that have presentation, business logic, and persistence layers. Services are the building blocks of SOA applications. While any functionality can be made into a service, the challenge is to define a service interface that is at the right level of abstraction. Services should provide coarse-grained functionality. Component Based Architecture: A component is a software object, meant to interact with other components, encapsulating certain functionality or a set of functionalities. A component has a clearly defined interface and conforms to a prescribed behavior common to all components within an architecture. The goal of CBA is to increase the productivity, quality, and time to market in software development Example: eBay web service.

6.2.6

Resource Oriented Architecture Now a day’s plug & Play (PNP) important role etc., plug and play of drivers, components etc., so Service Oriented operation mainly consider the service point which decides how to go. As complexity of plug and play increases it is difficult maintain by Service Point (End Point). Here it starts the Resource oriented architecture. Main focus is on Resource. Resource is anything that is important enough to be referenced as a anything in itself. A resource is something that can be stored on a computer and represented as a stream of bits, a document, a row of database, or the result of running algorithm. URI (universal Resource Identifier or Address) is a name and address of a resource. If a piece of information it is not a resource. Stateless means second request never relies on the information of first request. If second request requires the information what client got from first request it ask once again in the second request. Verbs are actions/messages that performed by the client. So, client only perform these operation. Example: MSDN, where you can access the data through the address.

6.3 Difference between OOA, SOA and ROA Attribute Granularity Main Focus

OOA Object Instance Marshalling Parameter values Addressing/ Request Routed Unique Object Focusing instance Are replies No cacheable? Application Interface Specific to this Object/Class description is middleware specific (Ex: IDL)

ROA Resource Instance Request addressing (URLs) Unique address per resource Yes

Coupling State

Loosely Coupling Stateless

SOA Service Instance Creation of request Payloads One endpoint address per service Yes

Generic to the request Specific to this service mechanism description is protocol (ex: HTTP verbs) specific (ex: WSDL) Payload / data Yes – Usually middleware No – nothing directly Yes – Part of service format description specific linked to address / description (ex: XML (ex: IDL) URL Schema in WSDL) Tightly Coupling Stateful

Loosely Coupling Stateless