Unit 02

TY IT
1
 1. Building the analysis model
2
(Analysis Modelling in Software Engineering)
 Analysis Model is a technical representation of the system. It
acts as a link between system description and design model.
 In Analysis Modelling, information, behaviour, and functions of
the system are defined and translated into the architecture,
component, and interface level design in the design modelling.
 Objectives of Analysis Modelling:
 It must establish a way of creating software design.
 It must describe the requirements of the customer.
 It must define a set of requirements that can be validated, once
the software is built.
 1. Building the analysis model: Elements of Analysis
3 Model

 Data Dictionary:
 It is a repository that consists of a
description of all data objects used or
produced by the software.
 It stores the collection of data present in
the software. It is a very crucial element
of the analysis model.
 It acts as a centralized repository and
also helps in modelling data objects
defined during software requirements.
 1. Building the analysis model: Elements of Analysis
4 Model

 Entity Relationship Diagram (ERD):

 It depicts the relationship between data objects and is used in conducting
data modelling activities.
 The attributes of each object in the Entity-Relationship Diagram can be
described using Data object description. It provides the basis for activity
related to data design.
 Data Flow Diagram (DFD):
 It depicts the functions that transform data flow and it also shows how data
is transformed when moving from input to output.
 It provides the additional information which is used during the analysis of
the information domain and serves as a basis for the modelling of function.
 It also enables the engineer to develop models of functional and
information domains at the same time.
 1. Building the analysis model: Elements of Analysis
5 Model

 State Transition Diagram:

 It shows various modes of behaviour (states) of the system and also shows the
transitions from one state to another state in the system.
 It also provides the details of how the system behaves due to the consequences of
external events.
 It represents the behaviour of a system by presenting its states and the events
that cause the system to change state. It also describes what actions are taken
due to the occurrence of a particular event.
 Process Specification:
 It stores the description of each function present in the data flow diagram.
 It describes the input to a function, the algorithm that is applied for the
transformation of input, and the output that is produced.
 It also shows regulations and constraints imposed on the performance
characteristics that are applicable to the process and layout constraints that could
influence the way in which the process will be implemented.
 1. Building the analysis model: Elements of Analysis
6 Model

 Control Specification:
 It stores additional information about the control aspects of the software.
 It is used to indicate how the software behaves when an event occurs and
which processes are invoked due to the occurrence of the event.
 It also provides the details of the processes which are executed to manage
events.
 Data Object Description:
It stores and provides complete knowledge about a data object present and
used in the software.
 It also gives us the details of attributes of the data object present in the Entity
Relationship Diagram.
 Hence, it incorporates all the data objects and their attributes.
 2. Negotiating requirements
7

 The inception, elicitation, and elaboration tasks in an ideal requirements

engineering setting determine customer requirements in sufficient depth to
proceed to later software engineering activities.
 Development team might have to negotiate with one or more stakeholders.
Most of the time, stakeholders are expected to balance functionality,
performance, and other product or system attributes against cost and time-
to-market.
 The goal of this discussion is to create a project plan that meets the
objectives of stakeholders while also reflecting the real-world restrictions
(e.g., time, personnel, and budget) imposed on the software team.
 The successful negotiations aim for a “win-win” outcome. That is,
stakeholders, benefit from a system or product that meets the majority of
their needs, while development benefit from working within realistic and
reasonable budgets and schedules.
 2. Negotiating requirements
8

 At the start of each software process iteration, Boehm defines a series of

negotiating actions.
 Rather than defining a single customer communication activity, the following
are defined:
 Identifying the major stakeholders in the system or subsystem.
 Establishing the stakeholders’ “win conditions.”
 Negotiation of the win conditions of the stakeholders in order to reconcile
them into a set of win-win conditions for all people involved.
 3. Validating Requirements

 Each aspect of the requirements model is checked for consistency, omissions,

and ambiguity as it is developed. The model’s requirements are prioritised by
stakeholders and bundled into requirements packages that will be
implemented as software increments.
 The following questions are addressed by an examination of the requirements
model:
 Is each requirement aligned with the overall system/product objectives?
 Were all requirements expressed at the appropriate level of abstraction? Do
some criteria, in other words, give a level of technical information that is
inappropriate at this stage?
 Is the requirement truly necessary, or is it an optional feature that may or
may not be critical to the system’s goal?
 Is each requirement well defined and unambiguous?
 Is each requirement attributed? Is there a source noted for each requirement?
 3. Validating Requirements

10

 Are there any requirements that conflict with others?

 Is each requirement attainable in the technical environment in which the
system or product will be housed?
 Is each requirement, once implemented, testable?
 Does the requirements model accurately represent the information,
functionality, and behaviour of the system to be built?
 Has the requirements model been “partitioned” in such a way that
progressively more detailed information about the system is exposed?
 Have requirements patterns been used to reduce the complexity of the
requirements model?
 Have all patterns been validated properly? Are all patterns in accordance with
the requirements of the customers?
 4. System Design Overview

11
 A good system design is to organize the program modules in such a way that
are easy to develop and change.
 Structured design techniques help developers to deal with the size and
complexity of programs. Analysts create instructions for the developers about
how code should be written and how pieces of code should fit together to
form a program.
 Importance:
 If any pre-existing code needs to be understood, organized, and pieced
together.
 It is common for the project team to have to write some code and produce
original programs that support the application logic of the system.
 4.1 Design Process
 4.2 Design concepts
 4.3 Design model
 4. System Design Overview: 4.1 Design Process

12

 Software design is an iterative process through which requirements are

translated into a “blueprint” for constructing the software.
 Initially, the blueprint represent a holistic view of software.
 That is, the design is represented at a high level of abstraction— a level that
can be directly traced to the specific system objective and more detailed
data, functional, and behavioral requirements.
 As design iterations occur, subsequent refinement leads to design
representations at much lower levels of abstraction.
 These can still be traced to requirements, but the connection is more subtle.
 4. System Design Overview: 4.1 Design Process

13

 Software quality guidelines

 A design is generated using the recognizable architectural styles and
compose a good design characteristic of components and it is implemented in
evolutionary manner for testing.
 A design of the software must be modular i.e the software must be logically
partitioned into elements.
 In design, the representation of data , architecture, interface and components
should be distinct.
 A design must carry appropriate data structure and recognizable data
patterns.
 Design components must show the independent functional characteristic.
 4. System Design Overview: 4.1 Design Process

14

 Software quality guidelines

 A design creates an interface that reduce the complexity of connections
between the components.
 A design must be derived using the repeatable method.
 The notations should be use in design which can effectively communicates its
meaning.
 Quality attributes :The attributes of design name as 'FURPS' are
as follows:
 Functionality:
It evaluates the feature set and capabilities of the program.
 Usability:
It is accessed by considering the factors such as human factor, overall
aesthetics, consistency and documentation.
 4. System Design Overview: 4.1 Design Process

15
 Quality attributes :The attributes of design name as 'FURPS' are
as follows:
 Reliability:
 It is evaluated by measuring parameters like frequency and security of failure,
output result accuracy, the mean-time-to-failure(MTTF), recovery from failure
and the program predictability.
 Performance:
 It is measured by considering processing speed, response time, resource
consumption, throughput and efficiency.
 Supportability:
 It combines the ability to extend the program, adaptability, serviceability.
These three term defines the maintainability.
 Testability, compatibility and configurability are the terms using which a
system can be easily installed and found the problem easily.
 Supportability also consists of more attributes such as compatibility,
 4. System Design Overview: 4.2 Design concepts

16
 4.2 Design concepts
 A set of fundamental software design concepts has evolved over the history of
software engineering.
 Although the degree of interest in each concept has varied over the years, each
has stood the test of time.
 Each provides the software designer with a foundation from which more
sophisticated design methods can be applied.
 Each helps you answer the following questions:
 • What criteria can be used to partition software into individual components?
 • How is function or data structure detail separated from a conceptual
representation of the software?
 • What uniform criteria define the technical quality of a software design?
 M. A. Jackson [Jac75] once said: “The beginning of wisdom for a [software
engineer] is to recognize the difference between getting a program to work, and
getting it right.” Fundamental software design concepts provide the necessary
framework for “getting it right.”
 4. System Design Overview: 4.2 Design concepts

17
 4.2 Design concepts
 The set of fundamental software design concepts are as follows:
 1. Abstraction
 2. Architecture
 3. Patterns
 4. Modularity
 5. Information hiding
 6. Functional independence
 7. Refinement
 8. Refactoring
 9. Design classes
 4. System Design Overview: 4.2 Design concepts

18
 1. Abstraction
 A solution is stated in large terms using the language of the problem
environment at the highest level abstraction.
 The lower level of abstraction provides a more detail description of the
solution.
 A sequence of instruction that contain a specific and limited function refers in
a procedural abstraction.
 A collection of data that describes a data object is a data abstraction.
 4. System Design Overview: 4.2 Design concepts

19
 2. Architecture
 The complete structure of the software is known as software architecture.
 Structure provides conceptual integrity for a system in a number of ways.
 The architecture is the structure of program modules where they interact with
each other in a specialized way.
 The components use the structure of data.
 The aim of the software design is to obtain an architectural framework of a
system.
 The more detailed design activities are conducted from the framework.
 4. System Design Overview: 4.2 Design concepts

20
 3. Patterns
A design pattern describes a design structure and that structure solves a
particular design problem in a specified content.
 4. Modularity
 A software is separately divided into name and addressable components.
Sometime they are called as modules which integrate to satisfy the problem
requirements.
 Modularity is the single attribute of a software that permits a program to be
managed easily.
 5. Information hiding
Modules must be specified and designed so that the information like
algorithm and data presented in a module is not accessible for other modules
not requiring that information.
 4. System Design Overview: 4.2 Design concepts

21
 6. Functional independence
 The functional independence is the concept of separation and related to the
concept of modularity, abstraction and information hiding.
 The functional independence is accessed using two criteria i.e Cohesion and
coupling.
 Cohesion: Cohesion is an extension of the information hiding concept.
 A cohesive module performs a single task and it requires a small interaction
with the other components in other parts of the program.
 Coupling: Coupling is an indication of interconnection between modules in a
structure of software.
 4. System Design Overview: 4.2 Design concepts

22
 7. Refinement
 Refinement is a top-down design approach.
 It is a process of elaboration.
 A program is established for refining levels of procedural details.
 A hierarchy is established by decomposing a statement of function in a
stepwise manner till the programming language statement are reached.
 4. System Design Overview: 4.2 Design concepts

23
 8. Refactoring
 It is a reorganization technique which simplifies the design of components
without changing its function behaviour.
 Refactoring is the process of changing the software system in a way that it
does not change the external behaviour of the code still improves its internal
structure.
 9. Design classes
 The model of software is defined as a set of design classes.
 Every class describes the elements of problem domain and that focus on
features of the problem which are user visible.
 4. System Design Overview: 4.3 Design model

24
 4.3 Design model
 The design model can be viewed
in two different dimensions as
illustrated in Figure.
 The process dimension indicates
the evolution of the design model
as design tasks are executed as
part of the software process.
 The abstraction dimension
represents the level of detail as
each element of the analysis
model is transformed into a design
equivalent and then refined
iteratively.
 4. System Design Overview: 4.3 Design model

25
 4.3 Design model
 Referring to Figure, the dashed line indicates the boundary between the
analysis and design models.
 In some cases, a clear distinction between the analysis and design models is
possible. In other cases, the analysis model slowly blends into the design and
a clear distinction is less obvious.
 The elements of the design model use many of the same UML diagrams that
were used in the analysis model.
 The difference is that these diagrams are refined and elaborated as part of
design; more implementation-specific detail is provided, and architectural
structure and style, components that reside within the architecture, and
interfaces between the components and with the outside world are all
emphasized.
 The design model has four major elements: data, architecture,
components, and interface and 5th Deployment-Level .
 4. System Design Overview: 4.3 Design model

26
 1. Data design elements
 The data design element produced a model of data that represent a high level
of abstraction.
 This model is then more refined into more implementation specific
representation which is processed by the computer based system.
 The structure of data is the most important part of the software design.
 4. System Design Overview: 4.3 Design model

27
 2. Architectural design elements
 The architecture design elements provide us overall view of the system.
 The architectural design element is generally represented as a set of
interconnected subsystem that are derived from analysis packages in the
requirement model.
 The architecture model is derived from following sources:
 The information about the application domain to build the software.
 Requirement model elements like data flow diagram or analysis classes,
relationship and collaboration between them.
 The architectural style and pattern as per availability.
 4. System Design Overview: 4.3 Design model

28
 3. Interface design elements
 The interface design elements for software represents the information flow
within it and out of the system.
 They communicate between the components defined as part of architecture.
 Following are the important elements of the interface design:
1. The user interface
2. The external interface to the other systems, networks etc.
3. The internal interface between various components.
 4. System Design Overview: 4.3 Design model

29
 4. Component level diagram elements
 The component level design for software is similar to the set of detailed
specification of each room in a house.
 The component level design for the software completely describes the
internal details of each software component.
 The processing of data structure occurs in a component and an interface
which allows all the component operations.
 In a context of object-oriented software engineering, a component shown in a
UML diagram.
 The UML diagram is used to represent the processing logic.
 4. System Design Overview: 4.3 Design model

30
 5. Deployment level design
elements
 The deployment level design element
shows the software functionality and
subsystem that allocated in the
physical computing environment
which support the software.
 Following figure shows three
computing environment as shown.
These are the personal computer, the
CPI server and the Control panel.
 5. Pattern based software design

31
 In software engineering, a software design pattern is a general, reusable
solution of how to solve a common problem when designing an application or
system.
 Unlike a library or framework, which can be inserted and used right away, a
design pattern is more of a template to approach the problem at hand.
 Design patterns are used to support object-oriented programming (OOP), a
paradigm that is based on the concepts of both objects (instances of a class;
data with unique attributes) and classes (user-defined types of data).
 There are 23 classic design patterns, although there are at least 26 design
patterns discovered to date. These design patterns gained popularity after the
publication of Design Patterns: Elements of Reusable Object-Oriented
Software, a 1994 book published by the “Gang of Four” (GoF): Erich Gamma,
Richard Helm, Ralph Johnson, and John Vlissides. Due to this, the 23 design
patterns are often known as the gang of four design patterns.
 Design patterns can be broken down into three types, organized by their
intent into creational design patterns, structural design patterns, and
behavioural design patterns.
 5. Pattern based software design

32
 1. Creational Design Patterns
 A creational design pattern deals with object
creation and initialization, providing guidance about
which objects are created for a given situation.
These design patterns are used to increase flexibility
and to reuse existing code.
 Factory Method: Creates objects with a common
interface and lets a class defer instantiation to
subclasses.
 Abstract Factory: Creates a family of related
objects.
 Builder: A step-by-step pattern for creating complex
objects, separating construction and representation.
 Prototype: Supports the copying of existing objects
without code becoming dependent on classes.
 Singleton: Restricts object creation for a class to
 5. Pattern based software design

33
 2. Structural Design Patterns
 A structural design pattern deals with class and object composition, or how to
assemble objects and classes into larger structures.
 Adapter: How to change or adapt an interface to that of another existing
class to allow incompatible interfaces to work together.
 Bridge: A method to decouple an interface from its implementation.
 Composite: Leverages a tree structure to support manipulation as one
object.
 Decorator: Dynamically extends (adds or overrides) functionality.
 Façade: Defines a high-level interface to simplify the use of a large body of
code.
 Flyweight: Minimize memory use by sharing data with similar objects.
 Proxy: How to represent an object with another object to enable access
control, reduce cost and reduce complexity.
 5. Pattern based software design

34
 3. Behavioural Design Patterns
 A behavioural design pattern is concerned with communication between
objects and how responsibilities are assigned between objects.
 Chain of Responsibility: A method for commands to be delegated to a
chain of processing objects.
 Command: Encapsulates a command request in an object.
 Interpreter: Supports the use of language elements within an application.
 Iterator: Supports iterative (sequential) access to collection elements.
 Mediator: Articulates simple communication between classes.
 Memento: A process to save and restore the internal/original state of an
object.
 Observer: Defines how to notify objects of changes to other object(s).
 State: How to alter the behaviour of an object when its stage changes.
 5. Pattern based software design

35
 3. Behavioural Design Patterns
 Strategy: Encapsulates an algorithm inside a class.
 Visitor: Defines a new operation on a class without making changes to the
class.
 Template Method: Defines the skeleton of an operation while allowing
subclasses to refine certain steps.
 5. Pattern based software design

36
 Need Design Patterns
 Design patterns offer a best practice approach to support object-oriented
software design, which is easier to design, implement, change, test and
reuse. These design patterns provide best practices and structures.
 1. Proven Solution: Design patterns provide a proven, reliable solution to a
common problem, meaning the software developer does not have to
“reinvent the wheel” when that problem occurs.
 2. Reusable: Design patterns can be modified to solve many kinds of
problems – they are not just tied to a single problem.
 3. Expressive: Design patterns are an elegant solution.
 4. Prevent the Need for Refactoring Code: Since the design pattern is already
the optimal solution for the problem, this can avoid refactoring.
 5. Lower the Size of the Codebase: Each pattern helps software developer
change how the system works without a full redesign. Further, as the
“optimal” solution, the design pattern often requires less code.
 6. Architectural design

37
 The software needs the architectural design to represents the design of
software.
 IEEE defines architectural design as “the process of defining a collection of
hardware and software components and their interfaces to establish the
framework for the development of a computer system.”
 The software that is built for computer-based systems can exhibit one of
these many architectural styles.
 Each style will describe a system category that consists of:
 A set of components (eg: a database, computational modules) that will
perform a function required by the system.
 The set of connectors will help in coordination, communication, and
cooperation between the components.
 Conditions that how components can be integrated to form the system.
 Semantic models that help the designer to understand the overall properties
of the system.
 6. Architectural design

38
 The use of architectural styles is to establish a structure for all the
components of the system.
 Taxonomy of Architectural styles:
 1. Data Centered architectures
 2. Data flow architectures
 3. Call and Return architectures
 6. Architectural design

39
 1. Data Centered architectures
 A data store will reside at the center of this architecture and is accessed
frequently by the other components that update, add, delete or modify the
data present within the store.
 The figure illustrates a typical data centered style. The client software
access a central repository. Variation of this approach are used to
transform the repository into a blackboard when data related to client or
data of interest for the client change the notifications to client software.
 This data-centered architecture will promote integrability. This means that
the existing components can be changed and new client components can
be added to the architecture without the permission or concern of other
clients.
 Data can be passed among clients using blackboard mechanism.
 6. Architectural design

40
 2. Data flow architectures:
 This kind of architecture is used when input data to be transformed into
output data through a series of computational manipulative components.
 The figure represents pipe-and-filter architecture since it uses both pipe
and filter and it has a set of components called filters connected by pipes.
 Pipes are used to transmit data from one component to the next.
 Each filter will work independently and is designed to take data input of a
certain form and produces data output to the next filter of a specified
form. The filters don’t require any knowledge of the working of neighboring
filters.
 If the data flow degenerates into a single line of transforms, then it is
termed as batch sequential. This structure accepts the batch of data and
then applies a series of sequential components to transform it.
 6. Architectural design

41
 3. Call and Return architectures:
 It is used to create a program that is easy to scale and modify. Many sub-
styles exist within this category. Two of them are explained below.
 Remote procedure call architecture: This components is used to
present in a main program or sub program architecture distributed among
multiple computers on a network.
 Main program or Subprogram architectures: The main program
structure decomposes into number of subprograms or function into a
control hierarchy. Main program contains number of subprograms that can
invoke other components.
 7. User interface design

42
 User interface is the front-end application view to which user interacts in
order to use the software. The software becomes more popular if its user
interface is:
 Attractive
 Simple to use
 Responsive in short time
 Clear to understand
 Consistent on all interface screens
 There are two types of User Interface:
 Command Line Interface: Command Line Interface provides a command
prompt, where the user types the command and feeds to the system. The
user needs to remember the syntax of the command and its use.
 Graphical User Interface: Graphical User Interface provides the simple
interactive interface to interact with the system. GUI can be a combination of
both hardware and software. Using GUI, user interprets the software.
 7. User interface design

43
 User interface is the front-end application view to which user interacts in
order to use the software. The software becomes more popular if its user
interface is:
 Attractive
 Simple to use
 Responsive in short time
 Clear to understand
 Consistent on all interface screens
 There are two types of User Interface:
 Command Line Interface: Command Line Interface provides a command
prompt, where the user types the command and feeds to the system. The
user needs to remember the syntax of the command and its use.
 Graphical User Interface: Graphical User Interface provides the simple
interactive interface to interact with the system. GUI can be a combination of
both hardware and software. Using GUI, user interprets the software.
 7. User interface design

44
 7.1 Golden Rules:
 The following are the golden rules stated by Theo Mandel that must be followed during
the design of the interface.
 Place the user in control
 Reduce the user’s memory load
 Make the interface consistent

 1. Place the user in control

 Define the interaction modes in such a way that does not force the user into
unnecessary or undesired actions: The user should be able to easily enter and exit the
mode with little or no effort.
 Provide for flexible interaction: Different people will use different interaction
mechanisms, some might use keyboard commands, some might use mouse, some
might use touch screen, etc, Hence all interaction mechanisms should be provided.
 7. User interface design

45
 7.1 Golden Rules:
 1. Place the user in control
 Allow user interaction to be interruptible and undoable: When a user is doing a
sequence of actions the user must be able to interrupt the sequence to do some other
work without losing the work that had been done. The user should also be able to do
undo operation.
 Streamline interaction as skill level advances and allow the interaction to be
customized: Advanced or highly skilled user should be provided a chance to customize
the interface as user wants which allows different interaction mechanisms so that user
doesn’t feel bored while using the same interaction mechanism.
 Hide technical internals from casual users: The user should not be aware of the
internal technical details of the system. He should interact with the interface just to do
his work.
 Design for direct interaction with objects that appear on screen: The user should be
able to use the objects and manipulate the objects that are present on the screen to
perform a necessary task. By this, the user feels easy to control over the screen.
 7. User interface design

46
 7.1 Golden Rules: 2. Reduce the user’s memory load:
 Reduce demand on short-term memory: When users are involved in some complex
tasks the demand on short-term memory is significant. So the interface should be
designed in such a way to reduce the remembering of previously done actions,
given inputs and results.
 Establish meaningful defaults: Always initial set of defaults should be provided to
the average user, if a user needs to add some new features then he should be
able to add the required features.
 Define shortcuts that are intuitive: Mnemonics should be used by the user.
Mnemonics means the keyboard shortcuts to do some action on the screen.
 The visual layout of the interface should be based on a real-world metaphor:
Anything you represent on a screen if it is a metaphor for real-world entity then
users would easily understand.
 Disclose information in a progressive fashion: The interface should be organized
hierarchically i.e. on the main screen the information about the task, an object or
some behavior should be presented first at a high level of abstraction. More detail
should be presented after the user indicates interest with a mouse pick.
 7. User interface design

47
 7.1 Golden Rules:
 3. Make the interface consistent:
 Allow the user to put the current task into a meaningful context: Many interfaces have
dozens of screens. So it is important to provide indicators consistently so that the user
know about the doing work. The user should also know from which page has navigated
to the current page and from the current page where can navigate.
 Maintain consistency across a family of applications: The development of some set of
applications all should follow and implement the same design, rules so that
consistency is maintained among applications.
 If past interactive models have created user expectations do not make changes unless
there is a compelling reason.

 User interface design is a crucial aspect of software engineering, as it is the means by

which users interact with software applications. A well-designed user interface can
improve the usability and user experience of an application, making it easier to use
and more effective.
 7. User interface design

48
 7.2 User Interface Design
Process:
 The analysis and design process of a
user interface is iterative and can be
represented by a spiral model.
 The analysis and design process of
user interface consists of four
framework activities.
 7. User interface design

49
 7.2 User Interface Design Process:
 1. User, task, environmental analysis, and modeling:
 Initially, the focus is based on the profile of users who will interact with the system, i.e.
understanding, skill and knowledge, type of user, etc, based on the user’s profile users
are made into categories.
 From each category requirements are gathered. Based on the requirements developer
understand how to develop the interface.
 Once all the requirements are gathered a detailed analysis is conducted.
 In the analysis part, the tasks that the user performs to establish the goals of the
system are identified, described and elaborated.
 The analysis of the user environment focuses on the physical work environment.
Among the questions to be asked are:
 Where will the interface be located physically?
 Will the user be sitting, standing, or performing other tasks unrelated to the interface?
 Does the interface hardware accommodate space, light, or noise constraints?
 Are there special human factors considerations driven by environmental factors?
 7. User interface design

50
 7.2 User Interface Design Process:
 2. Interface Design:
 The goal of this phase is to define the set of interface objects and actions i.e. Control
mechanisms that enable the user to perform desired tasks.
 Indicate how these control mechanisms affect the system. Specify the action sequence
of tasks and subtasks, also called a user scenario.
 Indicate the state of the system when the user performs a particular task. Always
follow the three golden rules stated by Theo Mandel.
 Design issues such as response time, command and action structure, error handling,
and help facilities are considered as the design model is refined.
 This phase serves as the foundation for the implementation phase.
 7. User interface design

51
 7.2 User Interface Design Process:
 3. Interface construction and implementation:
 The implementation activity begins with the creation of prototype (model) that enables
usage scenarios to be evaluated.
 As iterative design process continues a User Interface toolkit that allows the creation
of windows, menus, device interaction, error messages, commands, and many other
elements of an interactive environment can be used for completing the construction of
an interface.
 4. Interface Validation:
 This phase focuses on testing the interface.
 The interface should be in such a way that it should be able to perform tasks correctly
and it should be able to handle a variety of tasks.
 It should achieve all the user’s requirements.
 It should be easy to use and easy to learn. Users should accept the interface as a
useful one in their work.
 7. User interface design

52
 7.3 There are several key principles that software engineers should follow
when designing user interfaces:
 Overall, user interface design is a key component of software engineering, as it can
have a significant impact on the usability, effectiveness, and user experience of an
application. Software engineers should follow best practices and design principles to
create interfaces that are user-centered, consistent, simple, and accessible.

 User-centered design: User interface design should be focused on the needs and
preferences of the user.
 This involves understanding the user’s goals, tasks, and context of use, and designing
interfaces that meet their needs and expectations.
 Consistency: Consistency is important in user interface design, as it helps users to
understand and learn how to use an application.
 Consistent design elements such as icons, color schemes, and navigation menus
should be used throughout the application.
 7. User interface design

53
 7.3 There are several key principles that software engineers should follow
when designing user interfaces:
 Simplicity: User interfaces should be designed to be simple and easy to use, with
clear and concise language and intuitive navigation.
 Users should be able to accomplish their tasks without being overwhelmed by
unnecessary complexity.
 Feedback: Feedback is important in user interface design, as it helps users to
understand the results of their actions and confirms that they are making progress
towards their goals.
 Feedback can take the form of visual cues, messages, or sounds.
 Accessibility: User interfaces should be designed to be accessible to all users,
regardless of their abilities.
 This involves considering factors such as colour contrast, font size, and assistive
technologies such as screen readers.
 Flexibility: User interfaces should be designed to be flexible and customizable,
allowing users to tailor the interface to their own preferences and needs.