You are on page 1of 11

Summary of A Formal Technique for Evolving Hierarchically Decomposed Systems

Tanmaya Mahapatra
M.Sc Software Systems Engineering, Matriculation Number : 340959, Rheinisch-Westf alische Technische Hochschule, Aachen tanmaya.mahapatra@rwth-aachen.de

Abstract. In this summary Software architecture, their role and evolution has been briey discussed. Software Evolution is a key problem faced today. The need and importance of software evolution is discussed in detail and techniques like refactoring has also been dealt. Major problems associated with evolution like loss of quality, inclusion of subsequent errors also exist. Formal techniques of evolution, the associated theory behind evolution has been discussed. The concepts are beautifully explained with the help of an example. Lastly, evolution does not mean just changing the implementation but also its architecture else the architecture description fails to describe faithfully the current implementation of the software. Keywords: Software Architecture, Software Evolution, Evolving Critical systems, Refactoring, Architecture description languages

What is Software Evolution ?

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

Microsoft Word is a word processor developed by Microsoft. OpenOce.org (OOo), commonly known as OpenOce, is a discontinued opensource oce suite.

Tanmaya Mahapatra

Software Evolution & Productivity

Software Evolution and Software productivity are very closely related terms. There are numerous methods of software development but very few techniques have given due importance to software evolution. Software productivity has been units formally dened as : productivity = ef f ort [9]. It is very dicult to dene the term units in the context of Software Engineering. Nierstrasz(2002), has dened units to be : f unctionality quality . The denotes some arithmetic addition of the two factors. The factors of functionality and quality are laid out in the Software Requirements but productivity of a Software is not a constant factor. Because with time the original requirements may change, the need to x existing bugs would arise and also optimizations may be desired (both of Time and Space ). Thus the functionality and quality dened in the requirements cannot bind the productivity of a Software. It has to obey [5] : The law of continuing change A program must change with time or else it fails to cater to the changing needs. The law of increasing complexity With evolution the number of features grow as a result of which the complexity increases. With increased complexity the amount of eort required to keep its structure simple increases considerably. 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 available for developing Software do not consider Software Evolution as an important factor [9].

Software Evolution & ECS

Software Evolution is a continuous and unavoidable process because of the changing requirements [11]. Whatever modications are done to the Software, there are chances that the evolved or modied software may lack in quality, fail to meet some additional requirements or incur huge costs [10]. Critical Systems are important backbones of businesses and any unpredictable malfunctioning is highly catastrophic [6].They are geared for a very specic purpose and their existence is of vital importance. They have very strict usage guidelines with their security features and interaction mechanisms streamlined. There is a need to evolve critical systems without loss of quality.

Software Architecture

Software architecture is essentially collection of components that make up the software [3]. The architecture also species the dierent behavioral properties of components and how one component interacts with other. Architecture can also provide information about the properties of relation between various components [1]. Having architecture of a software system makes the life of all persons

A Formal Technique for Software Evolution

including developers, managers and senior management easy who are involved with the product. Generally architectures are depicted pictorially. So when we model the software architecture we generally show the components with their dierent ports, the communication channels etc. The entire architecture of the software system can be decomposed hierarchically. But the relation between architecture and ADL3 is rather complicated. A software architecture can provide functional and non-functional information about a software system [7]. 4.1 Architecture Description Languages

Architecture description languages are used to represent the architecture of a software system [3]. It is a formal approach for the same. Software architecture plays a crucial role in the development and maintenance of a critical software intensive system. The relation between architecture description and implementation should be well dened for easy maintenance of a critical software [7]. The architecture description and the software itself should evolve simultaneously. Any changes committed to one must be reected in the other. This is very important for ECS else the architecture description fails to describe faithfully the current implementation of the software with the passage of time [7]. Evolving the software architecture is a big challenge and unfortunately it is unavoidable. There are two ways to integrate changes with the current system without compromising on quality [7] : 1. By analyzing and verifying the resulting architectural description after the changes. 2. By analyzing the initial architectural description together with the delta or increment applied to it to make the changes.

Refactoring

As a software evolves, the level of complexity of software increases. The technique used to tackle this increasing level of complexity, while continuously improving the internal quality is called restructuring. In the world of object oriented software development it is called as refactoring. Refactoring is a technique to improve the internal structure of a system while preserving the observable properties of the system [4].Constant refactoring is a pre requisite for eective Software evolution. Refactoring is used to improve the quality of the software like extensibility, modularity, reusability, complexity, maintainability, eciency etc. [8]. The process of refactoring can be summarized as follows [8] : 1. Identify the spots where the software needs to be refactored. 2. Determine what refactoring factors should be applied.
3

Architecture Description Languages

Tanmaya Mahapatra

3. Assure that the observable behaviour of the system would remain same after the refactoring factors have been applied. 4. Apply the refactoring factors. 5. Check the eect on overall software quality and interaction with other software modules.

Person

Person check_privilege() int id

Refactoring

Employee check_privilege() int id

Non-Employee check_privilege() Employee Non-Employee

Fig. 1. Illustration - Refactoring

In the above given example of refactoring the attribute empid has been pulled into the super class which is a kind of structural generalization. The method check previlege() has been factored and adapted accordingly. The preservance of observable properties depends on a number of view points like system, class etc.

6
6.1

Example for Evolution


Modeling Software Architectures

Generally a Software system consists of various components which are either physically or logically distributed. Their data space stands separated and communication between such components take place via buered, directed channels. Examples include employee database maintained by a multinational company or power distribution system in a country etc. The components which ultimately form the system have explicit ports for communication with other components or external world. These components can be decomposed hierarchically. Detailed explanation of this hierarchical decomposition for evolution has been explained in the example discussed below. 6.2 Example

For demonstrating staged evolution we consider a web based application. The detailed consideration scenarios and the architecture of the system is discussed below.

A Formal Technique for Software Evolution

1. A web based application is used for storing highly condential client information like name, phone number, social security number etc. 2. The web application can be broadly classied into 2 components. Client side component Displays the UI4 on the web browser running on the clients system. Server side component Where the information is stored in the database5 . 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 keeping the observable behaviour of the system constant. The current architecture and the evolved architecture are depicted below and detailed discussion follows 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 insecure channel. 2. The Data is accepted, passed and stored in the database. Problem We want to secure the transmitted data between the client and server module 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 Module 3. This additional change must not alter the observable behaviour of the system in any way or aect the existing performance and reliability of the system drastically. 6.3 Detailed Explanation

Step 0 Decide and Group 1. Here we decide what observed behaviour will not be changed. The UI displaying information retrieved from database or allowing user to enter personal data and sending to remote database for saving is the behaviour that wont be changed. 2. The observed channels are grouped into components. Basically the channel through which the data is transmitted from the client side to the server side is to be evolved i.e. we want to enhance the level of security oered by the system during data transmission.
4 5

User Interface 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.

Tanmaya Mahapatra

Step 1 Add Necessary Components The Necessary encryption and decryption modules 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 data channel. Step 3 Connect Input & Output Channels Here the new components are added to the main data channel but the old channel is not removed. So nothing can go wrong as we are not using the new components till here Step 4 Establish Invariant Between Channels Here we have to prove that the outgoing data(from client side) K is same if it goes through old or new communication 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 remove the 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 are further classied into various sub-components. 6.4 Underlying Formalism

Here we discuss the underlying formal theory behind evolution and some of the necessary conditions for evolution to proceed in the right context. Systematic transformations of a model is done to improve the architecture while retaining the observable behaviour. The evolved architecture is generally a subset of the old 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.

Role of Testing

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

A Formal Technique for Software Evolution

Insecure Communication Channel

Processing Module User Interface Client Side Server Side Present System Architecture Database

Insecure Communication Channel

Processing Module User Interface Client Side Server Side Step 0: Decide and Group Database

Insecure Communication Channel

Processing Module User Interface Client Side Server Side Database

Encryption Module

Decryption Module

Decryption Module

Encryption Module

Step 1: Add Necessary Components

Fig. 2. Staged Evolution Example

Tanmaya Mahapatra

Insecure Communication Channel

Processing Module User Interface Client Side Server Side Database

Encryption Module

Decryption Module

Decryption Module

Encryption Module

Step 2: Define Signature and Behaviour of New Components

Insecure Communication Channel

Processing Module User Interface Client Side


Input Output

Database Server Side


Output Input

Encryption Module

Decryption Module

Decryption Module

Encryption Module

Step 3: Connect Input & Output Channels

Fig. 3. Staged Evolution Example(contd.)

A Formal Technique for Software Evolution

Outgoing Data = K Incoming Data = I

Insecure Communication Channel

Processing Module User Interface Client Side


Input Data = K Data = Decrypt(E(I)) = N Output

Database
Incoming Data = I

Server Side
Output Input

Data = Decrypt(E(K)) = M

Encryption Module

Decryption Module

Decryption Module

Encryption Module

Data = E(K)

Data = E(I)

Step 4: Establish Invariant Between Channels

Outgoing Data = K Incoming Data = I

Processing Module User Interface Client Side


Input Data = K Data = Decrypt(E(I)) = N Output

Database
Incoming Data = I

Server Side
Output Input

Data = Decrypt(E(K)) = M

Encryption Module

Decryption Module

Decryption Module

Encryption Module

Data = E(K)

Data = E(I)

Step 5: Remove unused Data Channel

Fig. 4. Staged Evolution Example(contd.)

10

Tanmaya Mahapatra
Outgoing Data = K Incoming Data = I

Processing Module User Interface Client Side


Input Data = K Data = Decrypt(E(I)) = N Output

Database
Incoming Data = I

Server Side
Output Input

Data = Decrypt(E(K)) = M

Encryption Module

Decryption Module

Decryption Module

Encryption Module

Data = E(K)

Data = E(I)

Step 6: Fold New parts into sub components

Fig. 5. Staged Evolution Example(contd.)

the software product. The structure and the observable behaviour of the system are subjected to tests. Testing is deemed to be successful if the observation remains invariant during refactoring. The testing involves design of test cases and execution of those test cases on the test architecture to determine if invariant property holds.

Evolution & Refactoring

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

Conclusion

We have dealt with the need of software evolution and the problems arising out of it. Software evolution is an unavoidable process. The process of refactoring and an example demonstrating the staged evolution process has already been discussed. The formal theory behind evolution exists and in a theoretical way evolution can be supported in a logically staged approach but the existence of

A Formal Technique for Software Evolution

11

practical tools is a issue to be discussed. Can something be done about the practical 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. 16 25. 4. Fowler, e. a. Refactoring: Improving the Design of Existing Code. Addison Wesley 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 descriptions of critical systems. IEEE Computer 43, 5 (2010), 4248. , T. A survey of software refactoring. 126162. 8. Mens, T., and Tourwe 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.

You might also like