CH 01: Software Design Concepts and Principles

0.0(0)
studied byStudied by 0 people
0.0(0)
full-widthCall Kai
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
GameKnowt Play
Card Sorting

1/58

encourage image

There's no tags or description

Looks like no tags are added yet.

Study Analytics
Name
Mastery
Learn
Test
Matching
Spaced

No study sessions yet.

59 Terms

1
New cards

Software Design

Encompasses the set of principles, concepts, and practices that lead to the development of a high quality system or product.

2
New cards

Design principles

establish an overriding philosophy that guides the designer as the work is performed.

3
New cards

Design concepts

must be understood before the mechanics of design practice are applied.

4
New cards

Software design practices

CHANGE CONTINUOUSLY as new methods, better analysis, and broader understanding evolve.

5
New cards

Software Engineering Design

- Data/Class design

- Architectural design

- Interface design

- Component-level design

6
New cards

Data/Class design

transforms analysis classes into implementation classes and data structures.

7
New cards

Architectural design

defines relationships among the major software structural elements.

8
New cards

Interface design

defines how software elements, hardware elements, and end-users communicate.

9
New cards

Component-level design

transforms structural elements into procedural descriptions of software components.

10
New cards

Behavioral Elements

State diagrams

Activity diagrams

11
New cards

Scenario-based Elements

Use cases-test

Use case diagrams

Swimlane diagrams

Sequence diagrams

12
New cards

Class-Based Elements

Class diagrams

Analysis packages

CRC models

Collaboration diagrams

13
New cards

design

The ______ must implement all of the EXPLICIT REQUIREMENTS contained in the analysis model, and it must accommodate all of the IMPLICIT REQUIREMENTS desired by the customer.

14
New cards

design

The _____ should be a READABLE, UNDERSTANDABLE guide for those who generate code and for those who test and subsequently support the software.

15
New cards

design

The _____ should provide a COMPLETE PICTURE OF THE SOFTWARE, addressing the data, functional, and behavioral domains from an implementation perspective

16
New cards

(a) created using recognizable ARCHITECTURAL STYLES OR PATTERNS

(b) composed of WELL DESIGNED COMPONENTS

(c) implemented in an EVOLUTIONARY FASHION

Quality Guidelines

A design should exhibit an architecture (a) _____ , (b) _____, (c) _____.

17
New cards

MODULAR

Quality Guidelines

A design should be _____.

18
New cards

DISTINCT REPRESENTATIONS

Quality Guidelines

A design should contain _________ of data, architecture, interfaces, and components.

19
New cards

RECOGNIZABLE DATA PATTERNS

Quality Guidelines

A design should lead to data structures that are drawn from _______.

20
New cards

FUNCTIONALLY INDEPENDENT COMPONENTS

Quality Guidelines

A design should contain ______.

21
New cards

REDUCE THE COMPLEXITY OF CONNECTIONS

A design should lead to interfaces that ________ between components and the external environment.

22
New cards

REPEATABLE METHOD

A design should be derived using a ______ that is driven by software requirements analysis.

23
New cards

MEANINGFUL NOTATION

A design should be represented using _____.

24
New cards

Each new software design methodology introduces UNIQUE HEURISTICS AND NOTIONS - yet they each contain:

1. mechanism

2. notation

3. Heuristics

4. Guidelines

25
New cards

MECHANISM

A _______ for the translating the requirements model into a design representation.

26
New cards

NOTATION

A _______ for representing functional components and their interfaces.

27
New cards

HEURISTICS

for refinement and partitioning.

28
New cards

GUIDELINES

for quality assessment.

29
New cards

Design Concepts

- Abstraction

- Architecture

- Design Patterns

- Separation of concerns

- Modularity

- Information Hiding

- Functional independence

- Stepwise Refinement

- Refactoring

- Design Classes

30
New cards

Abstraction

data (named collection of data describing data object), procedural (name sequence of instructions with specific and limited function).

31
New cards

Architecture

overall structure or organization of software components, ways components interact, and structure of data used by components.

32
New cards

Design Patterns

describe a design structure that solves a well-defined design problem within a specific context.

33
New cards

Separation of concerns

any complex problem can be more easily handled if it is subdivided into pieces.

34
New cards

Modularity

compartmentalization of data and function

35
New cards

Information Hiding

controlled interfaces which define and enforces access to component procedural detail and any local data structure used by the component.

36
New cards

Functional independence

single-minded (high cohesion) components with aversion to excessive interaction with other components (low coupling).

37
New cards

Stepwise Refinement

incremental elaboration of detail for all abstractions.

38
New cards

Refactoring

a reorganization technique that simplifies the design without changing functionality.

39
New cards

Design Classes

provide design detail that will enable analysis classes to be implemented.

40
New cards

Design Class Characteristics

- Complete

- Primitiveness

- High cohesion

- Low coupling

41
New cards

Complete

includes all necessary attributes and methods) and sufficient (contains only those methods needed to achieve class intent).

42
New cards

Primitiveness

each class method focuses on providing one service.

43
New cards

High cohesion

small, focused, single-minded classes.

44
New cards

Low coupling

class collaboration kept to minimum.

45
New cards

Design Modeling Principles

• Principle #1. Design should be traceable to the requirements model.

• Principle #2. Always consider the architecture of the system to be built.

• Principle #3. Design of data is as important as design of processing functions.

• Principle #4. Interfaces (both internal and external) must be designed with care.

• Principle #5. User interface design should be tuned to the needs of the end-user and stress ease of use.

• Principle #6. Component-level design should be functionally independent.

• Principle #7. Components should be loosely coupled to each other than the environment.

• Principle #8. Design representations (models) should be easily understandable.

• Principle #9. The design should be developed iteratively.

• Principle #10. Creation of a design model does not preclude using an agile approach.

46
New cards

Data model

data objects and database architectures.

47
New cards

Data model

○ Examines data objects independently of processing.

○ Focuses attention on the data domain.

○ Creates a model at the customer's level of abstraction.

○ Indicates how data objects relate to one another.

48
New cards

Data object

can be an external entity, a thing, an event, a place, a role, an organizational unit, or a structure.

49
New cards

Data objects

contain a set of attributes that act as an quality, characteristic, or descriptor of the object.

50
New cards

Data objects

may be connected to one another in many different ways.

51
New cards

Interface

is a set of operations that describes the externally observable behavior of a class and provides access to its public operations.

52
New cards

Interface

Important elements:

- User interface (UI).

- External interfaces to other systems.

- Internal interfaces between various design components.

53
New cards

UI or User Experience (UX)

is a major engineering action to ensure the creation on usable software products.

54
New cards

Internal and external interfaces

should incorporate both error checking and appropriate security features.

55
New cards

Deployment Design Elements

Indicates how software functionality and subsystems will be allocated within the physical computing environment.

56
New cards

Deployment Design Elements

Modeled using UML deployment diagrams.

57
New cards

UML deployment diagrams.

- Descriptor form deployment diagrams

- Instance form deployment diagrams

58
New cards

Descriptor form deployment diagrams

show the computing environment but does not indicate configuration details.

59
New cards

Instance form deployment diagrams

identify specific hardware configurations and are developed in the latter stages of design.