Essential Software Design Principles and Concepts

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 Feedback Signal CYBER/Human Sensor(s) Actuator(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 (cont) 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 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 (cont) 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 (cont) 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