Jump to content

Edward V. Berard

Edit links
From Wikiquote

Edward V. Berard (born ca 1950) is an American software engineer and consultant for The Object Agency, Inc.

Quotes

[edit]
  • Recently, I have had conversations with a number of people who were attempting their first object-oriented project. Most of these people claimed to be using “use cases” in their object-oriented analysis and design approaches. However, listening to them describe their projects, it became quite apparent to me that there is a great deal of confusion regarding the definition, context, and use of use cases. This confusion can (and often does) lead to poorly-designed systems.
  • Software people seem to have a love-hate relationship with metrics. On one hand, they despise and distrust anything that sounds or looks like a measurement. They are quick to point out the "flaws" in the arguments of anyone who talks about measuring software products, software processes, and (especially) software people. On the other hand, these same people seem to have no problems identifying which programming language is the best, the stupid things that managers do to "ruin" projects, and who's methodology works in what situations.

Essays on object-oriented software engineering (1993)

[edit]

Edward V. Berard (1993) Essays on object-oriented software engineering. Volume 1. Englewood Cliffs, N.J. : Prentice Hall

  • 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.
    • p. 5
  • Walking on water and developing software from a specification are easy if both are frozen.
    • p. 46
  • Object-oriented domain analysis seeks to identify reusable items localized around objects e.g., classes, instances, systems of interacting objects, and kits.
    • p. 185
  • An object which is used to create instances, i.e., a template, description, pattern, or "blueprint" of a category or collection of very similar items. Among other things, a class describes the interface the these items will present to the outside world, i.e., the available and appropriate methods, constants, and exceptions. A class represents an abstraction of the items. A class may itself be parameterized (i.e., it actually represents a family of very closely related classes), in which case we refer to it as a parameterized class. Class is a recursive concept. Specifically, we may define classes as being composed of other classes (i.e., heterogeneous composite classes and homogeneous composite classes), in terms of itself (a recursively defined class), as inheriting characteristics from one or more other classes (i.e., the superclasses of the class), and as providing characteristics to other classes (i.e., the subclasses of the class). In some places, classes are defined as "the set of all instances of a type," and the term "type" is given the above definition for class.
    • p. 328
  • Objects are the real and conceptual things we find in the world around us. An object may be hardware, software, a concept (e.g., velocity), or even "flesh and blood." Objects are complete entities, i.e., they are not "simply information" or "simply information and actions." Software objects strive to capture as completely as possible the characteristics of the "real world" objects which they represent. Finally, objects are "black boxes," i.e., their internal implementations are hidden from the outside world, and all interactions with an object take place via a well-defined interface.
  • An action which is suffered by, or required of, an object. Operations may be selectors, constructors, or iterators. An operation is contained in an object's interface and has its details described in a corresponding method. Operations may be composite, i.e., composed of other operations. However, encapsulation of composite operations within the interface to an object is not encouraged.
    • p. 336

Object‐Oriented Design (2002)

[edit]

Edward V. Berard (2003) "Object‐Oriented Design." in Encyclopedia of Software Engineering

  • Work on what was to become “structured design” began in the early 1960s. Structured design, as a well-defined and named concept, did not achieve appreciable visibility until the publication of an article in the IBM Systems Journal in 1974 (Stevens et al., 1974). There is more than one way to accomplish a “structured design.”
    • Abstract
  • Like structured design, the term object-oriented design (OOD) means different things to different people. For example, OOD has been used to imply such things as
    • The design of individual objects, and/or the design of the individual methods contained in those objects
    • The design of an inheritance (specialization) hierarchy of objects
    • The design of a library of reusable objects
    • The process of specifying and coding of an entire object-oriented application
The term nonformal is used to describe approaches to OOD that are not well defined, step-by-step, or repeatable, such as those that emphasize the design of individual objects, specialization (inheritance) hierarchies, and libraries of objects...
  • Abstract
[edit]
Retrieved from "https://en.wikiquote.org/w/index.php?title=Edward_V._Berard&oldid=2594945"