Software Engineering

(CSC 3114)

Software Design

1
 Software Design

• Software design is an iterative process through which

requirements are translated into a “blueprint” for
constructing the software.
– Initially, the blueprint depicts a holistic view of software
• Software design encompasses a set of principles, concepts
and practices that lead to the development of a high-quality
system or product.
– The quality of the design is assessed through a series of technical
reviews or design walkthroughs
• The goal of software design is to create a model of software
that will implement all customer requirements correctly and
bring delight to those who use it.

2
 Software Design: Why is it important?

• Design allows to model the system that is to be built. This

model can be assessed for quality and improved before code
is generated, tests are conducted, and end users become
involved in large numbers.
• Design is the place where software quality is established.
• Without design, we risk building an unstable system that
– Will fail when small changes are made
– May be difficult to test
– Cannot be assessed for quality later in the software process
when time is short and most of the budget has been spent

3
 Software Design

 Mitch Kapor, the creator of Lotus 1-2-3, presented a

“software design manifesto” in Dr. Dobbs Journal.
He said that good software design should exhibit:
• Firmness: A program should not have any bugs
that inhibit its function.
• Commodity: A program should be suitable for the
purposes for which it was intended.
• Delight: The experience of using the program
should be a pleasurable one.

4
 Characteristics that serve as guide for the
evaluation of a good Design
1) The design 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.
2) The design must be a readable, understandable guide for
those who generate code and for those who test and
subsequently support the software.
3) The design should provide a complete picture of the
software, addressing the data, functional, and behavioral
domains from an implementation perspective.

5
 Fundamental SW Design Concepts
• Abstraction (data, procedure, control ) – as a mechanism for creating
reusable software components
• Architecture — to better understand the overall structure of the software
• Patterns—”conveys the essence” of a proven design solution
• Separation of concerns —any complex problem can be more easily
handled if it is subdivided into pieces
• Modularity —compartmentalization of data and function, to make
software more testable and more maintainable
• Information Hiding —the designing of modules so that the algorithms and
local data contained within them are inaccessible from other modules,
for reducing the propagation of side effects when errors occur

6
 Fundamental SW Design Concepts
• Functional independence —single-minded function and low coupling
• Refinement —elaboration of detail for all abstractions
• Aspects —a mechanism for understanding how global requirements affect
design
• Refactoring —a reorganization technique that simplifies the design (or code)
of a component without changing its function or external behavior.
• OO design concepts — OO paradigm is widely used in modern SE (classes,
objects, inheritance, messages, polymorphism etc.) – Appendix 2
• Design Classes— refines the analysis classes by providing design detail that
will enable the classes to be implemented

7
 Abstraction
• “Abstraction permits one to concentrate on a problem at
some level of abstraction without regard to low level
details”
• Data Abstraction
– This is a named collection of data that describes a data object
• Procedural Abstraction
– Refers to a sequence of instructions that has a specific & limited
function
• Control Abstraction
– A program control mechanism without specifying internal details

8
 Architecture
 “The overall structure of the software and the ways
in which that structure provides conceptual integrity
for a system.” [SHA95a]

 Software Architecture: The hierarchical structure of

program components, the manner in which these
components interact and the structure of data that
are used by the components.

9
 Patterns
• Each pattern describes a problem which occurs over
and over again in our environment, and then
describes the core of the solution to that problem, in
such a way that you can use this solution a million
times over, without ever doing it the same way
twice.

10
 Separation of Concerns
• Separation of concerns is a design concept that suggests that
any complex problem can be more easily handled if it is
subdivided into pieces that can each be solved and/or
optimized independently.
• A concern is a feature or behavior that is specified as part of
the requirements model for the software.
• By separating concerns into smaller, and therefore more
manageable pieces, a problem takes less effort and time to
solve.
• Divide-and-conquer strategy

11
 Modularity
 Modularity is an attribute of software that allows a program to be
intellectually manageable into distinct logical parts.
 Modularity is the degree to which a system's components are logically
separated into distinct parts called modules and recombined again.
 Monolithic software (i.e., a large program composed of a single
module) cannot be easily grasped by a software engineer. Modularity
makes software intellectually manageable so as to grasp the control
paths, span of reference, number of variables, and overall complexity.
 In almost all instances, you should break the design into many
modules, hoping to make understanding easier and as a consequence,
reduce the complexity and cost required to build the software.

12
 Modularity
• Don’t overdo it. Too many modules makes integration
complicated
• Sometimes the code must be monolithic (e.g. real-time
and embedded software) but the design still shouldn’t
be
• Effective modular design is achieved by developing
“single minded” (highly cohesive) modules with an
“aversion” to excessive interaction (low coupling)
• Benefits of Modularity – Easier to build; easier to
change; easier to fix
13
 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
14
 Information Hiding
• A more accurate term would be “details hiding”
• Modules should be “characterized by design
decisions that each hides from all others”
• Modules are designed so that information within a
module is inaccessible to other modules with no
need for the information
• Defines and enforces access constraints
• Very important for accommodating change and
reducing coupling

15
 Why Information Hiding?
• Reduces the likelihood of “side effects”
• Limits the global impact of local design decisions
• Emphasizes communication through controlled
interfaces
• Discourages the use of global data
• Leads to encapsulation—an attribute of high quality
design
• Results in higher quality software

16
 Refinement
• Refinement is a process where one or several
instructions of the program are decomposed into
more detailed instructions.
• Refinement is actually a process of elaboration
• Stepwise Refinement
– A top-down design strategy
– Gradual top-down elaboration of detail
– Abstraction and Refinement are complementary. Abstraction
suppresses low-level detail while Refinement gradually reveals it.

17
 Functional Independence
• Functional independence is a key to good design and design is
the key to software quality.
• Functional independence is achieved by developing modules
with "single-minded" function and an "aversion" to excessive
interaction with other modules.
• Benefits:
• Easier to develop
• Easier to maintain & test
• Measured using 2 qualitative criteria:
 Cohesion : Measure of the relative strength of a module
 Coupling : Measure of the relative interdependence among modules

18
 Functional Independence
• Cohesion is an indication of the relative 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.
– The degree of interaction within a module
– Strive for high cohesion

• 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.
– The degree of interaction between modules
– Strive for lowest coupling possible

19
 Aspects
• As design begins, requirements are refined into a
modular design representation.
• Consider two requirements, A and B.
Requirement A crosscuts requirement B “if a software
decomposition [refinement] has been chosen in which
B cannot be satisfied without taking A into account”
[Ros04]
• An aspect is a representation of a cross-cutting
concern.

20
 Refactoring
• An important design activity suggested for many
agile methods.
• Refactoring is a reorganization technique that
simplifies the design (or code) of a component
without changing its function or behavior.
• Fowler [FOW99] defines refactoring in the following
manner:
– "Refactoring is the process of changing a software system
in such a way that it does not alter the external behavior of
the code [design] yet improves its internal structure.”

21
 Refactoring
• During refactoring, the existing design is
examined for
– redundancy
– unused design elements
– inefficient or unnecessary algorithms
– poorly constructed or inappropriate data
structures, or
– any other design failure that can be corrected to
yield a better design

22
User Interface (UI)
Design

23
 User Interface (UI) Design
• What is a User Interface?
– The most important element of a computer-based system
– A User Interface is the body of a software
• What is User Interface Design?
– User interface (UI) design is the process of making interfaces in
software or computerized devices with a focus on looks or style.
Designers aim to create designs users will find easy to use, easy to
learn and pleasurable. UI design typically refers to graphical user
interfaces but also includes others, such as voice-controlled ones.
– UI design creates an effective communication medium between a
human and a computer.

24
 Why UI Design is Important?
• If software is difficult to use, if it forces you into mistakes, or if
it frustrates your efforts to accomplish your goals, you won’t
like it, regardless of the computational power it exhibits, the
content it delivers, or the functionality it offers. The interface
has to be right because it molds a user’s perception of the
software.
• If the UI is poorly designed, the user’s ability to tap the
computational power and informational content of an
application may be severely hindered. In fact, a weak
interface may cause an otherwise well-designed and solidly
implemented application to fail.

25
 User Interface (UI) design

• Easy to learn?
• Easy to use?
• Easy to understand? Typical Design Errors
• lack of consistency
• too much memorization
• no guidance / help
• no context sensitivity
• Obscure / unfriendly

26
 The Golden Rules of UI Design
(coined by Theo Mandel [MAN97])

1. Place the user in control

2. Reduce the user’s memory load
3. Make the interface consistent

27
 (1) Place the User in Control
• Define interaction modes in a way that does not force a user into unnecessary
or undesired actions. - The user should always be able to enter and exit the
mode with little or no effort.
• Provide for flexible interaction - Because different users have different
interaction preferences, choices should be provided (e.g. software might allow
a user to interact via keyboard commands, mouse movements, digitizer pen or
voice recognition commands).
• Allow user interaction to be interruptible and undoable - A user should be able
to interrupt a sequence of actions to do something else (without losing the
work that has been done). The user should always be able to “undo” any
action.
• Streamline interaction as skill levels advance and allow the interaction to be
customized – The user shall be able to use a macro mechanism to perform a
sequence of repeated interactions and to customize the interface
28
 (1) Place the User in Control
• Hide technical internals from the casual user - The user shall
not be required to directly use OS, file management,
networking etc. commands to perform any action. Instead,
these operations shall be hidden from the user and performed
“behind the scenes” in the form of a real-world abstraction
• Design for direct interaction with objects that appear on the
screen – The user shall be able to manipulate objects on the
screen in a manner similar to what would occur if the object
were a physical thing (e.g. stretch a rectangle, press a button,
move a slider)

29
 (2) Reduce the User’s Memory Load
• Reduce demand on short-term memory (navigation) – The interface shall provide visual
cues that enable a user to recognize past actions, inputs, and results rather than having
to recall them
• Establish meaningful defaults - A user should be able to specify individual preferences;
however, a reset option should be available to enable the redefinition of original default
values (e.g. balance 0.00).
• Define shortcuts that are intuitive (intuitive - having the ability to understand or know
something without any direct evidence or reasoning process) – e.g.,“Alt-P to print”
• The visual layout of the interface should be based on a real world metaphor – The
screen layout of the UI shall contain well-understood visual cues that the user can relate
to real-world actions (e.g. Print Symbol)
• Disclose information in a progressive fashion - The interface should be organized
hierarchically. The information should be presented first at a high level of abstraction.

30
 (3) Make the Interface Consistent
• Allow the user to put the current task into a meaningful
context - The user should be able to determine where he has
come from and what alternatives exist for a transition to a new
task.
• Maintain consistency across a family of applications - “MS
Office Suite”
• If past interactive models have created user expectations, do
not make changes unless there is a compelling reason to do so -
Once a particular interactive sequence has become a de-facto
standard (Alt-S  save file), the user expects this in every
application she encounters.

31
 Interface Analysis

Interface Analysis means understanding :

1. The people (end-users) who will interact with the system
through the interface
2. The tasks that end-users must perform to do their work
3. The content that is presented as part of the interface
4. The environment in which these tasks will be conducted
(e.g. embedded system)

32
 User Analysis
• Are users trained professionals, technician, official, or manufacturing workers?
• What level of formal education does the average user have?
• Are the users capable of learning from written materials or have they expressed a
desire for classroom training?
• Are users expert typists or keyboard phobic?
• What is the gender and age range of the user community?
• How are users compensated for the work they perform? Do users work normal
office hours or do they work until the job is done? (banking software)
• Is the software to be an integral part of the work users do or will it be used only
occasionally?
• What is the primary spoken language among users?
• What are the consequences if a user makes a mistake using the system?
• Are users experts in the subject matter that is addressed by the system?
• Do users want to know about the technology that sits behind the interface?

33
 Task Analysis and Modeling
 Answers the following questions …
– What work will the user perform in specific circumstances?
– What tasks and subtasks will be performed as the user does the work?
– What specific problem domain objects will the user manipulate as work
is performed?
– What is the sequence of work tasks—the workflow?
– What is the hierarchy of tasks?
 Use-cases define basic interaction
 Object elaboration identifies interface objects (classes)
 Task elaboration refines interactive tasks
 Workflow analysis defines how a work process is completed
when several people (and roles) are involved
– Swimlane diagram
34
 Analysis of Display Content
• Are different types of data assigned to consistent geographic locations on the
screen (e.g., photos always appear in the upper right hand corner)?
• Can the user customize the screen location for content?
• Is proper on-screen identification assigned to all content?
• If a large report is to be presented, how should it be partitioned for ease of
understanding?
• Will mechanisms be available for moving directly to summary information for large
collections of data.
• Will graphical output be scaled to fit within the bounds of the display device that is
used? (e.g. smart phones)
• How will color to be used to enhance understanding? (errors are in red color)
• How will error messages and warning be presented to the user? (dialogue box, or
text message)
Remember that the font carry a message to!
peace
WAR

35
 Interface Design Principles-I
• Anticipation —A WebApp should be designed so that it anticipates the
use’s next move.
• Communication —The interface should communicate the status of any
activity initiated by the user
• Consistency —The use of navigation controls, menus, icons, and
aesthetics (e.g., color, shape, layout)
• Controlled autonomy —The interface should facilitate user movement
throughout the WebApp, but it should do so in a manner that enforces
navigation conventions that have been established for the application.
• Efficiency —The design of the WebApp and its interface should optimize
the user’s work efficiency, not the efficiency of the Web engineer who
designs and builds it or the client-server environment that executes it.

36
 Interface Design Principles-II
• Focus —The WebApp interface (and the content it presents) should
stay focused on the user task(s) at hand.
• Fitt’s Law —“The time to acquire a target is a function of the
distance to and size of the target.”
• Human interface objects —A vast library of reusable human
interface objects has been developed for Web and MobileApps.
• Latency reduction —The WebApp should use multi-tasking in a way
that lets the user proceed with work as if the operation has been
completed.
• Learnability — A WebApp interface should be designed to minimize
learning time, and once learned, to minimize relearning required
when the WebApp is revisited.

37
 Interface Design Principles-III
• Maintain work product integrity —A work product (e.g., a form
completed by the user, a user specified list) must be
automatically saved so that it will not be lost if an error occurs.
• Readability —All information presented through the interface
should be readable by young and old.
• Track state —When appropriate, the state of the user
interaction should be tracked and stored so that a user can
logoff and return later to pick up where she left off.
• Visible navigation —A well-designed WebApp interface provides
“the illusion that users are in the same place, with the work
brought to them.”

38
 Mapping User Objectives
Menu bar
major functions

List of use r obje ct ive s

graphic, logo, and company name
obje ct ive #1
obje ct ive #2

obje ct ive #3
obje ct ive #4

obje ct ive #5
graphic

obje ct ive #n

Home page text copy

Navigation
menu

39
User Interface Design Process

40
 Design Evaluation Cycle
preliminary
design

build
prototype #1
interface

build
prototype # n
interface

user
evaluate's
interface
design
modifications
are made

evaluation
is studied by
designer

Interface design
is complete

41
 Design Evaluation Cycle
1) Preliminary design
2) Build first interface prototype
3) User evaluates interface
4) Evaluation is studied by designer
5) Design modifications made
6) Build next prototype
7) If interface is not complete, then go to step 3

42