Wikiquote

Object-orientation

software engineering concept
(Redirected from Object-Oriented Analysis)

Object-orientation or Object-oriented is a software engineering concept, in which concepts are represented as "objects".

Quotes

edit
Quotes are arranged in chronological order

1980s

edit
  • Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world.
    • Grady Booch (1986) Software Engineering with Ada p. 220. cited in: David J. Gilmore et al. (1994) User-Centred Requirements for Software Engineering Environments. p. 108
  • Object-oriented programming languages support encapsulation, thereby improving the ability of software to be reused, refined, tested, maintained, and extended. The full benefit of this support can only be realized if encapsulation is maximized during the design process.
    We argue that design practices which take a data-driven approach fail to maximize encapsulation because they focus too quickly on the implementation of objects. We propose an alternative object-oriented design method which takes a responsibility-driven approach. We show how such an approach can increase the encapsulation by deferring implementation issues until a later stage.

1990s

edit
  • Philosophy and cognitive science have contributed to the advancement of the object model. The idea that the world could be viewed either in terms of objects or processes was a Greek innovation, and in the seventeenth century, we find Descartes observing that humans naturally apply an object-oriented view of the world. In the twentieth century, Rand expanded upon these themes in her philosophy of objectivist epistemology. More recently, Minsky has proposed a model of human intelligence in which he considers the mind to be organized as a society of otherwise mindless agents. Minsky argues that only through the cooperative behavior of these agents do we find what we call intelligence.
    • Grady Booch (1991) Object-oriented design: With Applications. p. 34-35
  • Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships.
    • Grady Booch (1991) Object-oriented design: With Applications. p. 35
  • 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.
    • Edward V. Berard (1993) Essays on object-oriented software engineering. Volume 1. p. 5
  • From a very early age, we form concepts. Each concept is a particular idea or understanding we have about our world. These concepts allow us to make sense of and reason about the things in our world. These things to which our concepts apply are called objects.
  • The integration technology and infrastructure elements available today, in 1993, would enable an enterprise to develop a significant integration infrastructure. However, integration projects are constrained by cultural inertia, financial and resource limitations, and, significantly, risk management Thus, Enterprise Integration projects and their supporting integration infrastructures tend to be deployed in an incremental and evolutionary manner. Since each enterprise chooses its integration path based on particular business needs, the corporations visited in this study each presented a different road map of integration efforts to date and a unique snapshot of current integration infrastructure....
    DoD, in concert with leading companies, should formulate an R&D strategy to create a new generation of enterprise architectures, models, tools, and software systems, and to determine the potential for new business operations, engineering practices, and manufacturing concepts. To achieve potential functional and performance improvements, integrators should combine the leverage of several emerging threshold technologies, such as operational integration frameworks, object-based and knowledge-based product and process representations, application-oriented network services, near-term and mid-term solutions to database integration, and wide-area object brokerage and execution.-
    • Robert I. Winner (1993) Information Infrastructures for Integrated Enterprises p. 38 & p. 89-90
  • Is object-oriented technology mature enough upon which to build indus­trial-strength systems? Absolutely. Does this technology scale? Indeed. Is it the sole technology worth considering? No way. Is there some better technology we should be using in the future? Possibly, but I am clueless as to what that might be.
    It is dangerous to make predictions, especially in a discipline that changes so rapidly, but one thing I can say with confidence is that I have seen the future, and it is object-oriented.
    • Grady Booch (1996) Object Solutions: Managing the Object-Oriented Project. p. 277
  • The Unified Modeling Language (UML) is a general-purpose visual modeling language that is used to specify, visualize, construct, and document the artifacts of a software system. It captures decisions and understanding about systems that must be constructed. It is used to understand, design, browse, configure, maintain, and control information about such systems. It is intended for use with all development methods, lifecycle stages, application domains, and media. The modeling language is intended to unify past experience about modeling techniques and to incorporate current software best practices into a standard approach. UML includes semantic concepts, notation, and guidelines. It has static, dynamic, environmental, and organizational parts. It is intended to be supported by interactive visual modeling tools that have code generators and report writers. The UML specification does not define a standard process but is intended to be useful with an iterative development process. It is intended to support most existing object-oriented development processes.

2000s

edit
  • All OO languages show some tendency to suck programmers into the trap of excessive layering. Object frameworks and object browsers are not a substitute for good design or documentation, but they often get treated as one. Too many layers destroy transparency: It becomes too difficult to see down through them and mentally model what the code is actually doing. The Rules of Simplicity, Clarity, and Transparency get violated wholesale, and the result is code full of obscure bugs and continuing maintenance problems.
  • The key books about object-oriented graphical modeling languages appeared between 1988 and 1992. Leading figures included Grady Booch [Booch,OOAD]; Peter Coad [Coad, OOA], [Coad, OOD]; Ivar Jacobson (Objectory) [Jacobson, OOSE]; Jim Odell [Odell]; Jim Rumbaugh (OMT) [Rumbaugh, insights], [Rumbaugh, OMT]; Sally Shlaer and Steve Mellor [Shlaer and Mellor, data], [Shlaer and Mellor, states] ; and Rebecca Wirfs-Brock (Responsibility Driven Design) [Wirfs-Brock].
    • Martin Fowler (2004) A Brief Guide to the Standard Object Modeling Language. p. 7

2010s

edit
  • Systems engineering as an approach and methodology grew in response to the increase size and complexity of systems and projects... This engineering approach to the management of complexity by modularization was re-deployed in the software engineering discipline in the 1960s and 1970s with a proliferation of structured methodologies that enabled the the analysis, design and development of information systems by using techniques for modularized description, design and development of system components. Yourdon and DeMarco's Structured Analysis and Design, SSADM, James Martin's Information Engineering, and Jackson's Structured Design and Programming are examples from this era. They all exploited modularization to enable the parallel development of data, process, functionality and performance components of large software systems. The development of object orientation in the 1990s exploited modularization to develop reusable software. The idea was to develop modules that could be mixed and matched like Lego bricks to deliver to a variety of whole system specifications. The modularization and reusability principles have stood the test of time and are at the heart of modern software development.
    • Peter Allen, Steve Maguire, Bill McKelvey (2011) The SAGE Handbook of Complexity and Management. p. 35
edit
 
Wikipedia
Wikipedia has an article about:
Retrieved from "https://en.wikiquote.org/w/index.php?title=Object-orientation&oldid=3401971"