System design with Ada
Software engineering with Ada
Designing large real-time systems with Ada
Designing large real-time systems with Ada
Object-oriented systems analysis: modeling the world in data
Object-oriented systems analysis: modeling the world in data
Principles of software engineering management
Principles of software engineering management
An object-oriented requirements specifications method
Communications of the ACM
Software Component with ADA
Structured analysis and object-oriented development are not compatible
ACM SIGAda Ada Letters
Object-oriented graphics for requirements analysis and logical design
ACM SIGAda Ada Letters
An ada object-based analysis and design approach
ACM SIGAda Ada Letters
Manageable object-oriented development: abstraction, decomposition, and modeling
TRI-Ada '91 Proceedings of the conference on TRI-Ada '91: today's accomplishments; tomorrow's expectations
TRI-Ada '92 Proceedings of the conference on TRI-Ada '92
Experiences in object oriented development
TRI-Ada '92 Proceedings of the conference on TRI-Ada '92
Adapting an Object-Oriented Development Method
IEEE Software
Transition to object-oriented software development
Communications of the ACM
Functional lists: object-oriented design classes for MIS applications
WADAS '90 Proceedings of the seventh Washington Ada symposium on Ada
Using the Shlaer-Mellor Object-Oriented Analysis Method
IEEE Software
A Parallelizing Compiler by Object Oriented Design
COMPSAC '97 Proceedings of the 21st International Computer Software and Applications Conference
Hi-index | 0.02 |
The Object-Oriented Software Development Method (OOSD) includes object-oriented requirements analysis, as well as object-oriented design. OOSD is a practical method of developing a software system which focuses on the objects of a problem throughout development. OOSD's focus on objects early in the development, with attention to generating a useful model, creates a picture of the system that is modifiable, reusable, reliable, and understandable — the last perhaps most important because the picture of a software system created by a development method must be an effective device for communication among developers, customers, management, and quality-assurance personnel.Most object-oriented methods competing for the attention of the software developer actually apply traditional Structured Analysis (function-based), or variations of Structured Analysis, to requirements activity, and work through a transition process to an object-oriented design [1,2,7,10,11]. In these methods the developer begins with functionally-based requirements analysis, and only reaches an object-oriented design by the intermediary step of converting a traditional, functionally-decomposed data flow diagram (DFD) to an object-oriented DFD (or equivalent). In this conversion process, objects are identified through a set of heuristics which group “transformations” in the DFD generated during requirements analysis. These methods carry a number of interesting but unfortunate burdens. Lower-level objects, which directly relate to real-world objects, are easily identified, but higher-level objects are generally more arbitrary, so that developers do not consistently identify a hierarchy of objects which achieves significant improvement in software engineering goals (e.g., reliability, maintainability, reusability). The heuristics for identifying objects usually relate the DFD transforms to the object that controls execution of an operation, rather than the object which “owns” the operation. These methods generally ignore the need to convert behavior descriptions of the DFD transforms into behavior descriptions of the objects. Finally, the use of Structured Analysis in an otherwise object-oriented approach complicates the tracing of requirements by forcing the developer to look first to DFD transforms and their behavior descriptions, and then to the objects.