Abstract
Software Engineering as a discipline has seen numerous changes. From Waterfall model to Agile, dramatic changes have occurred over time. Over the past few years, the most significant developments in Software Engineering have been the emergence of UML as a standard for the description and development of Object Oriented systems and the wider acceptance and employment of Agile Development methodologies like XP.
Not all techniques can be applied across situations. One very important aspect to be considered in any software engineering activity is the understanding and application of basic fundamentals and principles. Without these, the application of any technique will be highly localized and limited in nature. We propose a framework which, while retaining the essence of software engineering principles, will cater and adapt to emerging techniques. The framework does not neglect nor overemphasize any concern but rather provides a sound ground to build software that can be maintained easily over the course of its lifetime. This paper will discuss the framework and its application, the new techniques that are currently being employed, the merits and demerits of some of the new techniques and what needs to be kept in mind to avoid pitfalls during the employment of these techniques in projects.
Introduction
Engineering disciplines rely on fundamental principles to solve complex problems associated with activities in their respective areas. Software Engineering should be no different. A recent trend among the software community is to forego these principles and rely on other practices to achieve goals. The goals of present day activities are largely defined by economic factors. Such an approach not only impacts the quality of the final product, but also influences the software community attitude towards following these principles. Under the current circumstances, we propose an approach which is a healthy mixture of technology and principles. The approach was applied on multiple live projects and was found to be highly effective.
Defining Software Engineering
There are numerous definitions for Software Engineering. We note down three definitions that are sufficient to define it thoroughly.
The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and works on real machines [1].
(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1) [2]
Software engineering is the technological and managerial discipline concerned with systematic production and maintenance of software products that are developed and modified on time and within cost estimates [3]
Guiding Principles
The definitions above lay emphasis on a) Usage of an Established Engineering Principle which is b) Quantifiable and can be applied to c) Develop, Operate & Maintain software d) Economically by managing time and cost. These aspects form the guiding principles of the framework.
As with all engineering practices, software engineering comprises of a set of three key elements – Methods, Tools and Procedures [4]. Methods define the technical “how to” for building software. Tools enable the automation of Methods while Procedures define the processes that hold Methods and Tools together to build software that adhere to the guiding principles described above. Although the above classification is not new, it is surprising to note that the increased concentration on economic factors affecting software has provided practitioners with seemingly justifiable excuses to ignore these elements.
Motivation
Although the ultimate goals of development methodologies like XP are in alignment with the basic principles, their lack of endorsement of the application of automation techniques and impuissant focus on design, incapacitate their effectiveness in building large reliable software.
On the other hand, pure engineering approaches, which rely on the volume and levels of detailing and are applied for building large systems, suffer from time and cost implications.
Another important aspect that has been neglected is the representation of business processes and the relationship to their implementations in technology. Today, the construction of large systems is driven by technology rather than by business.
Taking all of the above into consideration, we have arrived at the conclusion that a healthy mixture of lightweight and heavyweight processes, utilized in a structured and defined manner adequately addresses the problem.
Approach
Our extensive research on software engineering methods, tools and procedures enabled us to arrive at four fundamental concepts which need to be considered during any software engineering activity:
- Abstract
- Automate
- Manage
- Reuse
1. Abstract
It is not difficult to understand how abstraction plays a key role in software engineering. Quantitative measure of the complexity of software can be used to gauge the level of its abstraction by inspecting the implementing language. Halstead’s theory of software science [5] can be used to arrive at such a measure. Software science assigns quantitative laws to the development of software. Although the computational model is not sufficient to compute the complexity of software, it has been experimentally proved [6] that abstractions tend to reduce effort required to create complex programs. Methodologies like OOD provide for data and functional abstractions of real-world domains [7]. Using standards like BPMN & UML, the creation of models help in the better understanding of the software system under development [8].
In the represented framework, all abstractions are achieved through visual representations. By default, visual models abstract a lot of information through predefined representations. Thus, in our proposed framework, visual models play a vital role. The representation standards vary depending upon the nature of the model and the area which it addresses.
2. Automate
The automation of Software Engineering Methods helps to eliminate redundancy in the activities involved. Every engineering discipline has gained significantly from automation. Only in the discipline of Software Engineering has there been no significant progress in the recent past. The early 1990’s saw the introduction of CASE tools. By 2000, they were virtually non existent. One of the most relevant factors that led to the early demise of these tools was the lack of a de facto standard. Today, the standards are available but the takers are few. The over emphasis on writing code is so prevalent that there is outright rejection of automation techniques even if they are based on standards.
Our framework relies extensively on automation. For this, we have identified areas which can be automated without compromising the flexibility available by employing manual means.
3. Manage
Although abstraction and automation play crucial roles the engineering process, the management of methods, tools and procedures through easily comprehensible standard representations is essential for knowledge retention and reapplication. In our framework, our primary concern will be the management of knowledge related to the software being built. For this purpose, the framework warrants the use of models to represent the software, methods that allow the models to be built, tools that allow the models to be created & managed and procedures that will enable the activity to be economically feasible without compromising quality.
It is worthwhile to note that the creation of too many models or a single model does not provide a complete solution. Every non trivial system is best approached through a small set of nearly independent models [8]. Moreover, resigning to managing models rather than code will provide for better productivity (refer to benefits of abstraction).
4. Reuse
Reusability is not a new term. But the level at which reuse is utilized is where the problems lie. Componentization has enabled abstraction of complexity and provided for wide scale reuse. However, one of the greatest drawbacks of software components is their intricate relationship with the platforms for which they have been built.
The framework we propose takes reuse to a higher level of abstraction - design. Enabling the free and unbiased reuse of platform independent designs help in the creation of better software systems faster.
Framework
As mentioned in (5), abstraction and automation form the basis for the framework. As such each element in the framework exhibits the ability to adhere to either one or both of the concepts.
The framework components are organized according to the different phases in a classical software development process. The different phases themselves have not changed much to date, only the extent to which they are applied and their utilization sequence has.
Analysis
Analysis (Requirements Analysis as is often called) is often referred to as an engineering practice that bridges the gap between system engineering and software design [4]. Our understanding is slightly different from the above. We define Analysis as the engineering practice that links a business need to its implementation in software. There are significant differences between system functionality and business processes. We shall not go into that in this paper.
Requirements Analysis in our framework involves the identification, elaboration and representation of business process, both from a business perspective and a system level implementation perspective. These perspectives can be represented very clearly using Business Process Models and Use Case Models.
Any project, be it development, maintenance or enhancement, require adequate representations of the business processes available in a standard and easily comprehensible format. Although there is no universal format which can be applied to represent business processes, we have found out that the BPMN 1.0 specifications from BPMI.org to be of practical use. Our framework proposes the use of this standard for all business process representations.
In order to represent the business processes from a software perspective, UML Use Cases are an ideal candidate. A prevalent thought among practitioners is that properly defined use cases are all that is required to define a software system. We believe that UML Use Cases are central to modeling the behavior of a system from a technology point of view [8].
In the proposed framework, Use Cases shall be defined from to different perspectives and two different levels of granularity. The two different perspectives are 1) Object Decomposed Use Cases and 2) Function Decomposed Use Cases. The two different levels at which Use Cases are defined are 1) Macro Use Cases 2) Micro Use Cases. The relationship between these two perspectives from a usage point of view is available for reference in Appendix A.
In our framework, we propose to represent both Object decomposed as well as Functional decomposed use cases. From our experience, we have come to the conclusion that Functional decomposed use cases help in detailing and identifying behavioral aspects of the system while Object decomposed use cases help in the realization of Use Cases as objects (Controllers, in software terms) that participate in the software.
Traceability of relations between these Use Cases needs to be managed using tools. Note that it is not necessary to completely specify the business requirements and create all models in order to move over to the next phase. The objective is to do only as much as required. An example of this can be seen in the figure represented in appendix B which is an adaptation of the framework for Agile development.
Besides Business Process Models and Use Case Models, Interaction diagrams that depict the relationships of different components like Controller Objects and Boundary Objects are also helpful.
Design
Design can be defined as the process of applying various techniques and principles for the purpose of defining a device, a process or a system in sufficient detail to permit its physical realization [10]. From a software point of view, design can be defined as the stage of a system that describes how the system will be implemented at a logical level above code [9].
The above definitions stress on the fact that designs should be defined only in sufficient detail so as to enable the realization of the system. We do not mean to say that design is only limited to the above. However, this is an important observation. In the proposed framework, we utilize a variety of models to represent the software system under consideration (refer to appendix A). Moreover, the design of the system is directed in such a way as to enable the construction of compilable source code. Tools should be able to consume designs and generate source code.
The framework influences practitioners to build platform independent models during design. The capability of the framework to abstract platform dependencies during design stage helps practitioners focus on business requirements.
Reusability of designs can be easily achieved in the framework. Again, tools with the capability to enable this are required. The framework broadly divides reusable designs into a number of logical components 1) Foundation Libraries 2) BluePrints and
3) Solution Patterns. Foundation libraries are platform independent design libraries which are generic in nature with regards to their functionality. BluePrints on the other hand are function specific design components. Solution Patterns address end-to-end business requirements and can be customized to meet specific requirements.
It is to be noted that the design activity phase in our proposed framework consumes more effort than in traditional approaches. This is due to the increased focus on building complete designs during this phase. By complete- we mean designs with embedded abstractions of application logic expressed in a high level language compliant with UML Action Semantics.
Construction
The construction of software is one of the most critical and widely performed activities today. Development methodologies like Agile are proponents of approaches with detailed focus on construction. In our framework, construction does not assume the same amount of importance. This is because of the fact that most of the construction activity is automated in nature. As mentioned in 6.2, the framework warrants the need to create complete designs. Thus, using appropriate tools, it is possible to create complete source code for a system.
The majority of the activity during construction involves the mapping of platform independent models to platform dependent models.
The approach to design from a platform independent perspective enables the construction of software for multiple platforms and languages with relative ease. Thus from a single source (the design models) we can have multiple target implementations without extra effort. This has been found to be of great importance to those who wish to create software systems that need to be deployed on multiple environments.
Test
The benefits of automated construction directly affect testing. Functional adherence is managed by the strong cohesion rules put forward by the framework while semantic errors are eliminated by the automated code generators. The facility to create profiles and integrate software test components into the design eases test cycles.
Adaptation
The flexibility of the framework makes it ideal for adapting to different methodologies like RUP, XP etc. although with a slight shift in focus. We have leveraged the framework to develop large software systems using these different methodologies.
Critical Success factors
Successful implementations of the framework have consistently relied on the following a) The availability of tools b) Knowledge of the framework, UML and its application c) Experience of the user with respect to design and architecture of systems. The above mentioned attributes affect the success of any project implemented using the framework.
Conclusions and Future Work
From our experience in implementing this framework, we draw the following conclusions. 1) Too much or too little detailing are both harmful 2) Design as a key element is imperative, 3) Tools should be utilized to automate software engineering as much as possible 4) Abstractions and reuse is key to reducing time and cost 5) Focus on business is required to build a functionally complete system.
Currently we are in the process of enabling simulation of models. This will eliminate the need to deploy systems for testing as well as help users identify system bottlenecks and other errors during the design stage itself.
References
[1]Bauer, F. L., Software Engineering. Information Processing 71, 1972.
[2]IEEE Std 610-1990
[3]Fairley, R., Software Engineering Concepts. New York: McGraw-Hill, 1985.
[4]Pressman, R. S., Software Engineering-A Practitioners Approach, McGraw-Hill, 1992.
[5]Halstead, M., Elements of Software Science, North Holland, 1977.
[6]Waguespack, L. J., and S. Badlani, “Software Complexity Assessment: An Introduction and Annotated Bibliography”, ACM Software Engineering Notes, vol. 12, no. 4, October 1987, pp. 52-71.
[7]Wiener, R., and R. Sincovec, Software Engineering with Modula-2 and Ada, Wiley, 1984, pp. 129.
[8]Booch, G., Rumbaugh, J., and I. Jacobson, The Unified Modeling Language User Guide, Addison Wesley, 1999.
[9]Booch, G., Rumbaugh, J., and I. Jacobson, The Unified Modeling Language Reference Manual, Addison Wesley, 1999.
[10]Taylor, E.S., An Interim Report on Engineering Design, Massachusetts Institute of Technology, 1959
|
