WMS - 334 Application Developent Methods

1
THE INTERNATIONAL UNIVERSITY OF

MANAGEMENT
WINDHOEK-NAMIBIA
STUDY MANUAL
APPLICATION DEVELOPMENT METHODS
CODE: WMS - 334

TABLE OF CONTENTS
Copyright
Published by the International University of Management, Namibia, Windhoek, 2010. IUM Namibia. No part of this publication
may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying,
recording or otherwise, without prior permission of the publishers
IUM WMS 334
2
CHAPTER
PAGE NUMBER
1. Object-oriented concepts.7
2. The unified modeling language.21
3. Object-oriented design.42
4. Rapid prototyping... ..47
5. Visual development.......83
6. User interface design guidelines. 89
Copyright
IUM WMS 334
3
THE STRUCTURE OF THIS STUDY MODULE
The Module has margin icons that show the student the objectives, activities,
in-text questions, feedback, further reading, key words and terms, stop and
reflex signs.
Chapter One focuses on Object-Oriented Concepts; defining object oriented

concepts objects, states, properties, behaviour, encapsulation and methods.
Chapter Two looks at the Unified Modelling Language. Here define what UML is
and why it used in Software Development. The diagrammatic notations used in
UML are also introduced here.
Chapter Three explores Object-Oriented Design. How do you use OOD in

developing software? That is discussed in this chapter
Chapter Four focuses on Rapid Prototyping. Here we explain and define Rapid
Software development and its advantages and disadvantages to software
development.
Chapter Five looks at the visual development environments
Chapter Six dwells on the User Interface Guidelines. Why is User Interface
Design important to software development? That is discussed here in this
chapter. We also look at the principles and guidelines on how to design and
working and interactive user interfaces (applications)
This module therefore works as a strong guide to Application Development, and hence must
be used in collaboration with other recommended textbooks, not as the ONLY source of
information for this exciting subject.
Copyright
IUM WMS 334
The author wishes you a pleasant study and best regards.
Copyright
IUM WMS 334
5
COURSE OVERVIEW
This tutorial seeks to educate the learner in Application Development Methods. This module
focuses on exploring Software Development world and how Applications are designed from
scratch. Important concepts and definitions used in Software development are covered in this
module. Different models and designs are used in software design which lead to the
successful development and implementation of software applications. Good software
applications interact with users and easily avoid and handle errors that are made by the users
whilst they use the application. Students developing applications should become familiar with
important principles and guidelines in developing software applications.
An examination is appropriately set to test you on this critical area of your study.
Copyright
IUM WMS 334
6
COURSE OBJECTIVES- use action verbs;
Upon completion of this course you will be able to:
Analyse the main concepts of object-orientation

Design a simple object-oriented application
Demonstrate the eight golden rules of user interface design
Illustrate the essential features of a modern visual development environment
which enable rapid application development, especially with regard to
database applications
Define Object Oriented Concepts and Design
State and explain the role of Object Oriented models in software design
List examples of approaches used in software prototyping.
Illustrate how a good User Interface interacts with users to avoid errors
Give examples and explain types of diagrams used in UML
Copyright
IUM WMS 334
7
Module Outcomes
Illustrate the key issues of web page design with regard to the balance of
dynamics, performance and aesthetics.
Explain the operation of the World Wide Web and related Internet
technologies
Demonstrate the ability to set up and manage a web server.
As you go through his module you will oftenly see the icons below and what they
mean and they emphasize on what you need to understand or look out for. These
may be objectives, activities, feedback e.t.c as listed in the table below. Take note of
them and know what they mean when you see them. They will assist you in making
your study easier and interesting and also in helping you master the keys concepts
and things to understand in this module.
Activity What the student has to do (written work)
Feedback the author giving a guide to how a question should be

answered
In-text Question students have to answer questions on content
covered
Further reading
Key words / Terms
Stop & Reflect - student just have to think about a question, idea,
view, opinion (real life practical examples in Namibian context
Copyright
IUM WMS 334
Objectives
Copyright
IUM WMS 334
1 Object-Oriented Concept
Chapter 1
-understand object-orientation in software development
Objectives
Basic Concept
Object-orientation is so called because this method sees things that are
part of the real world as objects. A phone is an object in the same way as
a bicycle, a human being, or an insurance policy are objects. In everyday
life, we simplify objects in our thinking we work with models. Software
development does essentially the same: objects occurring in reality are
reduced to a few features that are relevant in the current situation.
Instead of real objects, we work with symbols. Properties and composition
of objects correspond only roughly to reality; the model selects only
those aspects that are useful for carrying out a specific task. In figure 1.1,
we use model to describe a reality that a teacher owns a bicycle and he
reads a book.
Figure 1.1 Complex realities are made more manageable by abstract models.
Copyright
IUM WMS 334
10
1.1.1
Data Abstraction
Abstraction is the presentation of simple concept (or object) to the

external world. Abstraction concept is to describe a set of similar
concrete entities. It focuses on the essential, inherent aspects of an
entity and ignoring its accidental properties. The abstraction concept is
usually used during analysis: deciding only with application-domain
concepts, not making design and implementation decisions.
Two popular abstractions: procedure abstraction and data abstraction.
Procedure abstraction is to decompose problem to many simple subworks. Data abstraction is to collect essential elements composing to a
compound data. These two abstractions have the same objective:
reusable and replaceable. Figure 1.2 shows an example of data
abstraction to abstract doors as a data structure with essential
properties.
Figure 1.2 Example of Data Abstraction.

1.1.2
Encapsulation
Encapsulation means as much as shielding. Each object-oriented object

has a shield around it. Objects can't 'see' each other. They can exchange
things though, as if they are interconnected through a hatch. Figure 1.3
shows the concept of the encapsulation. It separates the external aspects
of an object from the internal implementation details of the object, which
Copyright
IUM WMS 334
11
are hidden from other objects. The object encapsulates both data and the
logical procedures required to manipulate the data.
Figure 1.3 Example of Encapsulation Concept.
1.2
Class Modeling
1.2.1
Class and Object Instance
A class is used to describe something in the world, such as occurrences,

things, external entities, roles, organization units, places or structures. A
class describes the structure and behavior of a set of similar objects. It is
often described as a template, generalized description, pattern or
blueprint for an object, as opposed to the actual object, itself. Once a
class of items is defined, a specific instance of the class can be defined.
An instance is also called object. Figure 1.4 shows an example of
teacher class and its object in UML notation.
Copyright
IUM WMS 334
12
The following table gives some examples of classes and objects
Type
Example of class
Example
object
Occurrence
Alarm
Fire alarm
Things
Car
Ferrari 360
External entities
Door
Fire door
Roles
Teacher
John, Nick
Organizational
units
IECS department
FCU_IECS,
1.2.2
of
Figure 1.4 Class and Object.

Property and Method
Properties in a class are used to present the structure of the objects:

their components and the information or data contained therein.
(e.g., name, owner, ground clearance).An instance of a class has the
properties defined in its class and all of the classes from which its
class inherits. In figure 1.5, name, weight and breed are three
properties of the class Dog.
Copyright
IUM WMS 334
13
Methods in a class describe the behavior of the objects. It represents

a function that an instance of the class can be asked to perform. In
the figure 1.5, a Dog class defines three methods: sit, beg and run
which indicate the behavior a dog can have.
Figure 1.5 An example of a Dog Class

1.2.3
Association
An association is a relationship between different objects of one more

classes. A simple example of an association is the relationship among an
enterprise, departments and employees showed in figure 1.6.
Figure 1.6 Associations

Multiplicity
In the simple case, an association is represented by a single line between
two classes. Usually, however, associations are shown in as much detail
as possible. Then, the association receives a name and a numerical
specification (Multiplicity indication) of how many objects on one side of
the association are connected with how many objects on the other side.
In the Figure 1.6 shows an example of association with multiplicity.
Common multiplicities are:
Copyright
IUM WMS 334
14
0..1
No instance,
instance
or
one
Exactly one instance
0..*, *
Zero or more instances
1..*
One or more instances
Aggregation
Aggregation is a special form of association. Aggregation is the
composition of an object out of a set of parts. A car, for example, is an
aggregation of tires, engine, steering wheel, brakes and so on. These
parts may in turn be aggregations: a brake consists of disk, pads,
hydraulic, etc. Aggregation represents a has relationship: a car has an
engine. Instead of aggregation, some people talk about whole-part
hierarchy. For example, in figure 1.7, where an Enterprise represents a
whole end and Department represents a part end.
Figure 1.7 Aggregation

Inheritance
Inheritance is the property whereby one class extends another class by
including additional methods and/or variables. The original class is called
the superclass of the extending class, and the extending class is called
Copyright
IUM WMS 334
15
the subclass of the class that is extended. Since a subclass contains all of
the data and methods of the superclass plus additional resources, it is
more specific. Conversely, since the superclass lacks some of the
resources of the subclass, it is more general or abstract, than its
subclasses. Figure 1.8 shows an example, where Circle and Rectangle
inherit from GeomFigure and own all attributes and methods from
GeomFigure.
Figure 1.8 Inheritance

1.3
Object-oriented Programming
1.3.1
Interface
Interface classes are abstract definitions of purely functional interfaces.

They DO NOT define any attributes or associations. An interface can not
instantiate any object instances. They only define a set of abstract
operations. They often define pre-conditions, post-conditions, invariants
and possible exceptions for these operations. Figure 1.9 is an example
the String class implements the interface Sortable. Note that isEqual() in
the interface Sortable do not have method implemented, but String must
Copyright
IUM WMS 334
16
have its implementation on isEqual() since it is defined to implement

Sortable.
Figure 1.9 Interface
1.3.2
Event and Listener
Event and Listener is an important part using in CIM modeling. An event

listener is an object to which a component has delegated the task of
handling a particular kind of event. In other words, if you want an object
in your program to respond to another object which is generating events,
you must register your object with the event generating object, and then
handle the generated events when the come. A typical example is the
ActionListener shows in figure 1.10. JButton is a kind of event source
component. When the event is activated, it will notify ActionListener to
handle it. The EventHandler is a ActionListener responsible for the event.
Copyright
IUM WMS 334
17
Figure 1.10 ActionListener

1.3.3
Object Communication
Communication between objects is achieved by exchanging messages

(Figure 1.11). These messages lead to the operations, which means that
an object understands precisely those messages for which it has
operations.
Figure 1.11 Message Exchange in Classes

1.3.4
Polymorphism
Polymorphism indicates the meaning of many form. In object-oriented

design, polymorphism present a method can has many definitions
(forms). Polymorphism is related to Overloading and Overriding.
Copyright
IUM WMS 334
18
Overloading indicates a method can have different definitions by defining

different type of parameter, for example
getPrice(): void
getprice(String name): void
getPrice() has two different forms is the same meaning of different
definitions. Overriding indicates that subclass and parentclass have the
same methods, parameters and return types (namely to redefine the
methods in parentclass). In figure 1.12, encrypt(String) method has three
definitions, distribute in subclass and parentclass. Document object
claims Encryption object to assist ecryption. In its encryString() method,
it doesnt indicate RSAEncryption or DesEncryption is the encryption
actor, just only send a message to Encryption object:
EncryptString(Encryption e) {
result = e.encrypt(source);
Figure 1.12 Polymorphism

1.4
Unified Modeling Language
Copyright
IUM WMS 334
19
The Unified Modeling Language was originally developed at Rational

Software but is now administered by the Object Management Group (see
link). It is a modeling syntax aimed primarily at creating models of
software-based systems, but can be used in a number of areas. It is:
Syntax only - UML is just a language, it tells you what

model elements and diagrams are available and the rules
associated with them. It doesn't tell you what diagrams to
create.
Comprehensive - it can be used to model anything. It is

designed to be user extended to fill any modeling
requirement.
Language independent - it doesn't matter what hi-level

language is to be used in the code. Mapping into code is a
matter for the case tool you use.
Process independent - the process by which the models

are created is separate from the definition of the language.
You will need a process in addition to the use of UML itself.
Tool independent - UML leaves plenty of space for tool

vendors to be creative and add value to visual modeling with
UML. However, some tools will be better than others for
particular applications.
Well documented - the UML notation guide is available as a
reference to all the syntax available in the language.
Its application is not well understood - the UML notation
guide is not sufficient to teach you how to use the language.
It is a generic modeling language and needs to be adapted by
the user to particular applications.
Originally just for system modeling - some user defined

extensions are becoming more widely used now, for example
for business modeling and modeling the design of web-based
applications.
In brief, UML is a standard modeling language from system analysis,
system design to implementation.
Table 1.1 UML Notations A Summary
Copyright
IUM WMS 334
20
Notation
Name
Description
Class
A
class
describes the
structure and
behavior of a
set of similar
objects.
Object
An instance of
a class
Association
A relationship
between
different
objects of one
more classes
Inheritance
One
class
extends
another class
Interface
Abstract
definitions
purely
functional
interfaces
of
Copyright
IUM WMS 334
21
Interface
Implementa
tion
Implement the
functions
defined
in
interface
Aggregatio
n
Aggregation is
the
composition of
an object out
of a set of
parts.
Others refer to UML Spec.
1.5
Modeling tool - introduction to Rational Rose
There are many tools that support UML modeling. Here we take
Rational Rose to introduce these basic modeling concepts.
1.5.1
Rational Rose
Rational Rose is a program that allows you to build models based on the
Unified Modeling Language or more commonly known as the UML. You
are able to create three diagrams in Rational Rose, the use-case diagram,
the sequence diagram, and the class diagram. Here we simple introduce
the class diagram part. The class diagram describes the types of objects
in the program and how they are related to each other.
Before we start modeling, it is important that we know the important
features of the main window. If you look to the far left you will see a side
panel as shown in Figure .13. 1The Use Case View is where you will see all
the use cases that you will make. Along with the use cases you will see
any actors used in your use case diagrams and the different associations
created between the use case and the actor. The Logical View is where
Copyright
IUM WMS 334
22
you will build your class diagram and your sequence diagrams. Inside
here as well you will see the different classes you created and the
associations that exist between them.
Figure 1.13 Side panel

Beside the side menu you will see a very important toolbox. This toolbox
allows you to create many of the different elements that you will use in
your diagrams. Figure 3.14 shows some of the most important elements.
Copyright
IUM WMS 334
23
Figure 31.14 Notations

Now I am going to teach you how to model in class diagram. When you
think of UML diagrams, class diagrams are typically the ones that come
to mind. Figure 1.15 shows a simple example of a class diagram with
three classes named VideoStore, Database, and Video.
Copyright
IUM WMS 334
24
Figure 1.15 Example of class diagram

When creating a class diagram the first thing that you need to do is
create the class diagram window. To do this:
Right click on Logical View shown on the side bar
Go to new and Class Diagram
Type in the name of the class diagram
Double click on the name you just typed to bring the window up.
Now that you have your window ready, lets create our first class.
On the toolbox click the fifth button from the top. Refer to
Figure1.14
Now just drag where you want your class to be in the window.
Now that you have a class lets put some attributes and operations into it.
When you double click on the class that you just created a box will pop
up like in figure 1.16 this is where you will be editing your class. Here you
Copyright
IUM WMS 334
25
can do many things including changing the name of the class and adding
attributes and operations.
Figure 1.16 Property editor

Now you should see a box like in Figure 1.16. To add operations:
Click on the tab that reads operations
Right click anywhere on the white part and select insert
Type in the name of the operation and then hit enter
If you double click on the operation you created another box will pop
up that allows you to customize the operation. Things you can customize
includes adding parameters and return types. To create an attribute click
on the attribute tab and follow the same procedure
Once you create your class you can make another class in the same
fashion, and connect the two classes with an association. To see how to
Copyright
IUM WMS 334
26
connect using an association, refer back to the Use Case Diagram

section.1.5.2
Other Modeling tools
Except the Ration Rose, there are still many other UML modeling tools,
such as ArgoUML, Borland Together, Rational XDE, Eclipse, Power
Designer, Visual Paradigm for UML, MagicDraw and etc.
Copyright
IUM WMS 334
27
Activity 1
- What are some of the attributes of UML?
Activity
Feedback Activity 1
Feedback
Syntax only - UML is just a language, it tells you what model

elements and diagrams are available and the rules associated with
them. It doesn't tell you what diagrams to create.
Comprehensive - it can be used to model anything. It is designed to
be user extended to fill any modeling requirement.
Language independent - it doesn't matter what hi-level language is
to be used in the code. Mapping into code is a matter for the case tool
you use.
Process independent - the process by which the models are created
is separate from the definition of the language. You will need a
process in addition to the use of UML itself.
Tool independent - UML leaves plenty of space for tool vendors to be
creative and add value to visual modeling with UML. However, some
tools will be better than others for particular applications.
Well documented - the UML notation guide is available as a
reference to all the syntax available in the language.
Its application is not well understood - the UML notation guide is
not sufficient to teach you how to use the language. It is a generic
modeling language and needs to be adapted by the user to particular
applications.
Originally just for system modeling - some user defined extensions
are becoming more widely used now, for example for business
modeling and modeling the design of web-based applications.
Object Oriented Concept
Data Abstraction Encapsulation
Class Modelling
Key Words/Terms
Copyright
IUM WMS 334
28
2.
What is UML?
Chapter 2
-Define UML and its primary goals
-understand the history of UML
Objectives
The Unified Modeling Language (UML) is a standard language for specifying,

visualizing, constructing, and documenting the artifacts of software systems,
as well as for business modeling and other non-software systems. The UML
represents a collection of best engineering practices that have proven
successful in the modeling of large and complex systems. The UML is a very
important part of developing object oriented software and the software
development process. The UML uses mostly graphical notations to express
the design of software projects. Using the UML helps project teams
communicate, explore potential designs, and validate the architectural
design of the software.
Goals of UML
The primary goals in the design of the UML were:
1. Provide users with a ready-to-use, expressive visual
modeling language so they can develop and exchange
meaningful models.
2. Provide extensibility and specialization mechanisms to
extend the core concepts.
3. Be independent of particular programming languages and
development processes.
4. Provide a formal basis for understanding the modeling
language.
Copyright
IUM WMS 334
29
5. Encourage the growth of the OO tools market.

6. Support higher-level development concepts such as
collaborations, frameworks, patterns and components.
7. Integrate best practices.
Why Use UML?
As the strategic value of software increases for many companies, the
industry looks for techniques to automate the production of software and to
improve quality and reduce cost and time-to-market. These techniques
include component technology, visual programming, patterns and
frameworks. Businesses also seek techniques to manage the complexity of
systems as they increase in scope and scale. In particular, they recognize the
need to solve recurring architectural problems, such as physical distribution,
concurrency, replication, security, load balancing and fault tolerance.
Additionally, the development for the World Wide Web, while making some
things simpler, has exacerbated these architectural problems. The Unified
Modeling Language (UML) was designed to respond to these needs.
History of UML
Identifiable object-oriented modeling languages began to appear between
mid-1970 and the late 1980s as various methodologists experimented with
different approaches to object-oriented analysis and design. The number of
identified modeling languages increased from less than 10 to more than 50
during the period between 1989-1994. Many users of OO methods had
trouble finding complete satisfaction in any one modeling language, fueling
the "method wars." By the mid-1990s, new iterations of these methods
began to appear and these methods began to incorporate each others
techniques, and a few clearly prominent methods emerged.
The development of UML began in late 1994 when Grady Booch and Jim
Rumbaugh of Rational Software Corporation began their work on unifying the
Booch and OMT (Object Modeling Technique) methods. In the Fall of 1995,
Ivar Jacobson and his Objectory company joined Rational and this unification
effort, merging in the OOSE (Object-Oriented Software Engineering) method.
Copyright
IUM WMS 334
30
As the primary authors of the Booch, OMT, and OOSE methods, Grady Booch,
Jim Rumbaugh, and Ivar Jacobson were motivated to create a unified
modeling language for three reasons. First, these methods were already
evolving toward each other independently. It made sense to continue that
evolution together rather than apart, eliminating the potential for any
unnecessary and gratuitous differences that would further confuse users.
Second, by unifying the semantics and notation, they could bring some
stability to the object-oriented marketplace, allowing projects to settle on
one mature modeling language and letting tool builders focus on delivering
more useful features. Third, they expected that their collaboration would
yield improvements in all three earlier methods, helping them to capture
lessons learned and to address problems that none of their methods
previously handled well.
The efforts of Booch, Rumbaugh, and Jacobson resulted in the release of the
UML 0.9 and 0.91 documents in June and October of 1996. During 1996, the
UML authors invited and received feedback from the general community.
They incorporated this feedback, but it was clear that additional focused
attention was still required.
While Rational was bringing UML together, efforts were being made on
achieving the broader goal of an industry standard modeling language. In
early 1995, Ivar Jacobson (then Chief Technology Officer of Objectory) and
Richard Soley (then Chief Technology Officer of OMG) decided to push harder
to achieve standardization in the methods marketplace. In June 1995, an
OMG-hosted meeting of all major methodologists (or their representatives)
resulted in the first worldwide agreement to seek methodology standards,
under the aegis of the OMG process.
During 1996, it became clear that several organizations saw UML as strategic
to their business. A Request for Proposal (RFP) issued by the Object
Management Group (OMG) provided the catalyst for these organizations to
join forces around producing a joint RFP response. Rational established the
UML Partners consortium with several organizations willing to dedicate
resources to work toward a strong UML 1.0 definition. Those contributing
most to the UML 1.0 definition included: Digital Equipment Corp., HP, i-Logix,
IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle,
Rational Software, TI, and Unisys. This collaboration produced UML 1.0, a
modeling language that was well defined, expressive, powerful, and
Copyright
IUM WMS 334
31
generally applicable. This was submitted to the OMG in January 1997 as an

initial RFP response.
In January 1997 IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich
Technologies and Softeam also submitted separate RFP responses to the
OMG. These companies joined the UML partners to contribute their ideas,
and together the partners produced the revised UML 1.1 response. The focus
of the UML 1.1 release was to improve the clarity of the UML 1.0 semantics
and to incorporate contributions from the new partners. It was submitted to
the OMG for their consideration and adopted in the fall of 1997.
Copyright
IUM WMS 334
32
Types of UML Diagrams

Each UML diagram is designed to let developers and customers view a
software system from a different perspective and in varying degrees of
abstraction. UML diagrams commonly created in visual modeling tools
include:
Use Case Diagram displays the relationship among actors and use cases.
Class Diagram models class structure and contents using design elements
such as classes, packages and objects. It also displays relationships such as
containment, inheritance, associations and others.
Interaction Diagrams
Sequence Diagram displays the time sequence of the objects

participating in the interaction. This consists of the vertical
dimension (time) and horizontal dimension (different objects).
Collaboration Diagram displays an interaction organized

around the objects and their links to one another. Numbers are
used to show the sequence of messages.
State Diagram displays the sequences of states that an object of an

interaction goes through during its life in response to received stimuli,
together with its responses and actions.
Activity Diagram displays a special state diagram where most of the states
are action states and most of the transitions are triggered by completion of
the actions in the source states. This diagram focuses on flows driven by
internal processing.
Physical Diagrams
Component Diagram displays the high level packaged

structure of the code itself. Dependencies among components
are shown, including source code components, binary code
components, and executable components. Some components
Copyright
IUM WMS 334
33
exist at compile time, at link time, at run times well as at more

than one time.
Deployment Diagram displays the configuration of run-time

processing elements and the software components, processes,
and objects that live on them. Software component instances
represent run-time manifestations of code units.
A use case is a set of scenarios that describing an interaction between a user

and a system. A use case diagram displays the relationship among actors
and use cases. The two main components of a use case diagram are use
cases and actors.
An actor is represents a user or another system that will interact with the
system you are modeling. A use case is an external view of the system that
represents some action the user might perform in order to complete a task.
When to Use: Use Cases Diagrams
Use cases are used in almost every project. The are helpful in exposing
requirements and planning the project. During the initial stage of a project
most use cases should be defined, but as the project continues more might
become visible.
How to Draw: Use Cases Diagrams
Use cases are a relatively easy UML diagram to draw, but this is a very
simplified example. This example is only meant as an introduction to the
UML and use cases
Copyright
IUM WMS 334
34
Start by listing a sequence of steps a user might take in order to complete an

action. For example a user placing an order with a sales company might
follow these steps.
1. Browse catalog and select items.
2. Call sales representative.
3. Supply shipping information.
4. Supply payment information.
5. Receive conformation number from salesperson.
These steps would generate this simple use case diagram:
Copyright
IUM WMS 334
35
This example shows the customer as a actor because the customer is using
the ordering system. The diagram takes the simple steps listed above and
shows them as actions the customer might perform. The salesperson could
also be included in this use case diagram because the salesperson is also
interacting with the ordering system.
From this simple diagram the requirements of the ordering system can easily
be derived. The system will need to be able to perform actions for all of the
use cases listed. As the project progresses other use cases might appear.
The customer might have a need to add an item to an order that has already
been placed. This diagram can easily be expanded until a complete
description of the ordering system is derived capturing all of the
requirements that the system will need to perform.
Copyright
IUM WMS 334
36
Class Diagrams
Class diagrams are widely used to describe the types of objects in a system
and their relationships. Class diagrams model class structure and contents
using design elements such as classes, packages and objects. Class
diagrams describe three different perspectives when designing a system,
conceptual, specification, and implementation. These perspectives become
evident as the diagram is created and help solidify the design. This example
is only meant as an introduction to the UML and class diagrams. Classes are
composed of three things: a name, attributes, and operations. Below is an
example of a class.
Class diagrams also display relationships such as containment, inheritance,

associations and others.2 Below is an example of an associative relationship:
The association relationship is the most common relationship in a class

diagram. The association shows the relationship between instances of
classes. For example, the class Order is associated with the class Customer.
The multiplicity of the association denotes the number of objects that can
participate in then relationship. For example, an Order object can be
Copyright
IUM WMS 334
37
associated to only one customer, but a customer can be associated to many

orders.
Another common relationship in class diagrams is a generalization. A
generalization is used when two classes are similar, but have some
differences. Look at the generalization below:
In this example the classes Corporate Customer and Personal Customer have
some similarities such as name and address, but each class has some of its
own attributes and operations. The class Customer is a general form of both
the Corporate Customer and Personal Customer classes. This allows the
designers to just use the Customer class for modules and do not require indepth representation of each type of customer.
When to Use: Class Diagrams
Copyright
IUM WMS 334
38
Class diagrams are used in nearly all Object Oriented software designs. Use
them to describe the Classes of the system and their relationships to each
other.
How to Draw: Class Diagrams
Class diagrams are some of the most difficult UML diagrams to draw. To
draw detailed and useful diagrams a person would have to study UML and
Object Oriented principles for a long time. Therefore, this page will give a
very high level overview of the process.
Before drawing a class diagram consider the three different perspectives of
the system the diagram will present; conceptual, specification, and
implementation. Try not to focus on one perspective and try see how they all
work together.
When designing classes consider what attributes and operations it will have.
Then try to determine how instances of the classes will interact with each
other. These are the very first steps of many in developing a class diagram.
However, using just these basic techniques one can develop a complete view
of the software system.
Copyright
IUM WMS 334
39
This example is only meant as an introduction to the UML and use cases.
Interaction diagrams model the behavior of use cases by describing the way
groups of objects interact to complete the task. The two kinds of interaction
diagrams are sequence and collaboration diagrams. This example is only
meant as an introduction to the UML and interaction diagrams.
When to Use: Interaction Diagrams
Interaction diagrams are used when you want to model the behavior of
several objects in a use case. They demonstrate how the objects collaborate
for the behavior. Interaction diagrams do not give a in depth representation
Copyright
IUM WMS 334
40
of the behavior. If you want to see what a specific object is doing for several
use cases use a state diagram.
How to Draw: Interaction Diagrams
Sequence diagrams, collaboration diagrams, or both diagrams can be used
to demonstrate the interaction of objects in a use case. Sequence diagrams
generally show the sequence of events that occur. Collaboration diagrams
demonstrate how objects are statically connected. Both diagrams are
relatively simple to draw and contain similar elements.
Sequence diagrams:
Sequence diagrams demonstrate the behavior of objects in a use case by
describing the objects and the messages they pass. the diagrams are read
left to right and descending. The example below shows an object of class 1
start the behavior by sending a message to an object of class 2. Messages
pass between the different objects until the object of class 1 receives the
final message.
Below is a slightly more complex example. The light blue vertical rectangles
the objects activation while the green vertical dashed lines represent the life
of the object. The green vertical rectangles represent when a particular
object has control. The represents when the object is destroyed. This
diagrams also shows conditions for messages to be sent to other object. The
condition is listed between brackets next to the message. For example, a
[condition] has to be met before the object of class 2 can send a message()
to the object of class 3.
Copyright
IUM WMS 334
41
The next diagram shows the beginning of a sequence diagram for placing an
order. The object an Order Entry Window is created and sends a message to
an Order object to prepare the order. Notice the names of the objects are
followed by a colon. The names of the classes the objects belong to do not
have to be listed. However the colon is required to denote that it is the
name of an object following the objectName:className naming system.
Next the Order object checks to see if the item is in stock and if the [InStock]
condition is met it sends a message to create an new Delivery Item object.
Copyright
IUM WMS 334
42
The next diagrams adds another conditional message to the Order object. If
the item is [OutOfStock] it sends a message back to the Order Entry Window
object stating that the object is out of stack.
Copyright
IUM WMS 334
43
This simple diagram shows the sequence that messages are passed between
objects to complete a use case for ordering an item.
Collaboration diagrams:
Collaboration diagrams are also relatively easy to draw. They show the
relationship between objects and the order of messages passed between
them. The objects are listed as icons and arrows indicate the messages
being passed between them. The numbers next to the messages are called
sequence numbers. As the name suggests, they show the sequence of the
messages as they are passed between the objects. There are many
acceptable sequence numbering schemes in UML. A simple 1, 2, 3... format
can be used, as the example below shows, or for more detailed and complex
diagrams a 1, 1.1 ,1.2, 1.2.1... scheme can be used.
The example below shows a simple collaboration diagram for the placing an
order use case. This time the names of the objects appear after the colon,
such as :Order Entry Window following the objectName:className naming
convention. This time the class name is shown to demonstrate that all of
objects of that class will behave the same way.
Copyright
IUM WMS 334
44
State Diagrams
State diagrams are used to describe the behavior of a system. State
diagrams describe all of the possible states of an object as events occur.
Each diagram usually represents objects of a single class and track the
different states of its objects through the system.
When to Use: State Diagrams
Use state diagrams to demonstrate the behavior of an object through many
use cases of the system. Only use state diagrams for classes where it is
necessary to understand the behavior of the object through the entire
system. Not all classes will require a state diagram and state diagrams are
not useful for describing the collaboration of all objects in a use case. State
diagrams are other combined with other diagrams such as interaction
diagrams and activity diagrams.
How to Draw: State Diagrams
State diagrams have very few elements. The basic elements are rounded
boxes representing the state of the object and arrows indicting the transition
to the next state. The activity section of the state symbol depicts what
activities the object will be doing while it is in that state.
Copyright
IUM WMS 334
45
All state diagrams being with an initial state of the object. This is the state of
the object when it is created. After the initial state the object begins
changing states. Conditions based on the activities can determine what the
next state the object transitions to.
Below is an example of a state diagram might look like for an Order

object. When the object enters the Checking state it performs the activity
"check items." After the activity is completed the object transitions to the
next state based on the conditions [all items available] or [an item is not
available]. If an item is not available the order is canceled. If all items are
available then the order is dispatched. When the object transitions to the
Dispatching state the activity "initiate delivery" is performed. After this
activity is complete the object transitions again to the Delivered state.
Copyright
IUM WMS 334
46
State diagrams can also show a super-state for the object. A super-state is
used when many transitions lead to the a certain state. Instead of showing
all of the transitions from each state to the redundant state a super-state can
be used to show that all of the states inside of the super-state can transition
to the redundant state. This helps make the state diagram easier to read.
The diagram below shows a super-state. Both the Checking and Dispatching
states can transition into the Canceled state, so a transition is shown from a
super-state named Active to the state Cancel. By contrast, the state
Dispatching can only transition to the Delivered state, so we show an arrow
only from the Dispatching state to the Delivered state.
Copyright
IUM WMS 334
47
Activity Diagrams
Activity diagrams describe the workflow behavior of a system. Activity
diagrams are similar to state diagrams because activities are the state of
doing something. The diagrams describe the state of activities by showing
the sequence of activities performed. Activity diagrams can show activities
that are conditional or parallel.
When to Use: Activity Diagrams

Activity diagrams should be used in conjunction with other modeling
techniques such as interaction diagrams and state diagrams. The main
reason to use activity diagrams is to model the workflow behind the system
being designed. Activity Diagrams are also useful for: analyzing a use case
by describing what actions need to take place and when they should
occur; describing a complicated sequential algorithm; and modeling
applications with parallel processes.
However, activity diagrams should not take the place of interaction diagrams
and state diagrams. Activity diagrams do not give detail about how objects
behave or how objects collaborate.
How to Draw: Activity Diagrams

Copyright
IUM WMS 334
48
Activity diagrams show the flow of activities through the system. Diagrams
are read from top to bottom and have branches and forks to describe
conditions and parallel activities. A fork is used when multiple activities are
occurring at the same time. The diagram below shows a fork after activity1.
This indicates that both activity2 and activity3 are occurring at the same
time. After activity2 there is a branch. The branch describes what activities
will take place based on a set of conditions. All branches at some point are
followed by a merge to indicate the end of the conditional behavior started
by that branch. After the merge all of the parallel activities must be
combined by a join before transitioning into the final activity state.
Copyright
IUM WMS 334
49
Below is a possible activity diagram for processing an order. The diagram

shows the flow of actions in the system's workflow. Once the order is
received the activities split into two parallel sets of activities. One side fills
and sends the order while the other handles the billing. On the Fill Order
side, the method of delivery is decided conditionally. Depending on the
condition either the Overnight Delivery activity or the Regular Delivery
activity is performed. Finally the parallel activities combine to close the
order.
Physical Diagrams
Copyright
IUM WMS 334
50
There are two types of physical diagrams: deployment diagrams and

component diagrams. Deployment diagrams show the physical
relationship between hardware and software in a system. Component
diagrams show the software components of a system and how they are
related to each other. These relationships are called dependencies. 1
When to Use: Physical Diagrams
Physical diagrams are used when development of the system is complete.
Physical diagrams are used to give descriptions of the physical information
about a system.
How to Draw: Physical Diagrams
Many times the deployment and component diagrams are combined into one
physical diagram. A combined deployment and component diagram
combines the features of both diagrams into one diagram.
The deployment diagram contains nodes and connections. A node usually
represents a piece of hardware in the system. A connection depicts the
communication path used by the hardware to communicate and usually
indicates a method such as TCP/IP.
Copyright
IUM WMS 334
51
The component diagram contains components and dependencies.

Components represent the physical packaging of a module of code. The
dependencies between the components show how changes made to one
component may affect the other components in the system. Dependencies
in a component diagram are represented by a dashed line between two or
more components. Component diagrams can also show the interfaces used
by the components to communicate to each other.
The combined deployment and component diagram below gives a high level
physical description of the completed system. The diagram shows two nodes
which represent two machines communicating through TCP/IP. Component2
is dependant on component1, so changes to component 2 could affect
component1. The diagram also depicts component3 interfacing with
component1. This diagram gives the reader a quick overall view of the
entire system.
Copyright
IUM WMS 334
52
Activity 2
- What are the different diagrams used in UML
Activity
Copyright
IUM WMS 334
53
Feedback Activity 2
Feedback
Use Case Diagram

Class Diagram
Sequence Diagram
Collaboration Diagram
State Diagram
Activity Diagram
Physical Diagrams
Component Diagram
Deployment Diagram
Unified Modelling Language

UML diagrams
Key Words/Terms
Copyright
IUM WMS 334
54
3. Object-oriented Design
The objective of this chapter is to introduce an approach to software design
where the design is structured as interacting objects. When you have read
this chapter, you will:
Objectives
Chapter 3
understand how a software design may be
represented as a set of interacting objects that
manage their own state and operations,
know the most important activities in a general
object-oriented design process,
understand different models that may be used to
document an object oriented design ,
have been introduced to the representation of these
models in the Unified Modeling Language (UML).
Object-oriented design is a design strategy where system designers think in

terms of things instead of operations or functions. The executing system is
made up of interacting objects that maintain their own local state and
provide operations on that state information (Figure 3.1). They hide
information about the representation of the state and hence limit access to
it. An object-oriented design process involves designing the object classes
and the relationships between these classes. When the design is realised as
an executing program, the required objects are created dynamically using
the class definitions.
Object-oriented design is part of object-oriented development where an
object-oriented strategy is used throughout the development process:
Object-oriented analysis is concerned with developing an objectoriented model of the application domain. The identified objects reflect
entities and operations that are associated with the problem to be
solved.
Object-oriented design is concerned with developing an object-oriented
model of a software system to implement the identified requirements.
The objects in an object-oriented design are related to the solution to
the problem that is being solved. There may be close relationships
between some problem objects and some solution objects but the
Copyright
IUM WMS 334
55
designer inevitably has to add new objects and to transform problem

objects to implement the solution.
Object-oriented programming is concerned with realising a software
design using an object-oriented programming language. An objectoriented programming language, such as Java, supports the direct
implementation of objects and provides facilities to define object
classes.
The transition between these stages of development should be a seamless

one with the same notation used at each stage. Moving to the next stage
involves refining the previous stage by adding detail to existing object
classes and devising new classes to provide additional functionality. As
information is concealed within objects, detailed design decisions about the
representation of data can be delayed until the system is implemented. In
some cases, decisions on the distribution of objects and whether or not
objects can be sequential or concurrent may also be delayed. This means
that software designers are not constrained by details of the system
implementation. They can devise designs that can be adapted to different
execution environments.
Object-oriented systems should be maintainable as the objects are
independent. They may be understood and modified as stand-alone entities.
Changing the implementation of an object or adding services should not
affect other system objects. Because objects are associated with things,
there is often a clear mapping between real-world entities (such as hardware
components) and their controlling objects in the system. This improves the
understandability and hence the maintainability of the design.
Objects are potentially reusable components because they are independent
encapsulations of state and operations. Designs can be developed using
objects that have been created in previous designs. This reduces design,
programming and validation costs. It may also lead to the use of standard
objects (hence improving design understandability) and reduces the risks
involved in software development.
Copyright
IUM WMS 334
56
Figure 3.1 A system made up of interacting objects
3.1 Objects and object classes

The terms object and object-oriented are now widely used. They are
applied to different types of entity, design methods, systems and
programming languages. However, there is a general acceptance that an
object is an encapsulation of information and this is reflected in my definition
of an object and an object class:
An object is an entity that has a state and a defined set of operations which
operate on that state. The state is represented as a set of object attributes.
The operations associated with the object provide services to other objects
(clients) which request these services when some computation is required.
Objects are created according to an object class definition. An object class
definition serves as a template for creating objects. It includes declarations
of all the attributes and operations which should be associated with an object
of that class.
The notation that I use here for object classes is that defined in the UML. An
object class is represented as a named rectangle with two sections. The
object attributes are listed in the top section. The operations that are
associated with the object are set out in the bottom section. Figure 3.2
Copyright
IUM WMS 334
57
illustrates this notation using an object class which models an employee in

an organisation. In the UML, the term operation is the specification of an
action; the term method is used to refer to the implementation of the
operation.
Figure 3.2 An employee object

The class Employee defines a number of attributes that hold information
about employees including their name and address, social security number,
tax code, etc. The ellipsis (...) indicates that there are more attributes
associated with the class that are not shown here. Operations associated
with the object are join (called when an employee joins the organisation),
leave (called when an employee leaves the organisation), retire (called when
the employee becomes a pensioner of the organisation) and changeDetails
(called when some employee information needs to be modified).
Objects communicate by requesting services (calling methods) from other
objects and, if necessary, by exchanging the information required for service
provision. The copies of information needed to execute the service and the
results of service execution are passed as parameters. Some examples of
this style of communication are:
// Call a method associated with a buffer object that returns the
next value
Copyright
IUM WMS 334
58
// in the buffer
v = circularBuffer.Get () ;
// Call the method associated with a thermostat object that sets
the
// temperature to be maintained
thermostat.setTemp (20) ;
In some distributed systems, object communications are implemented
directly as text messages which objects exchange. The receiving object
parses the message, identifies the service and the associated data and
carries out the requested service. However, when the objects co-exist in the
same program, method calls are implemented in the same way as procedure
or function calls in a language such as C or Ada.
When service requests are implemented in this way, communication
between objects is synchronous. That is, the calling object waits for the
service request to be completed. However, if objects are implemented as
concurrent processes or threads the object communication may be
asynchronous. The calling object may continue in operation while the
requested service is executing. I explain how objects may be implemented as
concurrent processes later in this section.
Copyright
IUM WMS 334
59
Figure 3.3 A Generalization hierarchy

Object classes can be arranged in a generalisation or inheritance hierarchy
that shows the relationship between general and more specific object
classes. The more specific object class is completely consistent with the
general object class but includes further information. In the UML,
generalisation is indicated by an arrow that points to the parent class. In
object-oriented programming languages, generalisation is usually
implemented using the inheritance mechanism. The child class inherits
attributes and operations from the parent class.
Figure 3.3 shows an example of such a hierarchy where different classes of
employee are shown. Classes lower down the hierarchy have the same
attributes and operations as their parent classes but may add new attributes
and operations or modify some of those from their parent classes. This
means that there is one-way interchangeability. If the name of a parent class
is used in a model, this means that the object in the system may either be
defined as that class or of any of its descendants.
The class Manager in Figure 3.3 has all of the attributes and operations of the
class Employee but has, in addition, two new attributes that record the
Copyright
IUM WMS 334
60
budgets controlled by the manager and the date that the manager was
appointed to a particular management role. Similarly, the class Programmer
adds new attributes that define the project that the programmer is working
on and the programming language skills that they have. Objects of class
Manager or Programmer may therefore be used anywhere where an object of
class Employee is required.
Objects that are members of an object class participate in relationships with
other objects. These relationships may be modelled by describing the
associations between the object classes. In the UML, associations are
denoted by a line between the object classes that may optionally be
annotated with information about the association. This is illustrated in Figure
3.4 which shows the association between objects of class Employee and
objects of class Department and between objects of class Employee and
objects of class Manager. Association is a very general relationship and is
often used in the UML to indicate that either an attribute of an object is an
associated object or the implementation of an object method relies on the
associated object. However, in principle at least, any kind of association is
possible. One of the most common associations is aggregation which
illustrates how objects may be composed of other objects.
Figure 3.4 An association model

3.1.1 Concurrent objects
Conceptually, an object requests a service from another object by sending a
service request message to that object. There is no requirement for serial
execution where one object waits for completion of a requested service.
Consequently, the general model of object interaction allows objects to
Copyright
IUM WMS 334
61
execute concurrently as parallel processes. These objects may execute on

the same computer or as distributed objects on different machines.
In practice, most object-oriented programming languages have as their
default a serial execution model where requests for object services are
implemented in the same way as function calls. Therefore, when an object
called theList is created from a normal object class, you write in Java:
theList.append (17)
This calls the append method associated with theList object to add the
element 17 to theList and execution of the calling object is suspended until
the append operation has been completed. However, Java includes a very
simple mechanism (threads) that lets you create objects that execute
concurrently. It is therefore easy to take an object-oriented design and
produce an implementation where the objects are concurrent processes.
There are two kinds of concurrent object implementation:
1. Servers where the object is realised as a parallel process with methods
corresponding to the defined object operations. Methods start up in
response to an external message and may execute in parallel with
methods associated with other objects. When they have completed
their operation, the object suspends itself and waits for further
requests for service.
2. Active objects where the state of the object may be changed by
internal operations executing within the object itself. The process
representing the object continually executes these operations so never
suspends itself.
Copyright
IUM WMS 334
62
Figure 3.5 Implementation of an active object using Java threads

Servers are most useful in a distributed environment where the calling object
and the called object execute on different computers. The response time for
the service that is requested is unpredictable so, wherever possible, you
should design the system so that the object that has requested a service
does not have to wait for that service to be completed. They can also be
used in a single machine where a service takes some time to complete (e.g.
printing a document) and the service may be requested by several different
objects.
Active objects are used when an object needs to update its own state at
specified intervals. This is common in real-time systems where objects are
associated with hardware devices that collect information about the systems
environment. The objects methods allow other objects access to the state
information.
Copyright
IUM WMS 334
63
Figure 3.5 shows how an active object may be defined and implemented in
Java. This object class represents a transponder on an aircraft. The
transponder keeps track of the aircrafts position using a satellite navigation
system. It can respond to messages from air traffic control computers. It
provides the current aircraft position in response to a request to the
givePosition method.
This object is implemented as a thread where a continuous loop in the run
method includes code to compute the aircrafts position using signals from
satellites. Threads are created in Java by using the built-in Thread class as a
parent class in a class declaration. Threads must include a method called run
and this is started by the Java run-time system when objects that are defined
as threads are created. This is shown in Figure 3.5.
Copyright
IUM WMS 334
64
3.2 An object-oriented design process

In this section, we illustrate the process of object-oriented design by
developing an example design for the control software that is embedded in
an automated weather station. As I discussed in the introduction, there are
several methods of object oriented design with no definitive best method or
design process. The process that we cover here is a general one that
incorporates activities that are common to most OOD processes. In this
respect, it is comparable to the proposed UML process (Rumbaugh, Jacobson
et al., 1999) but we have significantly simplified this process for presentation
here. The general process that we use here for object-oriented design has a
number of stages:
1.
2.
3.
4.
5.
Understand and define the context and the modes of use of the system
Design the system architecture
Identify the principal objects in the system
Develop design models
Specify object interfaces
We have deliberately not illustrated this as a simple process diagram as that

would imply that there was a neat sequence of activities in this process. In
fact, all of the above activities can be thought of as inter-leaved activities
that influence each other. Objects are identified and the interfaces fully or
partially specified as the architecture of the system is defined. As object
models are produced, these individual object definitions may be refined and
this may mean changes to the system architecture.
We discuss these as separate stages in the design process later in this
section. However, you should not assume from this that design is a simple,
well-structured process. In reality, you develop a design by proposing
solutions and refining these solutions as information becomes available. You
inevitably have to backtrack and retry when problems arise. Sometimes you
explore options in detail to see if they work; at other times you ignore details
until late in the process.
We illustrate these process activities by developing an example of an object
oriented design. The example that I use to illustrate object-oriented design is
part of a system for creating weather maps using automatically collected
meteorological data. The detailed requirements for such a weather mapping
Copyright
IUM WMS 334
65
system would take up many pages. However, an overall system architecture

can be developed from a relatively brief system description:
A weather mapping system is required to generate weather maps on a
regular basis using data collected from remote, unattended weather stations
and other data sources such as weather observers, balloons and satellites.
Weather stations transmit their data to the area computer in response to a
request from that machine.
The area computer system validates the collected data and integrates the
data from different sources. The integrated data is archived and, using data
from this archive and a digitised map database, a set of local weather maps
is created. Maps may be printed for distribution on a special-purpose map
printer or may be displayed in a number of different formats.
This description shows that part of the overall system is concerned with
collecting data, part with integrating the data from different sources, part
with archiving that data and part with creating weather maps. Figure 2.6
illustrates a possible system architecture that can be derived from this
description. This is a layered architecture that reflects the different stages of
processing in the system namely data collection, data integration, data
archiving and map generation. A layered architecture is appropriate in this
case because each stage only relies on the processing of the previous stage
for its operation.
Copyright
IUM WMS 334
66
Figure 3.6
Layered architecture for weather mapping system
In Figure 3.6, We have shown the different layers and have included the layer
name in a UML package symbol that has been denoted as a subsystem. A
UML package represents a collection of objects and other packages. I have
used it here to show that each layer includes a number of other components.
In Figure 3.7 We have expanded on this abstract architectural model by
showing that the components of the subsystems. Again, these are very
abstract and they have been derived from the information in the description
of the system. I continue the design example by focusing on the weather
station subsystem that is part of the data collection layer.
Copyright
IUM WMS 334
67
3.1 System context and models of use

The first stage in any software design process is to develop an understanding
of the relationships between the software that is being designed and its
external environment. Developing this understanding helps you decide how
to provide the required system functionality and how to structure the system
so that it can communicate effectively with its environment.
Figure 3.7 Subsystems in the weather mapping system

The system context and the model of system use represent two
complementary models of the relationships between a system and its
environment:
1. The system context is a static model that describes the other systems
in that environment.
2. The model of the system use is a dynamic model that describes how
the system actually interacts with its environment.
The context model of a system may be represented using associations
where, essentially, a simple block diagram of the overall system architecture
is produced. This can be expanded by representing a subsystem model using
UML packages as shown in Figure 3.7. This illustrates that the context of the
Copyright
IUM WMS 334
68
weather station system is within a subsystem concerned with data collection.

It also shows other subsystems that make up the weather mapping system.
Figure 3.8 Use cases for the weather station
System Weather station
Use-case Report
Actors Weather data collection system, Weather station
Data The weather station sends a summary of the weather data that
has been collected from the instruments in the collection period to the
weather data collection system. The data sent are the maximum
minimum and average ground and air temperatures, the maximum,
minimum and average air pressures, the maximum, minimum and
average wind speeds, the total rainfall and the wind direction as
sampled at 5 minute intervals.
Stimulus The weather data collection system establishes a modem

link with the weather station and requests transmission of the data.
Response The summarised data is sent to the weather data collection

system
Copyright
IUM WMS 334
69
Comments Weather stations are usually asked to report once per hour
but this frequency may differ from one station to the other and may be
modified in future.
Copyright
IUM WMS 334
70
When you model the interactions of a system with its environment you
should use an abstract approach that does not include too much detail of
these interactions. The approach that is proposed in the UML is to develop a
use-case model where each use-case represents an interaction with the
system. In use-case models, each possible interaction is named in an ellipse
and the external entity involved in the interaction is represented by a stick
figure. In the case of the weather station system, this external entity is not a
human but the data processing system for the weather data.
A use-case model for the weather station is shown in Figure 3.8. This shows
that weather station interacts with external entities for startup and
shutdown, for reporting the weather data that has been collected and for
instrument testing and calibration. Each of these use cases can be described
using a simple natural language description. This helps designers identify
objects in the system and gives them an understanding of what the system
is intended to do. We use a stylised form of this description that clearly
identifies what information is exchanged, how the interaction is initiated etc.
you can use any technique for describing use-cases so long as the is short
and easily understandable. You need to develop descriptions for each of the
use-cases that are shown in the model.
The use-case description helps to identify objects and operations in the
system. From the description of the Report use-case, it is obvious that
objects representing the instruments that collect weather data will be
required as will an object representing the summary of the weather data.
Operations to request weather data and to send weather data are required.
3.2 Architectural design
Once the interactions between the software system that is being designed
and the systems environment have been defined, you can then use this
information as a basis for designing the system architecture. Of course, you
need to combine this with your general knowledge of principles of
architectural design and with more detailed domain knowledge.
Copyright
IUM WMS 334
71
Figure 3.10 The weather station architecture

The automated weather station is a relatively simple system and its
architecture can again be represented as a layered model. We have
illustrated this in Figure 3.10 as three UML packages within the more general
Weather station package. Notice how I have used UML annotations (text in
boxes with a folded corner) to provide additional information here.
The three layers in the weather station software are:
1. The interface layer which is concerned with all communications with
other parts of the system and with providing the external interfaces of
the system.
2. The data collection layer which is concerned with managing the
collection of data from the instruments and with summarising the
weather data before transmission to the mapping system.
3. The instruments layer which is an encapsulation of all of the
instruments that are used to collect raw data about the weather
conditions.
In general, you should try and decompose a system so that architectures are
as simple as possible. A good rule of thumb is that there should not be more
than seven fundamental entities included in an architectural model. Each of
Copyright
IUM WMS 334
72
these entities can be described separately but, of course, you may choose to
reveal the structure of the entities as I have done in Figure 3.7.
Object identification
By this stage in the design process, you will already have formulated some
ideas about the essential objects in the system that you are designing. In the
weather station system, it is clear that the instruments are objects and you
need at least one object at each of the architectural levels. This reflects a
general principle that objects tend to emerge during the design process.
However, you usually also have to look for and document other objects that
may be relevant.
Although I have headed this section object identification, in practice this
process is actually concerned with identifying object classes. The design is
described in terms of these classes. Inevitably, you have to refine the object
classes that you initially identify and revisit this stage of the process as you
develop a deeper understanding of the design. There have been various
proposals made about how to identify objects classes:
1. Use a grammatical analysis of a natural language description of a
system. Objects and attributes are nouns, operations or services are
verbs. (Abbott, 1983). This approach has been embodied in the HOOD
method for object-oriented design (Robinson, 1992) that has been
widely used in the European aerospace industry.
2. Use tangible entities (things) in the application domain such as aircraft,
roles such as manager, events such as request, interactions such as
meetings, locations such as offices, organisational units such as
companies, etc. (Shlaer and Mellor, 1988; Coad and Yourdon, 1990;
Wirfs-Brock, Wilkerson et al., 1990).Support this by identifying storage
structures (abstract data structures) in the solution domain that might
be required to support these objects.
3. Use a behavioural approach where the designer first understands the
overall behaviour of the system. The various behaviours are assigned
to different parts of the system and an understanding is derived of who
initiates and participates in these behaviours. Participants who play
significant roles are recognised as objects (Rubin and Goldberg, 1992).
4. Use a scenario-based analysis where various scenarios of system use
are identified and analysed in turn. As each scenario is analysed, the
Copyright
IUM WMS 334
73
team responsible for the analysis must identify the required objects,
attributes and operations. A method of analysis called CRC cards where
analysts and designers take on the role of objects is effective in
supporting this scenario based approach (Beck and Cunningham,
1989).
These approaches help you get started with object identification. In practice,
many different sources of knowledge have to be used to discover objects and
object classes. Objects and operations that are initially identified from the
informal system description can be a starting point for the design. Further
information from application domain knowledge or scenario analysis may
then be used to refine and extend the initial objects. This information may be
collected from requirements documents, from discussions with users and
from an analysis of existing systems.
I have used a hybrid approach here to identify the weather station objects. I
dont have space to describe all the objects but I have shown five object
classes in Figure 3.11. The Ground thermometer, Anemometer and
Barometer represent application domain objects and the WeatherStation and
WeatherData objects have been identified from the system description and
the scenario (use-case) description. These objects are related to the different
levels in the system architecture.
1. The WeatherStation object class provides the basic interface of the
weather station with its environment. Its operations therefore reflect
the interactions shown in Figure 3.8. In this case, I use a single object
class to encapsulate all of these interactions but, in other designs, it
may be more appropriate to use several classes to provide the system
interface.
2. The WeatherData object class encapsulates the summarised data from
the different instruments in the weather station. Its associated
operations are concerned with collecting and summarising the data
that is required.
3. The GroundThermometer, Anemometer and Barometer object classes
are directly related to instruments in the system. They reflect tangible
hardware entities in the system and the operations are concerned with
controlling that hardware.
Copyright
IUM WMS 334
74
Figure 3.11 Examples of object classes in the weather station system

At this stage in the design process, knowledge of the application domain may
be used to identify further objects and services. In this case, we know that
weather stations are often located in remote places. They include various
instruments which sometimes go wrong. Instrument failures should be
reported automatically. This implies that attributes and operations to check
the correct functioning of the instruments are necessary. Obviously, there are
many remote weather stations. You therefore need some way of identifying
the data collected from each station so each weather station should have its
own identifier.
We have decided not to make the objects associated with each instrument
active objects. The collect operation in WeatherData calls on instrument
objects to make readings when required. Active objects includes their own
control and, in this case, it would mean that each instrument would decide
when to make readings. However, the disadvantage of this is that, if a
decision was made to change the timing of the data collection or if different
weather stations collected data differently then new object classes would
have to be introduced. By making the instrument objects make readings on
request, any changes to collection strategy can be easily implemented
without changing the objects associated with the instruments.
Copyright
IUM WMS 334
75
3.4 Design models

Design models show the objects or object classes in a system and, where
appropriate, different kinds of relationships between these entities. Design
models essentially are the design. They are the bridge between the
requirements for the system and the system implementation. This means
that there are conflicting requirements on these models. They have to be
abstract so that unnecessary detail doesnt hide the relationships between
them and the system requirements. However, they also have to include
enough detail for programmers to make implementation decisions.
In general, you get round this conflict by developing different models at
different levels of detail. Where there are close links between requirements
engineers, designers and programmers then abstract models may be all that
are required. Specific design decisions may be made as the system is
implemented. When the links between system specifiers, designers and
programmers are indirect (e.g. where a system is being designed in one part
of an organisation but implemented elsewhere) then more detailed models
may be required.
An important step in the design process, therefore, is to decide which design
models that you need and the level of detail of these models. This also
depends on the type of system that is being developed. A sequential data
processing system will be designed in a different way from an embedded
real-time system and different design models will therefore be used. There
are very few systems where all models are necessary and minimising the
number of models that are produced reduces the costs of the design and the
time required to complete the design process.
There are two types of design models that should normally be produced to
describe an object-oriented design. These are:
1. Static models that describe the static structure of the system in terms
of the system object classes and their relationships. Important
relationships that may be documented at this stage are generalisation
relationships, uses/usedby relationships and composition relationships.
2. Dynamic models that describe the dynamic structure of the system
and that show the interactions between the system objects (not the
object classes). Interactions that may be documented include the
sequence of service requests made by objects and the way in which
the state of the system is related to these object interactions.
Copyright
IUM WMS 334
76
The UML provides for a large number of possible static and dynamic models
that may be produced to document a design. Booch et al. (Booch, Rumbaugh
et al., 1999) propose 9 different types of diagram to represent these models.
I dont have space to go into all of these and not all are appropriate for the
weather station example. The models that I will discuss in this section are:
1. Subsystem models that show logical groupings of objects into coherent
subsystems. These are represented using a form of class diagram
where each subsystem is shown as a package. Subsystem models are
static models.
2. Sequence models that show the sequence of object interactions. These
are represented using a UML sequence or a collaboration diagram.
Sequence models are dynamic models.
Figure 3.12 Weather station packages

Copyright
IUM WMS 334
77
State machine models that show how individual objects change their state in
response to events. These are represented in the UML using statechart
diagrams. State machine models are dynamic models.
We have already discussed other types of model that may be developed
earlier in this chapter and in other chapters. Use-case models show
interactions with the system, object models describe the object classes,
generalisation or inheritance models show how classes may be
generalizations of other classes and aggregation models show how
collections of objects are related.
A subsystem model is, in my view, one of the most helpful static models as it
shows how the design may be organised into logically related groups of
objects. We have already seen examples of this type of model that showed
the subsystems in the weather mapping system. In the UML packages are
encapsulation constructs and do not reflect directly on entities in the system
that is developed. However, they may be reflected in structuring constructs
such as Java libraries.
Figure 3.12 shows the objects in the subsystems in the weather station. I also
show some associations in this model. For example, the CommsController
object is associated with the WeatherStation object and the WeatherStation
object is associated with the Data collection package. This means that this
object is associated with one or more objects in this package. A package
model plus an object class model should describe the logical groupings in the
system.
Copyright
IUM WMS 334
78
Figure 3.13 Sequence of operations data collection

One of the most useful and understandable dynamic models that may be
produced is a sequence model that documents, for each mode of interaction,
the sequence of object interactions that take place. In a sequence model:
1. The objects involved in the interaction are arranged horizontally with a
vertical line linked to each object.
2. Time is represented vertically so that time progresses down the dashed
vertical lines. Therefore, the sequence of operations can be read easily
from the model.
3. Interactions between objects are represented by labelled arrows linking
the vertical lines. These are not data flows but represent messages or
events that are fundamental to the interaction.
4. The thin rectangle on the object lifeline represents the time when the
object is the controlling object in the system. An object takes over
control at the top of this rectangle and relinquishes control to another
object at the bottom of the rectangle. If there is a hierarchy of calls,
control is not relinquished until the last return to the initial method call
has been completed.
Copyright
IUM WMS 334
79
This is illustrated in Figure 3.13 that shows the sequence of interactions

when the external mapping system requests the data from the weather
station. This diagram may be read as follows:
1. An object that is an instance of CommsController (:CommsController)
receives a request from its environment to send a weather report. It
acknowledges receipt of this request. The half-arrowhead indicates that
the message sender does not expect a reply.
2. This object sends a message to an object that is an instance of
WeatherStation to create a weather report. The instance of
CommsController then suspends itself (its control box ends). The style
of arrowhead used indicates that the CommsController object instance
and the WeatherStation object instance are objects that may execute
concurrently.
3. The object that is an instance of WeatherStation sends a message to a
WeatherData object to summarise the weather data. In this case, the
different style of arrowhead used indicates that the instance of
WeatherStation waits for a reply.
4. This summary is computed and control returns to the WeatherStation
object. The dotted arrow indicates a return of control.
5. This object sends a message to CommsController requesting it to
transfer the data to the remote system. The WeatherStation object
then suspends itself.
6. The CommsController object sends the summarised data to the remote
system, receives an acknowledgement and then suspends itself
waiting for the next request.
From the sequence diagram we can see that the CommsController object and
the WeatherStation object are actually concurrent processes where execution
can be suspended and resumed. Essentially, the CommsController object
instance listens for messages from the external system, decodes these
messages and initiates weather station operations.
When documenting a design, you should produce a sequence diagram for
each significant interaction. If you have developed a use-case model then
there should be a sequence diagram for each use-case that you have
identified.
Sequence diagrams are used to model the combined behaviour of a group of
objects but you may also want to summarise the behaviour of a single object
Copyright
IUM WMS 334
80
in response to the different messages that it can process. To do this, you can
use a state machine model that shows how the object instance changes
state depending on the messages that it receives. The UML uses statecharts,
initially invented by Harel (Harel, 1987) to describe state machine models.
Figure 3.14 is a statechart for the WeatherStation object that shows how it
responds to requests for various services. You can read this diagram as
follows:
1. If the object state is Shutdown then it can only respond to a startup ()
message. It then moves into a state where it is waiting for further
messages. The unlabelled arrow with the black blob indicates that the
Shutdown state is the initial state.
2. In the Waiting state, the system expects further messages. If a
shutdown () message is received, the object returns to the shutdown
state.
3. If a reportWeather () message is received, the system moves to a
summarising state then, when the summary is complete, to a
transmitting state where the information is transmitted through the
CommsController. It then returns to a waiting state.
If a calibrate () message is received, the system moves to a calibrating state
then a testing state then a transmitting state before returning to the waiting
state. If a test () message is received, the system moves directly to the
testing state.
Copyright
IUM WMS 334
81
Figure 3.14 State diagram for WeatherStation

1. If a signal from the clock is received, the system moves to a collecting
state where it is collecting data from the instruments. Each instrument
is instructed in turn to collect its data.
It is not usually necessary to produce a statechart for all of the objects that
you have defined. Many of the objects in a system are relatively simple
objects and a state machine model would not help implementors to
understand these objects.
3.5 Object interface specification

An important part of any design process is the specification of the interfaces
between the different components in the design. You need to specify
interfaces so that objects and other components can be designed in parallel.
Once an interface has been specified, the developers of other objects may
assume that interface will be implemented.
Copyright
IUM WMS 334
82
Designers should avoid interface representation information in their interface

design. Rather the representation should be hidden and object operations
provided to access and update the data. If the representation is hidden, it
can be changed without affecting the objects that use these attributes. This
leads to a design which is inherently more maintainable. For example, an
array representation of a stack may be changed to a list representation
without affecting other objects which use the stack. By contrast, it often
makes sense to expose the attributes in a static design model as this is the
most compact way of illustrating essential characteristics of the objects.
There is not necessarily a simple 1:1 relationship between objects and
interfaces. The same object may have several interfaces that are each
viewpoints on the methods that it provides. This is supported directly in Java
where interfaces are declared separately from objects and objects
implement interfaces. Equally, a group of objects may all be accessed
through a single interface.
Figure 3.15 Java description of weather station interface

Object interface design is concerned with specifying the detail of the
interface to an object or to a group of objects. This means defining the
signatures and semantics of the services that are provided by the object or
by a group of objects. Interfaces can be specified in the UML using the same
Copyright
IUM WMS 334
83
notation as in a class diagram. However, there is no attribute section and the

UML stereotype <<interface>> should be included in the name part.
An alternative approach that I prefer is to use a programming language to
define the interface. This is illustrated in Figure 3.15 that shows the interface
specification in Java of the weather station. As interfaces become more
complex, this approach becomes more effective because the syntax
checking facilities in the compiler may be used to discover errors and
inconsistencies in the interface description. The Java description can show
that some methods can take different numbers of parameters. Therefore, the
shutdown method can either be applied to the station as a whole if it has no
parameters or can shutdown a single instrument.
3.3 Design evolution

An important advantage of an object-oriented approach to design is that it
simplifies the problem of making changes to the design. The reason for this
is that object state representation does not influence the design. Changing
the internal details of an object is unlikely to affect any other system objects.
Furthermore, because objects are loosely coupled, it is usually
straightforward to introduce new objects without significant effects on the
rest of the system.
To illustrate the robustness of the object-oriented approach, assume that
pollution monitoring capabilities are to be added to each weather station.
This involves adding an air quality meter to compute the amount of various
pollutants in the atmosphere. The pollution readings are transmitted at the
same time as the weather data. To modify the design, the following changes
must be made:
1. An object class called Air quality should be introduced as part of
WeatherStation at the same level as WeatherData.
2. An operation reportAirQuality should be added to Weather Station to
send the pollution information to the central computer. The weather
station control software must be modified so that pollution readings
are automatically collected when requested by the top level
WeatherStation object.
Copyright
IUM WMS 334
84
3. Objects representing the types of pollution monitoring instruments

should be added. In this case, levels of nitrous oxide, smoke and
benzene can be measured.
Figure 3.16 New objects to support pollution monitoring

Figure 3.16 shows Weather station and the new objects added to the system.
Apart from at the highest level of the system (WeatherStation) no software
changes are required in the original objects in the weather station. The
addition of pollution data collection does not affect weather data collection in
any way.
Copyright
IUM WMS 334
85
Activity 3
- Draw a diagram to show an Association model
Activity
Feedback Activity 3
Refer to Figure 3.4
Feedback
KEY POINTS
Object-oriented design is a means of designing software so that the

fundamental components in the design represent objects with their
own private state and operations rather than functions.
An object should have constructor and inspection operations allowing
its state to be inspected and modified. The object provides services
(operations using state information) to other objects. Objects are
created at run-time using a specification in an object class definition.
Objects may be implemented sequentially or concurrently. A
concurrent object may be a passive object whose state is only changed
through its interface or an active object that can change its own state
without outside intervention.
The Unified Modeling Language (UML) has been designed to provide a
range of different notations that can be used to document an objectoriented design.
The process of object-oriented design includes activities to design the
system architecture, identify objects in the system, describe the design
using different object models and document the object interfaces.
A range of different models may be produced during an object-oriented
design process. These include static models (class models,
generalisation models, association models) and dynamic models
(sequence models, state machine models)
Copyright
IUM WMS 334
86
Object interfaces must be defined precisely so that they can be used

by other objects. A programming language such as Java may be used
to document object interfaces.
An important advantage of object-oriented design is that it simplifies
the evolution of the system.
Object Oriented Analysis

Object Oriented Design
Object Oriented Programming
Key Words/Terms
Copyright
IUM WMS 334
87
4.
Rapid Prototyping
Objectives
Chapter 4
- To describe the use of prototypes in different types
of development project
- To discuss evolutionary and throw-away
prototyping
- To introduce three rapid prototyping techniques high-level language development, database
programming and component reuse
- To explain the need for user interface prototyping
The Topics covered in this chapter include, Prototyping in the software

process, Prototyping techniques, User interface prototyping.
System prototyping
Prototyping is the rapid development of a system. In the past, the developed
system was normally thought of as inferior in some way to the required
system so further development was required. Now, the boundary between
prototyping and normal system development is blurred and many systems
are developed using an evolutionary approach
Uses of system prototypes
The principal use is to help customers and developers understand the
requirements for the system
Requirements elicitation. Users can experiment with a prototype to see
how the system supports their work
Requirements validation. The prototype can reveal errors and
omissions in the requirements
Prototyping can be considered as a risk reduction activity which reduces
requirements risks
Prototyping benefits
Copyright
IUM WMS 334
88
Misunderstandings between software users and developers are exposed.

Missing services may be detected and confusing services may be identified.
A working system is available early in the process. The prototype may serve
as a basis for deriving a system specification The system can support user
training and system testing
Prototyping process
Prototyping in the software process

Evolutionary prototyping
An approach to system development where an initial prototype is
produced and refined through a number of stages to the final system
Throw-away prototyping
A prototype which is usually a practical implementation of the system
is produced to help discover requirements problems and then
discarded. The system is then developed using some other
development process
Prototyping objectives
Copyright
IUM WMS 334
89
The objective of evolutionary prototyping is to deliver a working system to

end-users. The development starts with those requirements which are best
understood.
The objective of throw-away prototyping is to validate or derive the system
requirements. The prototyping process starts with those requirements which
are poorly understood
Approaches to prototyping
Evolutionary prototyping must be used for systems where the specification

cannot be developed in advance e.g. AI systems and user interface systems.
It must be based on techniques which allow rapid system iterations.
Verification is impossible as there is no specification. Validation means
demonstrating the adequacy of the system.
Copyright
IUM WMS 334
90
Evolutionary prototyping advantages
Accelerated delivery of the system - Rapid delivery and deployment

are sometimes more important than functionality or long-term software
maintainability
User engagement with the system - Not only is the system more likely
to meet user requirements, they are more likely to commit to the use
of the system
Specification, design and implementation are inter-twined

The system is developed as a series of increments that are delivered to
the customer
Techniques for rapid system development are used such as CASE tools
and 4GLs
User interfaces are usually developed using a GUI development toolkit
Evolutionary prototyping problems
Management problems - Existing management processes assume a

waterfall model of development and Specialist skills are required which
may not be available in all development teams
Copyright
IUM WMS 334
91
Maintenance problems - Continual change tends to corrupt system

structure so long-term maintenance is expensive
Contractual problems
Prototypes as specifications
Some parts of the requirements (e.g. safetycritical functions) may be

impossible to prototype and so dont appear in the specification
An implementation has no legal standing as a contract
Non-functional requirements cannot be adequately tested in a system
prototype
Incremental development
System is developed and delivered in increments after establishing an

overall architecture
Requirements and specifications for each increment may be developed
Users may experiment with delivered increments while others are
being developed. Therefore, these serve as a form of prototype system
Intended to combine some of the advantages of prototyping but with a
more manageable process and better system structure
Incremental development process
Copyright
IUM WMS 334
92
Used to reduce requirements risk

The prototype is developed from an initial specification, delivered for
experiment then discarded
The throw-away prototype should NOT be considered as a final system
Some system characteristics may have been left out
There is no specification for long-term maintenance
The system will be poorly structured and difficult to maintain
Copyright
IUM WMS 334
93
Prototype delivery
Developers may be pressurised to deliver a throwaway prototype as a final

system
This is not recommended
It may be impossible to tune the prototype to meet nonfunctional
requirements
The prototype is inevitably undocumented
The system structure will be degraded through changes made during
development
Normal organisational quality standards may not have been applied
Rapid prototyping techniques
Various techniques may be used for rapid development

Dynamic high-level language development
Database programming
Component and application assembly
These are not exclusive techniques - they are often used together
Visual programming is an inherent part of most prototype development
systems
Copyright
IUM WMS 334
94
Dynamic high-level languages
Languages which include powerful data management facilities

Need a large run-time support system. Not normally used for large
system development
Some languages offer excellent UI development facilities
Some languages have an integrated support environment whose
facilities may be used in the prototype
Prototyping languages
Language
Smalltalk
Java
Prolog
Lisp
Type
Object-oriented
Object-oriented
Logic
List-based
Application domain
Interactive systems
Interactive systems
Symbolic processing
Symbolic processing
Choice of prototyping language
What is the application domain of the problem?

What user interaction is required?
What support environment comes with the language?
Different parts of the system may be programmed in different
languages. However, there may be problems with language
communications
Database programming languages
Domain specific languages for business systems based around a

database management system
Normally include a database query language, a screen generator, a
report generator and a spreadsheet.
May be integrated with a CASE toolset
The language + environment is sometimes known as a fourthgeneration language (4GL)
Cost-effective for small to medium sized business systems
Copyright
IUM WMS 334
95
Database programming
Component and application assembly
Prototypes can be created quickly from a set of reusable components

plus some mechanism to glue these component together
The composition mechanism must include control facilities and a
mechanism for component communication
The system specification must take into account the availability and
functionality of existing components
Prototyping with reuse
Application level development

Entire application systems are integrated with the prototype so
that their functionality can be shared
For example, if text preparation is required, a standard word
processor can be used
Component level development
Individual components are integrated within a standard
framework to implement the system
Copyright
IUM WMS 334
96
Frame work can be a scripting language or an integration

framework such as CORBA
Reusable component composition
Copyright
IUM WMS 334
97
Compound documents
For some applications, a prototype can be created by developing a

compound document
This is a document with active elements (such as a spreadsheet) that
allow user computations
Each active element has an associated application which is invoked
when that element is selected
The document itself is the integrator for the different applications
Application linking in compound documents
Visual programming
Scripting languages such as Visual Basic support visual programming

where the prototype is developed by creating a user interface from
standard items and associating components with these items
Copyright
IUM WMS 334
98
A large library of components exists to support this type of

development
These may be tailored to suit the specific application requirements
Copyright
IUM WMS 334
99
Visual programming with reuse
Problems with visual development
Difficult to coordinate team-based development

No explicit system architecture
Complex dependencies between parts of the program can cause
maintainability problems
User interface prototyping
It is impossible to pre-specify the look and feel of a user interface in an

effective way. prototyping is essential
UI development consumes an increasing part of overall system
development costs
User interface generators may be used to draw the interface and
simulate its functionality with components associated with interface
entities
Web interfaces may be prototyped using a web site editor
Copyright
IUM WMS 334
100
Key points
A prototype can be used to give end-users a concrete impression of the

systems capabilities
Prototyping is becoming increasingly used for system development
where rapid development is essential
Throw-away prototyping is used to understand the system
requirements
In evolutionary prototyping, the system is developed by evolving an
initial version to the final version
A prototype can be used to give end-users a concrete impression of the
systems capabilities
Prototyping is becoming increasingly used for system development
where rapid development is essential
Throw-away prototyping is used to understand the system
requirements
In evolutionary prototyping, the system is developed by evolving an
initial version to the final version
Rapid development of prototypes is essential.
This may require leaving out functionality or relaxing non-functional
constraints
Prototyping techniques include the use of very high-level languages,
database programming and prototype construction from reusable
components
Prototyping is essential for parts of the system such as the user
interface which cannot be effectively pre-specified. Users must be
involved in prototype evaluation
Copyright
IUM WMS 334
101
Activity 4
- What is Evolutionary prototyping
- What is Throw-away prototyping
Activity
Feedback Activity 4
Feedback
- Evolutionary prototyping
An approach to system development where an initial
prototype is produced and refined through a number of
stages to the final system
- Throw-away prototyping
A prototype which is usually a practical implementation of
the system is produced to help discover requirements
problems and then discarded. The system is then
developed using some other development process
Copyright
IUM WMS 334
102
Visual programming
Scripting languages such as Visual Basic support visual programming

where the prototype is developed by creating a user interface from
standard items and associating components with these items
A large library of components exists to support this type of
development
These may be tailored to suit the specific application requirements
Visual programming with reuse
Problems with visual development
Difficult to coordinate team-based development

No explicit system architecture
Complex dependencies between parts of the program can cause
maintainability problems
Copyright
IUM WMS 334
103
User interface prototyping

It is impossible to pre-specify the look and feel of a user interface in an
effective way. Prototyping is essential UI development consumes an
increasing part of overall system development costs. User interface
generators may be used to draw the interface and simulate its functionality
with components associated with interface entities. Web interfaces may be
prototyped using a web site editor
Some Key points to note in User Interface design are that a prototype can be
used to give end-users a concrete impression of the systems capabilities.
Prototyping is becoming increasingly used for system development where
rapid development is essential. Throw-away prototyping is used to
understand the system requirements and In evolutionary prototyping, the
system is developed by evolving an initial version to the final version. Rapid
development of prototypes is essential and this may require leaving out
functionality or relaxing non-functional constraints.
Prototyping techniques include the use of very high-level languages,
database programming and prototype construction from reusable
components Prototyping is essential for parts of the system such as the user
interface which cannot be effectively pre-specified. Users must be involved in
prototype evaluation
Formal Specification
Techniques for the unambiguous specification of software
Objectives
To explain why formal specification techniques help discover problems
in system requirements
To describe the use of algebraic techniques for interface specification
To describe the use of model-based techniques for behavioural
specification
Formal methods
Formal specification is part of a more general collection of techniques
that are known as formal methods
Copyright
IUM WMS 334
104
These are all based on mathematical representation and analysis of

software
Formal methods include
Formal specification
Specification analysis and proof
Transformational development
Program verification
Acceptance of formal methods

Formal methods have not become mainstream software development
techniques as was once predicted Other software engineering techniques
have been successful at increasing system quality hence the need for formal
methods has been reduced. Market changes have made time-to-market
rather than software with a low error count the key factor. Formal methods
do not reduce time to market. The scope of formal methods is limited. They
are not well-suited to specifying and analysing user interfaces and user
interaction. Formal methods are hard to scale up to large systems.
Use of formal methods
Formal methods have limited practical applicability and their principal
benefits are in reducing the number of errors in systems so their main area
of applicability is critical systems. In this area, the use of formal methods is
most likely to be cost-effective.
Specification in the software process
Specification and design are inextricably intermingled and architectural
design is essential to structure a specification. Formal specifications are
expressed in a mathematical notation with precisely defined vocabulary,
syntax and semantics.
Specification and design
Copyright
IUM WMS 334
105
Specification in the software process
Specification techniques
Algebraic approach - The system is specified in terms of its operations

and their relationships
Model-based approach - The system is specified in terms of a state
model that is constructed using mathematical constructs such as sets
and sequences. Operations are defined by modifications to the
systems state
Use of formal specification

Copyright
IUM WMS 334
106
Formal specification involves investing more effort in the early phases

of software development
This reduces requirements errors as it forces a detailed analysis of the
requirements
Incompleteness and inconsistencies can be discovered and resolved
Hence, savings as made as the amount of rework due to requirements
problems is reduced
Development costs with formal specification
Interface specification
Large systems are decomposed into subsystems with well-defined

interfaces between these subsystems
Specification of subsystem interfaces allows independent development
of the different subsystems
Copyright
IUM WMS 334
107
Interfaces may be defined as abstract data types or object classes

The algebraic approach to formal specification is particularly wellsuited to interface specification
User Interface Proto-Typing

Visual Programming
Key Words/Terms
5. Visual Development Environments
Chapter 5
- Understand a visual development environment in
the development of software
Objectives
Software Components
In the last ten years, software components gained a significant role in the
software development process. Although several different specifications
(usually referred to as component models) of what a software component
actually is were introduced, the basic idea behind the scene is more or
less the same. The main idea of the component-oriented approach is
splitting the code of an application into several, well-formed pieces
(usually called components), with well defined functionality (usually called
specification) and with unified access points (usually called interfaces).
The application development process naturally benefits from this
approach in several different ways, which will be described in the next
section in detail. The most important examples include reusability,
Copyright
IUM WMS 334
108
interchangeability, and the possibility of distributed deployment of the

software components.
Hierarchical Composition
One of the main concepts that are intensively used by this work is the
hierarchical composition of software components. The basic idea behind
the hierarchical composition is to apply the same process that leads to
splitting an application into several components to the components itself,
thus creating subcomponents of a component, and by repeating this step
recursively. Although a significant amount of the traditional software
components call multiple count of other software components in order to
perform their functionality, it is usually done in a different way, on the
source code level.
In such cases, it seems to be more natural to see the multiple
components used as subcomponents composed into a single composed
component. Also, the component and its subcomponents should be
interconnected by the component framework based on the interfaces and
on the component description, rather than by performing functional calls
from a custom source code inside the components.
Using the concept of hierarchical composition, an application can be seen
as a composed component. Each of the subcomponents of a composed
component is either a composed component again, or a primitive
component, i.e. component containing a source code. In contrast, the
composed components do not contain any custom source code, the
component framework generates them based on the component
description. When the rule is applied recursively, the application becomes
an assembly tree of software components. The source code is contained
in the primitive components, leaves of this tree. The inner nodes of the
assembly tree represent the composed components, defining the way in
which the functionality of the primitive components will be combined.
Visual Development
The term visual development is mostly used for a development process
where some steps are performed in a different way than writing a textual
code; graphical diagrams, property sheets, and dialogs are the most
common examples of a visual environment offered for the development
Copyright
IUM WMS 334
109
purposes. The main reason for using visual development tools is to simplify
and speed-up the development process. The advantage of a visual
development tool, over writing a source code, is even more significant when
dealing with a complicated code, when using a large count of reference to
the other parts of the code, or when describing an entity that could be rather
imagined or represented visually.
As an example important for this thesis, the textual description of a
composed component (e.g. using the Component Description Language) is
usually quite complex and does not provide human-perceivable
representation of the internal structure. However, the internal structure of a
composed component can be represented as a lucid, easily understandable
graphical diagram.
Here we describe a number of existing software development products And
we list the practices and concepts that might be useful in a visual
development environment for software components.
Visual Basic
The first visual development environment introduced is the Microsofts Visual
Basic. It offers a variety of visual controls, widgets that can be composed into
an application. The application is developed by choosing the desired types of
controls from the toolbox (refer to diagram below) and by placing them onto
a form (refer to diagram below), the container of the designed application.
The configuration and interconnection of the designed controls is performed
using the property sheet (refer to diagram below), a set of available
options for each designed control.
Form
Copyright
IUM WMS 334
110
Copyright
IUM WMS 334
111
Tool box
Property Sheet
When a control is double-clicked, the environment is switched into a source

code editing mode, when a custom event-handling code for the selected
control can be provided. During this mode, automatic completion and
highlighting of the edited source code is offered. Except the useful concept of
control composition, Visual Basic introduces several other concepts:
References: If all available controls should be offered in the toolbox,

and all available classes should be offered in the source code editing
mode, the selections would always have to be made from a large
amount of choices. Therefore, in the references dialog, the developer
marks the libraries that should be used, and only the controls and
classes from the selected libraries are offered.
Object Browser: A tool that can be used to browse classes and methods
contained in the libraries that were selected for use.
Copyright
IUM WMS 334
112
Class Builder: A tool that can be used to compose classes visually, by

creating new methods and adding parameters.
Visual Component Manager: A visual interface that can be connected

to a local or remote database and used to store and retrieve source
code, documentation, libraries, images, components, or any other files
needed in the development process. The stored resources can be
assigned a keyword or a textual description, so that they could be
looked up later and retrieved.
Visual Studio .NET

Microsofts newest development product, Visual Studio .NET, uses the
identical concepts as Visual Basic, except it can now support multiple
programming languages, including Basic, C++ and C#. It also contains a
packaging tool and an ER-modeling tool for designing the structure of
databases.
C++ Builder / Delphi
Borlands C++ Builder and Delphi (its an analogy, for the Pascal
programming language) are two examples of classical visual development
products. They use very similar concepts as Visual Basic. Furthermore, these
two products contain the Type Library Editor, a tool that supports the
development of COM components and CORBA objects (do not confuse with
CCM components) by helping the developer in the process of describing the
type information. The editor displays the tree structure of an edited module,
provides a toolbar with buttons for creating new elements (e.g. modules,
interfaces, methods, structures, and exceptions), and offers a dialog for the
customization of each these elements. The type information created can be
exported in the form of the MIDL file (for the COM component model), or in
the form of the IDL (for the CORBA component model).
NetBeans IDE
Sun Microsystems NetBeans IDE, also known as Forte for Java, is a platform
independent visual development environment. It is made up of a core that
can be extended using several plug-in modules, provided by various vendors.
Copyright
IUM WMS 334
113
More than ten modules are already present in the default distribution. The
core by itself already provides several tree-views of a file system, a tree-view
of the runtime nodes, and property sheets for performing various
configurations of the selected node.
Activity 5
- What are some of the useful concepts given by Visual
Basic
Activity
Copyright
IUM WMS 334
114
Feedback Activity 5
Feedback
References: If all available controls should be

offered in the toolbox, and all available classes
should be offered in the source code editing mode,
the selections would always have to be made from
a large amount of choices. Therefore, in the
references dialog, the developer marks the libraries
that should be used, and only the controls and
classes from the selected libraries are offered.
Object Browser: A tool that can be used to browse

classes and methods contained in the libraries that
were selected for use.
Class Builder: A tool that can be used to compose

classes visually, by creating new methods and
adding parameters.
Visual Component Manager: A visual interface that

can be connected to a local or remote database
and used to store and retrieve source code,
documentation, libraries, images, components, or
any other files needed in the development process.
The stored resources can be assigned a keyword or
a textual description, so that they could be looked
up later and retrieved.
Visual Development Environment (e.g. Visual Basic)

Objects
Properties
Tools
Key Words/Terms
Copyright
IUM WMS 334
115
6. User interface design
Objectives
Chapter 6
- Understand the importance of User Interfaces in
the process of Application Development
- To suggest some general design principles for user
interface design
- To explain different interaction styles
- To introduce styles of information presentation
- To describe the user support which should be builtin to user interfaces
- To introduce usability attributes and system
approaches to system evaluation
Designing effective interfaces for software systems

In this chapter on user interface design we will focus on user interface design
principles, User interaction, Information presentation, User support, Interface
evaluation.
The user interface
System users often judge a system by its interface rather than its
functionality
A poorly designed interface can cause a user to make catastrophic
errors
Poor user interface design is the reason why so many software systems
are never used
Graphical user interfaces
Most users of business systems interact with these systems through
graphical interfaces although, in some cases, legacy text-based interfaces
are still used.
GUI characteristics
Characterist
ic
Description
Copyright
IUM WMS 334
116
Windows
Icons
Menus
Pointing
Graphics
Multiple windows allow different information to be displayed

simultaneously on the users screen.
Icons different types of information. On some systems, icons
represent files; on others, icons represent processes.
Commands are selected from a menu rather than typed in a
command language.
A pointing device such as a mouse is used for selecting
choices from a menu or indicating items of interest in a
window.
Graphical elements can be mixed with text on the same
display.
GUI advantages
They are easy to learn and use.

Users without experience can learn to use the system quickly.
The user may switch quickly from one task to another and can interact
with several different applications.
Information remains visible in its own window when attention is
switched.
Fast, full-screen interaction is possible with immediate access to
anywhere on the screen
User-centered design
Software engineers need to pay attention to key issues underlying the design
rather than the implementation of user interfaces. User-centered design is an
approach to User Interfaces design where the needs of the user are
paramount and where the user is involved in the design process.
User Interface design always involves the development of prototype
interfaces.
User interface design process
Copyright
IUM WMS 334
117
User Interface design principles

User Interface design must take account of the needs, experience and
capabilities of the system users and designers should be aware of peoples
physical and mental limitations (e.g. limited short-term memory) and should
recognise that people make mistakes. User Interface design principles
underlie interface designs although not all principles are applicable to all
designs.
Principle
Description
User familiarity
The interface should use terms and

concepts which are drawn from the
experience of the people who will
make most use of the system.
The interface should be consistent in
that, wherever possible, comparable
operations should be activated in the
same way.
Users should never be surprised by
the behaviour of a system.
Consistency
Minimal surprise
Copyright
IUM WMS 334
118
Recoverability
User guidance
User diversity
The interface should include

mechanisms to allow users to recover
from errors.
The interface should provide
meaningful feedback when errors
occur and provide context-sensitive
user help facilities.
The interface should provide
appropriate interaction facilities for
different types of system user.
Design principles
User familiarity - The interface should be based on user-oriented terms

and concepts rather than computer concepts. For example, an office
system should use concepts such as letters, documents, folders etc.
rather than directories, file identifiers, etc.
Consistency - The system should display an appropriate level of
consistency. Commands and menus should have the same format,
command punctuation should be similar, etc.
Minimal surprise - If a command operates in a known way, the user
should be able to predict the operation of comparable commands
Recoverability - The system should provide some resilience to user
errors and allow the user to recover from errors. This might include an
undo facility, confirmation of destructive actions, 'soft' deletes, etc.
User guidance - Some user guidance such as help systems, on-line
manuals, etc. should be supplied
Copyright
IUM WMS 334
119
User diversity - Interaction facilities for different types of user should be

supported. For example, some users have seeing difficulties and so larger
text should be availableUser-system interaction
Two problems must be addressed in interactive systems design. How should
information from the user be provided to the computer system? How should
information from the computer system be presented to the user? User
interaction and information presentation may be integrated through a
coherent framework such as a user interface metaphor
Interaction styles
Direct manipulation
Menu selection
Form fill-in
Command language
Natural language
Interactio
n
styles
Direct
Manipulatio
n
Main
advantages
Menu
selection
Form fill-in
Main
disadvantage
Fast and
intuitive
interaction
Easy to learn
Avoids user
error
Little typing
required
Simple data
entry
May be hard to
implement
Only suitable
where there is a
visual metaphor
for tasks and
objects
Slow for
experienced
users
Can become
complex if many
menu options
Takes up a lot of
screen space
Application
Video games
CAD systems
Most general
purpose
systems
Stock control,
Personal loan
Copyright
IUM WMS 334
120
Command
language
Natural
language
Easy to learn
Powerful and
flexible
Accessible to
casual users
Easily
extended
Hard to learn
Poor error
management
Requires more
typing
Natural language
understanding
systems are
unreliable
processing
Operating
systems,
Library
information
retrieval
systems
Timetable
systems
WWW
Information
retrieval
systems
Direct manipulation advantages

Users feel in control of the computer and are less likely to be intimidated by
it and User learning time is relatively short. Users get immediate feedback
on their actions so mistakes can be quickly detected and corrected
Direct manipulation problems
The derivation of an appropriate information space model can be very
difficult. Given that users have a large information space, what facilities for
navigating around that space should be provided? Direct manipulation
interfaces can be complex to program and make heavy demands on the
computer system
Control panel interface
Copyright
IUM WMS 334
121
Menu systems
-
Users make a selection from a list of possibilities presented to them by

the system
The selection may be made by pointing and clicking with a mouse,
using cursor keys or by typing the name of the selection
May make use of simple-to-use terminals such as touch screens
Advantages of menu systems

-
Users need not remember command names as they are always

presented with a list of valid commands
- Typing effort is minimal
- User errors are trapped by the interface
- Context-dependent help can be provided. The users context is
indicated by the current menu selection
Problems with menu systems
-
Actions which involve logical conjunction (and) or disjunction (or) are

awkward to represent
Menu systems are best suited to presenting a small number of choices.
If there are many choices, some menu structuring facility must be used
Experienced users find menus slower than command language
Copyright
IUM WMS 334
122
Form-based interface
Copyright
IUM WMS 334
123
Command interfaces
-
User types commands to give instructions to the system e.g. UNIX

May be implemented using cheap terminals.
Easy to process using compiler techniques
Commands of arbitrary complexity can be created by command
combination
Concise interfaces requiring minimal typing can be created
Problems with command interfaces

-
Users have to learn and remember a command language. Command

interfaces are therefore unsuitable for occasional users
Users make errors in command. An error detection and recovery
system is required
System interaction is through a keyboard so typing ability is required
Command languages
-
Often preferred by experienced users because they allow for faster

interaction with the system
Not suitable for casual or inexperienced users
May be provided as an alternative to menu commands (keyboard
shortcuts). In some cases, a command language interface and a menubased interface are supported at the same time
Natural language interfaces

The user types a command in a natural language. Generally, the vocabulary
is limited and these systems are confined to specific application domains
(e.g. timetable enquiries). NL processing technology is now good enough to
make these interfaces effective for casual users but experienced users find
that they require too much typing
Copyright
IUM WMS 334
124
Multiple user interfaces
Information presentation
- Information presentation is concerned with presenting system
information to system users
- The information may be presented directly (e.g. text in a word
processor) or may be transformed in some way for presentation (e.g. in
some graphical form)
- The Model-View-Controller approach is a way of supporting multiple
presentations of
Copyright
IUM WMS 334
125
Model-view-controller
-
Static information
Copyright
IUM WMS 334
126
Initialised at the beginning of a session. It does not change

during the session
May be either numeric or textual
Dynamic information
Changes during a session and the changes must be
communicated to the system user
May be either numeric or textual
Information display factors
Is the user interested in precise information or data relationships?

How quickly do information values change?
Must the change be indicated immediately?
Must the user take some action in response to a change?
Is there a direct manipulation interface?
Is the information textual or numeric? Are relative values important?
Alternative information presentations
Copyright
IUM WMS 334
127
Analogue vs. digital presentation
Digital presentation
Compact - takes up little screen space
Precise values can be communicated
Analogue presentation
Easier to get an 'at a glance' impression of a value
Possible to show relative values
Easier to see exceptional data values
Dynamic information display
Copyright
IUM WMS 334
128
Displaying relative values
Textual highlighting
Copyright
IUM WMS 334
129
Data visualization
Concerned with techniques for displaying large amounts of information

Visualisation can reveal relationships between entities and trends in
the data
Possible data visualisations are:
Weather information collected from a number of sources
The state of a telephone network as a linked set of nodes
Chemical plant visualised by showing pressures and
temperatures in a linked set of tanks and pipes
A model of a molecule displayed in 3 dimensions
Web pages displayed as a hyperbolic tree
Colour displays
Colour adds an extra dimension to an interface and can help the user
understand complex information structures
Can be used to highlight exceptional events
Common mistakes in the use of colour in interface design include:
The use of colour to communicate meaning
Copyright
IUM WMS 334
130
Over-use of colour in the display
Colour use guidelines
User
Don't use too many colours

Use colour coding to support use tasks
Allow users to control colour coding
Design for monochrome then add colour
Use colour coding consistently
Avoid colour pairings which clash
Use colour change to show status change
Be aware that colour displays are usually lower resolution
support
User guidance covers all system facilities to support users including online help, error messages, manuals etc.
The user guidance system should be integrated with the user interface
to help users when they need information about the system or when
they make some kind of error
The help and message system should, if possible, be integrated
Help and message system
Copyright
IUM WMS 334
131
Error messages
Error message design is critically important. Poor error messages can

mean that a user rejects rather than accepts a system
Messages should be polite, concise, consistent and constructive
The background and experience of users should be the determining
factor in message design
Design factors in message wording

Copyright
IUM WMS 334
132
Context
Experience
Skill level
Style
Culture
The user guidance system should be aware of what the user is

doing and should adjust the output message to the current
context.
As users become familiar with a system they become irritated
by long, meaningful messages. However, beginners find it
difficult to understand short terse statements of the problem.
The user guidance system should provide both types of
message and allow the user to control message conciseness.
Messages should be tailored to the users skills as well as their
experience. Messages for the different classes of user may be
expressed in different ways depending on the terminology
which is familiar to the reader.
Messages should be positive rather than negative. They should
use the active rather than the passive mode of address. They
should never be insulting or try to be funny.
Wherever possible, the designer of messages should be familiar
with the culture of the country where the system is sold. There
are distinct cultural differences between Europe, Asia and
America. A suitable message for one culture might be
unacceptable in another.
Copyright
IUM WMS 334
133
Nurse input of a patients name
System and user-oriented error messages

System-oriented error message
User-oriented error message
Copyright
IUM WMS 334
134
Copyright
IUM WMS 334
135
Help system design

-
Help? means help I want information

Help! means HELP. I'm in trouble
Both of these requirements have to be taken into account in help
system design
Different facilities in the help system may be required
Help
-
information
Should not simply be an on-line manual
Screens or windows don't map well onto paper pages.
The dynamic characteristics of the display can improve information
presentation.
- People are not so good at reading screen as they are text.
Help system use

- Multiple entry points should be provided so that the user can get into the help
system from different places.
- Some indication of where the user is positioned in the help system is
valuable.
- Facilities should be provided to allow the user to navigate and traverse the
help system.
Entry points to a help system
Copyright
IUM WMS 334
136
Help system windows
Copyright
IUM WMS 334
137
User documentation
-
As well as on-line information, paper documentation should be supplied

with a system
Documentation should be designed for a range of users from
inexperienced to experienced
As well as manuals, other easy-to-use documentation such as a quick
reference card may be provided
Copyright
IUM WMS 334
138
User document types
Document types
Functional description
Brief description of what the system can do
Introductory manual
Presents an informal introduction to the system
System reference manual
Describes all system facilities in detail
System installation manual
Describes how to install the system
System administrators manual
Describes how to manage the system when it is in use
User interface evaluation
-
Some evaluation of a user interface design should be carried out to

assess its suitability
Full scale evaluation is very expensive and impractical for most
systems
Ideally, an interface should be evaluated against a usability
specification. However, it is rare for such specifications to be produced
Usability attributes
Attribute
Learnability
Description
How long does it take a new user to become productive
Copyright
IUM WMS 334
139
Speed of
operation
Robustness
Recoverability
Adaptability
with the system?

How well does the system response match the users
work practice?
How tolerant is the system of user error?
How good is the system at recovering from user errors?
How closely is the system tied to a single model of work?
Simple evaluation techniques

-
Questionnaires for user feedback

Video recording of system use and subsequent tape evaluation.
Instrumentation of code to collect information about facility use and
user errors.
The provision of a grip button for on-line user feedback.
Key points
- Interface design should be user-centered. An interface should be
logical and consistent and help users recover from errors
- Interaction styles include direct manipulation, menu systems form fillin, command languages and natural language
- Graphical displays should be used to present trends and approximate
values. Digital displays when precision is required
- Colour should be used sparingly and consistently
- Systems should provide on-line help. This should include help, Im in
trouble and help, I want information
- Error messages should be positive rather than negative.
- A range of different types of user documents should be provided
- Ideally, a user interface should be evaluated against a usability
specification
Activity 6
- Give examples of User Document Types
Activity
Copyright
IUM WMS 334
140
Feedback Activity 6
Feedback
Functional description
Brief description of what the system can do
Introductory manual
Presents an informal introduction to the system
System reference manual
Describes all system facilities in detail
System installation manual
Describes how to install the system
System administrators manual
Describes how to manage the system when it is in use
Copyright
IUM WMS 334
141
As a student studying in Software Development the following tips and

techniques should prove valuable:
1. Consistency, consistency, consistency. I believe the most
important thing you can possibly do is ensure your user interface
works consistently. If you can double-click on items in one list and have
something happen, then you should be able to double-click on items in
any other list and have the same sort of thing happen. Put your
buttons in consistent places on all your windows, use the same
wording in labels and messages, and use a consistent color scheme
throughout. Consistency in your user interface enables your users to
build an accurate mental model of the way it works, and accurate
mental models lead to lower training and support costs.
2. Set standards and stick to them. The only way you can ensure
consistency within your application is to set user interface design
standards, and then stick to them. You should follow Agile Modeling
(AM)s Apply Modeling Standards practice in all aspects of software
development, including user interface design.
3. Be prepared to hold the line. When you are developing the user
interface for your system you will discover that your stakeholders often
have some unusual ideas as to how the user interface should be
developed. You should definitely listen to these ideas but you also
need to make your stakeholders aware of your corporate UI standards
and the need to conform to them.
4. Explain the rules. Your users need to know how to work with the
application you built for them. When an application works consistently,
it means you only have to explain the rules once. This is a lot easier
than explaining in detail exactly how to use each feature in an
application step-by-step.
5. Navigation between major user interface items is important. If
it is difficult to get from one screen to another, then your users will
quickly become frustrated and give up. When the flow between
screens matches the flow of the work the user is trying to accomplish,
then your application will make sense to your users. Because different
users work in different ways, your system needs to be flexible enough
to support their various approaches. User interface-flow diagrams
Copyright
IUM WMS 334
142
should optionally be developed to further your understanding of the

flow of your user interface.
6. Navigation within a screen is important. In Western societies,
people read left to right and top to bottom. Because people are used to
this, should you design screens that are also organized left to right and
top to bottom when designing a user interface for people from this
culture? You want to organize navigation between widgets on your
screen in a manner users will find familiar to them.
7. Word your messages and labels effectively. The text you display
on your screens is a primary source of information for your users. If
your text is worded poorly, then your interface will be perceived poorly
by your users. Using full words and sentences, as opposed to
abbreviations and codes, makes your text easier to understand. Your
messages should be worded positively, imply that the user is in control,
and provide insight into how to use the application properly. For
example, which message do you find more appealing You have input
the wrong information or An account number should be eight digits in
length. Furthermore, your messages should be worded consistently
and displayed in a consistent place on the screen. Although the
messages The persons first name must be input and An account
number should be input are separately worded well, together they are
inconsistent. In light of the first message, a better wording of the
second message would be The account number must be input to
make the two messages consistent.
8. Understand the UI widgets. You should use the right widget for the
right task, helping to increase the consistency in your application and
probably making it easier to build the application in the first place. The
only way you can learn how to use widgets properly is to read and
understand the user-interface standards and guidelines your
organization has adopted.
9. Look at other applications with a grain of salt. Unless you know
another application has been verified to follow the user interfacestandards and guidelines of your organization, dont assume the
application is doing things right. Although looking at the work of others
to get ideas is always a good idea, until you know how to distinguish
between good user interface design and bad user interface design, you
Copyright
IUM WMS 334
143
must be careful. Too many developers make the mistake of imitating

the user interface of poorly designed software.
10.
Use color appropriately. Color should be used sparingly in
your applications and, if you do use it, you must also use a secondary
indicator. The problem is that some of your users may be color blind
and if you are using color to highlight something on a screen, then you
need to do something else to make it stand out if you want these
people to notice it. You also want to use colors in your application
consistently, so you have a common look and feel throughout your
application.
11.
Follow the contrast rule. If you are going to use color in your
application, you need to ensure that your screens are still readable.
The best way to do this is to follow the contrast rule: Use dark text on
light backgrounds and light text on dark backgrounds. Reading blue
text on a white background is easy, but reading blue text on a red
background is difficult. The problem is not enough contrast exists
between blue and red to make it easy to read, whereas there is a lot of
contrast between blue and white.
12.
Align fields effectively. When a screen has more than one
editing field, you want to organize the fields in a way that is both
visually appealing and efficient. I have always found the best way to do
so is to left-justify edit fields: in other words, make the left-hand side of
each edit field line up in a straight line, one over the other. The
corresponding labels should be right-justified and placed immediately
beside the field. This is a clean and efficient way to organize the fields
on a screen.
13.
Expect your users to make mistakes. How many times have
you accidentally deleted some text in one of your files or deleted the
file itself? Were you able to recover from these mistakes or were you
forced to redo hours, or even days, of work? The reality is that to err is
human, so you should design your user interface to recover from
mistakes made by your users.
14.
Justify data appropriately. For columns of data, common
practice is to right-justify integers, decimal align floating-point
numbers, and to left-justify strings.
Copyright
IUM WMS 334
144
15.
Your design should be intuitable. In other words, if your
users dont know how to use your software, they should be able to
determine how to use it by making educated guesses. Even when the
guesses are wrong, your system should provide reasonable results
from which your users can readily understand and ideally learn.
16.
Dont create busy user interfaces. Crowded screens are
difficult to understand and, hence, are difficult to use. Experimental
results show that the overall density of the screen should not exceed
40 percent, whereas local density within groupings should not exceed
62 percent.
17.
Group things effectively. Items that are logically connected
should be grouped together on the screen to communicate they are
connected, whereas items that have nothing to do with each other
should be separated. You can use white space between collections of
items to group them and/or you can put boxes around them to
accomplish the same thing.
18.
Take an evolutionary approach. Techniques such as user
interface prototyping and Agile Model Driven Development (AMDD) are
critical to your success as a developer.
User Interface Design Principles
1.The structure principle. Your design should organize the user

interface purposefully, in meaningful and useful ways based on clear,
consistent models that are apparent and recognizable to users,
putting related things together and separating unrelated things,
differentiating dissimilar things and making similar things resemble
one another. The structure principle is concerned with your overall
user interface architecture.
2.The simplicity principle. Your design should make simple, common
tasks simple to do, communicating clearly and simply in the users
own language, and providing good shortcuts that are meaningfully
related to longer procedures.
Copyright
IUM WMS 334
145
3.The visibility principle. Your design should keep all needed options
and materials for a given task visible without distracting the user with
extraneous or redundant information. Good designs dont overwhelm
users with too many alternatives or confuse them with unneeded
information.
4.The feedback principle. Your design should keep users informed of
actions or interpretations, changes of state or condition, and errors or
exceptions that are relevant and of interest to the user through clear,
concise, and unambiguous language familiar to users.
5.The tolerance principle. Your design should be flexible and tolerant,
reducing the cost of mistakes and misuse by allowing undoing and
redoing, while also preventing errors wherever possible by tolerating
varied inputs and sequences and by interpreting all reasonable
actions reasonable.
6.The reuse principle. Your design should reuse internal and external
components and behaviors, maintaining consistency with purpose
rather than merely arbitrary consistency, thus reducing the need for
users to rethink and remember.
The user interface of an application will often make or break it. Although the
functionality that an application provides to users is important, the way in
which it provides that functionality is just as important. An application that is
difficult to use wont be used. Period. It wont matter how technically
superior your software is or what functionality it provides, if your users dont
like it they simply wont use it. Dont underestimate the value of user
interface design nor of usability.
8 Golden rules of Interface Design
1. Strive for consistency. Consistent sequences of actions should be required in
similar situations; identical terminology should be used in prompts, menus,
and help screens; and consistent commands should be employed throughout.
2. Enable frequent users to use shortcuts. As the frequency of use increases, so
do the user's desires to reduce the number of interactions and to increase the
Copyright
IUM WMS 334
146
pace of interaction. Abbreviations, function keys, hidden commands, and
macro facilities are very helpful to an expert user.
3. Offer informative feedback. For every operator action, there should be some
system feedback. For frequent and minor actions, the response can be
modest, while for infrequent and major actions, the response should be more
substantial.
4. Design dialog to yield closure. Sequences of actions should be organized into
groups with a beginning, middle, and end. The informative feedback at the
completion of a group of actions gives the operators the satisfaction of
accomplishment, a sense of relief, the signal to drop contingency plans and
options from their minds, and an indication that the way is clear to prepare
for the next group of actions.
5. Offer simple error handling. As much as possible, design the system so the
user cannot make a serious error. If an error is made, the system should be
able to detect the error and offer simple, comprehensible mechanisms for
handling the error.
6. Permit easy reversal of actions. This feature relieves anxiety, since the user
knows that errors can be undone; it thus encourages exploration of unfamiliar
options. The units of reversibility may be a single action, a data entry, or a
complete group of actions.
7. Support internal locus of Control. Experienced operators strongly desire the
sense that they are in charge of the system and that the system responds to
their actions. Design the system to make users the initiators of actions rather
than the responders.
8. Reduce short-term memory load. The limitation of human information
processing in short-term memory requires that displays be kept simple,
multiple page displays be consolidated, window-motion frequency be
reduced, and sufficient training time be allotted for codes, mnemonics, and
sequences of actions.
Copyright
IUM WMS 334
147
User Interface design

User Involvement
Using UMI: Software Engineering with Objects and

Components: P. Stevens & R. Pooley: Longman, Updated
Ed (1999)
Key Words/Terms
Further Reading
Acknowledgements
Using UMI: Software Engineering with
Objects and Components
Learning to Program with Visual Basic
P. Stevens & R. Pooley: Longman,

Updated Ed (1999)
P. Mckeown, Wiley (2001)
Copyright
IUM WMS 334

WMS - 334 Application Developent Methods

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

WMS - 334 Application Developent Methods

Caricato da

Copyright:

Formati disponibili

1

THE INTERNATIONAL UNIVERSITY OF

CODE: WMS - 334

2. The unified modeling language.21

4. Rapid prototyping... ..47

6. User interface design guidelines. 89

Chapter One focuses on Object-Oriented Concepts; defining object oriented

Chapter Three explores Object-Oriented Design. How do you use OOD in

Chapter Five looks at the visual development environments

The author wishes you a pleasant study and best regards.

Analyse the main concepts of object-orientation

Define Object Oriented Concepts and Design

List examples of approaches used in software prototyping.

Give examples and explain types of diagrams used in UML

Activity What the student has to do (written work)

Feedback the author giving a guide to how a question should be

Key words / Terms

Abstraction is the presentation of simple concept (or object) to the

Figure 1.2 Example of Data Abstraction.

Encapsulation means as much as shielding. Each object-oriented object

Figure 1.3 Example of Encapsulation Concept.

Class and Object Instance

A class is used to describe something in the world, such as occurrences,

The following table gives some examples of classes and objects

Figure 1.4 Class and Object.

Properties in a class are used to present the structure of the objects:

Methods in a class describe the behavior of the objects. It represents

Figure 1.5 An example of a Dog Class

An association is a relationship between different objects of one more

Figure 1.6 Associations

Exactly one instance

Zero or more instances

One or more instances

Figure 1.7 Aggregation

Figure 1.8 Inheritance

Interface classes are abstract definitions of purely functional interfaces.

have its implementation on isEqual() since it is defined to implement

Figure 1.9 Interface

Event and Listener

Event and Listener is an important part using in CIM modeling. An event

Figure 1.10 ActionListener

Communication between objects is achieved by exchanging messages

Figure 1.11 Message Exchange in Classes

Polymorphism indicates the meaning of many form. In object-oriented

Overloading indicates a method can have different definitions by defining

Figure 1.12 Polymorphism

Unified Modeling Language

The Unified Modeling Language was originally developed at Rational

Syntax only - UML is just a language, it tells you what

Comprehensive - it can be used to model anything. It is

Language independent - it doesn't matter what hi-level

Process independent - the process by which the models

Tool independent - UML leaves plenty of space for tool

Originally just for system modeling - some user defined

Others refer to UML Spec.

Modeling tool - introduction to Rational Rose

Figure 1.13 Side panel

Figure 31.14 Notations

Figure 1.15 Example of class diagram

Figure 1.16 Property editor

Click on the tab that reads operations

Right click anywhere on the white part and select insert

Type in the name of the operation and then hit enter

connect using an association, refer back to the Use Case Diagram