SWEBoK Design Flashcards
Software Design
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
Two Main Activities of Design
- Architectural Design
- Software Detailed Design
Wicked Problem
A problem with no definitive solution
General Design Concepts
Form of Problem Solving
Also includes goals, constraints, alternatives, representations, and solutions
Architectural Design
High-Level Design
describes how software is organized into components
Detailed Design
describes the desired behavior of architectural components
Design Principle
Key notations that provide the basis for many different design approaches and concepts.
Abstraction
design principle
a view of an object that focuses on information relevant to a specific purpose and ignores the remainder of information.
Coupling
design principle
a measure of the interdependence among modules in a computer program
Cohesion
design principle
a measure of the strength of association of the elements within a module
Decomposition and Modularization
design principle
means that large software systems are divided into a number of smaller named components having well-defined interfaces that describe component interaction.
Encapsulation and Information Hiding
design principle
means grouping and packaging the internal details of an abstraction and making those details inaccessible to external entities
Separation of Interface and Implementation
design principle
involves defining a component by specifying a public interface that is separate from the details of how the components is realized
Sufficiency, Completeness
design principle
means ensuring that a software component captures all the important characteristics of an abstraction and nothing more
Primitiveness
design principle
means the design should be based on patterns that are easy to implement
Separation of Concerns
design principle
“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
Key Issues in Design
Issues that must be dealt with in designing software
Concurrency
key issue
decomposing software into processes, tasks, and threads and dealing with related issues of efficiency, atomicity, sychronicity, and scheduling
Control
key issue
concerned with how to organize data add control flow
Handling Events
key issue
concerned with how to handle reactive and temporal events through various mechanisms such as implicit invocation and call-backs
Data Persistence
key issue
how to handle long-lived data
Distribution of Components
key issue
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
Error and Exception Handling and Fault Tolerance
key issue
how to prevent, tolerate, and process errors and deal with exceptional conditions
Interaction and Presentation
key issue
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
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
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”
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.
Logical View
satisfying the functional requirements
physical view
distribution issues
development view
how the design is broken down into implementation units
with explicit representation of the dependencies
among the units
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
General structures (major architectural style)
How programs in software are structured to handle problems
Distributed systems
major architectural style
Software distributed over a series of interconnected hardware components whether locally or over a network
Interactive systems
major architectural style
Software designed around interactions with the user and how data is hidden or loaded (MVC)
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.
Design Patterns
architecture
“a common
solution to a common problem in a given context”
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).
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
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.
User Interface Design
ensuring that interaction between the human
and the machine provides for effective operation and control of the machine
General User Interface Design Principles
ui design
- Learnability
- User familiarity
- Consistency
- Minimal surprise
- Recoverability
- User guidance
- User diversity
Learnability
ui design principle
The software should be easy to
learn so that the user can rapidly start working with the software.
User familiarity
ui design principle
The interface should use
terms and concepts drawn from the experiences of the people who will use the software.
Consistency
ui design principle
The interface should be consistent so that comparable operations are activated in the same way
Minimal surprise
ui design principle
The behavior of software
should not surprise users
Recoverability
ui design principle
The interface should provide
mechanisms allowing users to recover from
errors
User guidance
ui design principle
The interface should give
meaningful feedback when errors occur and
provide context-related help to users
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.).
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?
The Design of User Interaction Modalities
ui design
User interaction styles can be classified and this category discusses how to approach them.
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
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.
Menu selection (ui interaction)
The user selects a command from a menu list of commands.
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.
Command language (ui interaction)
The user issues a command and provides related parameters to direct the software what to do.
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
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
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.).
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
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.
Localization and Internationalization
ui design
means adapting software to the different languages, regional differences, and the technical requirements of a target market
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
Software Design Quality Analysis and
Evaluation
Series of topics used for quality analysis of a software design.
Quality Attributes
quality analysis
“-ilities”
(maintainability, portability, testability, usability)
and “-nesses”
(correctness, robustness) that contribute to the quality of SW Design
Quality Analysis and Evaluation Techniques
quality analysis
- Software design reviews
- Static analysis
- Simulation and prototyping
Measures
quality analysis
used to assess or to quantitatively estimate various aspects of a software
design; for example, size, structure, or quality.
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.
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
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)
Architecture description languages (ADLs)
structural notations
textual, often formal, languages used to
describe software architecture in terms of
components and connectors
Class and object diagrams
structural notations
used to represent a set of classes (and objects) and their
interrelationships
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
Class responsibility collaborator cards
(CRCs)
(structural notations)
used to denote the names of components (class), their responsibilities, and their
collaborating components’ names.
Deployment diagrams (structural notations)
used to represent a set of (physical) nodes and their interrelationships, and, thus, to model the physical aspects of software
Entity-relationship diagrams (ERDs)
structural notations
used to represent conceptual models of data stored
in information repositories.
Interface description languages (IDLs)
structural notations
programming-like languages used to define the interfaces (names and types of exported operations) of software components.
Structure charts (structural notations)
used to describe the calling structure of programs (which modules call, and are called by, which other modules).
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.
Activity diagrams
dynamic notations
used to show control flow from activity to activity. Can be used to represent concurrent activities
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.
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
Decision tables and diagrams
dynamic notations
used to represent complex combinations of conditions
and actions.
Flowcharts
dynamic notations
used to represent the flow of
control and the associated actions to be
performed.
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
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.
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.
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
Software Design Strategies
general strategies to help guide the design process
Software Design Methods
generally provide a set of notations to be used, description of the process to be used, and a set of
guidelines
General Strategies
design strategies
commonplace strategies followed such as divide-and-conquer and stepwise refinement
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
Object-Oriented Design
design strategies
inheritance and polymorphism play a key role, to the
field of component-based design
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
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)
Software Design Tools
used to support the creation of the software design artifacts during the software development process
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.
