SOFTWARE ENGINEERING

UNIT-3
SYSTEM MODELS

1. Introduction :

A number of system models will be developed during requirements

engineering process.

Models in the analysis process are required to develop an understanding

of the existing system that is to be replaced or improved or to specify
the new system that is required.

There are three different perspectives, used to develop different models.

a) External Perspective : Here the context or environment of the system

is modeled.

b) Behavioral Perspective : Here the behavior of the system is modeled.

c) Structural Perspective : Here, the architecture of the system or the

structure of the data processed by the system is modeled.

2. Types of System Models :

a) Data-flow Model : These models show how data is processed at

different stages in the system.

b) Composition Model : Composition or Aggregation model shows how

entities in the system are composed of other entities.

c) Architectural Model : These models show the principal sub-systems

that make up a system.

d) Classification Model : Object class / inheritance diagrams show how

entities have common characteristics.

e) Stimulus-response Model : This model (state transition diagram)

shows how the system reacts to internal and external events.

1
3. Context Model :

A context Model defines how context data are structured and

maintained.

Context models are simple communication tools used to depict the

context of a system.
The following is an architectural / context model that illustrates the
structure of the information system that includes a bank auto-teller
network.
High-level architectural models are usually expressed as simple block
diagrams, where each sub system is represented by a named rectangle,
and lines indicate associations between sub-systems.
In this diagram, each ATM is connected to an account database, a local
branch accounting system, a security system and a system to support
machine maintenance.
The system is also connected to a usage database that monitors how the
network of ATMs is used and to a local branch counter system.

2
4. Behavioral Model :

Behavioral Models are used to describe the overall behavior of the

system.

There are two types of behavioral models :

a) Data-flow models : which model the processing in the system

These models are an intuitive way of showing how data is processsed
by a system.
Data flow models are used to show how data flows through a
sequence of processing steps.
Data flow models are ‘top-down’ process.
Data-flow diagram of an insulin pump :

Data-flow models are valuable because tracing and documenting how

w the data associated with a particular process moves through the
system helps analysts understand what is going on.
Data-flow models show a functional perspective where each
transformation represents a single function or process.
They are particularly useful during the analysis of requirements as
they can be used to show end-to-end processing in a system.

3
b) State-machine models :describes how a system responds to internal
or external events.
The state machine model shows system states and events that cause
transactions from one state to other.
It does not show the flow of data within the system.
A state machine model of a system assumes that, at any time, the
system is in one of a number of possible states.
When a stimulus is received, this may trigger a transition to a
different state.
For example, a system controlling a valve may move from a state
‘Valve open’ to a state ‘Valve Closed’.
The below diagram shows a state machine model of a simple
microwave oven equipped with buttons to set the power and the
time and to start the system.
State Machine Model of a simple microwave oven :

4
5. Data Models :

The large software systems make use of a large database of information.

Some times, this database is independent of the software system.
In other systems, it is created for the system being developed.
An important part of systems modeling is defining the logical form of the
data processed by the system.
These are called ‘Semantic Data Models’.
The most widely used data modeling technique is ‘Entity-Relation-
Attribute’ modeling (ERA modeling), which shows the data entities, their
associated attributes and the relations between the entities.

Semantic Data Model for the LIBSYS system :

5
6. Object Models :
An objective-oriented approach to the whole software development
process is particularly for interactive systems development.
This means expressing the systems requirements using an object model,
designing using objects and developing the system in an object-oriented
programming language.
Object models that you develop during requirements analysis may be
used to represent both system data and its processing.
An object class is an abstraction over a set of objects that identifies
common attributes and the services or operations that are provided by
each object.
Objects are executable entities with the attributes and services of the
object class.
Objects are instantiations of the object class and many objects may be
created from a class.
An object class in UML, is represented as a vertically oriented rectangle
with three sections : (in the following figure)
a) The name of the object class is in the top section.

b) The class attributes are in the middle section.

c) The operations associated with the object class are in the lower
section of the rectangle.

Inheritance Models :

A taxonomyis a classification scheme that show how an object class is

related to other classes through common attributes and services.

To display this taxonomy, the classes are organized into an inheritance

hierarchy with the most general object classes at the top of the
hierarchy.

More specialized objects inherit their attributes and services.

These specialized objects may have their own attributes and services.

6
The following figure illustrates part of a simplified class hierarchy for a
model of the library.
This hierarchy gives information about the items held in the library.
Part of a class hierarchy for a library :

The library (above figure) holds various items, such as books, music,
recording of films, magazines and news papers.

In this figure, the most general item is at the top of the tree and has a
set of attributes and services that are common to all library items.

7
These are inherited by the classes ‘Published item’ and ‘Recorded item’,
which add their own attributes that are then inherited by lower-level
items.

The following figure is an example of another inheritance hierarchy that

might be part of the library model.

In this case, the uses of a library are shown.

There are two classes of user :

those who are allowed to borrow books

those who may only read books in the library without taking them
away.
In the UML notation, inheritance is shown ‘upwards’ rather than
‘downwards’, where sub-classes inherit from super-classes.
This is called ‘generalisation relationship’.
User Class Hierarchy :

8
 Multiple Inheritance :
Multiple Inheritance models are constructed where a class has several
parents.
The following is an example of multiple inheritance model that is a part
of the library model :

7. Object Aggregation :
Let there are some objects, which are groupings of other objects.
That is, an object is an aggregate of a set of other objects.
The classes representing these objects may be modeled using an object
aggregation model.
The UML notation for aggregation is to represent the composition by
including a diamond shape on the source of the link.
That is in the following diagram, ‘A study pack’ is composed of one of
more assignments, OHP slide packages, lecture notes and videotapes.
IN the following diagram, a library item is modeled.

9
 Aggregation object representing a course :

8. Object Behavior Modelling :

Here the sequence diagrams are used for behavior modeling.
IN a sequence diagram, objects and actors are aligned along the top of
the diagram.
Labelled arrows indicate operations.
The sequence of diagrams is from top to bottom.
Here, the library user accesses the catalogue to see whether the item
required is available.
If it is, the user requests the electronic issue of that item.
For copyright reasons, this must be licensed so there is a transaction
between the item and the user where the license is agreed.
The item to be issued is then sent to a network server object for
compression before being sent to the library user.
The objects are : catalog, library item and net server.

10
 The issue of electronic items :

9. Structured Methods :
A structured method is a systematic way of producing models of an
existing system that is to be built.
Structured methods provide a framework for detailed system modeling
as part of requirements elicitation and analysis.
CASE tools are usually available for method support.
These tools support model editing and code and report generation, and
provide some model-checking capabilities.
Analysis and design case tools support the
- creation - editing - analysis
of the graphical notations used in structured methods.
The following diagram shows the components that may be included
method support environment.

11
The components of a CASE tool for structured method support :

Comprehensive method support tolls are illustrated in the above

diagram are as follows :
a) Diagram Editors :used to create object models, data models,
behavioral models and so on.
b) Design analysis and checking tools : process the design and report on
errors and anomalies.
c) Repository query languages : allow the designer to find designs and
associated design information in the repository.
d) Data Dictionary : maintains information about the entities used in a
system design.
e) Report definition and generation tools : take information from the
central store and automatically generate system documentation.
f) Forms definition tools : allow screen and document formats to be
specified.
g) Import/Export facilities : allow the interchange of information from
the central repository with other development tools.
h) Code generators : generate code or code skeletons automatically
from the design captured in the central store.

12
10. Design Engineering :
Design Engineering encompasses the set of principles, concepts and
practices that lead to the development of a high-quality system or
product.
Design is a core engineering activity.
The goal of design engineering is to produce a mode or representation
that exhibits firmness, commodity and delight.
Design engineering for computer software changes continually as new
methods, better analysis and broader understanding evolve.
The flow information during software design is as follows.
i.e., Translating the analysis model into the design model :

The Architectural Design defines the relationship between major

structural elements of the software, the architectural styles and design
patterns that can be used to achieve the requirements defined for the
system, and the constraints that affect the way in which architectural
can be implemented.

13
11. Design Process :
Software Design is an iterative process through which requirements are
translated into a ‘blue print’ for constructing the software.
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.
There are three characteristics that serve as a guide for the evaluation of
a good design :
a) 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.

b) The design must be a readable, understandable guide for those who

generate code and for those who test and subsequently support the
software.

c) The design should provide a complete picture of the software,

addressing the data, functional, and behavioral domains from an
implementation perspective.

12. Quality Guidelines :

a) A design should exhibit an architecture that :

i) has been created using recognizable architectural styles or

patterns.

ii) is composed of components that exhibit good design

characteristics.

iii) can be implemented in an evolutionary fashion.

b) A design should be modular, i.e., the software should be logically

partitioned into elements or subsystems.

c) A design should contain distinct representations of data, architecture,

interfaces and components.

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

e) A design should lead to components that exhibit independent

functional characteristics.

f) A design should lead to interfaces that reduce the complexity of

connections between components and with the external
environment.

g) A design should be derived using a repeatable method that is driven

by information obtained during software requirements analysis.

h) A design should be represented using a notation that effectively

communicates its meaning.

13. Quality Attributes :

FURPS is the acronym for the following –
- Functionality
- Usability
- Reliability
- Performance
- Supportability
Functionality : is assessed by evaluating the feature set and capabilities
of the program, the generality of the functions that are delivered, and
the security of the overall system.
Usability : is assessed by considering human factors, overall aesthetics,
consistency and documentation.
Reliability : is evaluated by measuring the frequency and severity of
failure, the accuracy of output results, the mean-time-to-failure (MTTF),
the ability to recover from failure, and the predictability of the program.
Performance : is measured by processing speed, response time,
resource consumption, throughput and efficiency.
Supportability : combines the ability to extend the program,
adaptability, serviceability, testability, configurability.

15
14. Design Concepts :
‘Fundamental Software Design concepts provide the necessary
framework for getting it right’.
a) Abstraction : In a modular solution to any problem, many levels of
abstraction can be posed.

At the higher level of abstraction, a solution is stated in broad terms

using the language of the problem environment.

At the lower levels of abstraction, a more detailed description of the

solution is provided.
There are two types of abstractions :
i) Procedural Abstraction :refers to a sequence of instructions that
have a specific and limited function.
Ex : ‘open’ for a door.
ii) Data Abstraction : is a named collection of data that describes a
data object in the context of the procedural abstraction ‘open’,
one can define a data abstraction called ‘door’.
b) Architecture : ‘Software Architecture’ alludes to “the overall
structure of the software and the ways in which that structure
provides conceptual integrity for a system.

“A software architecture is the development work product that gives

the highest return on investment with respect to quality, schedule
and cost.”

One goal of software design is to derive an architectural rendering of

a system.

The architectural model design can be represented using one or more

of a number of different models.
- Structural models
- Framework models
- Dynamic models
- Process models
- Functional models

16
c) Patterns : “ A pattern is a named nugget of insight which conveys the
essence of a proven solution to a recurring problem within a certain
context amidst competing concerns”.
Each pattern describes a problem which occurs over and over again in
our environment, and then describes the core of the solution to the
problem, in such a way that you can use this solution a million times
over, without ever doing it the same way twice.
d) Modularity : Software architecture and design patterns embody
‘modularity’ – that is, software is divided into separately named and
addressable components, sometimes called ‘modules’, that are
integrated to satisfy problem requirements, that are integrated to
satisfy problem requirements.
‘Modularity’ is the single attribute of software that allows a program
to be intellectually manageable.
The complexity of two problems when they are combined is often
greater than the sum of the complexities, when each is taken
separately.
Modularity and Software Cost :

17
e) Information Hiding : The principle of ‘Information Hiding’ suggests
that modules be “characterized by design decisions that each hides
from all others.

That is, modules should be specified and designed so that

information (algorithms and data) contained within a module is
inaccessible to other modules that have no need for such
information.

f) Functional Independence : The concept of ‘functional independence’

is a direct outgrowth of modularity and the concepts of abstraction
and information hiding.
‘Functional Independence’ is achieved by developing modules with
‘single minded’ function and an ‘aversion’ to excessive interaction
with other modules.
Software with effective modularity, that is, independent modules, is
easier to develop because function may be compartmentalized and
interfaces are simplified.
Independence is assessed using two qualitative criteria :
i) Cohesion :‘Cohesion’ is an indication of the relative functional
strength of a module.
‘Cohesion’ is a natural extensionof the information hiding concept.
A cohesive module performs a single task, requiring little interaction
with other components in other parts of a program.
ii) Coupling : ‘Coupling’ is an indication of the relative interdepen-
dence among modules.
‘Coupling’ is an indication of interconnection among modules in a
software structure.
‘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.
In software design, we strive for ‘lowest possible coupling’.

18
g) Refinement : Stepwise refinement is a top-down design strategy.

A program is developed by successively refining levels of procedural

detail.

‘Refinement’ is actually a process of elaboration.

‘Refinement’ causes the designer to elaborate on the original
statement, providing more and more detail as each successive
refinement occurs.
Abstraction and refinement are complementary concepts :
‘Abstraction’ enables a designer to specify procedure and data
and yet suppress low-level details.
‘Refinement’ helps the designer to reveal low-level details as
design progresses.
h) Refactoring : ‘Refactoring’ is a reorganization technique that
simplifies the design (or code) of a component without changing its
function or behavior.
“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 improve its internal structure”.
When software is refactored, the existing design is examined for
- Redundancy
- Unused design elements
- Inefficient or unnecessary algorithms
- Poorly constructed or in appropriate data structures
- Any other design failure
that can be corrected to yield a better design.
i) Design Classes : As the design model evolves, the software team
must define a set of design classes that

i) refine the analysis classes by providing design detail that will

enable the classes to be implemented.

ii) create a new set of design classes that implement a software

infrastructure to support the business solution.

19
The following are the five different types of design classes, each
representing a different layer of the design architecture :

i) User Interface classes define all abstractions that are necessary

for ‘human computer interaction’ (HCI).

ii) Business Domain classes are often refinements of the analysis

classes defined earlier. The classes identify the attributes and
services (methods) that are required to implement some element
of the business domain.

iii) Process classes implement lower-level business abstractions

required to fully manage the business domain classes.

iv) Persistent Classes represent data stores (eg. Databases) that

will persist beyond the execution of the software.

v) System Classes implement software management and control

functions that enable the system to operate and communicate
within its computing environment and with the outside world.

Each class design should be reviewed to ensure that it is ‘well

formed”

There are FOUR characteristics of ‘well-formed Design Class’.

a) Complete and Sufficient : A design class should be the

complete encapsulation of all attributes and methods that can
reasonably be expected to exist for the class.

b) Primitiveness : Methods associated with a design class should

be focused on accomplishing one service for the class.

c) High-Cohesion : A cohesive design class has a small, focused

set of responsibilities and single-mindedly applies attributes
and methods to implement those responsibilities.

d) Low Coupling : Within the design model, it is necessary for

design classes to collaborate with one another.

20
15.Design Model :
The design model has four major elements :
- data - architecture
- components - interface
The design model can be viewed in two different dimensions as follows :
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.
In the following diagram, the dashed line indicates the boundary
between the analysis and design models.
The elements of 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.

Dimensions of the design model :

21
Data Design Elements : Data design creates a model of data and / or
information that is represented at a high level of abstraction.
The structure of data has always been an important part of software
design.
At the program component level, the design of data structures and the
associated algorithms required to manipulate them is essential to the
creation of high-quality applications.
At the application level, the translation of a data model into a database
is pivotal to achieving the business objectives of a system.
At the business level, the collection of information stored in disparate
databases and reorganized into a ‘data warehouse’ and reorganized into
a ‘data warehouse’ enables data mining or knowledge discovery that can
have an impact on the success of the business itself.

Architectural Design Elements : The architectural model is derived from

the application domain, the analysis model, and available styles and
patterns.
The ‘Architectural design’ for software is the equivalent to the floor plan
of a house.
The floor plan depicts the overall layout of the rooms, their size, shape
and relationship to one another, and the doors and windows that allow
movement into and out of the rooms.
The architectural model is derived from three sources :
a) Information about the application domain for the software to
be built.

b) Specific analysis model elements such as data flow diagrams or

analysis classes, their relationships and collaborations for the
problem at hand

c) The availability of architectural patterns and styles.

22
Interface Design Elements : The interface design for software is the
equivalent to a set of detailed drawings for the doors, windows and
external utilities of a house.
There are three important elements of interface design :
a) The user interface (UI)

UI is a major software engineering action.

The design of UI incorporates

aesthetic elements (eg. layout, color, graphics),
ergonomic elements (eg. information layout and placement,
UI navigation)
technical elements (eg. UI patterns, reusable components).

b) External Interfaces to other systems, devices, networks, or

other producers or consumers of information.
The design of external interfaces requires definitive
information about the entity to which information is sent or
received.

c) Internal Interfaces between various design components.

The design of internal interfaces is closely aligned with

component-level design.

Design realizations of analysis classes represent all operations

and the messaging schemes required to enable communication
and collaboration between operations in various classes.

Interface : “An interface is a specifier for the externally-visible

(public) operations of a class, component, or other classifier
without specification of internal structure”.
In other words, An ‘interface’ is a set of operations that describes
some part of the behavior of a class and provides access to those
operations.

23
Component-Level Design Elements :
The component-level design for software is equivalent to a set of
detailed drawings for each room in a house.
These drawings depict wiring and plumbing within each room, the
location of the electrical receptacles and switches, sinks, showers, tubs,
drains and cabinets.
Within the context of OOSE, a component is represented in UML
diagrammatic form.
Deployment-Level Design Elements :
Deployment-Level Design Elements indicate how software functionality
and subsystems will be allocated within the physical computing environ-
ment that will support the software.
For example, the elements of the ‘Safe Home’ product are configured to
operate within three primary computing environments :
a) A home-based PC
b) The ‘safe home’ control panel.
c) The server housed at CPI corp.(providing internet based access
to the system).

24
16.Designing Class Based Components :
Seven basic design principles are applicable to component-level design
and have been widely adopted when object-oriented software
engineering (OOSE) is applied :
a)The The Open-Closed Principle (OCP) : “ A module (component)
should open for extension but closed for modification”.
For example, assume that the ‘safe home’ security function makes use of
a ‘detector’ class that must check the status of each type of security
censor.
The OCP for the ‘detector’ class :

b) The Liskov Substitutuion Principle (LSP) :

“Subclasses should be substitutable for their base classes”
c) Dependency Inversion Principle (DIP) :
“Depend on abstractions. Do not depend on concretions”.
d) The Interface Segregation Principle (ISP) :
“Many client-specific interfaces are better than one general
purpose interface”.
e) The Release Reuse Equivalency Principle (REP) :
“The granule of reuse is the granule of release”.

25
 f) The Common Closure Principle (CCP) :
“Classes that change together belong to gether”.
g) The Common Reuse Principle (CRP) :
“Classes that are not reused together should not be grouped
together”.
17. Component- Level Design Guidelines :
A set of pragmatic design guidelines can be applied as component-level
design proceeds.
These guidelines apply to components, their interfaces and the
dependencies and inheritance characteristics that have an impact on the
resultant design.
a) 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 conventional-level model.
Architectural component names should be drawn from the problem
domain and should have meaning to all stakeholders who view the
architectural model.
b) Interfaces : Interfaces provide important information about
communication and collaboration.

It also help us to achieve OCP.

c) Dependencies and Inheritance : For improved readability, it is a good

idea to model dependencies from left to right and inheritance from
bottom (derived class) to top (base class).

18. Cohesion :
A set of pragmatic design guidelines can Within the context of
component-level design for object-oriented systems, ‘cohesion’ 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.

26
Different types of Cohesion :

a) Functional : Exhibited primarily by operations, this level of cohesion

occurs when a module performs one and only one computation and
then returns a result.

b) Layer : Exhibited by packages, components, and classes.

This type of cohesion occurs when a higher layer accesses the

services of a lower layer.

c) Communicational : All operations that access the same data are

defined within one class.

In general, such classes focus solely on the data in question, accessing

and storing it.

d) Sequential : Components or operations are grouped in a manner that

allows the first to provide input to the next and so on.

Then intent is to implement a sequence of operations.

e) Procedural : Components or operations are grouped in a manner that

allows one to be invoked immediately after the preceding one was
invoked, even when there is no data passed between them.

f) Temporal : Operations that are performed to reflect a specific

behavior or state.

i.e., An operation is performed at start-up or all operations

performed when an error is detected.

g) Utility : Components, classes or operations that exist within the same

category but or otherwise unrelated are grouped together.
For example, a class called ‘Statistics’ exhibits utility cohesion if it
contains all attributes and operations required to compute six simple
statistical measures.

27
19. Coupling :

“Coupling is a qualitative measure of the degree to which classes are

connected to one another”
a) Content Coupling : Occurs when one component “superstitiously”
modifies data that is internal to another component.

b) Common Coupling : Occurs when a number of components all make

use of a global variable.

c) Control Coupling : Occurs when operation A() invokes operation B()

and passes control flag to B.

The control flag then ‘directs’ logical flow within B.

d) Stamp Coupling : Occurs when Class B is declared as a type for an

argument of an operation of Class A.

e) Data Coupling : Occurs when operations pass long strings of data

arguments.

f) Routing Call Coupling : Occurs when one operation invokes another.

g) Type Use Coupling : Occurs when component A use a data type

defined in Component B.

h) Inclusion or Import Coupling : Occurs when component A imports or

includes a package or the content of component B.

i) External Coupling : Occurs when a component communicates or

collaborates with infrastructure components. (eg. operating system
functions, data base capability)

Software must communicate internally and externally.

The designer should work to reduce coupling whenever possible and
understand the ramifications of high coupling when it can not be
avoided.

28
20. Conducting Component-Level Design :

The following steps represent a typical task set for ‘component-level

design’, when it is applied for an object-oriented system.
a) Identify all design classes that correspond to the problem domain.

b) Identify all design classes that correspond to the infrastructure

domain.

c) Elaborate all design classes that are not acquired as reusable

components.

d) Specify message details when classes or components collaborate.

The analysis model makes use of a collaboration diagram to show

how analyses classes collaborate with one another.
Example : Consider the following diagram.
Let there are three objects :
Production-Job Work-Order Job-Queue
These three objects collaborate to prepare a print job for submission
to the production system.
Messages are passed between objects as illustrated b the arrow in
the diagram.
Collaboration diagram for the printing system :

29
e) Identify appropriate interfaces for each component.
Refactoring interfaces and class definitions for ‘Print Job’ :

Here, the class ‘WorkOrder’ will take care of all activities associated
with the assembly of a work order.
The operation ‘BuildWorkOrder’ is a method in the class
‘WorkOrder’.
A class ‘ProductionJob’ would encompass all information associated
with a production job to be passed to the production facility.
The interface ‘initiatejob’ is now cohesive, focusing on one function.
The interfaces associated with ‘ProductionJob’, ‘WorkOrder’, and
‘JobQueue’ are similarly single-minded.

f) Elaborate attributes and define data types and data structures

required to implement them.

g) Describe processing flow within each operation in detail.

h) Describe persistent data sources (databases and files) and identify

the classes required to manage them.

30
 i) Develop and elaborate behavioral representations for a class or
component.

j) Elaborate deployment diagrams to provide additional implementa-

tion detail.

k) Factor every component-level design representation and always

consider alternatives.

21. Performing User Interface Design :

Interface Design focuses on three areas :
- 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 interface between a human and the computer.
The Golden Rules :
The Interface Design coins three ‘Golden Rules’.
a) Place the user in Control :
- Define interaction modes in a way that does not force a user into
unnecessary or undesired actions.
- Provide for flexible interaction
- Allow user interaction to be interruptible and undoable
- Streamline interaction as skill levels advance and allow the intera-
ction to be customized.
- Hide technical internals from the casual user.
- Design for direct interaction with objects that appear on the screen.
b) Reduce the User’s Memory Load :
- Reduce demand on short-term memory
- Establish meaningful defaults
- Define shortcuts that are intuitive

31
 - The visual layout of the interface should be based on real world
metaphor.
- Disclose information in a progressive fashion.
c) Make the Interface Consistent :
- 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.
In general, things that look different should act different.
Things that look the same should act the same.

Note : These golden rules actually form the basis for a set of user
interface design principles that guide this important software
design action.

* * * * *

32