Software Design 2e - DIM

of a model for a solution, with functional decomposition providing a rather extremeexample of such a design strategy. Only in later forms, such as that of JSD, do we seea more even balance occurring between the elements of the model that are concernedwith the actions and those concerned with the data. Even then, the design steps themselvesare still directed towards developing the model by considering action-orientedfeatures of a problem.However, quite early on in the development of programming tools, the idea ofmodelling the structure of a problem around the concept of ‘passive’ objects of someform began to be explored. Simula in particular is generally considered a significantforerunner of the development of the object-oriented paradigm, not least for its introductionof the ‘class’, a concept which will be considered later in this section. (Such anapproach to modelling a problem could perhaps be considered as ‘noun-oriented’rather than ‘verb-oriented’.) The Smalltalk system extended this model still further andintroduced these concepts to a much wider audience.In a relatively early and highly influential paper, David Parnas (1972) had alreadyidentified the benefits that could be gained through designing around the principle ofinformation-hiding, which, as will be seen in the next subsection, is one of the characteristicsof an object-oriented system. However, Parnas recognized that, while theprinciple was valuable, it was difficult to find any procedural form of design actionthat could be used for generating designs in such a way as to ensure they wouldpossess the necessary properties. Unfortunately, as we will see, it appears that theefforts of the next three decades have failed to improve upon this position to anysignificant degree.Over a period of time, these influences began to come together in the idea of the‘object model’, characterized by implementations that:345The ‘object concept’nnnare organized around data (nouns) rather than actions (verbs);apply strict control of scope (visibility), so that data and operations within anobject are not normally available for use by other objects except through the externalmechanisms provided by the object;make use of little or no ‘global’ data (i.e. any data used in the system is storedwithin objects and only directly accessible to that object).Some of these issues relating to scope and access were described in Parnas (1979).As these ideas emerged, various efforts were made to maintain consistency of conceptsand terminology. A useful contribution was made by a working group, whoseconclusions are reported in Snyder (1993). A little later, the Unified Modeling Language(UML) has also played an important role in this, even though motivated, at leastin part, by rather more commercial reasons.The key outcome for our purpose here is that the essential properties of an objectare now generally well agreed. Equally, the terminology, if not always agreed, is atleast used fairly consistently. (These points probably apply chiefly to object-orientedanalysis and design, rather than to implementation, since language designers appear tohave delighted in finding new terms to use as well as different ways of using the sameterms and keywords!)