Design Concepts and Design Principal, Architectural Design, Component Level Design (Function Oriented Design, Object Oriented Design) (MS Visio Tool ),User Interface Design, Web Application Design.

1. Unit-5
Software Design

2. Design Concepts

3. Quality Guidelines
• 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
• 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.

4. Fundamental Concepts
• Abstraction—data, procedure, control
• Architecture—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
• Hiding—controlled interfaces
• 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
• OO design concepts
• Design Classes—provide design detail that will enable analysis classes to be
implemented

5. Data Abstraction
doordoor
implemented as a data structure
manufacturermanufacturer
model numbermodel number
typetype
swing directionswing direction
insertsinserts
lightslights
typetype
numbernumber
weightweight
opening mechanismopening mechanism

6. Procedural Abstraction
openopen
implemented with a "knowledge" of the
object that is associated with enter
details of enterdetails of enter
algorithmalgorithm

7. Modularity
• "modularity is the single attribute of software that
allows a program to be intellectually manageable”.
• Monolithic software (i.e., a large program composed
of a single module) cannot be easily grasped by a
software engineer.
– The number of control paths, span of reference,
number of variables, and overall complexity
would make understanding close to impossible.
• In almost all instances, you should break the design
into many modules, hoping to make understanding
easier and as a consequence, reduce the cost required
to build the software.

8. Functional Independence
• Functional independence is achieved by developing modules with
"single-minded" function and an "aversion" to excessive interaction with
other modules.
• 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.
• 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.

9. Classification of Cohesion

10. Classification of Cohesion
• Coincidental cohesion: A module is said to have
coincidental cohesion, if it performs a set of tasks
that relate to each other very loosely, if at all.

11. Classification of Cohesion
• Logical cohesion: A module is said to be logically
cohesive, if all elements of the module perform
similar operations, e.g. error handling, data input,
data output, etc.

12. Classification of Cohesion
• Temporal cohesion: When a module contains
functions that are related by the fact that all the
functions must be executed in the same time
span, the module is said to exhibit temporal
cohesion.

13. Classification of Cohesion
• Procedural cohesion: A module is said to possess
procedural cohesion, if the set of functions of the module
are all part of a procedure (algorithm) in which certain
sequence of steps have to be carried out for achieving an
objective, e.g. the algorithm for decoding a message.
• Communicational cohesion: A module is said to have
communicational cohesion, if all functions of the module
refer to or update the same data structure, e.g. the set of
functions defined on an array or a stack.

14. Classification of Cohesion
• Sequential cohesion: A module is said to possess
sequential cohesion, if the elements of a module form the
parts of sequence, where the output from one element of
the sequence is input to the next.
• Functional cohesion: Functional cohesion is said to exist, if
different elements of a module cooperate to achieve a
single function.

15. Classification of Coupling

16. Classification of Coupling
• Data coupling: Two modules are data coupled, if
they communicate through a parameter.
• Stamp coupling: Two modules are stamp coupled,
if they communicate using a composite data item
such as a record in PASCAL or a structure in C.

17. Classification of Coupling
• Control coupling: Control coupling exists between
two modules, if data from one module is used to
direct the order of instructions execution in
another.
• Common coupling: Two modules are common
coupled, if they share data through some global
data items.
• Content coupling: Content coupling exists between
two modules, if they share code, e.g. a branch
from one module into another module.

18. Aspects
• 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.
• An aspect is a representation of a cross-
cutting concern.

19. Refactoring
"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.”
• When software is refactored, 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.

20. OO Design Concepts
• Design classes
– Entity classes
– Boundary classes
– Controller classes
• Inheritance—all responsibilities of a superclass is
immediately inherited by all subclasses
• Messages—stimulate some behavior to occur in the
receiving object
• Polymorphism—a characteristic that greatly reduces
the effort required to extend the design

21. Design Model Elements
• Data elements
– Data model --> data structures
– Data model --> database architecture
• Architectural elements
– Application domain
– Analysis classes, their relationships, collaborations and behaviors are
transformed into design realizations
– Patterns and “styles” (Chapters 9 and 12)
• Interface elements
– the user interface (UI)
– external interfaces to other systems, devices, networks or other producers
or consumers of information
– internal interfaces between various design components.
• Component elements
• Deployment elements

22. Architecture & User Interface
Design

23. Definitions
• The software architecture of a program or computing system is
the structure or structures of the system which comprise
– The software components
– The externally visible properties of those components
– The relationships among the components
• Software architectural design represents the structure of the
data and program components that are required to build a
computer-based system
• An architectural design model is transferable
– It can be applied to the design of other systems
– It represents a set of abstractions that enable software
engineers to describe architecture in predictable ways

24. Architectural Design Process
• Basic Steps
– Creation of the data design
– Derivation of one or more representations of the
architectural structure of the system
– Analysis of alternative architectural styles to choose the one
best suited to customer requirements and quality attributes
– Elaboration of the architecture based on the selected
architectural style
• A database designer creates the data architecture for a system
to represent the data components
• A system architect selects an appropriate architectural style
derived during system engineering and software requirements
analysis

25. Architectural Elements
• The architectural model is derived from
below sources:
– information about the application domain for the
software to be built;
– specific requirements model elements such as
data flow diagrams or analysis classes, their
relationships and collaborations for the problem
at hand.

26. Software Architecture
• “The software architecture of a program or computing system is
the structure or structures of the system, which comprise the
software components, the externally visible properties of those
components, and the relationships among them.”
• It is not operational software but it is representation that enables
software engineer to
– Analyze the effectiveness of design in meeting its stated
requirement.
– consider architectural alternatives at a stage when making
design changes is still relatively easy,
– reduce the risks associated with the construction of the
software.

27. Importance of Software Architecture
• Representations of software architecture are an enabler for
communication between all parties (stakeholders) interested in
the development
• Architecture highlights early design decisions that will have a
profound impact on all software engineering work that follows.
• Architecture “constitutes a relatively small, intellectually
graspable model of how the system is structured and how its
components work together”

28. Data Design
• The structure of data has always been an
important part of software design.
• Component level – the design of data structures
and the associated algorithms required to
manipulate them is essential to the creation of
high-quality applications.
• Application level – the translation of a data model
into a database design

29. Data design at the component level
• Component level focuses on the representation of data structures that are
directly accessed by one or more software components.
Principles are applicable to data design
1. The systematic analysis principles applied to function and behavior should
also be applied to data.
2. All data structures and the operations to be performed on each should be
identified.
3. A data dictionary should be established and used to define both data and
program design (operations)
4. Low-level data design decisions should be deferred until late in the design
process.

30. 5. The representation of data structure should be known only to those
modules that must make direct use of the data contained within the
structure.
6. A library of useful data structures and the operations that may be
applied to them should be developed.
7. A software design and programming language should support the
specification and realization of abstract data types.

31. Architectural Style
• Style describes a system category that encompasses
1. A set of components (e.g., a database, computational modules) that
perform a function required by a system;
2. a set of connectors that enable “communication, co-ordinations and
cooperation” among components;
3. constraints that define how components can be integrated to form
the system
4. semantic models that enable a designer to understand the overall
properties of a system
It can be represent by
– Data-centered architecture
– Data flow architecture
– Call and return architecture
– Object oriented architecture
– Layered architecture.

32. Data-centered architecture

33. Data Flow architecture
Pipes and
filters
Batch Sequential

34. Data Flow architecture
• This architecture is applied when input data are to be transformed
through a series of computational or manipulative components into
output data.
• A pipe and filter pattern has a set of components, called filters,
connected by pipes that transmit data from one component to the
next.
• Each filter works independently (i.e. upstream, downstream) and is
designed to expect data input of a certain form, and produces data
output (to the next filter) of a specified form.
• the filter does not require knowledge of the working of its neighboring
filters.
• If the data flow degenerates into a single line of transforms, it is
termed batch sequential.

35. Call and return architecture

36. Call and return architecture
• Architecture style enables a software designer (system architect)
to achieve a program structure that is relatively easy to modify
and scale.
• Two sub-styles exist within this category:
1. Main/sub program architecture:
• Program structure decomposes function into a control hierarchy
where a “main” program invokes a number of program
components, which in turn may invoke still other components.
2. Remote procedure Call architecture:
• The components of a main program/subprogram architecture are
distributed across multiple computers on a network

37. Object-oriented architecture

38. Object-oriented architecture
• The object-oriented paradigm, like the abstract data type paradigm from
which it evolved, emphasizes the bundling of data and methods to
manipulate and access that data (Public Interface).
• Components of a system summarize data and the operations that must be
applied to manipulate the data.
• Communication and coordination between components is accomplished
via message passing.

39. Layered Architecture

40. User Interface
Analysis and Design

41. User Interface Design
• User interface design creates an effective
communication medium between a human
and a computer.
• Following a set of interface design principles,
design identifies interface objects and actions
and then creates a screen layout that forms
the basis for a user interface prototype.

42. Design Evaluation
user interface evaluation cycle

43. Background
• Interface design focuses on the following
– The design of interfaces between software components
– The design of interfaces between the software and other
nonhuman producers and consumers of information
– The design of the interface between a human and the
computer
• Graphical user interfaces (GUIs) have helped to eliminate
many of the most horrific interface problems
• However, some are still difficult to learn, hard to use,
confusing, counterintuitive, unforgiving, and frustrating
• User interface analysis and design has to do with the study of
people and how they relate to technology

44. A Spiral Process
• User interface development follows a spiral process
– Interface analysis (user, task, and environment analysis)
• Focuses on the profile of the users who will interact with the system
• Concentrates on users, tasks, content and work environment
– Interface design
• Defines a set of interface objects and actions (and their screen
representations) that enable a user to perform all defined tasks in a
manner that meets every usability goal defined for the system
– Interface construction
• Begins with a prototype that enables usage scenarios to be evaluated
• Continues with development tools to complete the construction
– Interface validation, focuses on
• The ability of the interface to implement every user task correctly, to
accommodate all task variations, and to achieve all general user
requirements

45. The Golden Rules of
User Interface Design

46. Place the User in Control
• Define interaction modes in a way that does not force a user into
unnecessary or undesired actions
– The user shall be able to enter and exit a mode with little or no
effort (e.g., spell check  edit text  spell check)
• Provide for flexible interaction
– The user shall be able to perform the same action via keyboard
commands, mouse movement, or voice recognition
• Allow user interaction to be interruptible and "undo"able
– The user shall be able to easily interrupt a sequence of actions
to do something else (without losing the work that has been
done so far)
– The user shall be able to "undo" any action

47. Place the User in Control
• 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
• Hide technical internals from the casual user
– The user shall not be required to directly use operating system, file management
networking. etc., commands to perform any actions. 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)

48. Make the Interface Consistent
• The interface should present and acquire information in a
consistent fashion
• Allow the user to put the current task into a meaningful context
• Maintain consistency across a family of applications
• If past interactive models have created user expectations, do not
make changes unless there is a compelling reason to do so

49. • Four different models come into play when a user
interface is analyzed and designed
– User profile model – Established by a human engineer
or software engineer
– Design model – Created by a software engineer
– Implementation model – Created by the software
implementers
– User's mental model – Developed by the user when
interacting with the application
• The role of the interface designer is to merge these
differences and derive a consistent representation of the
interface

50. User Profile Model• Establishes the profile of the end-users of the system
– Based on age, gender, physical abilities, education, cultural or ethnic background,
motivation, goals, and personality
• Considers syntactic knowledge of the user
– The mechanics of interaction that are required to use the interface effectively
• Considers semantic knowledge of the user
– The underlying sense of the application; an understanding of the functions that are
performed, the meaning of input and output, and the objectives of the system
• Categorizes users as
– Novices
• No syntactic knowledge of the system, little semantic knowledge of the application, only
general computer usage
– Knowledgeable, intermittent users
• Reasonable semantic knowledge of the system, low recall of syntactic information to use the
interface
– Knowledgeable, frequent users
• Good semantic and syntactic knowledge (i.e., power user), look for shortcuts and abbreviated
modes of operation

51. Design Model
• Derived from the analysis model of the requirements
• Incorporates data, architectural, interface, and procedural
representations of the software
• Constrained by information in the requirements specification that
helps define the user of the system
• Normally is incidental to other parts of the design model
– But in many cases it is as important as the other parts

52. Implementation Model
• Consists of the look and feel of the interface
combined with all supporting information (books,
videos, help files) that describe system syntax and
semantics
• Strives to agree with the user's mental model; users
then feel comfortable with the software and use it
effectively
• Serves as a translation of the design model by
providing a realization of the information contained
in the user profile model and the user’s mental
model

53. User's Mental Model
• Often called the user's system perception
• Consists of the image of the system that users
carry in their heads
• Accuracy of the description depends upon the
user’s profile and overall familiarity with the
software in the application domain

54. User Interface Analysis

55. Elements of the User Interface
• To perform user interface analysis, the practitioner needs to
study and understand four elements
– The users who will interact with the system through the
interface
– The tasks that end users must perform to do their work
– The content that is presented as part of the interface
– The work environment in which these tasks will be
conducted

56. User Analysis
• The analyst strives to get the end user's mental model and the
design model to converge by understanding
– The users themselves
– How these people use the system
• Information can be obtained from
– User interviews with the end users
– Sales input from the sales people who interact with customers
and users on a regular basis
– Marketing input based on a market analysis to understand how
different population segments might use the software
– Support input from the support staff who are aware of what
works and what doesn't, what users like and dislike, what
features generate questions, and what features are easy to use
• A set of questions should be answered during user analysis

57. Task Analysis and Modeling
• Task analysis strives to know and understand
– The work the user performs in specific circumstances
– The tasks and subtasks that will be performed as the user does the work
– The specific problem domain objects that the user manipulates as work is
performed
– The sequence of work tasks (i.e., the workflow)
– The hierarchy of tasks
• Use cases
– Show how an end user performs some specific work-related task
– Enable the software engineer to extract tasks, objects, and overall workflow
of the interaction
– Helps the software engineer to identify additional helpful features

58. Content Analysis
• The display content may range from character-based reports,
to graphical displays, to multimedia information
• Display content may be
– Generated by components in other parts of the
application
– Acquired from data stored in a database that is accessible
from the application
– Transmitted from systems external to the application in
question
• The format and aesthetics of the content (as it is displayed by
the interface) needs to be considered
• A set of questions should be answered during content

59. Work Environment Analysis
• Software products need to be designed to fit into the work environment,
otherwise they may be difficult or frustrating to use
• Factors to consider include
– Type of lighting
– Display size and height
– Keyboard size, height and ease of use
– Mouse type and ease of use
– Surrounding noise
– Space limitations for computer and/or user
– Weather or other atmospheric conditions
– Temperature or pressure restrictions
– Time restrictions (when, how fast, and for how long)

60. Component-Level Design

61. Introduction

62. Background
• Component-level design occurs after the
first iteration of the architectural design
• It attempts to create a design model from
the analysis and architectural models

63. The Software Component

64. Defined
• A software component is a modular building block for computer
software
– It is a modular, deployable, and replaceable part of a system
that encapsulates implementation and exposes a set of
interfaces
• A component communicates and collaborates with
– Other components
– Entities outside the boundaries of the system
• Three different views of a component
– An object-oriented view
– A conventional view
– A process-related view

65. Designing Class-Based
Components

66. Component-Level Design
Guidelines• Components
– Establish naming conventions for components that are specified
as part of the architectural model and then refined and
elaborated as part of the component-level model
– Obtain architectural component names from the problem
domain and ensure that they have meaning to all stakeholders
who view the architectural model (e.g., Calculator)
– Use infrastructure component names that reflect their
implementation-specific meaning (e.g., Stack)
• Dependencies and inheritance in UML
– Model any dependencies from left to right and inheritance from
top (base class) to bottom (derived classes)
– Consider modeling any component dependencies as interfaces
rather than representing them as a direct component-to-
component dependency

67. Graphical Design Notation
Sequence If-then-else
Selection Repetition
T F
T
T
T
F
F
F
T
F

68. Tabular Design Notation
1) List all actions that can be associated with a specific procedure
(or module)
2) List all conditions (or decisions made) during execution of the
procedure
3) Associate specific sets of conditions with specific actions,
eliminating impossible combinations of conditions;
alternatively, develop every possible permutation of conditions
4) Define rules by indicating what action(s) occurs for a set of
conditions

69. Tabular Design Notation
(continued)
Conditions 1 2 3 4
Condition A T T F
Condition B F T
Condition C T T
Actions
Action X  
Action Y 
Action Z   
Rules