A Formal Technique for Software Evolution Tanmaya Mahapatra 340959

8/12/2019 A Formal Technique for Software Evolution Tanmaya Mahapatra 340959

1/11

Summary of A Formal Technique for EvolvingHierarchically Decomposed Systems

Tanmaya Mahapatra

M.Sc Software Systems Engineering,Matriculation Number : 340959,

Rheinisch-Westf alische Technische Hochschule, [email protected]

Abstract. In this summary Software architecture, their role and evo-lution has been briey discussed. Software Evolution is a key problemfaced today. The need and importance of software evolution is discussedin detail and techniques like refactoring has also been dealt. Major prob-lems associated with evolution like loss of quality, inclusion of subsequenterrors also exist. Formal techniques of evolution, the associated theorybehind evolution has been discussed. The concepts are beautifully ex-plained with the help of an example. Lastly, evolution does not mean just changing the implementation but also i ts architecture else the archi-tecture description fails to describe faithfully the current implementationof the software.

Keywords: Software Architecture, Software Evolution, Evolving Criti-cal systems, Refactoring, Architecture description languages

1 What is Software Evolution ?Computer Software or simple software is the non-tangible aspect of a computersystem. Computer hardware is the tangible aspect of a computer system [ 2].Software can be implemented using a wide variety of programming languageslike C, C++, Java etc. They typically are geared for satisfying a single target ora specic group of targets. For example : The most popular word processors likeMicrosoft Word 1 or Writer 2 though vary greatly in their implementation gener-ally serve a similar kind of target. Due to nite nature of human intelligence itis very difficult to produce software which are bug free and have all the featuresin them so that no further updates are required to be incorporated. The Soft-ware produced today will eventually fail to cater our needs in future. ThereforeMicrosoft Word has different versions released, all updated and upgraded. Sameis the case with openOffice Writer. So to maintain the usability of a softwareproduct it has to evolve with time, adding new features or rening old features.So software evolution is a very essential and unavoidable phenomena.

1 Microsoft Word is a word processor developed by Microsoft.2 OpenOffice.org (OOo), commonly known as OpenOffice, is a discontinued open-

source office suite.


2/11

2 Tanmaya Mahapatra

2 Software Evolution & Productivity

Software Evolution and Software productivity are very closely related terms.There are numerous methods of software development but very few techniqueshave given due importance to software evolution. Software productivity has beenformally dened as : productivity = unitseffort [9]. It is very difficult to denethe term units in the context of Software Engineering. Nierstrasz(2002), hasdened units to be : functionality quality . The denotes some arithmeticaddition of the two factors. The factors of functionality and quality are laid outin the Software Requirements but productivity of a Software is not a constantfactor. Because with time the original requirements may change, the need tox existing bugs would arise and also optimizations may be desired (both of Time and Space ). Thus the functionality and quality dened in the requirementscannot bind the productivity of a Software. It has to obey [5] :

The law of continuing change A program must change with time or else itfails to cater to the changing needs.

The law of increasing complexity With evolution the number of featuresgrow as a result of which the complexity increases. With increased com-plexity the amount of effort required to keep its structure simple increasesconsiderably.

The most cost incurring phase of a Software in its life cycle is its Maintenance phase or Evolution phase . But still the various development methods availablefor developing Software do not consider Software Evolution as an importantfactor [9].

3 Software Evolution & ECSSoftware Evolution is a continuous and unavoidable process because of the chang-ing requirements [11]. Whatever modications are done to the Software, thereare chances that the evolved or modied software may lack in quality, fail tomeet some additional requirements or incur huge costs [ 10]. Critical Systemsare important backbones of businesses and any unpredictable malfunctioning ishighly catastrophic [6].They are geared for a very specic purpose and their ex-istence is of vital importance. They have very strict usage guidelines with theirsecurity features and interaction mechanisms streamlined. There is a need toevolve critical systems without loss of quality.

4 Software ArchitectureSoftware architecture is essentially collection of components that make up thesoftware [3]. The architecture also species the different behavioral propertiesof components and how one component interacts with other. Architecture canalso provide information about the properties of relation between various com-ponents [ 1]. Having architecture of a software system makes the life of all persons


3/11


4/11

4 Tanmaya Mahapatra

3. Assure that the observable behaviour of the system would remain same afterthe refactoring factors have been applied.

4. Apply the refactoring factors.5. Check the effect on overall software quality and interaction with other soft-

ware modules.

Person

check_privilege() check_privilege()

Employee Non-Employee

int id Employee Non-Employee

check_privilege()

Person

int id

Refactoring

Fig. 1. Illustration - Refactoring

In the above given example of refactoring the attribute empid has been pulledinto the super class which is a kind of structural generalization. The methodcheck previlege() has been factored and adapted accordingly. The preservanceof observable properties depends on a number of view points like system, classetc.

6 Example for Evolution6.1 Modeling Software Architectures

Generally a Software system consists of various components which are eitherphysically or logically distributed. Their data space stands separated and com-munication between such components take place via buffered, directed channels.Examples include employee database maintained by a multinational company orpower distribution system in a country etc. The components which ultimatelyform the system have explicit ports for communication with other componentsor external world. These components can be decomposed hierarchically. Detailedexplanation of this hierarchical decomposition for evolution has been explainedin the example discussed below.

6.2 Example

For demonstrating staged evolution we consider a web based application. Thedetailed consideration scenarios and the architecture of the system is discussedbelow.


5/11

A Formal Technique for Software Evolution 5

1. A web based application is used for storing highly condential client infor-mation like name, phone number, social security number etc.

2. The web application can be broadly classied into 2 components.Client side component Displays the UI 4 on the web browser running onthe clients system.

Server side component Where the information is stored in the database 5 .3. The communication between the client system and the server is typically

through an insecure communication channel. (eg. Internet)4. We want to evolve the current system to secure this ow of data while keep-

ing the observable behaviour of the system constant. The current architec-ture and the evolved architecture are depicted below and detailed discussionfollows it.

Staged Evolution In the existing architecture of the system:

1. The Data entered by user is accepted and sent to server side via an insecurechannel.

2. The Data is accepted, passed and stored in the database.

Problem We want to secure the transmitted data between the client and servermodule to maximize the security of user data.

Solution

1. We try evolving the part of the system we are currently focusing on.2. We add two modules

Encryption Module

Decryption Module3. This additional change must not alter the observable behaviour of the systemin any way or affect the existing performance and reliability of the systemdrastically.

6.3 Detailed Explanation

Step 0 Decide and Group1. Here we decide what observed behaviour will not be changed. The UI

displaying information retrieved from database or allowing user to enterpersonal data and sending to remote database for saving is the behaviourthat wont be changed.

2. The observed channels are grouped into components. Basically the chan-nel through which the data is transmitted from the client side to theserver side is to be evolved i.e. we want to enhance the level of securityoffered by the system during data transmission.

4 User Interface5 We consider that the data stored in the DB is encrypted and during retrieval process

is decrypted on the y. This feature is provided by the DB itself.


6/11

6 Tanmaya Mahapatra

Step 1 Add Necessary Components The Necessary encryption and decryptionmodules are added on both sides of the system but are not yet connected to

the main data channel. So nothing can go wrong till here.Step 2 Dene Signature and Behaviour of New Components Here we dene how

the modules would function but still they are not connected to the main datachannel.

Step 3 Connect Input & Output Channels Here the new components are addedto the main data channel but the old channel is not removed. So nothingcan go wrong as we are not using the new components till here

Step 4 Establish Invariant Between Channels Here we have to prove that theoutgoing data(from client side) K is same if it goes through old or newcommunication channel.

Outgoing Data in old communication channel : K Outgoing Data from Encryption Module : D=E(K) Outgoing Data from Decryption Module : M=Decrypt(E(K)) M should be same as K .

Similarly for incoming data(to client side) : Incoming Data from old communication channel : I Incoming Data from Encryption Module : D=E(I) Outgoing Data from Decryption Module : N=Decrypt(E(I)) N should be same as I .

Step 5 Remove unused Data Channel Once invariant is established we removethe old communication channel, now the system relies on the new way of data communication channel.

Step 6 Fold New parts into sub components The new components added arefurther classied into various sub-components.

6.4 Underlying Formalism

Here we discuss the underlying formal theory behind evolution and some of thenecessary conditions for evolution to proceed in the right context. Systematictransformations of a model is done to improve the architecture while retainingthe observable behaviour. The evolved architecture is generally a subset of theold architecture. The following verication conditions must also hold true :

The property of invariant holds. The output must be resistant to change of signature. The original and the evolved architecture must have the same observable

behaviour.

7 Role of Testing

During the entire process of so called staged evolution testing plays a very crucialrole and serves as a check point to indicate if the process is going wayward, doesnot satisfy the new requirements or there is a potential loss in overall quality of


7/11


Fig. 2. Staged Evolution Example


8/11

8 Tanmaya Mahapatra

Fig. 3. Staged Evolution Example(contd.)


9/11




10/11

10 Tanmaya Mahapatra


the software product. The structure and the observable behaviour of the systemare subjected to tests. Testing is deemed to be successful if the observationremains invariant during refactoring. The testing involves design of test casesand execution of those test cases on the test architecture to determine if invariantproperty holds.

8 Evolution & Refactoring

After careful observation of the example discussed above, we can consider thatevolution is nothing but strategic refactoring. If we can evolve the system in smallphases then evolution can be done on a larger scale too. The small transformationsteps are small, manageable & systematic. The general goals of transformationsinclude but not limited to evolutionary improvement, building abstractions etc.The Transformation calculi serves as an important tool for an evolutionary ap-proach to software development.

9 ConclusionWe have dealt with the need of software evolution and the problems arising outof it. Software evolution is an unavoidable process. The process of refactoringand an example demonstrating the staged evolution process has already beendiscussed. The formal theory behind evolution exists and in a theoretical wayevolution can be supported in a logically staged approach but the existence of


11/11


practical tools is a issue to be discussed. Can something be done about thepractical tools needed to carry out such evolution processes ?

References

1. Software architecture, wikipedia. http://en.wikipedia.org/wiki/Software_architecture .2. Software, wikipedia. http://en.wikipedia.org/wiki/Software .3. Clements, P. A survey of architecture description languages. In Proc. Intl

Workshop on Software Specication and Design (March 1996), IEEE Press, pp. 1625.

4. Fowler, e. a. Refactoring: Improving the Design of Existing Code . AddisonWesley Professional, 1999.

5. Lehman, M. M., and Belady, L. Program Evolution - Processes of Software Change . London Academic Press, 1985.

6. Lyu, M. R. Software reliability engineering: A roadmap. In FOSE (2007), L. C.Briand and A. L. Wolf, Eds., pp. 153170.

7. Mens, T., Magee, J., and Rumpe, B. Evolving software architecture descriptionsof critical systems. IEEE Computer 43 , 5 (2010), 4248.

8. Mens, T., and Tourw e, T. A survey of software refactoring. 126162.9. Nierstrasz, O. Software evolution as the key to productivity. In RISSEF (2002),

pp. 274282.10. Rajlich, V., and Bennett, K. H. A staged model for the software life cycle.

IEEE Computer 33 , 7 (2000), 6671.11. Swanson, E. B. The dimensions of maintenance. IEEE Press, pp. 492497.
http://en.wikipedia.org/wiki/Software_architecturehttp://en.wikipedia.org/wiki/Software_architecturehttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Software_architecture

A Formal Technique for Software Evolution Tanmaya Mahapatra 340959

Documents

Transcript of A Formal Technique for Software Evolution Tanmaya Mahapatra 340959