Systems’ Design Concepts

1
 FROM Analysis Model TO Design Model

System Description
(by a customer)

List of System
Specifications
system
description (that system engineer
and code developer
Analysis Model understands)
analysis
model

Design Model
design
model

Lists of System
Requirements
(that customer still
understands) System Development
by code developers -
technologists and
technicians
2
 Design Model as a Bridge between Analysis M. and Code Dev.
(using the By Analogy method)
Analysis of
Customer Req. Design Model (blueprints) Development

3
Analysis Model outcomes (several examples)

4
 General idea: Design Model’s expected outcomes =
Analysis Model’s actual outcomes + our ADDITIONAL design proposals

Additional functions/services as proposed by SE for

Examples:
Webster ++ system (several examples)
1) Remove some obsolete COs
1) to pay tuition fee in the system using CC, debit card,
2) Modify some COs (in terms of Add new attributes,
bank account, etc.;
Add new legal methods to some COs, etc.)
2) to audit POS + show what untaken courses are
available next semester;
etc. 5
 Correspondence between system’s
Analysis Model and Design Model
Option C … (a set of multiple significant
improvements of an old system)
Option B
(a set of small
improvements of an Design model
old system) = analysis
Option A model specs +
(a new system) huge number
of additional
design specs
Design model =
Analysis model
Design model specs + small
= Analysis additional design
model specs specs

Additional
design specs
Addit. design
specs
Examples of Analysis Model specs:
1) 28 different types of actors (from use cases, from context DFD, ...)
2) At least 567 different functions … (from COs, from STD, …)
3) At least 21 different types of data structures – stacks, files, arrays, lists, queues, databases, … 6
(from Level-0 DFD, …)
 Design

Design is a meaningful engineering representation of

something that must be built - i.e. blueprint(s) for engineers
and/or developers.

In system engineering context, design focuses on the following main areas:

1. Architecture architectural design that defines the relationships

between major structural elements of the software

2. Components component-level design that transforms structural

elements of the software architecture into a procedural
description of software components (based on control
specifications, process specifications and state transition
diagram).

3. Data/Classes data/class design that transforms the information domain Design Model
model into the particular data structures (as in 9th Ed., p. 158)

4. Interfaces interface design that describes how the software

communicates within itself, with other systems, and with
users

7
 FROM Analysis Model TO Design Model

Class objects and processing units

Maps into
Analysis model
(DOs, DFDs, ERDs, STDs,
activity diagrams, use cases,
etc.)
Design model
(architecture, components,
data, interfaces)

Software modules
8
 From Analysis Model to Design Model
(details)

Design Model

Co m p o n e n t -
sc e n a r i o - b a se d f l ow- or i e n t e d L e v e l D e sig n
e l e me nt s e l e me nt s
use-cases - text data flow diagrams
use-case diagrams control-flow diagrams
activity diagrams processing narratives
swim lane diagrams
In t e r f a c e D e sig n
Analy sis Model
Analysis Model
A r c h it e c t u r a l D e sig n
c l a ss- b a se d be ha v i or a l
e l e me nt s e l e me nt s
class diagrams state diagrams
analysis packages sequence diagrams
CRC models D a t a / Cla ss D e sig n
collaboration diagrams

Design Model

9
Systems Thinking Based Approach
in Systems’ Engineering

10
 Software Engineer:
A Profile Required by Industry these days
A set of composition of skills of software engineer required by industry/businesses, and companies:

25 % - Analytical Skills ability to see things as systems, identify, analyze, and

solve problems in an optimal way for a specific
organization.
(Examples of Bradley courses: CS 514, math courses, etc.)

25% - Technical Skills ability to understand how computers, data networks,

databases, operating systems, etc. work together, as
well as their potentials and limitations
(Examples of Bradley courses: programming courses, CS 571,
CS 590, CS 591, CIS595, CIS545, etc.)

25 % - Management Skills organization’s recourse management, project

include management (people and money), risk
management, and change management
(Examples of courses: CIS 591, CS 697 or CS 698 – Adv.
Topics/Research-focused topics)

25 % - Communication Skills include effective interpersonal communication (written,

verbal, visual, electronic, face-to-face conversations,
presentations in front of groups), listening, group facilitation
skills.
(Presentations and communications in classes, course projects,
team-working and discussions in your team, etc.) 11
 Analytical Skills
Analytical Skills include four sets of sub-skills that are essential for Software Engineer:
1) Systems Thinking,
2) Organizational Knowledge
3) Problem Identification, and
4) Problem Analyzing and Solving.

Systems Thinking involves a) identifying something as a system, b) “visualizing” that

system and translating it into abstract terms, and c) thinking about
the characteristics of the specific situation.

Systems Thinking is very useful in software engineering and development because software applications
can be seen as subsystems in larger organizational systems, taking input from, and
returning output to, their organizational environments.

Using Systems Thinking approach the goal is

NOT just to solve a problem in any way
BUT to solve it in accordance with customer’s
requirements and for customer environment (i.e. to take
limits/restrictions and actual customer/user/company’s
environment into consideration)

12
 What is a difference between a Technician,
Technologist and an Engineer?

[Link]

13
 A System and its Characteristics
A system is an inter-related set of components, with an identifiable boundary,
working together for some purpose.

Any system has nine (9) characteristics:

1) Environment - everything external to a system that interacts with the system

2) Boundary - a line (probably, a physical line and/or a virtual line) that separates
the system from its environment

3) Interfaces - points of “system-environment” and “subsystem-subsystem” contacts

4) Inputs - whatever a system takes from its environment

5) Outputs - whatever a system returns to its environment

6) Components - irreducible parts of a system (or, aggregation of parts)

7) Relations (links) - dependence of one component (or, set of components = subsystem)

on one or more components (or, subsystems)

8) Purpose/goal - the overall goal or function of a system

9) Constraint(s) - limit(s) to what a system can expand, shrink, perform, etc.

14
 A General Depiction of a System, including 9 system characteristics
(for any type of a system: software, technical, information, control, social, biological, organizational, etc.)

1 4 6
8
Environment
Purpose/
System 2
Goal

3
9
Constraints
7
/Limits 5

Source: Management Information Systems, 8 th Ed., K. Landon and M. Landon

Systems’ Thinking Approach: Self-learning and Practice
Describe various entities as a system by
identifying at least 3 examples (whenever
applicable) for EACH of its 9 main
characterictics (components, limits, inputs,
outputs, interfaces, etc,):

1. Webster system at Bradley U. (Online

Academic Services for Students system)

2. Bradley University as a system;

3. Bradley Online Library system

4. CS&IS Department as a system;

5. MyBradley or Canvas LMS as a system;

6. Your Program of Study at Bradley U. as a

system

7. This class as a system; ….

16
 IEEE standards in SE:
Software System’s Views

17
 IEEE standards: Views of Software System

Software architecture is commonly organized in views, which are analogous to the

different types of blueprints made in building architecture.

Within the ontology*) established by ANSI/IEEE 1471-2000,

Views are instances of viewpoints, where a viewpoint exists to describe the architecture
in question from the perspective of a given set of stakeholders and their concerns.

*) In computer science and information science,

An ontology is a formal representation of knowledge as a set of concepts within a
domain, and the relationships between those concepts.

Examples of SW system views in the IEEE-1471 ontology:

1) Development/structural view
2) Code/module view
3) Functional/logic view
4) Concurrency/process/thread view
5) Physical/deployment view
6) User action/feedback view
7) Data view,
etc.
18
 System Engineering: Development/Structural View

System System Level

(World View)

A subsystem

[Link]. A [Link]. B [Link]. N …... Level of Subsystems (Domains)

(Subsystem or Domain View)

A component

Level of Elements or Components

Functions Data Links Inputs Outputs
…...
(Element or Component View)
A detail (attribute)

Level of Sub-elements,
…... Details (for ex., attributes)
(Detail View)

19
 MyBradley Software System at Bradley U.:
Development/Structural View (system, subsystems, and component design)

System Level
System (MyBradley system)

A subsystem

Level of Subsystems (Domains)

GUI Databases Security …...
(Databases, GUI, Security, HELP, etc.)

A component

Tables Level of Elements or Components

Macros (DOs) Forms Queries Reports
…...
(tables, forms, queries, reports, macros
and modules, …)
A detail (attribute)

ID FN LN DOB YOA Status …

…... Level of Sub-elements, Details
(for ex., attributes)
(ID, First Name, Last Name, DOB,
YOA, status, …)

20
 Software Design: Systems Eng.-based approach (1/2)
Design - is a meaningful engineering representation of something that must be built.

In Software Engineering context (as proposed by R. Pressman et al), Software Design focuses on:

1) Goal.
Goal of software design is to produce a model or representation that is
- bug free (firmness),
- suitable for its intended uses (commodity), and
- pleasurable to use (delight).

2) Components + 3) Links = Architecture or Structure

architectural design defines the relationships between major structural elements

Components component-level design transforms structural elements

of the software architecture into a procedural description
of software components (based on control specifications,
process specifications and state transition diagram).

Data Objects (modules) data design transforms the information domain

model into the particular data structures

4) Interfaces interface design describes how the software communicates within itself, with other
systems, and with users/actors/collaborators

21
 Software Design: Additional Systems’ Features
that must be considered in SW Design Process due to
System’s Thinking approach (2/2) – this approach will
significantly improve quality of to-be-developed system

5) Inputs legal inputs by user, events (tables) – part of STD

6) Outputs legal states, behavior of the system, legal actions

(tables) – part of STD

7) Environment technical specifications of customer/end user environment

8) Constraints limits by customer of system’s functionality and specs, or limits

of design process (time, cost, etc.)

9) A boundary separation of an environment (external users) and system

(internals users); this is very important for security issues

22
Software Systems’ Design:
Concepts

23
 Software Design: Concepts

1. Abstraction data, procedure, control

2. Architecture the overall structure of the software
3. Patterns ”conveys the essence” of a proven design
solution (best cases, re-usable designs))
4. Modularity compartmentalization of data and function
5. Information Hiding controlled interfaces
6. Functional single-minded function and low coupling
Independence
7. Refinement elaboration of details for all abstractions
8. Re-factoring a reorganization technique that simplifies
the design

24
 1.1. Data Abstraction
(abstractive data models not actual objects)

door

manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism

implemented as a data object

Abstraction - allows designers to simplify a problem and focus on solving a problem without being
concerned about irrelevant lower level details

25
 1.2. Procedural Abstraction (solution algorithms)

open

details of enter
algorithm

implemented with a "knowledge" of the

object that is associated with “enter algorithm”

Abstraction - allows designers to simplify a problem and focus on solving a problem without being
concerned about irrelevant lower level details
(en example: procedural abstraction: a subroutine – a named sequence of actions and events) 26
 Examples of algorithms’ representations

[Link]
[Link] 27
Example of algorithm’s
representation
(extreme case = coding)

Note:
a) Software Engineering
is NOT a coding;
b) Coding is NOT
Software Engineering

28
 2. Software Architecture (details during next class)

The overall structure of the software and the ways in which that
structure provides conceptual integrity for a system
Structural properties. This aspect of the architectural design representation defines the components
of a system (e.g., modules, objects, filters) and the manner in which those components are
packaged and interact with one another. For example, objects are packaged to encapsulate
both data and the processing that manipulates the data and interact via the invocation of
methods.

Extra-functional properties. The architectural design description should address how the design
architecture achieves requirements for performance, capacity, reliability, security, adaptability,
and other system characteristics.

Families of related systems (reusable architectural building blocks). The architectural

design should draw upon repeatable patterns that are commonly encountered in the design of
families of similar systems. In essence, the design should have the ability to reuse architectural
building blocks.

(Details – in Ch. 9)
29
 System’s Architecture: an example (structural view)

System System Level

(World View)

A subsystem

[Link]. A [Link]. B [Link]. N …... Level of Subsystems (Domains)

(Subsystem or Domain View)

A component

Level of Elements or Components

Functions Data Links Inputs Outputs
…...
(Element or Component View)
A detail (attribute)

Level of Sub-elements,
…... Details (for ex., attributes)
(Detail View)

30
 3. Patterns
(Reusability of previous designs and design solutions)

Design Pattern Template:

Pattern name describes the essence of the pattern in a short but expressive name
Intent describes the pattern and its functions
Also-known-as lists any synonyms for the pattern
Motivation provides an example of the problem
Applicability notes specific design situations in which the pattern is applicable
Structure describes the classes that are required to implement the pattern
Participants describes the responsibilities of the classes that are required
to implement the pattern
Collaborations describes how the participants collaborate to carry out their responsibilities
Consequences describes the “design forces” that affect the pattern and the potential
trade-offs that must be considered when the pattern is implemented
Related patterns cross-references related design patterns

*) Patterns-based SE, patterns-based analysis, patterns-based software development,

pattern languages, etc. – still a lot of research needed, a lot of Ph.D. dissertations
31
 Patterns: Analogy in Construction Engineering
(reusability of previous designs and design solutions)

32
 Patterns: Analogy in Heavy Machinery by Caterpillar: CT660 Truck
(reusability of previous designs and design solutions)

Caterpillar CT660 Caterpillar CT660 Caterpillar CT660 (low

(base model) (vocational truck model) loader model)

Caterpillar CT660
(concrete pump model)

Caterpillar CT660
(concrete mixer
model)

33
 3a. Patterns (details)

A design pattern is a general reusable solution to a commonly occurring problem in software design.
A design pattern is not a finished design that can be transformed directly into code.
It is a description or template for how to solve a problem that can be used in many different situations.

34
3a. Patterns (details)

35
3a. Patterns (details)

36
Example of
Highly
Reusable
Base
Software
System

37
 4. Modular Design
(easier to build, easier to change, easier to fix…)

easier to build, easier to change, easier to fix ...

*) Boeing 747
Microsoft Design Center:
*) modern cars (standard modules)
Industrialization and modular object-oriented
*) reusable learning objects (modules of online
software development has theoretically made it
courses)
easy to tear things down and replace them.

38
 Modular Approach of Software Systems
(easier to build, easier to change, easier to fix…)

39
 Modularization vs Decomposition

Modularization Decomposition

Modularity is dividing a system into parts/chunks/modules of relatively uniform

size.

Decomposition is the process of breaking down a system into its component

parts.
40
 Software Modularity: Trade-offs

What is the "right" number of modules

for a specific software design?

module development cost

cost of
software

module
integration
cost

optimal number number of modules

of modules
41
 An example: Libraries (functions, subroutines, etc.)

[Link] 42
 Sizing Modules: Two Views
One important feature of a module is
its length.
Longer is not better.

What's How big

inside?? is it?? Compilation time is expensive; the
longer the module, the longer it takes
to compile. Most program changes that
require a recompilation of a module are
for minor changes, not involving lots of
code lines.
MODULE

Try to restrict your modules to 300

lines of code; optimal length: 60-200
LOC per module

If the module needs to be longer, split it

into multiple sub-modules, all with a
related name.
Source: [Link] 43
Modular Approach to
Learning Content Design:
System Level

Level of Subsystems (Domains)

Level of Components

Level of elements

44
 BTW: Pedagogical Patterns (details)

Pedagogical Patterns are high-level

patterns that have been recognized
in many areas of training and
pedagogy such as group work,
software design, human computer
interaction, education and others.

The concept is an extension of pattern

languages. In both cases, the patterns
seek to foster best practices of
teaching.

You may think about patterns as some

kind of metadata – a top-level
description of data about data.

45
 5. Information Hiding
(or, Encapsulation in Programming)

module • algorithm
controlled
interface • data structure
• details of external interface
• resource allocation policy

clients "secret"

a specific design decision 46

 Why Information Hiding?

 leads to encapsulation—an attribute of high quality design

 results in higher quality software
 limits the global impact of local design decisions
 emphasizes communication through well-structured and controlled interfaces
 reduces the likelihood of “side effects”
 discourages the use of global data

Advantages of Encapsulation in Programming

 Large software programs may be split into manageable modules

 Implementation details are hidden (isolated); as a result, no need to waste your time
 Subprograms and programs become more portable, and, probably, re-usable by external users
 Development time is shortened due to well-written, well-structured, well-tested sub-programs
(functions, lists, files, etc.)

47
 6. Functional Independence
 Functional independence is achieved by
developing modules with "single-minded"
function and an "aversion" (disliking) to
excessive interaction with other modules.

• One function inside

 Cohesion is an indication of the relative • One interface
functional strength of a module.
 A cohesive module performs a single task,
requiring little interaction with other components in
other parts of a program. Stated simply, a
cohesive module should (ideally) do just one thing.

 Coupling is an indication of the relative

interdependence among modules.
 Coupling depends on the interface complexity
between modules, the point at which entry or
reference is made to a module, and what data
pass across the interface.

• Many functions inside

• Multiple different interfaces 48
 7. Stepwise Refinement

Object
open
Activity Diagram (textual form)
walk to door;
reach for knob;
open door; repeat until door opens
turn knob clockwise;
walk through; if knob doesn't turn, then
close door. take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat

Instructions (code)
49
 Stepwise Refinement: An example

Processing unit Algorithm Code

function

Processing
unit: main
function

50
 FROM Analysis Model TO Design Model
(it is actually a refinement process)

high

a na ly sis m ode l

class diagrams
analysis packages
use-cases - t ext class diagrams
Requirement s:
CRC models use-case diagrams const raint s
analysis packages
collaborat ion diagrams
act ivit y diagrams CRC models int eroperabilit y
dat a f low diagrams sw im lane diagrams collaborat ion diagrams t arget s and
cont rol-f low diagrams collaborat ion diagrams dat a f low diagrams
processing narrat ives st at e diagrams cont rol-f low diagrams
conf igurat ion
sequence diagrams processing narrat ives
st at e diagrams
sequence diagrams

design class realizat ions

subsyst ems
collaborat ion diagrams t echnical int erf ace component diagrams
design class realizat ions
design design classes
subsyst ems
Navigat ion design act ivit y diagrams
collaborat ion diagrams
GUI design sequence diagrams
component diagrams
de sign m ode l design classes
ref inement s t o: act ivit y diagrams
ref inement s t o: sequence diagrams
component diagrams
design class realizat ions design classes
subsyst ems act ivit y diagrams
low collaborat ion diagrams sequence diagrams deployment diagrams

archit ect ure int erface component -level deployment -level

element s element s element s element s

process dimension
51
 An example of Structural View as a refinement process

System Level
System (Webster System)

A subsystem

Level of Subsystems (Domains)

GUI Databases Security …...
(Databases, GUI, Security, HELP, etc.)

A component

Tables Level of Elements or Components

Functions (DOs) Forms Queries Macros
…...
(tables, forms, queries, reports, macros
and modules, …)
A detail (attribute)

ID FN LN DOB YOA Status …

…... Level of Sub-elements, Details
(for ex., attributes)
(ID, First Name, Last Name, DOB,
YOA, status, …)

52
 The Bottom Line: FROM Analysis Model TO Design Model
(based on Analysis Model of we will be able
to create the system’s Design Model)

Class objects and processing units

Maps into
Analysis model
(DOs, DFDs, ERDs, STDs,
activity diagrams, use cases,
etc.)
Design model
(architecture, components,
data, interfaces)

Software modules
53
 8. Re-factoring
In software engineering, "refactoring" of source code means improving it
without changing its overall results, and is sometimes informally referred
to as "cleaning it up". Refactoring neither fixes bugs nor adds new
functionality, though it might precede either activity. Rather, it improves the
understandability of the code, changes its internal structure and design,
and removes dead code.

 These changes are intended to make the code easier to comprehend,

more maintainable, and more amenable to change.

 Refactoring is usually motivated by the difficulty of adding new

functionality to a program or fixing a bug in it.

When software is refactored, the existing design is examined for

 redundancy
 unused design elements
 inefficient or unnecessary algorithms
 poorly constructed or inappropriate data structures
 any other design failure that can be corrected to yield a better design.

Examples of re-factoring: __________________ ???

54
 8a. Re-factoring Techniques
(not a comprehensive list at all)

Techniques that allow for more abstraction:

 Encapsulate Field - force code to access the field with getter and setter methods
 Generalize Type - create more general types to allow for more code sharing
 Replace type-checking code with State/Strategy
 Replace conditional with polymorphism

Techniques for breaking code apart into more logical pieces:

 Extract Method, to turn part of a larger method into a new method. By breaking down code in
smaller pieces, it is more easily understandable. This is also applicable to functions.
 Extract Class moves part of the code from an existing class into a new class.

Techniques for improving names and location of code:

 Rename Method or - changing the name into a new one that better reveals its purpose
 Pull Up - in OOP, move to a superclass
 Push Down - in OOP, move to a subclass

Source: [Link] 55
 8b. Re-factoring Tools (in alphabetical order)
Add Parameter Parameterize Method
Change Bidirectional Association to Unidirectional Preserve Whole Object
Change Reference to Value Pull Up Constructor Body
Change Unidirectional Association to Bidirectional Pull Up Field
Change Value to Reference Pull Up Method
Collapse Hierarchy Push Down Field
Consolidate Conditional Expression Push Down Method
Consolidate Duplicate Conditional Fragments Reduce Scope of Variable by Mats Henricson
Convert Dynamic to Static Construction by Gerard M. Davison Refactor Architecture by Tiers (Link Only)
Convert Static to Dynamic Construction by Gerard M. Davison Remove Double Negative by Ashley Frieze and Martin Fowler
Decompose Conditional Remove Middle Man
Duplicate Observed Data Remove Parameter
Eliminate Inter-Entity Bean Communication (Link Only) Remove Setting Method
Encapsulate Collection Rename Method
Encapsulate Downcast Replace Array with Object
Encapsulate Field Replace Assignment with Initialization by Mats Henricson
Extract Class Replace Conditional with Polymorphism
Extract Interface Replace Conditional with Visitor by Ivan Mitrovic
Extract Method Replace Constructor with Factory Method
Extract Package by Gerard M. Davison Replace Data Value with Object
Extract Subclass Replace Delegation with Inheritance
Extract Superclass Replace Error Code with Exception
Form Template Method Replace Exception with Test
Hide Delegate Replace Inheritance with Delegation
Hide Method Replace Iteration with Recursion by Dave Whipp
Hide presentation tier-specific details from the business tier (Link Only) Replace Magic Number with Symbolic Constant
Inline Class Replace Method with Method Object
Inline Method Replace Nested Conditional with Guard Clauses
Inline Temp Replace Parameter with Explicit Methods
Introduce A Controller (Link Only) Replace Parameter with Method
Introduce Assertion Replace Record with Data Class
Introduce Business Delegate (Link Only) Replace Recursion with Iteration by Ivan Mitrovic
Introduce Explaining Variable Replace Static Variable with Parameter by Marian Vittek
Introduce Foreign Method Replace Subclass with Fields
Introduce Local Extension Replace Temp with Query
Introduce Null Object Replace Type Code with Class
Introduce Parameter Object Replace Type Code with State/Strategy
Introduce Synchronizer Token (Link Only) Replace Type Code with Subclasses
Localize Disparate Logic (Link Only) Reverse Conditional by Bill Murphy and Martin Fowler
Merge Session Beans (Link Only) Self Encapsulate Field
Move Business Logic to Session (Link Only) Separate Data Access Code (Link Only)
Move Class by Gerard M. Davison Separate Query from Modifier
Move Field Split Loop by Martin Fowler
Move Method Split Temporary Variable
Substitute Algorithm
Use a Connection Pool (Link Only)
Source: [Link] Wrap entities with session (Link Only) 56
Code
Re-Factoring
Tool:
An Example

57
Systems’ Design Concepts

Additional Information

58
 Software Design Concepts:
Davis’95 SW Design Principles

59
 Software Design Principles = Best Practices
(Davis’95)

1) The design process should not suffer from limited view = ‘tunnel vision.’
*) a good designer should consider several (3-5) alternatives and judge them based on given
requirements
(for ex: technical platforms or programming languages for a new SW system)

2) The design model (s) should be traceable to the analysis model.

*) a single element of the Design Model often traces to multiple requirements
(for ex: a component of Design Model -- a menu item -- may
have one-to-one correspondence with Process Specs, Control Specs, DFDs, State Transition
Diagrams, etc.)

3) The design should NOT reinvent the wheel.

*) D&D time is short and resources are limited; therefore, use well-tested
design patterns (software modules, learning objects) as often as possible
(ex: eventually it will lead to reusable SW components)
60
 Software Design Principles (cont.)

4) The design should “minimize the intellectual distance” between the software and
the problem as it exists in the real world.
*) SW design solutions should be as close (whenever possible) to the real-world problem
domain as possible;
(for ex: simulate user -- kids, students, professionals, etc. -- behavior
and level of their knowledge and perception;)

5) The design should exhibit uniformity and integration.

*) design solutions by multiple teams and designers should look like
ONE-person design solutions (one person designed all components of SW)
(for ex: similar interfaces and/or components of multiple Microsoft products)

6) The design should be structured to accommodate change.

*) upcoming modifications, updates and improvements should NOT lead to drastic
changes or re-design of software system
(ex: open-to-changes design instead of closed-to-changes design;
for ex: downloadable service packs for Win’2003, Office’2003;
for ex: Intel cannot replace a chip)

61
 Software Design Principles (cont.)

7) The design should be structured to degrade gently, even when aberrant data,
events, or operating conditions are encountered.
*) Use messages, progress bars, etc. as often as possible
(for ex: “System shut-down is in progress”, “System is experiencing problems with …”
BUTNO “blue screen of death …)

8) Well-defined depth of details of design solutions: “Design is not

coding, coding is not design”.
*) Do not go too far in depth in design
(for ex: design module in procedural languages is about 20…60 lines of code only)

9) The design MUST BE assessed for quality as it is being created, not

after the fact.
*) There are special measures to assess design quality.

10) The design should be reviewed to minimize conceptual (semantic)

errors.
*) Main conceptual elements of design (omissions, ambiguity, inconsistence, useless
repetitions, etc.) should be addressed at design stage not coding stage.
62
 Software Design:
Focus on FURPS Quality Factors

 Functionality – feature set and program capabilities

 Usability – human factors (aesthetics, consistency,

documentation)

 Reliability – frequency and severity of failure

 Performance – processing speed, response time,

throughput, efficiency

 Supportability – maintainability (extensibility, adaptability,

serviceability), testability, compatibility,
configurability

63
 Software Design: Guidelines that are required by Quality

 A design should exhibit an architecture that (1) has been created using recognizable architectural styles or
patterns, (2) is composed of components that exhibit good design characteristics and (3) can be implemented
in an evolutionary fashion
 For smaller systems, design can sometimes be developed linearly.

 A design should be modular; that is, the software should be logically partitioned into elements or
subsystems

 A design should contain distinct representations of data, architecture, interfaces, and components.

 A design should lead to data structures that are appropriate for the classes to be implemented and are
drawn from recognizable data patterns.

 A design should lead to components that exhibit independent functional characteristics.

 A design should lead to interfaces that reduce the complexity of connections between components and
with the external environment.

 A design should be derived using a repeatable method that is driven by information obtained during
software requirements analysis.

 A design should be represented using a notation that effectively communicates its meaning.
64
 Software Design Engineering

 Goal of software design is to produce a model or representation that is

- bug free (firmness),
- suitable for its intended uses (commodity), and
- pleasurable to use (delight).

 Encompasses the set of

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

 Design principles establish an overriding philosophy that guides the designer as the work is
performed

 Design concepts must be understood before the mechanics of design practice are applied

 Software design practices change continuously as new methods, better analysis, and broader
understanding evolve

65