The three challenges of object-oriented design are to identify the objects and classes needed to implement the software, describe the relationships between the identified objects and classes, and define the behavior of the objects by describing the function implementations of each class. To discover an initial set of objects and classes, researchers look at the noun phrases and nouns used to analyze the system and to describe the system requirements. Possible sources of objects include tangible things (cars, telemetry data, pressure sensors); roles (mother, teacher, politician); events (landing, interrupt, request); interactions (loan, meeting, intersection); people; places; organizations; devices; and locations [Booch 1991]. Walking through scenarios of system usage, focusing on the discovery of the important objects and their responsibilities, is an important technique used early in the design process [Jacobson et al. 1992; Wirfs-Brock et al. 1990]. When the important objects have been found, the details of the class relationships and object behavior are developed through a set of interconnected models that capture four dimensions of the software architecture: logical static, logical dynamic, physical static, and physical dynamic [Booch 1991]. The logical static model describes the relationships of instantiation (class membership), association, aggregation (part-of), and generalization (is-a). This is called the system object model [Coleman 1994]. The generalization relationship implies inheritance of attributes and methods. Graphical notations derived from the entity relationship notation for data modeling are frequently used to define the object model [Rumbaugh et al. 1991]. Constraints such as cardinality (for example, one-one, one-many, many-many) that are important to the design are also expressed in the object model. A textual notation derived from BackusNaur-form grammars is also used [Lieberherr 1996]. Grammars provide a more concise representation of the class structures. The logical dynamic model describes the interactions between objects. The interactions define the run-time behavior of the system in terms of a set of participating objects, an ordered sequence of messages between the objects, and a determination of the visibility of each object in the interaction. Object interaction diagrams [Booch 1991] and interaction graphs [Coleman 1994] are used to describe important interactions. These show the participating objects and the time-ordered messages between the objects. Object visibility within an interaction is expressed via visibility graphs. Object visibility determines how an object becomes part of the scope of the method sending it a message. For example, it may be a method argument, a local variable, a new object, or a part of the current object executing the

Object-oriented design

A method is presented for using composite objects which separates their role and meaning as models of relations between problem-domain concepts from their role and meaning as models of hierarchical sof’twarc structures. The meaning of composite objects is analysed in terms of connections bctwccn real-world concepts in object-oriented analysis and bctwccn software objects in object-oriented design. By capturing the designer’s rationale for model transformation, the resulting models arc casicr to understand and maintain. An embedded systems example illustrates the approach.

/pdf/roles-for-composite-objects-in-object-oriented-analysis-and-1bqynho2g3.pdf

Roles for composite objects in object-oriented analysis and design

The automatic layout of software diagrams is a very attractive graph drawing application for use in software tools. Object-oriented software may be modelled using a visual language called the Unified Modeling Language (UML). In this paper we present an algorithm for the automatic layout of UML class diagrams using an extension of the Sugiyama algorithm together with orthogonal drawing. These diagrams visualize the static structure of object-oriented software systems and are characterised by the use of two main types of edges corresponding to different relationships between the classes. The graph drawing algorithm accounts for these concepts by treating the different edge types in different ways.

/pdf/extending-the-sugiyama-algorithm-for-drawing-uml-class-2r0ls422rn.pdf

Extending the Sugiyama Algorithm for Drawing UML Class Diagrams: Towards Automatic Layout of Object-Oriented Software Diagrams

The middleware market represents a sizable segment of the overall Information and Communication Technology market. In 2005, the annual middleware license revenue was reported by Gartner to be in the region of d8.5 billion. In this article we address the question whether research had any involvement in the creation of the technology that is being sold in this marketq We attempt a scholarly discourse. We present the research method that we have applied to answer this question. We then present a brief introduction into the key middleware concepts that provide the foundation for this market. It would not be feasible to investigate any possible impact that research might have had. Instead we select a few very successful technologies that are representative for the middleware market as a whole and show the existence of impact of research results in the creation of these technologies. We investigate the origins of Web services middleware, distributed transaction processing middleware, message-oriented middleware, distributed object middleware and remote procedure call systems. For each of these technologies we are able to show ample influence of research and conclude that without the research conducted by PhD students and researchers in university computer science labs at Brown, CMU, Cambridge, Newcastle, MIT, Vrije, and University of Washington as well as research in industrial labs at APM, AT&T Bell Labs, DEC Systems Research, HP Labs, IBM Research, and Xerox PARC we would not have middleware technology in its current form. We summarise the article by distilling lessons that can be learnt from this evidenced impact for future technology transfer undertakings.

https://www.tamps.cinvestav.mx/~vjsosa/clases/sd/The_ImpactOfResearchOnDevelopmentOfMiddlewares_08.pdf

The impact of research on the development of middleware technology

Objects model phenomena and a phenomenon is usually a component. Information characterizing a component is encapsulated and accessible only by its methods. The relations between components are modeled explicitly by means of associations or references. A relation is also a phenomenon and objects can model this type of phenomena too. Components are usually related conceptually in diverse and subtle ways: Some relations are implicitly given and some are local to other more basic relations. Such kinds of relations are important for understanding the organization and cooperation of objects and may be supported in object-oriented analysis, design, and programming: An implicit association describes a relation between an object and objects local to this enclosing object, and a complex association describes an explicit relation between local objects in different enclosing objects. Such associations are described by classes and the objects have the usual properties including methods and attributes.

Grady Booch

Papers

Object-oriented design with 2176A