A Proposal for a Document Driven/Centric Software Engineering Approach Girish Balakrishnan Lecturer, Rajagiri School of Engineering and Technology

Transcription

1 A Proposal for a Document Driven/Centric Software Engineering Approach Girish Balakrishnan Lecturer, Rajagiri School of Engineering and Technology Software Engineering in Crisis This section attempts to present to the reader the crisis software engineering is facing and hence convince him for the need to betterment of software engineering methods. This need for improvement in software engineering techniques is felt by the experts in the field and is supported by the author with evidence from the industry. D L Parnas in his paper Document Driven Disciplined Development of Software has expressed this concern very critically. The author would like to produce opinions of D L Parnas as evidence in favour of stressing the need for more discipline in Software Engineering partly due to the authority that he holds over the software discipline. Parnas expressed concerns stating the following:- Something has gone wrong in the field that we call Software Engineering. Where a Mechanical Engineering journal might publish a paper on how to make sure that an impeller will not break if the fluid is viscous, or how to control a milling machine more precisely, Software Engineering journals publish papers on how to get people to cooperate better. In other words, we are focusing on aspects of project management and forgetting the problems of design and analysis that are at the heart of other areas of Engineering. The problem starts from the first stage of software development requirements gathering. Parnas states, Software engineers seem to be satisfied with going to potential users and asking, What would you like? Functional requirements for physical products can be checked for completeness and consistency; in software we accept the fact that our requirements will have neither property. As far as design is concerned Parnas states that, Where an Electrical Engineer would analyze a mathematical design for a circuit before producing physical components, most Software Engineers will have a vague design in their head as they write the code. The code is the first precise description of the component that can be reviewed by others. In short there is a growing concern often ignored by software companies on making software engineering more formal and predictable like other disciplines. The reasons why software engineering has not had significant advancement and the growing gap between the software engineering principles being advocated at major conferences and the practice of software engineering in many industrial and government laboratories are noted by Parnas et al in The Modular Structure of Complex Systems by major three points which the author restates differently as follows:

2 (a) Practicability: New software engineering ideas were impractical for real world problems. (b) Convincing: Responsible managers were unwilling to bet on principles that had been not been proven in practice thus creating a startup problem. (c) Relation to real world: Examples used in the research papers were too unlike the problems of the practitioners to serve as models (d) Adaptability: The ideas might need refinement or extension before they could be used as guidelines for projects with the complexity and resource constraints found in the field (e) Simplicity: The ideas which are presented should be simple enough to be following by a majority of practitioners. Thus any improvement which is intended to be proposed should be measured by these parameters. The problems which arise in Software Engineering are partly due to the lack of any physical laws which govern the capture of information, design and implementation of software projects. Example, there are no established formal methods of modularization or mathematical means to measure cohesion, coupling etc. The practitioners of software engineering would admit the existence of guiding principles like information hiding (proposed by Parnas) used successfully in developing good quality software. This research proposal will use and reiterate the significance of the use of information hiding in software design. A good introduction to this topic can be found in On the Criteria To Be Used in Decomposing Systems into Modules. The crisis of software engineering is growing as the software system become more complex in terms of the functional vastness, the distributed nature of the development i.e. contribution of teams from various locales, model driven etc. A very interesting example of such a product is the Business By Design of SAP, a hosted end-to-end business suite for the SME. Software Engineering: In the Context of Trans-disciplinary Research In the web site for Society for Design and Process Science (SDPS), the first transdisciplinary society ( one can read about the three fundamental revolutions namely, quantum revolution, computer revolution and biomolecular revolution. There is a need for a roadmap for the synergy between these revolutions in the wake of the reality that pure reductionist approach no longer works. Solutions of complex problems need this interdisciplinary cohesion. The author is of the opinion that software engineering will act as the backbone for all transdisciplinary research with its abstract concepts of separation of concerns, modules, cohesion etc. Hence any new developments in software engineering should also take into account its implications on how it will supplement the other revolutions i.e. in solving problems of the physical world how does software engineering techniques fare in the integration with other disciplines. Thus the challenges to software engineering are profound considering its present stage as put forth by Parnas.

3 In the article Software Engineering Programs Are Not Computer Science Programs Parnas clearly explains the transdisciplinary nature of software engineering and distinguishes it from computer science. Better Discipline in Software Design using Hierarchically Structured Document Structure of Software Systems The structure of a software system can be defined mathematically as shown below: Software System S = {M1, M2, } M i r M j where r is relation between M i and M j (M j and M i are modules). The relation r can be chosen as per what the situation demands. In the paper Modular Structure of Complex Systems Parnas advocates the use of a hierarchically structured design document in reducing difficulties in understanding complex software systems for designers and maintainers alike. The paper defines a structure for the document and thus makes use of this explicitly defined structure to supplement the concept of information hiding and abstraction which is used in designing the modules of the software. More details of the paper is left to the reader since the primary intend of describing it is to convince the reader that the technique of using a document is used before in literature by experts. However the success of this method is questionable due to lack of evidence from real world problems. In this research proposal the author presents a different structure to the document which will encompass not only design but all stages of software development (including testing) into a hierarchically structured document. Motivation and Philosophy behind the Proposed Approach * The author finds parallels between software development and the systematic manner of transforming an intellectual discipline still in its philosophical stage into an exact science. To achieve this, the reader has to be aware of the Kantian difference between philosophy and science. Philosophy, according to Kant, makes concepts given in everyday discourse analytically distinct and articulates the notes or predicates of conceptual intensions or contents. Science, on the other hand, interrelates synthetically concepts not given but made, the definitions of which are at the same time the constructions of the corresponding objects. The latter process is expressed in symbols or signs, arrived at in formal intuition; the former takes place in words of everyday language, whose meanings are arrived at in abstraction from empirical intuition. The logic ruling philosophy is general or formal logic, that ruling science is transcendental logic. Formal logic shows how to clarify concepts, transcendental logic how to construct objects. Conceptually we can assign the function of clarifying concepts to software requirements gathering and construction of objects to design and coding. In requirements gathering what we essentially are doing is to understand and capture the

4 concepts associated with the software to be built. These concepts should be clear i.e. their meanings should be unmistaken. The process of requirements gathering should make these clear concepts distinct i.e. the details of these clear concepts are fully determined. The author claims that the process of making clear concepts distinct is the exact equivalent of converting software requirements, which is the collection of concepts, to design, which comprises the details on how these concepts are to be realized. We consider software development as a movement of thought from experience of a thing to its definition written as code. This movement of thought is nothing but a hierarchy of clarities. Having introduced from Kant s logic the concept of moving from exposition of a concept to its definition as a hierarchy of clarities we propose the idea of developing a documentation structure, which will start from a very basic statement of the purport of the software to the detailed design, as the different levels of hierarchies of clarity. This document will thus encompass the stages of requirements gathering to the design and coding as the different levels of the hierarchy. The proposal is to define the structure of the document mathematically. The structure can be captured using XML tags. It would be interesting to check how DocBook can be modified to support the proposed structure. The hierarchical structure is similar to the levelled DFDs. In the next section we define the document structure in a formal manner. Proposed Levels in the Hierarchical Structure of the Document Complex software systems are divided in different ways. In this paper we will discuss a structure which is designed in such a way so that the transition from problem space (requirements specification) to design space (Data Flow Diagram) is captured in a single document. Also this single document should act as the basis for creating test case. The levels are proposed are as follows: 1) Product Description: The first level explains the objective behind the software system being developed in a very abstractly. It will be represented by P. 2) Scenario Descriptions: A product is divided into a collection of scenarios. A scenario is an end-to-end operation performed by user to achieve some goal. This description could include in it the UI design involving different screens which the user might use to achieve the goal. Scenarios will be represented by S. An example of a scenario in business software could be self-procurement by employees of a company. From the documentation at this level is obtained a set of S i s. 3) Processes Description: A scenario is the execution of a sequence of processes. Each process could belong to different domains of expertise (e.g. manufacturing, finance etc) hence developed by different teams. A process is typically a transformation function which has input and output. A process is

5 the concept derived from the procedural paradigm. Processes are represented by P. This level s description provides a collection of processes P i s which describe how the scenario s goal is achieved. 4) Object Description: The actual operations on data of a process are performed by objects which are encapsulation of data and related functions. Objects here are modules which are assigned responsibility. O represents objects/modules. This last level describes how object are related (all the relations like composition, inheritance etc) with each other to perform operations of data for the process to achieve the function. The reader can observe that separation of concerns is used here to divide the complex system. The overlap between objects in the higher layers is not evident until we drill down to Object Description level or Process Description level i.e. scenarios are independent entities. This kind of division is practiced by SAP in design for the development of Business By Design. The proposal of the current research is to introduce this structure to documentation (use of documentation for complex systems initiated by Parnas) since we find the structure supports evolution of the software system from requirements to design. This is primarily due to the independent objects of higher layer. The collection of objects (which are highly cohesive in functionality) of the Object Description layer enables reuse and hence lets us compose new processes and scenarios in future. Note that if we consider all the processes as set of alphabets then a scenario is a string of processes and the entire product a language generator. The structure of each process as a relation between modules/objects is more complex. Textbooks have defined relations like Composed Of, Hierarchy etc. and built directed graphs. Also note that the scenario is subject to organizational access control. Processes will have access control based on user profile. Thus every P is associated with an Ac (access control) which is set in the user profile. Hence we can say a process is represented by a pain (P, Ac). Process Involved in using the Hierarchically Structured Document The reader would have noticed that in this paper the attempt is to capture the structure of the software in the document. XML tags placed between the documents (not a conventional way of using XML) would help in extracting the structure. Thus the process which we follow will also be centric on the document. The difference between other standard software engineering models and the proposed method is that the details from each phase of other models go into different levels of the document. Requirements gathering would go into the top most layer and then design and object models appear in lower level.

6 The attempt is to transition from a logical system (the explanations in plain text) to a mathematical system (once we extract the structure from the XML tags). Scenarios and processes are basically time systems and the modules/object description can be categorized as algebraic systems. Processes should be arrived at in such a way that any change would affect the structure of the document and can be mathematically analysed. One would argue that when code itself is very structured means and can be used to analyse the overall structure why use the document. The reason is that a hierarchical document is the bridge between code, design and document. Thus if we extract the structure from the bridge between these disparate entities we get a fairly better understanding. In this section we have not proposed any processes which can be followed but have tried to explain the basic concept which will guide in later deciding the processes. The Proposal: A Tool The proposal is for a tool, if possible based on DocBook, which will let the user document as text details from requirements specification to object model as a hierarchy. The main entities (like scenario, process etc) will be named and tagged using XML. The tool will also extract structure based on relations like Component-Of from the document (based on the XML tagging) and display as a graph. This graph will help in understanding the impact of a proposed change when we have to change modules. Conclusion Even if the requirement of a document to solve the problem is not evident on first notice the author is convinced for distributed development in large teams documentation is the last thing to be delivered and thus difficult when teams collaborate. One might be aware without much convincing the role documentation plays during the maintenance phase. The vision is to provide documentation from where we can drill down to the code level as well as perform tests on a live system as we read about some features. It has be brought to the notice of the reader as to how the document encompasses in different levels time systems, algebraic systems etc. It is part of the proposal to check how systems concepts can be applied to the document based on a General Systems approach (refer Systems Approach to Theory of Computing Systems by Mihajlo Mesarovic).