Software people seem to have a love-hate relationship with metrics. On one hand, they despise and distrust anything that sounds or looks like a measu… - Edward V. Berard

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 (Stevens et al., 1974). There is more than one way to accomplish a “structured design.”

An action which is suffered by, or required of, an object. Operations may be selectors, constructors, or iterators. An operation is contained in an object's interface and has its details described in a corresponding method. Operations may be composite, i.e., composed of other operations. However, encapsulation of composite operations within the interface to an object is not encouraged.

In order to better understand object-oriented methodologies in general, it helps to understand the people who make up the "object-oriented community" itself. Far from being monolithic, there is a great deal of diversity within this community. Many object-oriented people, for example, seem to focus almost entirely on programming language issues. They tend to cast all discussions in terms of the syntax and semantics of their chosen object-oriented programming language. These people find it impossible (for all intents and purposes) to discuss any software engineering activity (e.g., analysis, design, and testing) without direct mention of some specific implementation language. Outside of producing executable "prototypes", people who emphasize programming languages seldom have well-defined techniques for analyzing their clients' problems or describing the overall architecture of the software product. A great deal of what they do is intuitive. If they happen to have a natural instinct/intuition for good analysis or good design, their efforts on small-to-medium, non-critical projects can result in respectable software solutions.