Object‐Oriented Design

Abstract

Work on what was to become “structured design” began in the early 1960s. Structured design, as a well‐defined and named concept, did not achieve appreciable visibility until the publication of an article in the IBM Systems Journal in 1974. There is more than one way to accomplish a “structured design.” Like structured design, the term object‐oriented design (OOD) means different things to different people. For example, OOD has been used to imply such things as The design of individual objects, and/or the design of the individual methods contained in those objects The design of an inheritance (specialization) hierarchy of objects The design of a library of reusable objects The process of specifying and coding of an entire object‐oriented application The term nonformal is used to describe approaches to OOD that are not well defined, step‐by‐step, or repeatable, such as those that emphasize the design of individual objects, specialization (inheritance) hierarchies, and libraries of objects. A survey of such approaches indicates that there may indeed be some repeatable rigor (and some sage advice) given for these approaches, but they are severely lacking when it comes to defining the software architecture of large and critical systems. Different approaches, techniques and experienced with object oriented design are discussed here.

An organizational approach to designing an intelligent knowledge-based system: Application to the decision-making process in design projects

“…Software development process: This category gathers the main phases of a standard life cycle for software development according to Berard [68]. The objective is to see how each design approach handles these phases.…”

A Catalogue of Refactorings for Model-to-Model Transformations.

“…However, the separation of the transformation logic into several rules comes with the price of having coupling between rules, but it can be seen on the average fan-in value that the coupling is still very low. This can be considered as necessary coupling level as pointed out by [Ber93], because a modular system without any coupling is useless in general.…”

Coupling Complexity Metric: A Cognitive Approach

“…There is no distinction between a strong and weak relation. Second, the metrics do not consider the various type of coupling complexity of the classes that were proposed by Edward Berard [17]. CBO is explained in section 3, the motivation of proposed metric is discussed in section 4, Calibration of Types of coupling is discussed in section 5, The proposed metric CWCBO is explained in section 6, the experimentation of a new metric and the case study is described in section 7, a comparative study of CWCBO with CBO in section 8 and Section 9 presents the conclusion and future work.…”

“…The various types coupling are Control Coupling (CC), Global Data Coupling (GDC), Internal Data Coupling (IDC), Data Coupling (DC) and Lexical Content Coupling (LCC) [17].The cognitive weight of these types of couplings is calibrated by means of psychological experiments conducted to students of masters and bachelors degree. With the new metric there is hope that this metric will reflect the real complexity of OO system.…”