Requirements for Student Registration System

Topics: Design pattern, Object-oriented programming, Software design patterns Pages: 23 (7482 words) Published: December 22, 2012
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:

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 specification for O-O design. This article provides a well-defined ontology and an underlying framework for the formal specification 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

1. Introduction
Architectural specifications 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 verifiable representation of the architectural specifications. 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 specifications of O-O systems to reflect 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 specification of O-O architectures is destined to neglect key regularities in their organization. Only naturally, coherent specifications 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 (Definition IV) and clans (Definition V), which reflect 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...
Continue Reading

Please join StudyMode to read the full document

You May Also Find These Documents Helpful

  • Student Registration System Essay
  • Essay about Student registration system
  • Registration System Essay
  • Database for Student Registration System Essay
  • Registration System Essay
  • Essay on Online Student Registration System
  • Systems Requirements, Design and Implementation Specification Research Paper
  • Student Registration System Essay

Become a StudyMode Member

Sign Up - It's Free