Data processing: software development – installation – and managem – Software program development tool – Code generation
Reexamination Certificate
2000-04-14
2004-06-29
Dam, Tuan (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Code generation
C717S144000, C717S133000, C717S114000, C714S038110
Reexamination Certificate
active
06757887
ABSTRACT:
BACKGROUND
1. Technical Field
The present invention relates generally to computer processing systems and, in particular, to a method for generating a software module from multiple software modules based on extraction and composition.
2. Background Description
Separation of concerns is at the core of software engineering. In its most general form, separation of concerns refers to the ability to identify, encapsulate, and manipulate only those parts of software that are relevant to a particular concept, goal, or purpose. Concerns are the primary motivation for organizing and decomposing software into manageable and comprehensible parts. Separation of concerns is further described by David L. Parnas, in “On the Criteria To Be Used in Decomposing Systems into Modules”, Communications of the ACM, Vol. 15, No. 12, December 1972.
Many different kinds, or dimensions, of concerns may be relevant to different developers in different roles, or at different stages of the software lifecycle. For example, the prevalent kind of concern in object-oriented programming is data or class; each concern in this dimension is a data type defined and encapsulated by a class. Features, like printing, persistence, and display capabilities, are also common concerns, as are aspects, like concurrency control and distribution, roles, viewpoints, variants, and configurations. Separation of concerns involves decomposition of software according to one or more dimensions of concern. Features, aspects, roles, viewpoints are respectively described by: Fuggetta et al., in “Feature Engineering”, Proceedings of the 9th International Workshop on Software Specification and Design, pp. 162-64, April 1998; Irwin et al., in “Aspect-Oriented Programming”, Proceedings of the European Conference on Object-Oriented Programming (ECOOP), Finland, Springer-Verlag, LNCS 1241, June 1997; Andersen et al., in “System Design by Composing Structures of Interacting Objects”, Proceedings of the European Conference on Object-Oriented Programming (ECOOP), June/July 1992; and Finkelstein et al., in “A Framework for Expressing the Relationships Between Multiple Views in Requirements Specifications”, Transactions on Software Engineering, Vol. 20, No. 10, pp. 260-773, Oct. 1994
Separation of concerns has been hypothesized to reduce software complexity and improve comprehensibility; promote traceability within and across artifacts and throughout the lifecycle; limit the impact of change, facilitating evolution and non-invasive adaptation and customization; facilitate reuse; and simplify component integration.
These goals, while laudable and important, have not yet been achieved in practice. This is because the set of relevant concerns varies over time and is context-sensitive. Different development activities, stages of the software lifecycle, developers, and roles often involve concerns of dramatically different kinds. One concern may promote some goals and activities, while impeding others. Thus, any criterion for decomposition will be appropriate for some contexts, but not for all. Further, multiple kinds of concerns may be simultaneously relevant, and they may overlap and interact, as features and classes do. Therefore, different concerns and modularizations are needed for different purposes. The different purposes may differently implicate class, feature, viewpoint, aspect, role, variant, or other criterion.
These considerations imply the need for “multi-dimensional separation of concerns”. Developers must be able to identify, encapsulate, modularize, and manipulate multiple dimensions of concern simultaneously, and to introduce new concerns and dimensions at any point during the software lifecycle, without suffering the effects of invasive modification and rearchitecture. However, even modern languages and methodologies suffer from a problem that has been referred to as the “tyranny of the dominant decomposition”. That is, the languages and methodologies permit the separation and encapsulation of only one kind of concern at a time. A body of software can generally be decomposed in only one way, just as a typical document is divided into sections and subsections in only one way. This one decomposition is dominant, and often excludes any other form of decomposition. The “tyranny of the dominant decomposition” is further described by Harrison et al., in “N Degrees of Separation: Multi-Dimensional Separation of Concerns”, Proceedings of the 21st International Conference on Software Engineering, pp. 107-19, May 1999.
Examples of tyrant decompositions are classes (in object-oriented languages), functions (in functional languages), and rules (in rule-based systems). Therefore, it is impossible to encapsulate and manipulate, for example, features in the object-oriented paradigm, or objects in rule-based systems. Accordingly, it is impossible to obtain the benefits of different decomposition dimensions throughout the software lifecycle. Developers of an artifact are forced to commit to one (or only a few at most), dominant dimension(s) early in the development of that artifact, and changing their choice can often have catastrophic consequences for the existing artifact. Further, since artifact languages often constrain the choice of dominant dimension (e.g., it must be class in object-oriented software), different artifacts (e.g., requirements and design documents) might be forced to use different decompositions, thus obscuring the relationships between them.
A particular decomposition of a body of software is a set of “modules” into which the software is divided. Modules can be nested within one another, and can be related in other ways. The intent is that each module encapsulate some particular concern. That is, all the software, and only the software, that pertains to that concern is contained within the module. Systems are built by selecting and composing modules. For example, modules in the JAVA programming language (henceforth referred to as “JAVA”) are packages, classes and interfaces. Classes and interfaces enforce “data abstraction”. Each is concerned with a particular data structure, and encapsulates all internal details of that data structure. All code is written within classes and interfaces, which in turn are grouped into packages. A system is built by selecting the packages, classes and interfaces to include.
Choice of decomposition, which implies choice of modules, is important because it determines which concerns are encapsulated within modules. These concerns can be more easily understood, because all the software pertaining to them is localized in the module. Moreover, these concerns can be modified with reduced impact, because changes are usually localized within the module. Further, these concerns can be used as the basis for system configuration. That is, these concerns can be selected for inclusion in, or exclusion from, systems. For example, in a standard JAVA system, packages, classes and interfaces can be included or excluded. In a system decomposed by feature, features can be included or excluded. However, since typical features involve portions of multiple classes, features cannot be used as the basis for configuration in standard JAVA, and classes could not be used as the basis for configuration in a feature-based decomposition. Lastly, these concerns can be used as a unit of reuse. However, concerns that are not encapsulated within modules typically cut across many modules. Such concerns are not localized and, therefore, do not enjoy the above described benefits.
The tyranny of the dominant decomposition forces a single decomposition on a body of software, thereby conferring benefits on a particular kind of concern at the expense of other concerns. Currently, it is believed that the tyranny of the-dominant decomposition is the single most significant cause of the failure to achieve many of the expected benefits of separation of concerns.
3. Problems with the State of the Art
A brief description will now be given of the prior art that is concerned with function extraction. In some restructuring tools, the user is all
Kaplan Matthew
Kruskal Vincent Joseph
Ossher Harold Leon
Tarr Peri Lynn
LandOfFree
Method for generating a software module from multiple... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for generating a software module from multiple..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for generating a software module from multiple... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3344024