Implementation Chapter 6. Introduction Implementation one of the most important phase of software...

Implementation

Chapter 6

Introduction

• Implementation one of the most important phase of software development, it can not be optional

• For better quality system has to be implemented from its architecture

• In terms of implementation architecture is prescriptive as well as restrictive

• Mapping the architecture is one of the problem• Concepts mentioned or defined at the architectural

level should be directly connected to the artifacts at implementation level

• Absence of proper mapping results in architectural degradation

• Gradually by one decision at a time the implementation of system deviates from architecture

• This architectural drift if not taken care of results into architectural erosion

• Degradation makes software harder to understand and difficult to retain its quality

• Proper implementation requires a well formed understanding of how the concepts in the architecture will be mapped onto implementation technology

Introduction

Mapping Problem

• Specifically mapping design decision to a particular implementation construct that understand those decisions is difficult

• Choosing how to create and maintain this mapping is critical in architecture based development

• Mapping is a form of traceability• Several concepts and design decisions are

mapped in implementation

• Component and connectors:– Design decisions about components and connectors partition

the application functionality in computation and communication– Programming environments provide mechanisms like packages,

libraries or classes– These mechanisms are used to partition functionality in

implementation– Challenge is to maintain the mapping between the partitions

established by the components and connectors at architectural level and packages, libraries and classes at implementation level

– improper mapping may result in architectural degradation

Mapping Problem

• Interface:– interfaces can be specified in many different ways– If the are specified in the way similar to syntax of

methods or procedure calls then it is easy to mapping them in implementation

– If they are defined using protocols or state transitions then it becomes difficult and needs greater efforts for mapping and implementation

Mapping Problem

• Configuration: – Configurations are mapped using graphs– Nodes represent components and edges represents

connectors– Same topology need to be mapped

• Design Rationale: – Rationale has no specific mapping as it is does not

directly influence the functionality of the application– Best way is using comments written in code

Mapping Problem

• Dynamic properties (Behavior):– Some behavior properties can be directly

translated into implementation skeleton or complete implementation

– Formal behavior specification often lack bindings to programming language level construct

– Which becomes difficult to determine if the behavioral specifications are actually implemented correctly or not

Mapping Problem

• Non functional properties:– Implementing non functional properties is the

most difficult task– Properties need to be achieved from the behavior

of the system– This difficulty is the reason why NFPs are

combined with functional properties whenever possible

Mapping Problem

One Way And Round Trip Mapping

• Architecture and implementation should co-relate with each other

• If any change in requirements or specification occurs, then architecture changes

• As a result implementation should change• If anything changes at implementation phase,

that should reflect in the architecture too• This is descriptive architecture of the system

• Decision can be made, whenever any change appears, either in requirements and specification or in implementation, it should be first done in architecture

• Once the change is noted in architecture then using tools or manually it should be mapped in implementation

• This is one way mapping• Another option is to allow changes to be initiated in

either the architecture or the implementation• This is two way mapping


• Two way mapping is better to detect and resolve architectural drift and erosion

• But they are expensive and complex to create and maintain

• This is also known as Round Trip Mapping problem as changes have to be mapped from architecture to implementation and back again


• When developing any system, ideal approach is to define the architecture first and then select implementation technologies that most closely matches the needs

• Implementation technologies can be programming language, libraries, operating system and so on

• This ideal is difficult to achieve• Selection of implementation technologies are often

driven by factors like cost, size, platform support etc.

Implementation Framework


• Important strategy to build the gap between concepts in an architecture and a system’s implementation technologies is to use architectural implementation framework

• Definition: An Architectural implementation framework is a piece of software that acts as a bridge between particular architectural style and a set of implementation technologies. It provides key elements of the architectural style in code, in a way that assists developers in implementing systems that conform to the prescriptions and constraints of the style

• Frameworks is a set of predefined software building blocks that programmers can use, extend or customize to suit their application.

• It is an object oriented reuse mechanism • It describes interfaces and flow of control• Because of frameworks, developers don’t have to start

from scratch• They help developers in conforming to a particular

architectural style while implementation, however they don’t bind them from not going outside the constraints of architectural style


• Most common example is I/O library in UNIX or in similar operating system

• This is a bridge between the pipe and filter architectural style and procedural, non concurrent programming language like C

• Developer can make use of present I/O libraries or can read data from disk files by ignoring library

• Framework is just a helping hand• Without implementation framework it is possible to develop

applications in any style• Developers at the end comes up with set of software

libraries and tools those are like framework


• Single architectural style can be supported by a number of different alternative frameworks

• Reasons can be many like, Different programming languages and different implementation platforms require different framework e.g. java, c, c++ uses different frameworks (java uses java.io.package, c uses stdio.h, c++ uses iostream) but uses same pipe and filter style

• Evaluating which framework is suitable for the architecture or architectural style is very important

• Evaluation of framework can be done based on different factors


• Platform support: – Architecture framework brings 3 things together:

architectural style, programming language and an operating system

– One of the most basic criteria is platform support– Once the architectural style is identified then for the target

combination of programming language and operating system, framework availability can be identified

– If project has freedom for platform then first framework will be selected and then suitable platform

– This is becoming increasingly rare, as software systems are more and more likely to run on existing platform

Evaluating Framework

• Fidelity:– Fidelity is quality of being accurate in producing whatever it

is aimed to produce– This is one of the important quality for architectural

framework, specifically fidelity to target architectural style– Identify the proper degree of involvement– To be useful, framework do not provide direct

implementation support for every single decision in target style

– Framework makes it easy for implementers to follow the constraint but don’t restrict them from breaking those constraints


• Matching Assumption: – Architectural style puts on some constraints on

application and similarly framework do the same– Ideally these constraints should be same– Style usually leave many aspects of the system

unconstrained and framework due to responsibility of supporting the concrete implementation puts additional constraints on application

– Problem occurs when assumption of framework conflicts with assumption of other implementation technologies


• Example of mismatch in assumptions: – OO programming language is supported by framework which

might require that every component have a main class that is derived from a base class provided by framework

– Project includes several GUI elements, and the GUI toolkit requires that GUI element classes extend base class provided by toolkit

– Base class have to be derived from 2 things base class provided by toolkit and by framework

– If programming language does not support multiple inheritance (java) then there is a serious mismatch

– Thus when valuating the framework it is important to identify the assumptions and compare these with other assumptions made by libraries, toolkit and environment


• Efficiency:– Framework is basically a building block between

the architecture and implementation– We are adding one new layer in the scenario– Whenever a new layer is added there always is a

danger about the efficiency getting decreased– So before committing to a framework it is useful

to run it as a sample with dummy values to test the efficiency


Evaluating Frameworks (cont’d)

• Other quality considerations– Nearly every other software quality can affect framework

evaluation and selection• Size• Cost• Ease of use• Reliability• Robustness• Availability of source code• Portability• Long-term maintainability and support

23

Middleware, Component Model and Application Frameworks

• Spectrum of technologies exists to integrate software components and provide services above and beyond those provided by the given programming language/ operating system

• These technologies go by different names middleware, implementation frameworks, component models etc. We will refer them middleware in general

• Popular examples: CORBA, COM/DCOM/COM+, java message service, various web services technologies

• There are many similarities between middleware and application framework

• Both provide implementation services to the developer that are not available in programming language or operating system

• Frameworks are forms of middleware but there is a subtle difference in how they emerge and develop– Middleware generally evolves based on a set of services

that the developers want to have available– Frameworks generally evolve based on a particular

architectural style that developers want to use


• By focusing on services, middleware developers often make other decisions that substantially impact architecture

• In this sense, middleware can induce an architecture or architectural style– CORBA induces the ‘distributed objects’ style– JMS induces a distributed implicit invocation style

• If developer choose distributed objects style then CORBA middleware might serve as an ideal architecture framework

• But it is not that simple


• Middleware can include style • Major conflicts can arise between architectural styles and

middleware:1. The architectural style chosen for the application does not

match that caused by the middleware chosen2. The application designers choose a middleware first based

on services provided and let this have an inappropriate influence over the architectural style of application

• Allowing the middleware to influence the architecture is backward

• Architecture should influence choice of middleware


Resolving Mismatches

• When there is a mismatch between architectural style and middleware several options are available:

• Change the style: – change the architectural style to which is suitable

to the middleware. – This is done only in case when middleware is so

advantageous that we can afford going backward and afford the cost of changing style

• Change the middleware: – Middleware can be change to better fit the architectural

style– This is also not easy as middleware packages are often

large and complex• Develop a glue code: – Architectural framework can be built on top of

middleware, giving advantages to the parts of middleware that match and working on part that do not match

– This way neither the style nor middleware has to change


• Ignore unneeded middleware services:– Ignore the services which are not compatible with style – Use subset of these services selectively

• Hide the middleware– Developers use middleware because it provides certain

services– If these services can be applied at specific points in the

architecture then it may be possible to hide the middleware inside individual component and connector

– Example CORBA is used for communication in heterogeneous components running on different hosts only. Other places it is hidden and not in use


• Some circumstances motivate the development of a new architectural framework like:– Architectural style in use is novel– Style being implemented on platform for which no framework

available– For style and platform the existing frameworks are not adequate

• Task of developing architectural framework can not be approached lightly

• This impact on many parts of the application and can become a reason make-or-break that part

• Intensive care has to be taken while developing it

Building A New Framework

• Developing a framework requires all those things which are require to develop any other application

• Gathering requirements, design, input from stakeholders, quality evaluation and so on

• There are however some additional guidelines that can be applied specifically to framework development


• Have a good understanding of a style: – Incomplete understanding of style results into a

inappropriate framework – No measure present to calculate the fidelity of the

framework towards style– Clear concise set of rules and constraints of

architectural style should be developed before framework design begins


• Limit the framework to the issues addressed in the architectural style:– Including application specific features that are not

part of style in a framework, limits reusability of the framework

– This also blurs the line between what is part of framework and what is part of application


• Choose the scope of framework:– A framework does not necessarily have to

implement all possible stylistic advantages– Frameworks are reusable assets – Developers must decide how it is going to be

reusable in future to properly scope its capabilities

35


• Avoid over-engineering– Don’t add capabilities simply because they are

clever or “cool”, especially if known target applications won’t use them

– Additional capabilities can involve additional layer – Increases level of abstraction– These add complexity and reduce its usability and

performance

36


• Limit overhead for application developers: – Every framework puts additional burden on

implementation to include standard code in components, implement standard behavior etc.

– This burden on implementers make the framework difficult to handle and less acceptable

– Limiting additional obligations can control this


• Develop a strategy for legacy & off the shelf resources:– Almost any application is bound to include

elements like component, connectors, middleware etc. that were not developed with the framework in mind

– The external resources that might be incorporated in applications should be strongly considered

– Establish strategies for integrating these resources to distribute the framework


Concurrency

• System in past were design to run on single computer with single processor

• Today every individual computer have multi-core and multithread processors

• Concurrency plays vital role, which can be implemented with variety of technologies

• Most architectural styles have some notation of concurrency• Many implementation frameworks and middleware have

concurrency management as their primary features• Research is going on to wrap the support for concurrency in

architectural framework

Existing Frameworks

• Framework for the pipe and filter architectural style:– The standard I/O framework– The java.io.framework

• Framework for C2 architectural style:– The Lightweight C2 framework– The Flexible C2 framework

Evaluating stdio

• Platform support– Available with most, if not

all, implementations of C programming language

– Operates somewhat differently on OSes with no concurrency (e.g., MS-DOS)

• Fidelity– Good support for

developing P&F applications, but no restriction that apps have to use this style

• Matching assumptions– Filters are processes and

pipes are implicit. In-process P&F applications might require modifications

• Efficiency– Whether filters make

maximal use of concurrency is partially up to filter implementations and partially up to the OS

41

Evaluating java.io• Platform support

– Available with all Java implementations on many platforms

– Platform-specific differences abstracted away

• Fidelity– Good support for developing

P&F applications, but no restriction that apps have to use this style

• Matching assumptions– Easy to construct intra- and

inter-process P&F applications

– Concurrency can be an issue; many calls are blocking

• Efficiency– Users have fine-grained

control over, e.g., buffering– Very high efficiency

mechanisms (memory mapped I/O, channels) not available (but are in java.nio)

42

Evaluating Lightweight C2 Framework

• Platform support– Available with all Java

implementations on many platforms

• Fidelity– Assists developers with

many aspects of C2 but does not enforce these constraints

– Leaves threading and queuing policies up to individual elements

• Matching assumptions– Comp/conn main classes

must inherit from distinguished base classes

– All messages must be in dictionary form

• Efficiency– Lightweight framework;

efficiency may depend on threading and queuing policy implemented by individual elements

43

Evaluating Flexible C2 Framework

• Platform support– Available with all Java

implementations on many platforms

• Fidelity– Assists developers with

many aspects of C2 but does not enforce these constraints

– Provides several alternative application-wide threading and queuing policies

• Matching assumptions– Comp/conn main classes

must implement distinguished interfaces

– Messages can be any serializable object

• Efficiency– User can easily swap out

and tune threading and queuing policies without disturbing remainder of application code

44

Implementation Chapter 6. Introduction Implementation one of the most important phase of software...

Documents

Transcript of Implementation Chapter 6. Introduction Implementation one of the most important phase of software...