SoftwareSystem Design Principles and Concepts Over the history

Software/System Design: Principles and Concepts • Over the history of software design, general principles were discovered. • This view of design looks at the general principles identified rather than historical development

The Design Problem • Design is a creative, problem-solving activity – No recipe for doing it, always need some type of “magic” – Quality and expertise of designers is determinant for success • Simon: An expert has over 50, 000 chunks of domain knowledge at hand – Solving a problem involves mapping into knowledge available – The larger this knowledge and the more accessible, the more successful the process will be • Brooks, Curtis: Successful software development often depends on a small number of exceptional designers who “think on a system level. ” – Curtis: Such people might not be particularly good programmers

The Design Problem (2) • Design problem: How to decompose system into parts – Each with a lower complexity than system as a whole – While minimizing interaction between the parts Such that the parts together solve the problem No universal way of doing this

Four Primary Design Principles 1. Separation of concerns – Deal with separate aspects of a problem separately 2. Abstraction – Identify important aspects of a phenomenon and ignore details that are irrelevant at this stage – Hierarchical abstraction: build hierarchical layers of abstraction • Procedural (functional) abstraction • Data abstraction • Control abstraction (abstract from precise sequence of events handled, e. g, nondeterminacy) • Object abstraction

Four Primary Design Principles (2) 3. Simplicity – Emphasis on software that is clear, simple, and therefore easy to check, understand, and modify 4. Restricted visibility – Locality of information Is there a fifth? Design should match problem structure

A General Model of Control Human Controller Computer Controller Control Signal Actuator(s) CYBER/Human Feedback Signal Sensor(s) PHYSICAL Control Action Feedback Controlled Process • Software is not unsafe; the control signals it generates can be • Virtually all software-related accidents have resulted from unsafe requirements; not software design/implementation errors

Abstraction/Design for a Control System?

General Software Design Concepts Implementations of the general principles • Decomposition – Can decompose with respect to time order, data flow, logical groupings, access to a common resource, control flow, or some other criterion – Decomposition by function seems to be a natural way for people to solve problems as evidenced by its wide use [Decomposition by objects does not seem to be as natural --- hard to learn] – Top-down decomposition: start at high levels of abstraction and progress to levels of greater and greater detail – Bottom-up: form and layer groups of instruction sequences until work way up to a complete solution.

General Software Design Concepts (2) • Decomposition (con’t) – Iterative decision making process • Put off difficult decisions until more info and decisions less likely to change • Design a module specification to hide each decision • Break module into further design decisions • Continue refining until all design decisions hidden in a module

General Software Design Concepts (3) • Virtual Machines – A module provides a virtual machine: a set of operations that can be invoked in a variety of ways and orders to accomplish a variety of tasks – Instead of thinking of systems in terms of components that correspond to steps in processing, provide a set of virtual machines that are useful for writing many programs • Information Hiding – Each design unit hides internal details of processing activities. – Design units communicate only through well-defined interfaces. – Each design unit specified by as little information as possible. – If internal details change, client units should need no change.

General Software Design Concepts (4) • Modularity – Separation of concerns 1. Deal with details of each module in isolation (ignoring details of other modules) 2. Deal with overall characteristics of all modules and their relationships in order to integrate them into a coherent system – Base on hierarchy and abstraction • Abstraction handled through information hiding • Hierarchy by defining uses and is-composed-of relations – Minimize connectivity

General Software Design Concepts (5) • Modularity (con’t) – Sample things to modularize and encapsulate: • • Abstract data types Algorithms (e. g. , sort) Input and output formats Processing sequence Machine dependencies (e. g. , character codes) Policies (e. g. , when and how to do garbage collection) External interfaces (hardware and software) – Potential benefits • • Allows understanding each part of a system separately Aids in modifying system May confine search for a malfunction to a single module Independent development

Bigger Picture The Design Problem Design Principles Design Concepts Design Methods

Design Methods • Set of guidelines, heuristics, and procedures on how to go about designing a system – Specify a sequence of activities and guidelines for decision making – Usually uses a notation or diagramming method • Trying to provide a systematic means for organizing the design process and its products • Design method may be based on: – Functional decomposition – Data Flow – Data Structures – Control Flow – Objects • Vary in degree of prescriptiveness (but all prescriptive) • Commercial products: often developed and taught by consultants

Michael Jackson (not the singer) • 1975: Jackson Structured Programming (uses a tree-structured diagramming technique) • Analyze data structures of inputs and outputs and then produce program design based on those data structures. • Assumes requirement changes are usually minor tweaks to existing structures.

Michael Jackson (not the singer) • 1983: Jackson System Development – Six steps • • • Entity/action step Initial model step Interactive function step Information function step System timing step System implementation step – Entity structure diagrams, network diagram (all use tree structures) • 1995: Software Requirements and Specifications • 1997: Business Process Implementation • 2001: Problem Frames

Object-Oriented Design Methods • Again a sequence of steps with a fixed set of diagrams – – – Identify objects and group into classes Identify the relationships among classes Create user object model diagram Define user object attributes Define the operations that should be performed on the classes Review glossary • Is object-orientation the best way to view/design all types of systems?

Object/Class Diagram

Readings and Thoughts • David Budgen, Software Design Methods: Life Belt or Leg Iron Will the adoption of a design method help the software development process (be a “life belt”) or is there significant risk that its use will lead to suboptimum solution (be a “leg iron”)? What is his argument? Do you agree or disagree?

Budgen • Argument: – Two general design characteristics 1. “Wicked” nature of any design process Adopting a particular solution approach to a problem may make the task of solving it more intractable, i. e. , the design process is not neutral. 2. Expert designers engage in opportunistic behavior: As solution’s form emerges, problem solving strategy is adapted to meet the new characteristics revealed, i. e. , expert designers do not follow a single method. – These challenge the belief that good software(system) engineering design solutions will most likely come from systematically following a prescriptive procedural method.

Budgen (con’t) • 60’s and 70’s: People recognized that a systematic approach to development needed to cope with large-scale projects. Needed a way to promulgate and encourage the adoption of desirable practices. – A procedural form (do this, then this …) lent itself to this role. – Also easily conveyed through books and courses, easy to teach, easy to write exam questions. – Consultants made enormous amounts of money from selling their methods – Did meet some real needs • By late 70’s, use of procedural form was entrenched.

Budgen (con’t) • But some principles that did not lend themselves to such a form, e. g. , information hiding (for which no satisfactory form of procedural development has been devised) • Reaction in 80’s to shortcomings was to “pile more on” – More diagrammatical forms – More models – More complexity “Arguably, much of this complexity stems from the paradox of object orientation, which seems to provide excellent paradigms for analysis and implementation, but presents major difficulties for the designers. ” • In 90’s, attempts to develop other paradigms for transferring design knowledge, e. g. , patterns and architectures

Budgen (con’t) • Peculiarity of software design: extent to which commercial interests have dominated the codifying of associated practices – More widely known design methods have been developed and marketed largely by consultants and commercial organizations (not academics) – Not true for requirements or testing – Suggests a real need for design skills, but does not create an objective forum for evaluation • Conclusion: – Life belt has become waterlogged and acting more like a leg iron – Need to stop pretending that software [system? ] design is largely a matter of following a set of well-defined activities. Recognize it as a creative process that requires us to develop design skills. – How do we identify, grow, and encourage those talents needed for the great designers who will create elegant and effective solutions to problems?

Takeaways • Design is a creative, problem solving activity. • Some general principles, but no universally “right” design process/method – Attempts to create one have increased adequate design but decreased great design (and made some people very rich) – Should we be focusing on providing one universal design process? A few design methods? Or should we focus on identifying and training great designers? • Perhaps a way forward is to 1. Make structure of design match problem (last week) 2. Make design process match problem structure • E. g. , object-oriented, function-oriented, control-oriented

Bigger Picture • What is the problem? How to Solve it? • System Engineering and Systems Theory • Process and Life Cycle Models • Requirements and Specification • Design Principles • Human-Centered Design • Building Confidence (Testing, Analysis, QA, Reviews) • Metrics • COTS and Reuse • Team Building, Managing People, Wrap up