LePUS has subsequently been replaced by LePUS3 ('Codecharts'). See: Amnon H. Eden, with contributions from Jonathan Nicholson. Codecharts: Roadmaps and Blueprints for Object-Oriented Programs. Hoboken, New Jersey: Wiley-Blackwell, 2011
Information Systems Frontiers 4:4, 379–391, 2002 C 2002 Kluwer Academic Publishers. Manufactured in The Netherlands.
A Theory of Object-Oriented Design
Amnon H. Eden
Center for Inquiry, Amherst, NY, USA E-mail: firstname.lastname@example.org
Abstract. Progress was made in the understanding of objectoriented (O-O) design through the introduction of patterns of design and architecture. Few works, however, offer methods of precise speciﬁcation for O-O design. This article provides a well-deﬁned ontology and an underlying framework for the formal speciﬁcation of O-O design: (1) We observe key design motifs in O-O design and architectures. (2) We provide a computational model in mathematical logic suitable for the discussion in O-O design. (3) We use our conceptual toolkit to analyze and compare proposed formalisms. Key Words. software design theory, software architecture, object oriented programming, formal foundations, design patterns
Architectural speciﬁcations provide software with “a unifying or coherent form or structure” (Perry and Wolf, 1992). Coherence is most effectively achieved through formal manifestations, allowing for unambiguous and veriﬁable representation of the architectural speciﬁcations. Various formalisms and Architecture Description Languages (ADLs) (Medvidovic and Taylor, 1997) were proposed for this purpose, each of which derives from an established formal theory. For example, Allen and Garlan extend CSP (Hoare, 1985) in WRIGHT (Allen and Garlan, 1997); Dean and Cordy (1995) use typed, directed multigraphs; and Abowd, Allen, and Garlan (1993) chose Z (Spivey, 1989) as the underlying theory. Other formalisms rely on Statecharts (Harel, 1987) and Petri Nets (Petri, 1962). In contrast, techniques idiosyncratic to the objectoriented programming (OOP) paradigm, such as inheritance and dynamic binding (Craig, 1999), induce regularities of a unique nature. Consequently, O-O systems deviate considerably from other systems in their architectures. We would expect the architec-
tural speciﬁcations of O-O systems to reﬂect their idiosyncrasies. Unfortunately, architectural formalisms largely ignore the O-O idiosyncrasies. Few works (Section 4) recognized the elementary building blocks of design and architecture patterns. As a result of this oversight, any attempt to use formalisms for the speciﬁcation of O-O architectures is destined to neglect key regularities in their organization. Only naturally, coherent speciﬁcations warrant the recognition of the underlying abstractions of the paradigm (Odenthal and Quibeldey-Cirkel, 1997). This is equally true for O-O programs. Hence, we observe primitives (“building blocks”) in O-O design, such as the inheritance class hierarchies (Deﬁnition IV) and clans (Deﬁnition V), which reﬂect the mechanisms that underlie the paradigm’s idiosyncrasies (inheritance and dynamic binding, respectively.) 1.1. Patterns More than any other form of documentation, software patterns (Coplien and Schmidt, 1995; Vlissides, Coplien, and Kerth, 1996; Martin, Riehle and Buschmann, 1997; Schmidt et al., 2000), in particular design patterns, proved effective in capturing recurring motifs in O-O software architecture. Each article of these catalogues addresses a distinct “design pattern”, documented in a structured format, and distinguished by a name which carries its intent. Patterns capture abstractions that facilitate communicating problems and solutions. It is safe to argue that the best insight into the regularities of O-O design is provided by the patterns literature. Yet the genre suffers from a few shortcomings, most prominent appear to be the following: 1. Ambiguity. The informal and ultimately fuzzy descriptions puzzle patterns’ users and cause...
Please join StudyMode to read the full document