Ed Yourdon

Edward Nash Yourdon (born 30 April 1944) is an American software engineer, computer consultant, author and lecturer, and pioneer in the software engineering methodology.

Quotes

 * A system composed of 100,000 lines of C++ is not be sneezed at, but we don't have that much trouble developing 100,000 lines of COBOL today. The real test of OOP will come when systems of 1 to 10 million lines of code are developed.
 * Yourdon (1990) cited in: Andreas Paepcke (1991) Object-oriented Programming Systems, Languages and Applications. p. 166.

Structured design: fundamentals of a discipline of computer program and systems design (1979)
Edward Yourdon and Larry L. Constantine (1979) Structured design: fundamentals of a discipline of computer program and systems design. Prentice-Hall, Inc.


 * Elements (lines of code) in a coincidentally-cohesive module have no relationship. Typically occurs as the result of modularizing existing code, to separate out redundant code.
 * p. 109; as cited in "Design" at swansonsoftware.com Draft Version 0.9, December 3 2005.

Object-oriented design (1991)
Peter Coad & Ed Yourdon (1991) Object-oriented design.


 * Designed as a companion volume to the acclaimed Object-Oriented Analysis, this book focuses on the middle part of the software lifecycle: the activity of design. It shows readers how to apply object-oriented design, and how to tailor and expand the method to suit specific organization and project needs. Readers will explore the major issues in OOD; the role of OOD in the systems lifecycle; how to use graphical notation; strategies for creating design; and hints for evaluating the efficiency of a design created with OOD. For software engineers and other users undertaking real-world systems development projects and designing overall software architecture for systems will find this reference approach to improving systems design indispensable.
 * Abstract.


 * OOA - Object-Oriented Analysis - is based upon concepts that we first learned in kindergarten: objects and attributes, wholes and parts, classes and members.
 * p. 1; cited in: Sten Carlsson and Benneth Christiansson. (1999) "The Concept of Object and its Relation to Human Thinking: Some Misunderstandings Concerning the Connection between Object-Orientation and Human Thinking." Informatica, Lith. Acad. Sci. 10.2. p. 147-160.


 * [Object-oriented analysis is] the challenge of understanding the problem domain and then the system's responsibilities in that light.
 * p. 8-9; as cited in: Elisa Bertino, ‎Susan Urban (1994) Object-Oriented Methodologies and Systems. p. 160.


 * To us, analysis is the study of a problem domain, leading to a specification of externally observable behavior; a complete, consistent, and feasible statement of what is needed; a coverage of both functional and quantified operational characteristics (e.g. reliability, availability, performance).
 * p. 18.


 * Subject. A Subject is a mechanism for guiding a reader (analyst, problem domain expert, manager, client) through a large, complex model. Subjects are also helpful for organizing work packages on larger projects, based upon initial OOA investigations.
 * p. 106.

Quotes about Ed Yourdon

 * 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.