Grady Booch

Object-oriented development

Object-oriented development is a partial-lifecycle software development method in which the decomposition of a system is based upon the concept of an object. This method is fundamentally different from traditional functional approaches to design and serves to help manage the complexity of massive software-intensive systems. The author examines the process of object-oriented development as well as the influences upon this approach from advances in abstraction mechanisms, programming languages, and hardware. The concept of an object is central to object-oriented development and so the properties of an object are discussed. The mapping of object-oriented techniques to Ada using a design case study is considered.

Object-oriented design

The current software depression is characterized by software that is late, erroneous, and costly. Experience indicates that the application of appropriate design methodolgies, embodied in a high-order language, is appropriate in combatting this depression. In particular, this paper describes an object-oriented design methodology, using Ada as the implementation language.

Collaborative Development Environments

Abstract A collaborative development environment (CDE) is a virtual space wherein all the stakeholders of a project—even if distributed by time or distance—may negotiate, brainstorm, discuss, share knowledge, and generally labor together to carry out some task, most often to create an executable deliverable and its supporting artifacts. CDEs are particularly useful as places where engineers may collaborate to solve problems. Here we focus on software developers in their tasks of designing, implementing, deploying, and maintaining high quality software-intensive systems where they are physically separated and make use of the Internet as the basis for their interactions. In this paper, we examine the points of friction in the software development process and the mechanisms that reduce that friction. We then survey a variety of sites, both inside and outside the software domain, which provide some of these mechanisms. We conclude with observations as to what a CDE is, what it is not, and what it can become.

Reusing Open-Source Software and Practices: The Impact of Open-Source on Commercial Vendors

One of the most intriguing ways that commercial developers of software can become more efficient is to reuse not only software but also best practices from the open-source movement. The open-source movement encompasses a wide collection of ideas, knowledge, techniques, and solutions. Commercial software vendors have an opportunity to both learn from the open-source community, as well as leverage that knowledge for the benefit of its commercial clients. This paper looks at a number of the characteristics of the open-source movement, offers a categorization of open-source dimensions, and provides an analysis of the opportunities available to commercial software vendors when applying the lessons from the open-source movement.

UML in action

ing, insurance, telephony, robotics, and avionics. The UML transcends most traditional programming languages: there are mappings from the UML to Java, C++, Smalltalk, Visual Basic, Ada, and many 4GLs. The UML even applies to all of the commercial middleware architectures, including Enterprise Java Beans (EJB), the OMG’s CORBA, and Microsoft’s DNA. The UML has also found a place in codifying architectural frameworks: IBM’s San Francisco frameworks and their Insurance Application Architecture both use the UML. The UML may not get the media attention of, for example, EJB, DNA, or XML, but in the past several years it has quietly proven itself to be an essential tool for building quality systems in an efficient and predictable fashion. The UML had its beginnings in the late 1980s. Faced with a new genre of object-oriented programming languages and increasingly complex applications, methodologists began to experiment with alternative approaches to analysis and design. The number of OO methods increased from fewer than 10 to more than 50 between 1989 and 1994. Many users of these methods had trouble finding a modeling language that met their needs completely, thus fueling the socalled method wars. As users learned from experience, new generations of these methods began to appear, a few clearly prominent, most notably Booch, Jacobson’s Object-Oriented Software Engineering (OOSE), and

The design of the C++ Booch Components

This paper describes design issues encountered developing a reusable component library. The design applied encapsulation, inheritance, composition and type parameterization. The implementation uses various C++ mechanisms, including: virtual and static member functions, templates, and exceptions. The resulting library contains about 500 components (mostly template classes and functions) and an optional utility for instantiating templates. The components provide variations of basic collection/container abstractions with various time and space complexities. A key insight gained from this project: the design process centered on developing a “template for the templates” — designing a component framework and orderly process for generating the template classes.

The Irrelevance of Architecture

The architecture of a software-intensive system is largely irrelevant to its end users. Far more important to these stakeholders is the systems behavior, exhibited by raw, naked, running code. Most interesting system tests should be based on the use cases that are identified incrementally over the systems life cycle, the same use cases that the systems architects used to guide their design decisions. Testers can conduct other system tests only after the systems architecture is crisp. Just as analysts use a systems architecture as scaffolding along which to climb and examine the details of every edge, so too can testers use a systems architecture to devise tests that are relevant to the particular texture of that implementation

An Architectural Oxymoron

In this paper, oxymoron is discussed. An oxymoron is not a bovine of meager intelligence, nor is it a chemical compound with two covalently bound oxygen atoms. Rather, an oxymoron is a figure of speech that combines two seemingly contradictory terms and unites them in an apparent paradox. This paper focuses specifically on the oxymoron of agile software architecture.

Enterprise Architecture and Technical Architecture

Enterprise architecture and technical architecture are related yet different: whereas EA focuses on the architecture of a business that uses software-intensive systems, TA focuses on the architecture of the software-intensive systems that are used by a business to makes its mission manifest.

The Economics of Architecture-First

Architecture is an artifact thats governed throughout the software life cycle - from conception through development to deployment and finally evolution, then to adaptation, assimilation, replacement, or abandonment. Similarly, the architect, either as an individual, a role, or a team, lovingly crafts, grows, and governs that architecture as it emerges from the thousands of individual design decisions of which its composed. In this sense, an architecture-first approach appears to be a reflection of sound development practices. Now, strict agilists might counter that an architecture-first approach is undesirable because we should allow a systems architecture to emerge over time. More than just a reflection, however, a software development process that swirls around the growth of a software-intensive systems architecture has considerable material value.