User talk:Musab132

History


When designing software for evolvability, it is important to understand which particular designs have worked in the past and which have not. The Lehman’s laws of evolution state  that  successful  software  systems  are condemned  to  change  over  time. A predominant proportion of changes are to meet ever Changing user needs. This is captured by the first law of Lehman “A program that is used in a real world environment necessarily must change or become progressively less useful in that environment”. Significant changes  also  derive  from  the  need  to  adapt  software  to interact with external entities, including people, organizations, and artificial systems. In fact, software is  infinitely  malleable  and,  therefore, it is often perceived  as  the  easiest  part  to change in a system.

Introduction


Today’s software environments provide a wide variety of tools to handle the various dimensions of software. There are tools for managing, editing, and debugging the source code. These tools, however, are not coordinated or integrated with one another and the result is that the software tends to evolve inconsistently along the different dimensions. The overall behavior of the system might have been speciﬁed initially, but there is no guarantee to the programmer that this speciﬁcation is actually followed by the code several years down the line. Test cases tend to be written and then become irrelevant to the evolving code. Coding conventions and constraints are emphasized initially, but are not necessarily checked or present in the developing system.

Development Framework


What is needed is a software development framework that supports the consistent evolution of the various dimensions of software. This framework should let the programmer specify the software along the different dimensions. It should provide tools for design, code maintenance, test case generation and support, user interface design, documentation, component speciﬁcation, behavioral descriptions, constraints. There are several approaches that can be taken to achieve consistent software evolution. The ﬁrst is to develop a comprehensive language that covers all the dimensions of software. A second involves developing a semantic representation for software development that handles all the dimensions and maintains their consistency. A third approach and the one we feel is the most practical and viable is to develop a mechanism that integrates tools for the different dimensions. For example, documentation is combined with code in Java using javadoc and its corresponding conventions. User interface design is combined with code in programming environments such as Visual Studio or Forte for Java where the user can design the interface and the system generates the code which the user never actually sees. Software has too many dimensions to combine within a single framework. Not only do the different dimensions require different notations, but they also do not interact hierarchically. Even something as simple as a design pattern can have consequences in multiple methods in multiple classes throughout a system. Moreover, the set of software dimensions is not ﬁxed. Different types of software require different speciﬁcations and designs. Rather than develop a single language that incorporates the different dimensions of software, one could develop an intermediate representation that supports a variety of tools in an integrated fashion within a software development environment. Already environments like Visual Studio provide facilities for editing source, designing user interfaces, and creating UML diagrams. A key insight in developing a mechanism for maintaining consistency is that the design and other software artifacts are simply constraints on the source code. The whole process of speciﬁcation and design can be thought of in general terms as specifying constraints on the ﬁnal solution. Any implementation of the system the satisﬁes the full range of such constraints should be an acceptable solution. This can be generalized to take into account situations where different design and speciﬁcation dimensions impose constraints on each other and even situations where the source imposes constraints on what should be included in the design.

challenges faced in software industry


The ﬁrst problem of the software industry concerns the complexity of software. While a mid-size software application twenty years ago had a few thousands or tens of thousands of lines of code, mid-size applications nowadays have tens of millions of lines of code. Even relatively simple applications, such as the familiar Microsoft Windows Paint program, consist of tens of thousands of lines of code, spread over hundreds of ﬁles, developed by tens of people over many years. These ﬁgures are orders of magnitude larger for banking, telecom, or industrial applications. Software code can be structured in many ways, e.g., as a ﬁle hierarchy; as a network of components, functions, or packages; or as a set of design patterns or aspects. No single hierarchy sufﬁces for understanding software and the inter-hierarchy relations are complex. If we add dynamic and proﬁling data to source code, the challenge of understanding software explodes.

While the second problem of the software industry is that software is continuously subject to evolution or change. The evolution of software is driven by a number of factors, including the change of requirements, technologies, platforms, and corrective and perfective maintenance (changes for removing bugs and improving functionality). Evolution of software increases its complexity. This phenomenon is described by the so-called laws of software evolution or the increase of software entropy

An industry survey organized by Grady Booch in 2005 estimates the total number of lines of code in maintenance to be around 800 billion [14]. Out of these, 30 billion lines of code are new or have to be modiﬁed every year by about 15 million software engineers. This requires a huge amount of resources. Industry studies estimate the maintenance costs to be around 80 - 90% [40] of the total software costs, and the maintenance personnel 60 -80% [21] of the total project staff

There are many possible ways to address the above challenges of the software industry, and they follow one of two main approaches:

1.	The preventive approach tries to improve the quality of a system by improving its design and the quality of the decisions taken during the development process;

2.	The assertive approach aims to facilitate the corrective, adaptive and perfective maintenance activities, and is supported by program and process understanding and fault localization tools.

Summary about laws of software evolution


1.	Continuing change

2.	Increasing complexity

3.	Self-regulation

4.	Conservation of organizational stability

5.	Conservation of familiarity

6.	Continuing growth

7.	Declining quality

8.	Feedback system

Conclusion
While maintaining the consistency of the various dimensions of software is not a panacea for making software easier to write or enabling the construction of better systems, it is a good ﬁrst step. We believe that an approach such as we have outline is needed if one wants to move beyond the narrow view of the source code being the system. Being able to view and maintain software along multiple dimensions should give developers more conﬁdence in their systems and should ensure that the resultant systems are more understandable and do what they are meant to.

References:

http://www.cs.brown.edu/~spr/research/clime/whitepaper.pdf

http://www.compaid.com/caiInternet/ezine/maintenance-canfora.pdf

http://alexandria.tue.nl/extra2/200711345.pdf