SWEBoK Design Flashcards
1
Q
Software Design
A
activity in which requirements are analyzed in order to produce a description of the software’s internal structure that will serve as the basis for its construction
2
Q
Two Main Activities of Design
A
- Architectural Design
- Software Detailed Design
3
Q
Wicked Problem
A
A problem with no definitive solution
4
Q
General Design Concepts
A
Form of Problem Solving
Also includes goals, constraints, alternatives, representations, and solutions
5
Q
Architectural Design
A
High-Level Design
describes how software is organized into components
6
Q
Detailed Design
A
describes the desired behavior of architectural components
7
Q
Design Principle
A
Key notations that provide the basis for many different design approaches and concepts.
8
Q
Abstraction
design principle
A
a view of an object that focuses on information relevant to a specific purpose and ignores the remainder of information.
9
Q
Coupling
design principle
A
a measure of the interdependence among modules in a computer program
10
Q
Cohesion
design principle
A
a measure of the strength of association of the elements within a module
11
Q
Decomposition and Modularization
design principle
A
means that large software systems are divided into a number of smaller named components having well-defined interfaces that describe component interaction.
12
Q
Encapsulation and Information Hiding
design principle
A
means grouping and packaging the internal details of an abstraction and making those details inaccessible to external entities
13
Q
Separation of Interface and Implementation
design principle
A
involves defining a component by specifying a public interface that is separate from the details of how the components is realized
14
Q
Sufficiency, Completeness
design principle
A
means ensuring that a software component captures all the important characteristics of an abstraction and nothing more
15
Q
Primitiveness
design principle
A
means the design should be based on patterns that are easy to implement
16
Q
Separation of Concerns
design principle
A
“area of interest with respect to a software design”
an area of design that is relevant to one of more of its stakeholders.
Separating concerns by views allows interested stakeholders to focus on a few things at a time and offers a means of managing complexity
17
Q
Key Issues in Design
A
Issues that must be dealt with in designing software
18
Q
Concurrency
key issue
A
decomposing software into processes, tasks, and threads and dealing with related issues of efficiency, atomicity, sychronicity, and scheduling
19
Q
Control
key issue
A
concerned with how to organize data add control flow
20
Q
Handling Events
key issue
A
concerned with how to handle reactive and temporal events through various mechanisms such as implicit invocation and call-backs
21
Q
Data Persistence
key issue
A
how to handle long-lived data
22
Q
Distribution of Components
key issue
A
how to distribute the software across the hardware (including local and network), how the components communicate, and how middleware can be used to deal with heterogeneous software
23
Q
Error and Exception Handling and Fault Tolerance
key issue
A
how to prevent, tolerate, and process errors and deal with exceptional conditions
24
Q
Interaction and Presentation
key issue
A
how to structure and organize interactions with users as well as the presentation of information
(eg. separation of presentation and business logic using MVC)
NOTE: This does not specify user interface details
25
Security
| key issue
how to prevent unauthorized disclosure, creation, change, deletion, or denial of access to information and other resources.
also how to tolerate sec-related attacks or violations by limiting damage, continuing service, speeding repair and recovery, and failing and recovering securely
26
Software Structure and Architecture
“the set of structures needed to reason about
the system, which comprise software elements,
relations among them, and properties of both”
27
Architectural Structures and Viewpoints
| architecture
Different high-level facets of a software design
can be described and documented.
(Facet) View: “A view represents a partial
aspect of a software architecture that shows specific properties of a software system”
Views pertain to distinct issues associated with software
design.
28
Logical View
satisfying the functional requirements
29
physical view
distribution issues
30
development view
how the design is broken down into implementation units
with explicit representation of the dependencies
among the units
31
Architectural Styles
| architecture
“a specialization of element and relation types, together with a set of
constraints on how they can be used”
provides the software’s high-level organization
32
```
General structures
(major architectural style)
```
How programs in software are structured to handle problems
33
Distributed systems
| major architectural style
Software distributed over a series of interconnected hardware components whether locally or over a network
34
Interactive systems
| major architectural style
Software designed around interactions with the user and how data is hidden or loaded (MVC)
35
Adaptable systems
| major architectural style
Software designed to adapt to the environment it is in or one being migrated to or to changing requirements. Being agnostic.
36
Design Patterns
| architecture
“a common
| solution to a common problem in a given context”
37
3 Lower Level Design Patterns
• Creational patterns (for example, builder,
factory, prototype, singleton)
• Structural patterns (for example, adapter,
bridge, composite, decorator, façade, flyweight, proxy)
• Behavioral patterns (for example, command,
interpreter, iterator, mediator, memento,
observer, state, strategy, template, visitor).
38
Architecture Design Decisions
| architecture
software designers make to make a number of fundamental decisions that
profoundly affect the software and the development process.
decision-based, software affecting
39
Families of Programs and Frameworks
| architecture
-families of programs, also known as software product lines
-can be done by identifying the commonalities
among members of such families and by designing
reusable and customizable components to account
for the variability among family members.
40
User Interface Design
ensuring that interaction between the human
| and the machine provides for effective operation and control of the machine
41
General User Interface Design Principles
| ui design
- Learnability
- User familiarity
- Consistency
- Minimal surprise
- Recoverability
- User guidance
- User diversity
42
Learnability
| ui design principle
The software should be easy to
| learn so that the user can rapidly start working with the software.
43
User familiarity
| ui design principle
The interface should use
| terms and concepts drawn from the experiences of the people who will use the software.
44
Consistency
| ui design principle
The interface should be consistent so that comparable operations are activated in the same way
45
Minimal surprise
| ui design principle
The behavior of software
| should not surprise users
46
Recoverability
| ui design principle
The interface should provide
mechanisms allowing users to recover from
errors
47
User guidance
| ui design principle
The interface should give
meaningful feedback when errors occur and
provide context-related help to users
48
User diversity
| ui design principle
```
The interface should provide appropriate interaction mechanisms
for diverse types of users and for users with
different capabilities (blind, poor eyesight,
deaf, colorblind, etc.).
```
49
User Interface Design Issues
| ui design
Answered by two questions:
• How should the user interact with the
software?
• How should information from the software
be presented to the user?
50
The Design of User Interaction Modalities
| ui design
User interaction styles can be classified and this category discusses how to approach them.
51
Question-answer
| ui interaction
The interaction is essentially restricted to a single
question-answer exchange between the user and the software. The user issues a question to the software, and the software returns the answer to the question
52
```
Direct manipulation
(ui interaction)
```
Users interact with objects on the computer screen. Direct manipulation often includes a pointing device (such as a mouse, trackball, or a finger on touch screens) that manipulates an object and invokes actions that specify what is to be done with that object.
53
```
Menu selection
(ui interaction)
```
The user selects a command from a menu list of commands.
54
Form fill-in
| ui interaction
The user fills in the fields of a form. Sometimes fields include menus, in which case the form has action buttons for the user to initiate action.
55
```
Command language
(ui interaction)
```
The user issues a command and provides related parameters to direct the software what to do.
56
```
Natural language
(ui interaction)
```
The user issues a command in natural language. That is, the natural language is a front end to a command language and is parsed and translated into software commands
57
The Design of Information Presentation
| ui design
Information presentation may be textual or graphical in nature. A good design keeps the information
presentation separate from the information itself
58
Information Presentation Guidelines
| ui design
• Limit the number of colors used.
• Use color change to show the change of software status.
• Use color-coding to support the user’s task.
• Use color-coding in a thoughtful and consistent way.
• Use colors to facilitate access for people
with color blindness or color deficiency
(e.g., use the change of color saturation and
color brightness, try to avoid blue and red
combinations).
• Don’t depend on color alone to convey
important information to users with different
capabilities (blindness, poor eyesight, colorblindness, etc.).
59
User Interface Design Process
| ui design
iterative process;
interface prototypes are often used to determine
the features, organization, and look of the software user interface
60
3 Core Activities of User Interface Design
• User analysis. In this phase, the designer analyzes the users’ tasks, the working environment, other software, and how users interact
with other people.
• Software prototyping. Developing prototype
software help users to guide the evolution of
the interface.
• Interface evaluation. Designers can observe
users’ experiences with the evolving interface.
61
Localization and Internationalization
| ui design
means adapting software to the different languages, regional differences, and the technical requirements of a target market
62
Metaphors and Conceptual Models
| ui design
use metaphors and conceptual models to set up mappings between the software and some reference system known to the users in the real world, which can help the users to more readily learn and use the interface
63
Software Design Quality Analysis and
| Evaluation
Series of topics used for quality analysis of a software design.
64
Quality Attributes
| quality analysis
“-ilities”
(maintainability, portability, testability, usability)
and “-nesses”
(correctness, robustness) that contribute to the quality of SW Design
65
Quality Analysis and Evaluation Techniques
| quality analysis
* Software design reviews
* Static analysis
* Simulation and prototyping
66
Measures
| quality analysis
used to assess or to quantitatively estimate various aspects of a software
design; for example, size, structure, or quality.
67
2 Types of Quality Analysis Measures
• Function-based (structured) design measures: measures obtained by analyzing functional decomposition; generally represented
using a structure chart (sometimes called a
hierarchical diagram) on which various measures can be computed.
• Object-oriented design measures: the design
structure is typically represented as a class
diagram, on which various measures can be
computed. Measures on the properties of the
internal content of each class can also be
computed.
68
Software Design Notations
notations that exist to represent software design
artifacts. Some are used to describe the structural
organization of a design, others to represent software behavior
69
```
Structural Descriptions (Static View)
(notations)
```
describe and represent the structural
aspects of a software design—that is, they are
used to describe the major components and how
they are interconnected (static view)
70
Architecture description languages (ADLs)
| structural notations
textual, often formal, languages used to
describe software architecture in terms of
components and connectors
71
Class and object diagrams
| structural notations
used to represent a set of classes (and objects) and their
| interrelationships
72
```
Component diagrams
(structural notations)
```
used to represent a set of components (“physical and replaceable part[s] of a system that [conform] to and [provide] the realization of a set of interfaces” [18]) and their interrelationships
73
Class responsibility collaborator cards
(CRCs)
(structural notations)
used to denote the names of components (class), their responsibilities, and their
collaborating components’ names.
74
```
Deployment diagrams
(structural notations)
```
used to represent a set of (physical) nodes and their interrelationships, and, thus, to model the physical aspects of software
75
Entity-relationship diagrams (ERDs)
| structural notations
used to represent conceptual models of data stored
| in information repositories.
76
Interface description languages (IDLs)
| structural notations
programming-like languages used to define the interfaces (names and types of exported operations) of software components.
77
```
Structure charts
(structural notations)
```
used to describe the calling structure of programs (which modules call, and are called by, which other modules).
78
```
Behavioral Descriptions (Dynamic View)
(notations)
```
describe the dynamic behavior of software systems and
components. Many of these notations are useful mostly, but not exclusively, during detailed design. Moreover, behavioral descriptions can include a rationale for design decision such as how a design will meet security requirements.
79
Activity diagrams
| dynamic notations
used to show control flow from activity to activity. Can be used to represent concurrent activities
80
Communication diagrams
| dynamic notations
used to show the interactions that occur among a group
| of objects; emphasis is on the objects, their links, and the messages they exchange on those links.
81
Data flow diagrams (DFDs)
| dynamic notations
used to show data flow among elements. A data flow diagram provides “a description based on modeling the flow of information around a network of operational elements, with each element making use of or modifying the information flowing into that element” [4*].
Data flows (and therefore data flow diagrams) can be used for security analysis, as they offer identification of possible paths for attack and disclosure of confidential information
82
Decision tables and diagrams
| dynamic notations
used to represent complex combinations of conditions
| and actions.
83
Flowcharts
| dynamic notations
used to represent the flow of
control and the associated actions to be
performed.
84
Sequence diagrams
| dynamic notations
used to show the interactions among a group of objects, with emphasis on the time ordering of messages passed between objects
85
State transition and state chart diagrams
| dynamic notations
used to show the control flow from state to state and how the behavior of a component changes based on its current state in a state machine.
86
Formal specification languages
| dynamic notations
textual languages that use basic notions from mathematics (for example, logic, set, sequence) to rigorously and abstractly define software component interfaces and behavior, often in terms of pre- and postconditions.
87
Pseudo code and program design languages
(PDLs)
(dynamic notations)
structured programming-like languages used to describe, generally at the detailed design stage, the behavior of a procedure or method
88
Software Design Strategies
general strategies to help guide the design process
89
Software Design Methods
generally provide a set of notations to be used, description of the process to be used, and a set of
guidelines
90
General Strategies
| design strategies
commonplace strategies followed such as divide-and-conquer and stepwise refinement
91
Function-Oriented (Structured) Design
| design strategies
decomposition centers on identifying the major software functions and then elaborating and refining them in a hierarchical topdown manner
92
Object-Oriented Design
| design strategies
inheritance and polymorphism play a key role, to the
| field of component-based design
93
Data Structure-Centered Design
| design strategies
starts from the data structures a program manipulates rather than from the function it performs
first describes the input and output data structures and then develops the program’s control structure based on these data structure diagrams
94
Component-Based Design (CBD)
| design strategies
addresses issues related to providing, developing, and
integrating components in order to improve reuse
( component is an independent unit, having well-defined interfaces and dependencies that can be composed and deployed independently)
95
Software Design Tools
used to support the creation of the software design artifacts during the software development process
96
What tasks do Software Design Tools support?
• to translate the requirements model into a
design representation;
• to provide support for representing functional components and their interface(s);
• to implement heuristics refinement and
partitioning;
• to provide guidelines for quality assessment.
