UNIT III SOFTWARE DESIGN

Design process – Design Concepts-Design Model– Design Heuristic – Architectural Design -

Architectural styles, Architectural Design, Architectural Mapping using Data Flow- User
Interface Design: Interface analysis, Interface Design –Component level Design: Designing Class
based components, traditional Components.

Software design 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 you in the design work you must perform. Design concepts must be understood before the
mechanics of design practice are applied, and design practice itself leads to the creation of various
representations of the software that serve as a guide for the construction activity.

DESIGN PROCESS
 Software design consists of the set of principles, concepts, and practices which is used for
developing the system or product
 Software design is an iterative process through which requirements are translated into a
blueprint for constructing the software

Fig: Translating the Requirements model into Design model

 Initially the design is represented at a high level of abstraction and as iteration occurs, the
design shows lower levels of abstraction.
 The design model provides detail about the software data structures, architecture, interfaces,
and components
Characteristics of a good design
 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.
 The design must be a readable, understandable guide for those who generate code and for those

1
 who test and subsequently support the software.
 The design should provide a complete picture of the software, addressing the data, functional,
and behavioral domains from an implementation perspective.

Quality Guidelines
 A design should exhibit an architecture that is created using recognizable architectural styles or
patterns and composed of components that exhibit good design characteristics and can be
implemented in an evolutionary fashion
 A design should be modular
 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.
Design Principles
 The design process should not suffer from ‘tunnel vision.’
 The design should be traceable to the analysis model.
 The design should exhibit uniformity and integration.
 The design should be structured to accommodate change.
 The design should be structured to degrade gently, even when aberrant data, events, or
operating conditions are encountered.
 Design is not coding, coding is not design.
 The design should be assessed for quality as it is being created, not after the fact.
 The design should be reviewed to minimize semantic errors.
Quality Attributes. [FURPS]
 Functionality is assessed by evaluating the feature set and capabilities of the program and the
security of the overall system etc.

 Usability is assessed by considering human factors, consistency and documentation.

2
  Reliability is evaluated by measuring the frequency and severity of failure, the mean- time-to-
failure (MTTF), the ability to recover from failure etc.
 Performance is measured by considering processing speed, response time, resource
consumption, throughput, and efficiency.
 Supportability combines the ability to extend the program (extensibility), adaptability,
serviceability
The Evolution of Software Design
 Early design work concentrated on criteria for the development of modular programs and
methods for refining software structures in a top down manner.
 Procedural aspects of design definition evolved into structured programming
 Later work proposed methods for the translation of data flow into a design definition.
 Newer design approaches proposed an object-oriented approach to design derivation.
 The design patterns can be used to implement software architectures and lower levels of design
abstractions.
 Aspect-oriented methods, model-driven development, and test-driven development emphasize
techniques for achieving more effective modularity and architectural structure in the designs.
Characteristics of design methods:
(1) A mechanism for the translation of the requirements model into a design representation,
(2) A notation for representing functional components and their interfaces,
(3) Heuristics for refinement and partitioning, and
(4) Guidelines for quality assessment.
DESIGN CONCEPTS
Concepts that has to be considered while designing the software are:
Abstraction, Modularity, Architecture, pattern, Functional independence, refinement,
information hiding, refactoring and design classes

1. Abstraction
 There are many levels of abstraction
 At the highest level of abstraction, a solution is stated in broad terms and at lower levels of
abstraction, a more detailed description of the solution is provided.
Types:
 Procedural abstraction refers to a sequence of instructions that have a specific and limited
function
 Example: open for a door. Open implies a long sequence of procedural steps (e.g., walk to

3
 the door, reach out and grasp knob, turn knob and pull door, step away from moving door,
etc.).
 Data abstraction is a named collection of data that describes a data object
 Eg: Data abstraction for door would encompass a set of attributes that describe the door (e.g.,
door type, swing direction, opening mechanism, weight, dimensions).
2. Architecture
 Software architecture is the overall structure of the software and the ways in which that
structure provides conceptual integrity for a system
Properties:
 Structural properties. This representation defines the components of a system and how they
interact with one another.
 Extra-functional properties. The architectural design should address how the design
architecture achieves requirements for performance, capacity, reliability, security, adaptability.
 Families of related systems. The architectural design should draw upon repeatable patterns that
are commonly encountered in the design of families of similar systems
Models to represent the Architectural design:
 Structural models represent architecture as an organized collection of program components.
 Framework models increase the level of design abstraction by attempting to identify repeatable
architectural design frameworks that are encountered in similar types of applications.
 Dynamic models address the behavioural aspects of the program architecture, indicating how the
structure changes when an external event occurs.
 Process models focus on the design of the business or technical process that the system must
accommodate.
 Functional models can be used to represent the functional hierarchy of a system.
 A number of different architectural description languages (ADLs) have been developed to
represent these models
3. Patterns
 Design pattern is a design structure that solves a particular design problem within a specific
context
 It provides a description to determine whether the pattern is applicable, whether the pattern can
be reused, and whether the pattern can serve as a guide for developing similar patterns
Separation of Concerns
 Any complex problem can be more easily handled by subdividing it into pieces which can be

4
 solved 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 manageable pieces, a problem takes less effort and time to
solve.
Modularity
 Modularity is the single attribute of software that allows a program to be intellectually
manageable
 Module is a separately named and addressable components that are integrated to satisfy
requirements (divide and conquer principle)
4. Information Hiding
 Information hiding is that the algorithms and local data contained within a module are
inaccessible to other modules
5. Functional Independence
 Functional independence is achieved by developing modules that have a "single-minded"
function having less interaction with other modules
 Independent modules are easier to maintain and test and error propagation is also reduced.
 Independence is assessed using two qualitative criteria: cohesion and coupling.
 Cohesion is an indication of the relative functional strength of a module.
 Coupling is an indication of the relative interdependence among modules.
 A module should have high cohesion and low coupling
 High cohesion – a module performs only a single task
 Low coupling – a module has the lowest amount of connection needed with other modules
6. Refinement
 Refinement is a process of elaboration
 It is the development of a program by successively refining levels of procedure detail
 This complements abstraction, which enables a designer to specify procedure and data and
suppress low-level details
 Refinement helps to reveal low-level details as design progresses.
Aspects
 An aspect is a representation of a cross-cutting concern

 These concerns include requirements, use cases, features, data structures, quality-of- service
issues, variants, intellectual property boundaries, collaborations, patterns and contracts

5
7. Refactoring
 Refactoring is a reorganization technique that simplifies the design of a component without
changing its function or external behaviour
 It removes redundancy, unused design elements, inefficient or unnecessary algorithms, poorly
constructed or inappropriate data structures, or any other design failures

DESIGN MODEL
 The design model can be viewed in two different dimensions
– (Horizontally) The process dimension indicates the evolution of the parts of the design
model as each design task is executed
– (Vertically) The abstraction dimension represents the level of detail as each element of
the analysis model is transformed into the design model and then iteratively refined
 Elements of the design model use many of the same UML diagrams used in the analysis model
– The diagrams are refined and elaborated as part of the design
– More implementation-specific detail is provided

Fig: Dimensions of the Design Model

 In Design model the emphasis is placed on

 Architectural structure and style
 Interfaces between components and the outside world
 Components that reside within the architecture
 The design model has the following layered elements
1. Data/class design
2. Architectural design
3. Interface design
4. Component-level design
 A fifth element that follows all of the others is deployment-level design

6
DESIGN ELEMENTS
1. Data/class design elements
 Data design creates a model of data and objects that is represented at a high level of abstraction

 This data model is then refined into progressively more implementation-specific representations
 At the program component level, the design of data structures and the associated algorithms are
used for the creating the high-quality applications.
 At the application level, the translation of a data model into a database is essential to achieve the
business objectives of a system.
 At the business level, the collection of information stored in different databases and reorganized into
a data warehouse enables data mining or knowledge discovery.
2. Architectural design elements
 Architectural design depicts the overall layout of the software
 The architectural model is derived from three sources:
(1) Information about the application domain
(2) Specific requirements model elements such as data flow diagrams and their relationships
(3) The availability of architectural styles and patterns.
 The architectural design element is usually represented as a set of interconnected subsystems, each
have its own architecture
3. Interface design elements
 Interface design tells how information flows into and out of the system and how it is communicated
among the various components of the architecture
 Elements of interface design:
o user interface,
o external interfaces, and
o internal interfaces.
 UI design (called as usability design) incorporates aesthetic elements (e.g., layout, color, graphics,
interaction mechanisms), ergonomic elements (e.g., information layout and placement, metaphors,

7
 UI navigation), and technical elements (e.g., UI patterns, reusable components).
 External interface design requires information about the entity to which the information is
communicated. The design should incorporate error checking and security features.
 Internal interface design is related with component-level design. Design realizations represent all
operations and the messaging schemes required to enable communication and collaboration between
operations in various classes.
4. Component-level design elements
 Component level design describes the internal detail of each software component like data structure
definitions, algorithms, and interface specifications.
 A UML activity diagram can be used to represent processing logic.
 Pseudocode or some other diagrammatic form (e.g., flowchart or box diagram) is used to represent
the detailed procedural flow between the component.
 Algorithmic structure follows the rules established for structured programming
 E.g.

Fig: Component diagram

5. Deployment-level design elements
 This design indicates how software functionality and subsystems will be allocated within the
physical computing environment that will support the software

Fig: Deployment Diagram

8
 DESIGN HEURISTIC
1. Evaluate the first iteration of the program structure to reduce the coupling and improve
cohesion
 The module independency can be achieved by exploding or imploding the modules
 Exploding means obtaining more than one modules in the final stage
 Imploding means combining the results of different modules
2. Attempt to minimize the structures with high fan-out and strive for fan-in as depth increases
 At the higher level of program structure the distribution of control should be made.
 Fan in means number of immediate ancestors the modules have
 Fan –out means number of immediate subordinates to the module.
3. Keep scope of the effect of a module within the scope of control of that module
 The decisions made in one module should not affect the other module which is not inside its scope
4. Evaluate the module interfaces to reduce complexity and redundancy and improve consistency
 The major cause of errors is module interfaces. They should simply pass the information and should be
consistent with the module
5. Define module whose function is predictable but avoid modules that are too restrictive
 The modules should be designed with simple processing logics and should not restrict the size of the
local data structure, control flow or modes of external interfaces
6. Strive for controlled entry modules by avoiding pathological connections
 Interfaces should be constrained and controlled. Pathological connection means many references or
branches into the middle of the module

9
 ARCHITECTURAL DESIGN
 The software architecture is the overall structure of the system which is includes the software
components , their properties and 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
o It can be applied to the design of other systems
o It represents a set of abstractions that enable software engineers to describe architecture in predictable
ways
 For deriving the architecture, horizontal and vertical partitioning are required
Horizontal Partitioning
 Horizontal Partitioning define separate branches of the module hierarchy for each major function
 This use control modules to coordinate communication between functions
 Eg:

Fig: Horizontal Partitioning Vertical Partitioning: Factoring

 Vertical partitioning suggests the control and work should be distributed top-down in the program
structure.
 The decision making modules should reside at the top of the architecture

Fig: Vertical Partitioning

ARCHITECTURAL STYLES
 The architectural styles is used to describes a system which has :
o A set of components that perform a function required by the system
o A set of connectors enabling communication among components
o Semantic constraints that define how components can be integrated to form the system
o A topological layout of the components indicating their runtime interrelationships
Taxonomy of Architectural styles Data-Centered Architecture
 A data store (e.g., a file or database) resides at the center of this architecture and is accessed
frequently by other components that update, add, delete, or modify data within the store.
 The main goal is to integrate the data
 The shared data may be a passive repository or an active blackboard
 Passive repository means the client software accesses the data independent of any changes to the
data or the actions of other client software.
 A variation on this approach transforms the repository into a “blackboard”
o A blackboard notifies subscriber clients when changes occur in data of interest
 Clients are relatively independent of each other so they can be added, removed, or changed in
functionality
 The data store is independent of the clients

Fig: Data centered architectural style

Advantages:
 Data-centered architectures promote integrability
 Data can be passed among clients using the blackboard mechanism.
 Client components can execute the processes independently.
Data Flow Architectures
 This architecture is used when input has to be transformed into output through a series of
computational components.
 The main goal is modifiability
 Pipe-and-filter style
o A pipe-and-filter pattern has a set of components, called filters, connected by
pipes that transmit data from one component to the next.
o The filters incrementally transform the data
o The filter does not require knowledge of the workings of its neighboring filters.

Fig: Pipe and filter style

 Batch sequential style
o If the data flow degenerates into a single line of transforms, it is termed batch sequential.
o This structure accepts a batch of data and then applies a series of sequential components
(filters) to transform it.

FILTER FILTER FILTER

Call-and-Return Architectural Style

 This architectural style enables to achieve a program structure that is relatively easy to modify
and scale.

Fig: Call and return architectural style

  Substyles of call and return architecture:
 Main program/subprogram architectures.
This style decomposes the function into a control hierarchy where a main program
invokes a number of program components which in turn may invoke other components.
 Remote procedure call architectures.
The components of a main program/subprogram architecture are distributed across
multiple computers on a network.
Object-oriented architectures.
 The components of a system encapsulate data and the operations that are applied to manipulate
the data.
 Communication between components are accomplished through message passing.
Layered architectures.

Fig: Layered architecture

 A number of different layers are defined, each accomplishing operations that progressively
become closer to the machine instruction set.
 At the outer layer, components service user interface operations.
 At the inner layer, components perform operating system interfacing.
 Intermediate layers provide utility services and application software functions. Note:
 Once requirements engineering uncovers the characteristics and constraints of the system, then
the appropriate architectural style can be chosen.
 For example, a layered style can be combined with a data-centered architecture in many
database applications.

ARCHITECTURAL DESIGN PROCESS

Architectural Design Steps
 1) Represent the system in context
2) Define archetypes
3) Refine the architecture into components
4) Describe instantiations of the system
1. Represent the System in Context
 To represent the system in context an architectural context diagram (ACD) is used that shows
– The identification and flow of all information into and out of a system
– The specification of all interfaces
– Any relevant support processing from other systems
 An ACD models in such a way that the software interacts with entities external to its
boundaries
 An ACD identifies systems that interoperate with the target system
– Super-ordinate systems are systems that use the target system as part of some higher
level processing scheme
– Sub-ordinate systems are systems that are used by target system and provide necessary
data or processing
– Peer-level systems are those systems that interact on a peer-to-peer basis with target
system to produce or consume data
– Actors are the people or devices that interact with target system to produce or consume
data

Fig: Architectural context diagram

2. Define Archetypes
 Archetypes indicate the abstractions within the problem domain.
 An archetype is a class or pattern that represents a core abstraction that is critical to the design
of an architecture for the target system
 It includes a common structure and class-specific design strategies and a collection of example
program designs and implementations
 Only a relatively small set of archetypes is required in order to design even relatively complex
systems
 The target system architecture is composed of these archetypes
o They represent stable elements of the architecture
o They may be instantiated in different ways based on the behavior of the system
o They can be derived from the analysis class model
 The archetypes and their relationships can be illustrated in the fig below

Fig: UML Class diagram

3. Refine the Architecture into Components
 The architectural designer refines the software architecture into components to describe the
overall structure and architectural style of the system
 These components are derived from various sources
o The application domain provides components, which are the domain classes in the
analysis model that represent entities in the real world
o The infrastructure domain provides design components that enable application
components but have no business connection
 Examples: memory management, communication, database, and task
management
 The interfaces in the ACD imply one or more specialized components that process the data that
 flow across the interfaceA UML class diagram can represent the classes of the refined
architecture and their relationships

4. Describe Instantiations of the System

 An actual instantiation of the architecture is developed by applying it to a specific problem
 This demonstrates that the architectural structure, style and components are appropriate
 A UML component diagram can be used to represent the instantiation of the system.

Fig: Refined Component diagram

ARCHITECTURAL MAPPING
Structured design provides a convenient transition from a data flow diagram to software
Architecture

Types of information flow

The 2 different types of information flows:
1. transaction flow - a single data item triggers information flow along one of many paths
2. transform flow
o overall data flow is sequential and flows along a small number of straight line paths
o Incoming Flow: The paths that transform the external data into an internal form
o Transform Center: The incoming data are passed through a transform center and begin
to move along paths that lead it out of the software
o Outgoing Flow: The paths that move the data out of the software

Fig: Types of Information flow

Transform mapping
 Mapping the DFD with transform flow into an Architectural design is referred as Transform
mapping

b g h
a e f
d
c i
j
data flow model

"Transform" mapping

e g i

h j

Fig: Transform mapping

STEPS INVOLVED IN ARCHTECTURAL MAPPING:
 Step 1. Review the fundamental system model.
o Eg: SAFE HOME PROJECT

Fig: Context level diagram for Alarm system

 Step 2. Review and refine data flow diagrams for the software.
Eg:

Fig: Level-n DFD

 Step 3. Determine whether DFD has transform or transaction flow characteristics.
 in general---transform flow
 special case---transaction flow
 Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries
o different designers may select slightly differently
o transform center can contain more than one bubble.

Eg:
 Step 5. Perform “first-level factoring”
o Program structure represents a top-down distribution control.
o factoring results in a program structure(top-level, middle-level, low-level)
o Number of modules limited to minimum.
Eg:

Fig: First level factoring

 Step 6. Perform “second-level factoring”
o Mapping individual transforms (bubbles) to appropriate modules.
o Factoring accomplished by moving outwards from transform center boundary.
 Fig: Second level factoring

Eg: First iteration architecture

 Step 7. Refine the first iteration program structure using design heuristics for improved
software quality.

Fig: final Architecture

 USER INTERFACE ANALYSIS AND DESIGN
Introduction
 Golden Rules
1. Place the user in control
 Define interaction modes in such a way that does not force a user into
unnecessary or undesired actions.
 Allow user interaction to be interruptible and undoable.
 Streamline interaction as skill levels advance and allow the interaction to be
customized.
 Design for direct interaction with objects that appear on the screen.
2. Reduce the user’s memory load
 Reduce demand on short-term memory.
 Establish meaningful defaults.
 Define shortcuts that are intuitive.
 The visual layout of the interface should be based on a real world metaphor.
 Disclose information in a progressive fashion
3. Make the interface consistent for the user
 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.

INTERFACE DESIGN MODELS

 There are Four different models for interface design:

o User profile model
 Establish the profile of end users of the system
 considers the syntactic and semantic knowledge of the user
o Design model
 This model is derived from the analysis model of the requirements
 This incorporates data, architectural, interface, and procedural
representations of the software
o Implementation model
 This model consists of the look and feel of the interface combined with all
supporting information that describe system syntax and semantics
o User's mental model
  This model is also called the user's system perception
 This model consists of the image of the system that users carry in their heads
INTERFACE DESIGN PROCESS
 User interface development follows a spiral process

Fig: Interface Design steps

 Steps involved in the interface design process:
1. Interface analysis
 This phase focuses on the profile of the users who will interact with the system
 Skill level, business understanding, and general ideas to the new system are
recorded; and different user categories are defined
 Concentrates on users, tasks, content and work environment
2. Interface design
 The set of interface objects and actions that is needed to perform all defined tasks
in a manner that meets every usability goal defined for the system are defined in
this phase.
3. Interface construction
 construction begins with a prototype that enables usage scenarios to be evaluated
 Continues with development tools to complete the construction
4. Interface validation
 This focus on the ability of the interface to implement every user task, to
accommodate all task variations, and to achieve all user requirements
 The degree to which the interface is easy to use and easy to learn
INTERFACE ANALYSIS
 Interface analysis means understanding
(1) The 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.
User Analysis
 The analyst uses both the user's mental model and the design model to understand the users and
how they use the system
 Information are collected 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 are easy to use etc.
 sample questionnaire used for user analysis
 Are users trained professionals, technician, clerical, or manufacturing workers?
 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?
 Are users experts in the subject matter that is addressed by the system?
Task Analysis and Modeling
 Task analysis helps to know and understand
o The work the user performs in specific cases
o The tasks and subtasks that are performed by the user
o The specific problem domain objects that the user manipulates as work is performed
o The sequence of work tasks
o The hierarchy of tasks
Use cases
 Use cases are used to define the interaction between the components.
 Use case show how an end user performs some specific work-related task
 This helps to extract tasks, objects, and overall workflow of the interaction
 This helps the software engineer to identify additional helpful features
Task elaboration
 Task elaboration refines interactive tasks
 This gives the step wise elaboration of the function
 Eg: withdraw from an ATM
o Insert the card
o enter pin
 o select withdraw option
o enter amount
o dispense cash etc
Object elaboration
 Object elaboration identifies interface objects
 Attributes of each class are defined, and an evaluation of the actions applied to each object
provides a list of operations.

 Eg: class Withdraw can include the attributes like account no, name, balance and
functions like withdraw() and update() etc
Workflow analysis
 Workflow analysis defines how a work process is completed when several people are involved
 For work flow analysis swimlane diagram is used
 Eg:

Fig: Swimlane diagram for ticket reservation

Hierarchical representation
 Once workflow has been established, a task hierarchy can be defined for each user type.
 The hierarchy is derived by a stepwise elaboration of each task identified for the user
Analysis of Display Content
 This phase is about analyzing how to present the variety of contents
 The display content may range from character-based reports (e.g Spreadsheet), to graphical
displays(e.g : histogram,3D model etc), to multimedia information(e.g Audio or video)
 Display content may be
 o Generated by components in other parts of the application
o Acquired from data stored in a database that is accessible from the application
o Transmitted from systems external to the application in question
 Sample questionnaire for content analysis
o Are different types of data assigned to consistent geographic locations on the screen?
o Can the user customize the screen location for content?
o Will graphical output be scaled to fit within the bounds of the display device that is
used?
o How will color to be used to enhance understanding?
o How will error messages and warning be presented to the user?
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
o Type of lighting
o Display size and height
o Keyboard size, height and ease of use
o Mouse type and ease of use
o Surrounding noise
o Space limitations for computer and/or user
o Weather or other atmospheric conditions
o Temperature or pressure restrictions
o Time restrictions (when, how fast, and for how long)
INTERFACE DESIGN
 User interface design is an iterative process, where each iteration elaborate and refines the
information developed in the preceding step
 Steps involved in user interface design
1. Define user interface objects and actions from the information collected in the analysis
phase
2. Define events that will cause the state of the user interface to change and model the
behavior
3. Depict each interface state as it will actually look to the end user

4. Indicate how the user interprets the state of the system from information provided
through the interface
Applying Interface Design steps
 Interface objects and actions are obtained from a grammatical parse of the use cases and the
software problem statement
 Interface objects are categorized into 3 types: source, target, and application
o A source object is dragged and dropped into a target object such as to create a
hardcopy of a report
o An application object represents application-specific data that are not directly
manipulated as part of screen interaction such as a list
 After identifying objects and their actions, an interface designer performs screen layout which
involves
o Graphical design and placement of icons
o Definition of descriptive screen text
o Specification and titling for windows
o Definition of major and minor menu items
o Specification of a real-world metaphor to follow
User Interface Design Patterns
 A design pattern is an abstraction that prescribes a design solution to a specific, well- bounded
design problem.
 Eg:
o CalendarStrip that produces a continuous, scrollable calendar in which the current date
is highlighted and future dates may be selected by picking them from the calendar.
Design Issues
 Four common design issues in any user interface
o System response time (both length and variability)
 Length is the amount of time taken by the system to respond.
 Variability is the deviation from average response time
o User help facilities
 Help facilities gives information about when is it available, how is it accessed, how is
it represented to the user, how is it structured, what happens when help is exited
 Eg: user manuals or online help facilities
o Error information handling
 Error messages and warnings should describe the problem
 It should provide constructive advice for recovering from the error
 It should indicate negative consequences of the error etc
 This messages helps to improve the quality of an interactive system and will
significantly reduce user frustration when problems do occur
o Menu and command labeling
  Menu and command labeling should be consistent, easy to learn
 Questions for menu labeling
1. Will every menu option have a corresponding command?
2. What can be done if a command is forgotten?
3. Can commands be customized or abbreviated by the user?
o Application accessibility
 Software engineers must ensure that interface design encompasses
mechanisms that enable easy access for those with special needs.
o Internationalization
 The challenge for interface designers is to create “globalized” software.
 That is, user interfaces should be designed to accommodate a generic core of
functionality that can be delivered to all who use the software.
 Localization features enable the interface to be customized for a specific market.

COMPONENT LEVEL DESIGN

 A component is a modular building block for computer software
 A component-level design can be represented using some intermediate representation (e.g.
graphical, tabular, or text-based) that can be translated into source code
DESIGNING CLASS-BASED COMPONENTS
Component-level Design Principles
• Open-closed principle
– A module or component should be open for extension but closed for modification .
– The designer should specify the component in a way that allows it to be extended without
the need to make internal code or design modifications to the existing parts of the
component
• Liskov substitution principle
– The Subclasses should be substitutable for their base classes
– A component that uses a base class should continue to function properly if a subclass of
the base class is passed to the component instead
• Dependency inversion principle
– This principle depend on abstractions , do not depend on concretions
– The more a component depends on other concrete components, the more difficult it will
be to extend
• Interface segregation principle
 – Many client-specific interfaces are better than one general purpose interface
– For a server class, specialized interfaces should be created to serve major categories of
clients
– Only those operations that are relevant to a particular category of clients should be
specified in the interface

Component Packaging Principles

• Release reuse equivalency principle
– The granularity of reuse is the granularity of release
– Group the reusable classes into packages that can be managed, upgraded, and controlled
as newer versions are created
• Common closure principle
– Classes that change together belong together
– Classes should be packaged cohesively; they should address the same functional or
behavioral area on the assumption that if one class experiences a change then they all will
experience a change
• Common reuse principle
– Classes that aren't reused together should not be grouped together
– Classes that are grouped together may go through unnecessary integration and testing
when they have experienced no changes but when other classes in the package have been
upgraded
Component-Level Design Guidelines
• Components
– Naming conventions should be established for components that are specified as part of
the architectural model and then refined and elaborated as part of the component-level
model
– architectural component names must be obtained from the problem domain and ensure
that they have meaning to all stakeholders who view the architectural model (e.g.,
Calculator)
– infrastructure component names must that reflect their implementation-specific meaning
(e.g., Stack)
• Dependencies and inheritance in UML
– Dependencies should be modelled from left to right and inheritance from top (base class)
to bottom (derived classes)
• Interfaces
 – Interfaces provide important information about communication and collaboration
– lollipop representation of an interface should be used in UML approach
– For consistency, interfaces should flow from the left-hand side of the component box;
– only those interfaces that are relevant to the component under consideration should be
shown

Cohesion
 Cohesion is the “single-mindedness’ of a component
 It implies that a component or class encapsulates only attributes and operations that are closely
related to one another and to the class or component itself
 The objective is to keep cohesion as high as possible
 The kinds of cohesion can be ranked in order from highest (best) to lowest (worst)
o Functional
 Exhibited primarily by operations
 This level of cohesion occurs when a component performs a targeted
computation and then returns a result.
o Layer
 Exhibited by packages, components, and classes,

Fig: Layer Cohesion

 This type of cohesion occurs when a higher layer accesses the services of a
lower layer, but lower layers do not access higher layers.
o Communicational
 All operations that access the same data are defined within one class.
Coupling
 Coupling is a qualitative measure of the degree to which operations and classes are connected
to one another
 The objective is to keep coupling as low as possible
 Different types of coupling are as follows:
 Content coupling
 o Occurs when one component surreptitiously modifies data that is internal to
another component .
o This violates information hiding.
 Data coupling
o Data coupling occurs when operations pass long strings of data arguments.
o Operation A() passes one or more atomic data operands to operation B(); the
less the number of operands, the lower the level of coupling
o Testing and maintenance are more difficult
 Common coupling
o This coupling occurs when a number of components make use of a global
variable, which can lead to uncontrolled error propagation and unforeseen side
effects when changes are made.
 Stamp coupling
o A whole data structure or class instantiation is passed as a parameter to an
operation
 Control coupling
o Operation A() invokes operation B() and passes a control flag to B that directs
logical flow within B()
o Consequently, a change in B() can require a change to be made to the meaning of
the control flag passed by A(), otherwise an error may result
 Routine call coupling
o Occurs when one operation invokes another.
 Type use coupling
o Occurs when a Component A uses a data type defined in component B
o If the type definition changes, every component that declares a variable of that
data type must also change
 Inclusion or import coupling
o Occurs when component A imports or includes a package or the content of
component B.
 External coupling
o Occurs when a component communicates or collaborates with infrastructure
components that are entities external to the software (e.g., operating system
functions, database functions, networking functions)
DESIGNING CONVENTIONAL COMPONENTS
 Conventional design constructs emphasize the maintainability of a functionaldomain
 The constructs include Sequence, condition, and repetition
 Each construct has a predictable logical structure where control enters at the top and exits at the
 bottom, enabling a maintainer to easily follow the procedural flow
 Various notations used for designing these constructs
1. Graphical design notation
• Sequence, if-then-else, selection, repetition
2. Tabular design notation
3. Program design language
• This is similar to a programming language but it uses narrative text embedded
within the program statements

Graphical design notation

 Graphical tools, such as the UML activity diagram or the flowchart, provide useful pictorial
patterns that shows the procedural detail.
 The activity diagram allows to represent sequence, condition, and repetition
 A flowchart like an activity diagram which is quite simple pictorially.
 Notations used in flowchart:
o A box is used to indicate a processing step.
o A diamond represents a logical condition
o arrows show the flow of control.

Fig: Flowchart constructs

Tabular Design Notation
 Decision tables provide a notation that translates actions and conditions into a tabular form.
 Tabular notation is difficult to misinterpret.
 The table is divided into four sections.
o The upper left-hand quadrant contains a list of all conditions.
o The lower left-hand quadrant contains a list of all actions that are possible based on
combinations of conditions.
o The right-hand quadrants form a matrix that indicates condition combinations and the
 corresponding actions that will occur for a specific combination.
o Therefore, each column of the matrix may be interpreted as a processing rule.

Eg:

 Steps involved in developing a decision table:

1) List all actions associated with each module
2) List all conditions during execution of the procedure
3) Associate specific sets of conditions with specific actions, eliminating impossible combinations
of conditions
4) Define rules by indicating what actions occurs for a set of conditions
Program Design Language
 Program design language (PDL), also called structured English or pseudocode,
 PDL combines the logical structure of a programming language with the free-form natural
language.
 Automated tools can be used to enhance the application.
 A PDL syntax should include constructs for component definition, interface description, data
declaration, block structuring, condition constructs, repetition constructs, and I/O constructs
 PDL can be extended to include keywords for multitasking and concurrent processing, interrupt
handling, interprocess synchronization etc.
 Sample PDL:
IF credit level exceeded
THEN (credit level exceeded)
IF customer has bad payment history THEN refuse credit
ELSE ( customer has good payment history) IF purchase is above $200
THEN refuse credit ELSE (purchase is below $200) Refer to
manager
ELSE (credit level not exceeded) allow credit