Software Engineering Design

Theory and Practice

Carlos Otero

• Publisher: Auerbach Publications
• Year: 2016
• ISBN:
  9781466510159
• Edition: 1
• Topic: Computer Science
• Subtopic: Information Technology
• Index: Computer Science

Taking a learn-by-doing approach, Software Engineering Design: Theory and Practice uses examples, review questions, chapter exercises, and case study assignments to provide students and practitioners with the understanding required to design complex software systems. Explaining the concepts that are immediately relevant to software designers, it be

1

Introduction to Software Engineering Design

CHAPTER OBJECTIVES

• Understand software design from the engineering perspective

• Understand the importance of software design in developing complex products

• Understand the issues that make software design challenging

• Understand the software design process and differentiate between its activities

• Become familiar with software design principles, considerations, and strategies

CONCEPTUAL OVERVIEW

Software design is an indispensable phase of the software engineering process for creating and evaluating software models that guide the construction effort for developing high-quality software systems on time and within budget. Conceptually, design is the process of transforming functional and nonfunctional requirements into models that describe the technical solution before construction begins. To achieve this, the concept of software design, its activities, and tasks must be well understood so that a problem-solving framework for designing quality into software products can be established. In today’s modern software systems, there are numerous design principles, processes, strategies, and other factors affecting how designers execute the software design phase. When equipped with the proper design foundation knowledge, an understanding of the designer’s roles and responsibilities can be acquired, allowing designers to become effective in designing large-scale software systems under a wide variety of challenging conditions. This chapter presents the fundamental concepts of software engineering design, within context, and provides the motivation for the rest of the book.

ENGINEERING DESIGN

Design is an integral part of every engineering discipline. Airplanes, bridges, buildings, electronic devices, cars, and many other products of similar complexity are all designed. In civil engineering, designs are used to specify detailed plans for developing physical and naturally built environments, such as bridges, roads, canals, dams, and buildings. In electrical engineering, designs are used to capture, evaluate, and specify the detailed qualitative and quantitative description of solutions for telecommunication systems, electrical systems, and electronic devices. In mechanical engineering, designs are used for analyzing, evaluating, and specifying technical features required to construct machines and tools, such as industrial equipment, heating and cooling systems, aircrafts, robots, and medical devices. In all other engineering disciplines, design provides a systematic approach for creating products that meet their intended functions and users’ expectations. Formally, Dym and Little (2008, p. 6) define engineering design as

A systematic, intelligent process in which designers generate, evaluate and specify designs for devices, systems or processes whose form(s) and function(s) achieve clients’ objectives and users’ needs while satisfying a specified set of constraints.

Design is a lengthy and complex process requiring significant investments in time and effort. So why conduct design in engineering disciplines? There are many possible answers to this question, stemming from simple common sense to more complicated ones involving professional, ethical, social, and legal implications. From the commonsense perspective, products of such complexity are hard to create, are costly to change, and, when built carelessly or incorrectly, can significantly impact human life. When working toward the creation of complex products, teams must organize in a disciplined manner, and a systematic approach needs to be employed to carefully ensure that products are built to meet their specifications. Consider the construction of a bridge that spans over a body of water and is required to support a particular weight, to maintain access to watercrafts navigating underneath, to withstand expected wind speeds, and to provide other features such as sidewalks—all while being bound by a schedule and budget. The successful construction of such a bridge is a nontrivial task and requires years of experience, formal education, and large teams collaborating together to achieve the construction goals. If constructed incorrectly­, reconstructing the bridge can skyrocket from its original construction cost; worse yet, if defects are undetected, the bridge could collapse, resulting in the catastrophic loss of human life. Similar to the construction of the bridge, teams engineering other products, such as airplanes, watercrafts, medical devices, and safety-critical software ­systems, share comparable challenges, and failure of these products can also result in ­catastrophic events. In an engineering environment, before product construction begins, the design of products needs to be carefully and extensively planned, evaluated, verified, and validated to ensure the product’s success. This is mainly achieved through design.

ENGINEERING PROBLEM SOLVING

Throughout the design process, designers are constantly engaging in problem-solving activities that are fundamental to all modern engineering projects. In a broad sense, engineers can be characterized as specialized problem solvers. Their work requires them to identify, evaluate, and propose solutions to complex problems (in particular domains) under tight project constraints. In some situations, engineers tackle problems that have never been solved before, creating challenges to meet not only functional aspects of products but also their established schedule and budget. Before engaging in more concrete design topics, a formal discussion on problem solving is necessary to identify fundamental concepts that are well understood by successful designers; these serve as basis for establishing a holistic problem solving framework that can be employed any time during design.

To become a good designer, engineers must be good problem solvers. This may require years of experience solving problems in a particular domain. In many cases, experience allows engineers to reuse already proven solutions across separate but similar problems. In other cases, where unsolved problems are encountered, designers are required to “think out of the box” and carefully craft a systematic approach for solving the problem in an acceptable manner, which may require problem classification, identification of the solution approach and type of adequate solution, and identifying the overall strategy for reaching its solution. In a general sense, problem solving during design occurs in three different states (Plotnik and Kouyoumdjian 2010):

• Initial state

• Operation state

• Goal state

Through these states, designers employ several techniques and strategies to create a landscape suitable for problem solving. The initial state is where problems are formulated and interpreted. In some cases, achieving full understanding of the problem is a problem itself. Once problems are well understood, designers move to the operational state, where thinking about the problem occurs and viable solutions come to light. Once an appropriate solution is identified, evaluated, and validated, designers move to the goal state, where a final solution to the problem is found, marking the end of the problem-solving process.

TABLE 1.1
Problem Classification

Problem	Description
Well-defined	Problem with clear goals and known constraints
Ill-defined	Problem with undefined or ambiguous goals and unknown constraints
Wicked	Problem with no definite solution; not understood until after the formulation of its solution

Initial State

Design problems are not all the same; they vary in size, complexity, and, based on these characteristics, the amount of time and effort required for their solution. In some cases, it quickly becomes evident that certain problems are harder to solve than others. When this determination is made, the strategy for the solution approach is adjusted to account for the additional complexity. Being able to differentiate between types of problem is crucial in helping designers account for the amount of effort, time, and risk associated with the solution approach. Therefore, an important problem-solving skill involves identifying and classifying the type of problem encountered, which includes well-defined, ill-defined, and wicked problems, as presented in Table 1.1 (Giachetti 2010).

Well-defined problems have clear defined goals and their constraints are well understood. This makes scoping the problem, proposing a solution approach, and arriving at the solution easier than with other types of problems, such as ill-defined and wicked problems. Ill-defined problems are problems where the mere interpretation of the problem is a problem itself; they are ambiguous with undefined goals and require more time and effort to clarify and interpret the problem to arrive at a solution. In some cases, with additional effort, ill-defined problems can be transformed into well-defined problems. Finally, wicked problems are problems where no single problem formulation exists. There may be many acceptable formulations of the problem and no definite solutions, and solutions are not deemed correct or incorrect but good or bad (Giachetti 2010). In many cases, wicked problems can lead to contradictive goals that need additional resolution before the problem solving can occur. When contradictive goals are present, providing a solution to one part of the problem results in the inability of solving other parts of the problem. In these types of problem, optimal solutions are hard to find, requiring additional struggle and collaborative brainstorming. Also, evaluation of alternative designs may require advanced techniques to determine the best course of action, which tends to require more time. In many cases, the solution to wicked problems is not known until after the problem is solved.

Operational State

The operational state of problem solving is where thinking about the problem solution takes place. It requires employing multiple techniques for problem solving such as using metaphors, decomposing problems into smaller, less complex problems (i.e., divide and conquer), reusing solutions (e.g., patterns), and so forth. In all of the techniques, designers are expected to exhibit a “think outside the box” mentality to be able to solve complex problems. This requires shifting the mental model from a conventional approach to unconventional methodology where solutions to complex problems may arise from thinking in ways that deviate from conventional wisdom. For example, consider the popular nine-dot puzzle illustrated in Figure 1.1 (Kershaw and Ohlsson 2004).

FIGURE 1.1
The nine-dot puzzle.

The requirements for solving the nine-dot puzzle problem are as follows:

1. Draw four straight lines to connect all dots.

2. The pencil cannot be lifted from the paper once the line-drawing process begins.

3. No lines can be retraced.

Before moving on, think about this problem and attempt to provide a solution. At first, this may seem difficult because of the tendency of fixing the mental process to operate on the assumption that lines should begin and end on a dot. This functional fixedness limits the ability to find solutions based on objects having a different function from their usual ones (Plotnik and Kouyoumdjian 2010). In the case of the nine-dot puzzle, for some, functional fixedness makes it awkward or even impossible to propose solutions that involve lines going past the dots, which is what is required to solve this problem. To increase the chance of overcoming functional fixedness, problems need to be attempted several times and considered from many different viewpoints and unusual angles (Plotnik and Kouyoumdjian). Overcoming functional fixedness is critical for designers attempting to provide solutions at the operational state of problem solving.

Thinking about the Problem

Different types of thinking take place when finding solutions to problems. For example, when learning about a problem for the first time, problem solvers may begin by asking questions, which allows them to think about many different alternative solutions; as the problem-solving process moves forward, problem solvers can begin narrowing down the possibilities and think about the single best solution to the problem. These types of thinking are known as convergent thinking and divergent thinking (Table 1.2).

Both convergent and divergent thinking have significant roles in solving engineering problems. In many cases, problem solvers begin using divergent thinking with different levels of abstraction, and each level provides finer-grained solutions to the problem until convergent thinking can be employed to solve it.

TABLE 1.2
Types of Thinking

Type	Description
Convergent thinking	Type of thinking that seeks to find one single solution to a problem
Divergent thinking	Type of thinking that seeks to find multiple solutions to a problem

TABLE 1.3
Types of Problem Solution

Problem	Description
Algorithm	Fixed set of rules that lead to the solution of a problem
Heuristic	Rules of thumb (or procedure) that may or may not lead to the solution of a problem

Problem Solution

In many cases, determining the type of solution required for a given problem can reduce wasted time and effort spent in attempting to find a single, optimal solution. In such cases, designers can elect to seek approximate solutions—as opposed to optimal solutions—that are appropriate and acceptable for meeting project constrain...

Table of contents

• Cover
• Title Page
• Copyright
• Dedication
• Contents
• Preface
• Acknowledgments
• About the Author
• Chapter 1: Introduction to Software Engineering Design
• Chapter 2: Software Design with Unified Modeling Language
• Chapter 3: Principles of Software Architecture
• Chapter 4: Patterns and Styles in Software Architecture
• Chapter 5: Principles of Detailed Design
• Chapter 6: Creational Design Patterns in Detailed Design
• Chapter 7: Structural and Behavioral Patterns in Detailed Design
• Chapter 8: Principles of Construction Design
• Chapter 9: Human–Computer Interface Design
• Chapter 10: Software Design Management, Leadership, and Ethics
• Index