Jump to ContentJump to Main Navigation
Beyond ProgrammingTo A New Era of Design$
Users without a subscription are not able to see the full content.

Bruce I. Blum

Print publication date: 1996

Print ISBN-13: 9780195091601

Published to Oxford Scholarship Online: November 2020

DOI: 10.1093/oso/9780195091601.001.0001

Show Summary Details
Page of

PRINTED FROM OXFORD SCHOLARSHIP ONLINE (oxford.universitypressscholarship.com). (c) Copyright Oxford University Press, 2021. All Rights Reserved. An individual user may print out a PDF of a single chapter of a monograph in OSO for personal use. date: 28 November 2021

Design Methods

Design Methods

Chapter:
10 (p.271) Design Methods
Source:
Beyond Programming
Author(s):

Bruce I. Blum

Publisher:
Oxford University Press
DOI:10.1093/oso/9780195091601.003.0017

The previous chapter on the software process introduced two contrasting orientations: problem and product. Both orientations have the same objective: the efficient and effective creation of an automated response to a real-world problem. They differ only in the methods and tools used to achieve that end. In the product-oriented model, the difficulty of realizing a solution is accepted as the critical path. Thus, the approach applies the principle of separation of concerns and divides the process into two discrete activities: first establish the essential requirements of what is needed, and then build a product that will satisfy those requirements. As already noted, this model is appropriate when the requirements are stable or if the complexity of development is so great that a fixed specification is necessary to reduce risk. In contrast, the problemoriented model is valuable for real-world problems with open requirements (open both in the sense of initial uncertainty and of operational change). Unfortunately, it can be implemented only for domains in which the technology is relatively mature. For example, military applications that push the limits of technology have open requirements (i.e., they begin with uncertainty and are subject to modification as potential adversaries develop responses to newly introduced capabilities). In this domain, however, the technology may be too complex for development without frozen requirements. In other domains, such as interactive information systems, the technological challenges are sufficiently well understood to permit a problem-oriented approach with its one-step process model. The adaptive design paradigm proposed in this book is problem oriented. The instantiation I describe in the next two chapters creates interactive information systems. In principle, there is no reason why the adaptive design model may not be used for complex, real-time military applications; the fact that it has not been so used is a function of our knowledge of that domain and not a limitation of the paradigm. There always will be a fuzzy boundary about the technology that separates what we can and cannot do. At that boundary, we must rely on experimentation and hacking to gain understanding.

Keywords:   Abstract data types, Cleanroom, Data-flow diagram, Entity-relationship model, Formal specification languages, GOTO-less programming, Information hiding, Language/action design

Oxford Scholarship Online requires a subscription or purchase to access the full text of books within the service. Public users can however freely search the site and view the abstracts and keywords for each book and chapter.

Please, subscribe or login to access full text content.

If you think you should have access to this title, please contact your librarian.

To troubleshoot, please check our FAQs , and if you can't find the answer there, please contact us .