Uniface Seven Development Methodology For Component-Based Applications

UNIFACE Component-based
Development Methodology
UNIFACE V7.2
151157206-00
Revision 0
Dec 2000
UMET
UNIFACE V7.2
UNIFACE Component-based
Development Methodology
Revision 0
Restricted Rights Notice
This document and the product referenced in it are subject to the following
legends:
1997-2000 Compuware Corporation. All rights reserved. Unpublished - rights
reserved under the Copyright Laws of the United States.
U.S. GOVERNMENT RIGHTS-Use, duplication, or disclosure by the U.S.
Government is subject to restrictions as set forth in Compuware Corporation
license agreement and as provided in DFARS 227.7202-1(a) and 227.7202-3(a)
(1995), DFARS 252.227-7013(c)(1)(ii)(OCT 1988), FAR 12.212(a) (1995), FAR
52.227-19, or FAR 52.227-14 (ALT III), as applicable. Compuware Corporation.
This product contains confidential information and trade secrets of Compuware
Corporation. Use, disclosure, or reproduction is prohibited without the prior
express written permission of Compuware Corporation.
Trademarks
Compuware is a registered trademark of Compuware Corporation and UNIFACE is a
registered trademark of Compuware Europe B.V. CICS, DB2, IBM, and OS/2 are
trademarks of International Business Machines Corporation. SOLID Server (TM), SOLID
Bonsai Tree (TM), SOLID Remote Control (TM), and SOLID SQL Editor (TM) are
trademarks of Solid Information Technology Ltd. All other company or product names used
in this publication are trademarks of their respective owners.
24-hour online customer support and learning

MyUNIFACE is an Internet-based support and learning environment which provides
real-time access to a wealth of UNIFACE product and technical information. Features
include online product documentation, technical tips and know-how, up-to-date platform
availability, product fixes, course information, online training, and live communication
with fellow developers. You can obtain full access privileges for MyUNIFACE by completing
an online registration form (customer license information is required) at
http://myuniface.com/.
For the latest version of the documentation always check the UNIFACE Library on the
MyUNIFACE site.
Your suggestions and comments about UNIFACE documentation and course material are
highly valued. Please send your reactions to:
Compuware Europe B.V.
Delivery Methods & Practices
P. O. Box 12933
1100 AX Amsterdam
The Netherlands
e-mail: DM&P-Hotline@nl.compuware.com
fax: +31 (0)20 311-6213
UNIFACE V7.2
Contents
Introduction
1.1
1.2
1.3
1.4
1.5
Objects and components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3

What is an object? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3
1.2.1
Object structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3
1.2.2
Object behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4
1.2.3
Encapsulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4
What is a component?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-6
1.3.1
Design by Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-7
1.3.2
Component interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-8
1.3.3
Data hiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9
Why develop component-based applications? . . . . . . . . . . . . . . . . . . . . . . .1-10
1.4.1
Adding new functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-10
1.4.2
Reusing components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-10
1.4.3
Easier maintenance of existing functionality . . . . . . . . . . . . . . . . . . .1-11
1.4.4
Replacing components with other components. . . . . . . . . . . . . . . .1-12
1.4.5
Separating application layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-12
1.4.6
Assembly of applications is simplified with components . . . . . . . . .1-13
1.4.7
Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-13
Why a new component-based modeling technique? . . . . . . . . . . . . . . . . . .1-14
Component-based development process

2.1
2.2
2.3
Inception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3
The Modeling Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-8
Modeling processanalysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-10
2.3.1
Business function modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11
2.3.2
Object modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-13
2.3.3
Behavioral modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-15
UNIFACE Component-based Development Methodology (Dec 2000)
iii
UNIFACE V7.2
2.4
2.5
2.6
2.7
2.8
2.9
2.10
Modeling processdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-21

2.4.1
Component model design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-22
2.4.2
Component design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-28
2.4.3
Relational model design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-30
2.4.4
Business rule design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-31
2.4.5
Inter-component communication design . . . . . . . . . . . . . . . . . . . . .2-32
2.4.6
UNIFACE design implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-33
Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-34
Incremental development approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-35
2.6.1
Incremental development process. . . . . . . . . . . . . . . . . . . . . . . . . . .2-36
2.6.2
Prioritizing increments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-37
Iterative development approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-38
Prototyping approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-40
2.8.1
Exploratory prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-41
2.8.2
Experimental prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-42
Quality assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-44
2.9.1
Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-45
2.9.2
White box testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-45
2.9.3
Black Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-46
2.9.4
Testing Techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-48
2.9.5
Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-49
2.9.6
Service level management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-50
2.9.7
Usability measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-50
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-50
Appendix A Sample use case description
iv
(Dec 2000)
UNIFACE V7.2
Chapter 1
Introduction
Component-based development represents a significant paradigm shift
in application development. While component-based development
techniques have been used effectively in engineering and manufacturing
circles for many years, their application to software development is
relatively recent. The techniques came about in response to many of the
issues facing IT organizations today: reducing time to market,
responding more rapidly to change, and providing the flexibility to
change the scale or scope of functionality to keep pace with changes in the
business.
There are some inherent challenges in applying component-based
development techniques to software development. Until now, it has been
usual practice to design and build large, monolithic systems that perform
very specific functions. Component-based development, however,
employs a three-phase approach of modeling reusable, interchangeable
components, constructing the components, and assembling them into a
complete application.
Component-based applications are quite different from those developed
in the past, and the process for developing component-based applications
is also very different. Therefore, Compuware has developed a new
methodology to address the particular demands of component-based
development.
A software engineering methodology is a process for the organized
production of software using a collection of predefined techniques and
notation conventions. A methodology is usually presented as a series of
steps, with techniques and deliverables associated with each step.
The UNIFACE component-based development methodology uses
industry-standard object-oriented modeling techniques and notation
incorporated in the Unified Modeling Language (UML). This
component-based methodology addresses the entire system development
life cycle, conceived specifically to deliver the optimum design for
component-based applications. To achieve this goal, a thorough
1-1
UNIFACE V7.2
understanding of the internal workings and goals of the business must

first be established. UML provides a means to model and communicate
an understanding of the business through a standard set of techniques
and notations. Ultimately, UML deliverables are used to populate the
UNIFACE application models and component models.
This methodology embodies the UNIFACE 3D paradigm of
component-based development, component-based deployment and
component-based delivery. It is designed to provide a high degree of
productivity and rapid response to change.
Component-based development is divided into the following main
activities:
Modeling
Construction
Assembly
Figure 1-1 shows the relative effort required in each of the activities
during the application development cycle.
Modeling
(Analysis & Design)
Effort
Construction
Assembly
Elapsed time
Figure 1-1 Component-based development.
UML provides an excellent means to model and communicate an

understanding of the business. Before discussing where UML techniques
are specifically applied in component-based modeling, refer first to
section 1.1 Objects and components.
1-2
(Dec 2000) Introduction
UNIFACE V7.2
The UNIFACE component-based development methodology enhances

Compuwares tools for modeling, construction and assembly of
component-based applications, and provides a practical methodology for
the successful development of large-scale component-based systems.
1.1 Objects and components

Before considering the UML techniques applied in modeling, it is
important to understand the answers to the following questions:
What is an object?
What is a component?
Why develop component-based applications?
Why use a new component-based modeling technique?
1.2 What is an object?

An object is a specific, real-world item that you need to keep information
about and use in order to conduct your business.
For example, a retailer of computer equipment might require objects
such as Computer Equipment, Peripheral Devices, Vendors, and Clients
to conduct their business. These objects are important to the business, so
it is necessary to keep relevant information about them. This information
is expressed as the structure and behavior of the objects.
1.2.1 Object structure

The structure of an object is defined as a group of attributes. Attributes
are the individual data items that are used to describe an object within
the context of the business. For example, the structure of the Computer
Equipment object might consist of:
Serial Number
Model Number
Manufacturer
1-3
UNIFACE V7.2
Cost
Retail Price
The structure defined for an object must be consistent for all occurrences
of that object.
1.2.2 Object behavior

The behavior of an object is defined as operations. Operations are the
distinct functions performed by an object within the scope of the
business. For example, the behavior of the Computer Equipment object
can include the following:
Order Equipment
Receive Equipment
Sell Equipment
The behavior defined for an object must be consistent for all occurrences
of the object.
1.2.3 Encapsulation
From the descriptions in section 1.2.1 Object structure and section 1.2.2
Object behavior, you might conclude that the objects structure is similar
to data specifications, and that the objects behavior is similar to process
specifications. This conclusion can be correct. However, prior to the use
of object-oriented design techniques, data design and process design were
addressed separately. When object-oriented design techniques such as
UML are used, there is no separation between structure (data) and
behavior (process). The behavior of an object encapsulates its structure.
Encapsulation means to enclose or conceal. When the term encapsulation
is applied to an object, it means that its structure is enclosed or hidden
by its behavior. This technique is often referred to as data hiding. The
objects data structure is concealed from the user, and is only accessible
by one of its public behaviors.
Figure 1-2 illustrates how structure is encapsulated by behavior.
1-4
UNIFACE V7.2
Order Equipment
Computer
Equipment
Receive
Equipment
Serial Number
Model Number
Manufacturer
Cost
Retail Price
Sell Equipment
Figure 1-2 The computer equipment objects behavior encapsulates its data.
Advantages of encapsulation
In todays dynamic business environment, frequent changes have become
commonplace. Keeping pace with this change is one of the greatest
challenges businesses face today. Using the example of a computer
equipment retailer, what would happen if the company decided to begin
repairing equipment in addition to selling it? They would need to add
new information to the structural and behavioral characteristics of the
computer equipment object. For example, the attributes Warranty Type
and Warranty Length, and a new operation Repair Equipment, would
need to be added.
Adding this additional data and functionality means that the retailer has
to make many extensive changes to existing programs and recompile any
programs that deal with computer equipment. With an encapsulated
object, however, none of this extra work is necessary. New attributes and
behavior can be added without affecting any of the existing behaviors.
Figure 1-3 illustrates this:
1-5
UNIFACE V7.2
Order Equipment
Computer
Equipment
Receive
Equipment
Serial Number
Model Number
Manufacturer
Cost
Retail Price
Warranty Type
Warranty Length
Repair
Equipment
Sell Equipment
Figure 1-3 Adding a new behavior.
1.3 What is a component?

A component is an independently deliverable collection of related
software operations that can be used to build applications or larger
components. A component can implement a single function, a subsystem,
or an entire application.
The operations implemented within components correspond to the
behaviors specified for the objects. Therefore, components (and their
interfaces) provide the means to achieve the encapsulation of the objects.
Figure 1-4 shows a simple example of how an operation can be
implemented within a component:
1-6
UNIFACE V7.2
Order Equipment
Receive
Equipment
Computer
Equipment
Serial Number
Model Number
Manufacturer
Cost
Retail Price
Warranty type
Warranty length
Repair
Equipment
Sell Equipment
Figure 1-4 Implementing an operation within a component.
1.3.1 Design by Contract

Design by Contract is an essential principle in component-based
development, and lays the foundation for the successful design of
components. Design by Contract associates a design contract with every
component, which is a set of logical assertions. These assertions define
the components contract and consist of the following:
Preconditionsconditions that must be true before an operation can
be executed
Business rulesfunctional requirement for each operation
Signaturesset of input and output parameters for each operation
Post conditionsoutput conditions for each operation
Invariantsglobal consistency conditions both assumed and
maintained by every operation (such as state and context)
Based upon the assertions of the contract, the developer using the
component can be confident of the integrity of its function and the
accuracy of its interface. Also, the following benefits can be derived from
Design by Contract:
1-7
UNIFACE V7.2
Development of components that accurately meet the needs of the

business
A rich source of requirements for component testing
A good quality assurance mechanism
Automatic documentation of component functions
The user of the component need not be concerned with the details of
its implementation
Applying the principle of Design by Contract requires:
Standards for defining component requirements

A standard for defining component interfaces
Component naming standards
Standard testing scripts to ensure the component functions according
to its defined requirements
A component management function, based upon a repository of the
component contracts
1.3.2 Component interfaces

All components should be accessed via their published interface.
Each component is made up of a group of related operations. Each of the
operations has a signature. The signature contains the string of data
attributes required by the operation to complete its function, as well as
the set of attributes the operation returns as output. Operations also
have pre-conditions and post-conditions. When a user interacts with a
component, they must activate a specific operation within the component
and supply all of the input parameters contained within the operations
signature. Prior to the activation of the operation, all pre-conditions must
be evaluated and satisfied. All post-conditions are assumed to be true
upon the successful completion of the operations.
A component interface consists of the collection of user-accessible
operations with their pre-conditions and post-conditions.
Based on the principle of data hiding, the domain of data that a user can
access through any given component is governed by the set of operations
made available through the component's public interface. You can access
a components functionality and data by activating an operation and by
populating the input parameters of its interface. When the operation
completes, the component returns the string of fields or occurrences
defined as the output parameters of the interface.
1-8
UNIFACE V7.2
The definition of published component interfaces can depend on the

granularity of the components themselves. Typically, components are
quite granular and contain a small group of related operations. However,
interfaces can be defined at higher levels for more complex components,
such as subsystems, encapsulated legacy applications, or TP monitor
transactions.
Component interfaces are the mechanism by which component
dependencies and links are implemented. They must have a standard
format (for more information, see the UNIFACE Component Interface
Standards), and should be managed through a component repository
(such as the UNIFACE assembly workbench).
1.3.3 Data hiding

Data hiding means that the component user or client does not actually
see or know the implementation details of the data structure as used
internally by the component. Instead of writing retrieval procedures or
query statements, the available data is accessed via the published
interface of the component.
In traditional software development, the developer requires detailed
knowledge of the underlying structure and storage techniques of an
applications data. A major advantage of component-based development
is that the component user or client does not require detailed knowledge
of its implementation. In other words, to utilize a component, the user
only needs to know the published interface. These characteristics should
all defined and governed by the design contract for the component.
Through the use of data hiding techniques, components can be reused
freely without concern for issues such as data retrieval, data storage, or
the communication of data between applications.
To achieve the benefits of reuse and architectural flexibility offered by
data hiding, the application must be separated into distinct presentation,
business logic, and data access layers. The desired reuse and
architectural flexibility is not realized unless all components function
exactly as stated by their design contract.
1-9
UNIFACE V7.2
1.4 Why develop component-based applications?

Component-based applications provide the following benefits:
The ability to add new functionality without impacting existing
functionality.
It is easier to maintain existing functionality.
You can replace components with other components sharing the same
interface.
The use of components make it easier to develop and assemble
applications.
Components can be reused.
Presentation, business logic and data access layers of the application
are separated.
Application scalability is enhanced.
1.4.1 Adding new functionality

Encapsulation makes it possible to add new functionality (behaviors) to
applications without impacting the existing functionality. In other
words, to add a new function, all that is required is to build the new
component, test it, and integrate it into the existing component
repository. No program changes or further compilations of other
components are necessary.
1.4.2 Reusing components

Components are reusable. This means that once a component is
developed, the operations within it can be activated by other components.
Consequently, you need to develop an operation only once.If the
operation is required by another component or subsystem, it can simply
be reused instead of being duplicated or re-created.
While reuse can significantly increase the speed and productivity of
application development efforts, it is equally important to identify and
implement an appropriate reuse strategy for each project. This strategy
ensures a balance between component granularity and component
function.
1-10
UNIFACE V7.2
If you develop a number of small components (a small component would

be, for example, a component containing a single computation or edit
function), the degree of reuse is high. However, assembling an
application using such small components can be complex and can
adversely affect productivity.
Larger, more complex components can result in greater productivity, but
offer less opportunity for reuse. Figure 1-5 illustrates the relationship
between reuse and productivity based on the granularity of components.
Packaged applications
Application components, subsystems
Objects, controls,
class libraries
Reuse
Business components,
subsystems
Productivity
Figure 1-5 Trade-off between reuse and productivity.
1.4.3 Easier maintenance of existing functionality

When maintaining existing functionality, changes can be made to
existing components as long as no changes are made to their interface.
Once a component is modified, the component should be thoroughly
tested to ensure it still functions as intended, using regression testing or
a similar testing regime. After testing, the component should be
reintegrated into the application and component repository. No program
changes or recompilations of other components are required. You do not
need to test any other functionality of the same component.
1-11
UNIFACE V7.2
1.4.4 Replacing components with other components

A component is a set of related operations. Each component has its own
unique design contract. Based upon the assertions of the contract, a
developer using a component can be confident in the integrity of its
function and the accuracy of its interface.
As components are assembled into applications, interfaces provide the
means of linking components together in order to provide the desired
functionality. For example, an order entry component might be linked to
a part selection component to enable the user to make a selection from a
list of available parts when entering an order.
As components are self-contained, they can be replaced by other
components. For example, the part selection component mentioned above
could have been implemented using C++. At some point, you can decide
that this function could be better implemented using a different
technology, such as UNIFACE. Any component can be replaced at
assembly time by another component that fulfills the specified design
contract.
1.4.5 Separating application layers

Components allow you to adopt a multitier architecture by making it
possible to separate the presentation, business logic, and data access
layers of an application. Components within the presentation layer
provide the graphical user interface (GUI) and govern the users
interaction with the application. Presentation components contain no
business rules and are stateless.
Components within the business logic layer realize all of the applications
business rules and disclose the public structural and behavior elements
to the presentation layer. These business rules include process-based
business rules, structural business rules, rules that apply to hierarchical
records sets, and rules that apply to specific occurrences or collections of
records.
Components within the data access layer provide transparent,
heterogeneous access to the various application data sources. Primarily,
these components consist of DBMS drivers or ODBC drivers.
Additionally, there can be other more complex data access components,
such as UNIFACE PolyServer or encapsulated DBMS stored procedures.
1-12
UNIFACE V7.2
There is also another variety of high-level components, called system

services components, that reside outside of these three layers. System
services components provide functions and services that can be used by
all applications residing within the application architecture. These are
global functions, such as security, global edits, error handling, and
controller objects.
Separating the presentation, business logic, and data access layers of the
application makes it possible to reuse components, or replace a
component by another component. A multitier architecture ensures
flexibility in application development, assembly, and deployment. It also
provides a great deal of flexibility when distributing components across
a wide variety of application architectures, such as the Internet, n-tier or
traditional two-tier client/server, mainframes, or a combination of these.
A multitier architecture has a major affect on the components designed
for an application. The definition of each layer of the architecture, and
the functions or services provided by each layer, must be defined as part
of the analysis phase. During the design phase, a component model must
be established that satisfies all the architectural requirements defined
during the analysis phase.
1.4.6 Assembly of applications is simplified with components

Component-based assembly is the process of linking a group of
components to form a complete application. The source for these
components is not limited to those developed in-house; components can
also be used from purchased packages or from legacy systems.
As components can be reused, it is no longer necessary to duplicate
functionality between applications. In addition, because you only need to
know a components interface in order to use it, there is no need for
extensive coding to integrate components.
1.4.7 Scalability
While there are many new applications being built today, many
mainframe and client/server legacy applications are still in use. The use
of components makes it possible to provide seamless integration between
these legacy applications and new, component-based applications. Also,
the rapid expansion of the Internet has created new business
requirements, such as B2C and B2B e-commerce. Components make it
1-13
UNIFACE V7.2
possible to open up previously closed, in-house systems to customers and

business partners over the Internet. These are just a few examples of how
the use of components make it possible to flexibly adjust the scale of an
application to address factors such as different architectures, varying
numbers of users, increased transaction volumes, legacy integration, and
e-commerce.
1.5 Why a new component-based modeling technique?

Component-based modeling, using industry-standard UML techniques,
allows you to create an optimal design for component-based applications.
Techniques such as Entity-Relationship Diagrams or Data Flow
Diagrams do not adequately express the structure and behavior of
objects. These techniques were developed for designing applications
made up of sequential processes and hierarchical data structures.
UML-based techniques allow for modeling encapsulated business objects
that offer all of the previously outlined advantages.
1-14
UNIFACE V7.2
Chapter 2
Component-based development
process
Figure 2-1 Component-based development process.
Figure 2-1 provides an overview of the component-based development

process. This process consists of five basic phases or activities: inception,
analysis, design, development and quality assurance. This chapter
describes each of these phases and the deliverables resulting from them.
2-1
UNIFACE V7.2
Figure 2-1 also shows that this process is iterative. Components are
developed through a number of iterations, or repetitions, of the CBD life
cycle:
Inceptiongather business requirements from users and
stakeholders
Analysisproduce and validate UML analysis models from business
requirements
Designapply the properties of the application architecture to the
analysis models to produce the UML design models
Developmentdevelop components based on the analysis and design
models
Quality assurancetest the functionality, usability, and performance
of the components to determine how well the requirements have been
met
Feedback from the testing become the requirements for the next
iteration
The first iteration through the CBD process addresses the requirements
for all functionality within the scope of the project. At the development
phase, application functionality is constructed (see section 2.6
Incremental development approach). Application functionality is divided
into increments (discrete portions). Each of these increments consists of
a set of independently deployable, reusable components. Thus the
development of each increment can proceed independently using
iterative development techniques (see section section 2.7 Iterative
development approach) to build and refine the increment.1
Once a development iteration for an increment has been completed, it
proceeds into the quality assurance phase where it is thoroughly tested.
The feedback from the testing then becomes the initial requirements for
the next iteration. Each subsequent iteration is then focussed on
satisfying the requirements of a specific increment. This cycle is repeated
for each increment a set number of times, or until the stated
requirements are satisfied.
Incremental development provides a number of advantages, including:
Smaller, more manageable development tasks

Opportunities for parallel development
Fewer risks
Improved quality of the components
1. Because the components delivered from each increment are independently deployable, increments can be
developed in parallel.
2-2
(Dec 2000) Component-based development process
UNIFACE V7.2
Improved ability to plan and execute development projects

During component-based development, it can be appropriate to use one
of several prototyping techniques (see section 2.8 Prototyping approach)
to help identify the solution best suited to the business needs. One such
technique is called exploratory prototyping, and can be used during
analysis to help define or clarify user requirements. Another protoyping
technique is called experimental prototyping, and which can be used as
part of iterative development to explore or compare various technical
solutions for a given requirement.
2.1 Inception
Figure 2-2 Inception.
2-3
UNIFACE V7.2
The inception phase takes place prior to modeling. The purpose of

inception is to define the business case and the scope of the project, and
to gather the high-level requirements for the proposed system.
The deliverables created during the inception phase are:
Problem statementA clear, concise definition of the business
problems, objectives and scope of the proposed application.
Actor analysisA precise definition of the roles and responsibilities
of all actors that interact with the proposed application.
Business use casesGraphical representations of interactions
between the actors and the main business functions to be fulfilled by
the application (see figure 2-3). Each diagram should also have a
structured, textual description that explains the details of the
functions performed within the use case, such as the business objects
used, the steps required to complete the use case and the business
rules associated with each step (see appendix A Sample use case
description). These details are easily gathered and validated using
presentation prototypes.
Presentation prototypesA set of software or paper-based
prototypes, based upon the established graphical user interface
standards, that define the basic user presentation for each business
use case (see figure 2-4). These prototypes should depict the basic
grouping of business objects and data attributes required to satisfy
the requirements of each business use case. They can also be used to
help identify and validate various business rules.
Business rules catalogA standard format for identifying,
classifying, and documenting business rules (see figure 2-5).
Business object package diagram (optional)Based upon the
business objects of the high-level business use case, an initial package
diagram can be drawn. This diagram indicates dependencies and
potential dependencies between packages. This information is useful
when defining project plans.
Nonfunctional requirementsdefinition of the main characteristics
of the environment in which the system will be implemented and
deployed. These requirements include operational constraints and an
architectural vision. Each architecture has specific properties and
requirements that determine the layer in which logic should be
implemented. The architectural vision prescribes how the system is
organized and structured, addressing characteristics such as
heterogeneity, scalability, reuse, and change.
2-4
UNIFACE V7.2
Additionally, you can be required to provide the project sponsors with a

cost/benefit analysis in order to gain their commitment to proceed with
the project. If so, you will need to do some initial analysis to estimate the
approximate effort and costs required to complete the project. The
deliverables resulting from the inception phase are a key part of this
process because they form the foundation and source of information for
subsequent modeling activities. Care must be taken to ensure that these
deliverables are accurate and validated by the application users and
sponsors. The business use case diagram (figure 2-3), the business use
case description (Appendix A Sample use case description) and the
business rules catalog (figure 2-5) provide an example of how the
proposed business solution is defined:
Figure 2-3 Example of a business use case diagram.
2-5
UNIFACE V7.2
Figure 2-4 Example of a presentation prototype.
2-6
UNIFACE V7.2
Figure 2-5 Example format for a business rules catalog.
2-7
UNIFACE V7.2
2.2 The Modeling Process
Figure 2-6 Evolution of the CBD modeling deliverables.
Modeling is divided into two processes: analysis and design. The analysis
process consists of the following activities:
Business function modeling
Object modeling
Behavioral modeling
The design process consists of the following activities:
2-8
Component model design

Relational model design
Business rules design
Inter-component communication design
UNIFACE design implementation
UNIFACE V7.2
During analysis, the structural and behavioral requirements for the

system are further defined and refined. The models and diagrams
produced during the analysis phase are a reflection of the business.
The purpose of the design phase is to translate these requirements into
a component architecture that fully supports the architectures vision.
Splitting the modeling process into two phases does not imply that design
activities can start only when analysis has been fully completed. The
boundary between analysis and design is not always clear. (The same
holds true for the boundary between design and development.) In the
process of refining analysis and design artifacts, switching from one
phase to the other is possible.
An overview of the activities for each phase is provided in the following
sections.
2-9
UNIFACE V7.2
2.3 Modeling processanalysis
Figure 2-7 Deliverables of the analysis phase of modeling.
Inception provides a high-level view of the system requirements. In the

analysis phase, these requirements are expanded to more detail.
The analysis phase consists of the following main activities:
Business function modeling (use case diagrams)
Object modeling (class diagrams)
Behavioral modeling (interaction diagrams, activity diagrams, and
statechart diagrams)
2-10
UNIFACE V7.2
2.3.1 Business function modeling

The purpose of business function modeling is to establish the functional
requirements for the system. This is accomplished by analyzing the
business use cases defined during inception to determine the elementary
business functions performed by each actor. This process involves
detailed discussions of the business use cases in user interview sessions.
An elementary business function is defined as an activity that cannot be
subdivided into separate and distinct functions. Elementary business
functions are typically performed by one person, in one place at one time.
A use case diagram and use case description are created for each
elementary business function. Figure 2-8 provides an example of an
elementary use case diagram.
Determining elementary business functions
The process of determining elementary business functions should not be
complex, but requires the input of users. A simple, but effective approach
for identifying and detailing the elementary business functions is as
follows:
1. Work with users in a facilitated discussion of the business, commonly
referred to as a joint application development (JAD) session.
2. Discuss the business process associated with each function listed for
each scenario of a business use case.
3. Go through each step of the business process, simulating how the
users do their jobs, using the presentation prototypes as a guide or
framework for the discussion.
4. If a step can not be broken down into other steps, it is considered to
be at an elementary level.
5. Identify all of the business objects, attributes, and global business
rules associated with each step.
6. Document each step of the elementary business function and the
specific rules associated with it in an elementary use case description.
7. Define each business rule in detail within the business rule catalog.
Each elementary business function should be given a unique name and
should appear on an elementary use case diagram (see figure 2-8).
2-11
UNIFACE V7.2
Figure 2-8 Elementary use case diagram.
2-12
UNIFACE V7.2
2.3.2 Object modeling

The purpose of object modeling is to identify the objects found within the
system. An object is a real-life item that has a unique identity and is
relevant to the business. Objects with the same structure, behaviors, and
relationships are grouped together in an object class (referred to simply
as class). The structure of a class is expressed in terms of attributes, its
behaviors as operations, and its relationships as associations. These
characteristics of classes are depicted using class diagrams.
The information used to construct the class diagram is taken from the
business objects and business rules defined in the elementary use case
descriptions. An initial version of the class diagram, containing only the
classes, attributes, and associations, is created during object modeling.
This initial class diagram is then progressively refined and extended
during behavioral modeling and throughout the design phase.
2-13
UNIFACE V7.2
Figure 2-9 Example of a class diagram.
A typical system can consist of many classes. Therefore, a mechanism for

breaking a system down into smaller, more manageable modules is
required. This is accomplished by defining class packages. An initial class
package diagram can have been developed during the inception phase,
and is extended as the class diagram evolves.
2-14
UNIFACE V7.2
A class package is a logical container for one or more business objects. A

business object can be a single class, or a grouping of several dependent
classes that function together as a unit. The definition of business objects
depends upon the viewpoint of the business. Packages and the
dependencies between them are described using package diagrams.
Figure 2-10 Example of a package diagram.
2.3.3 Behavioral modeling

The purpose of behavioral modeling is to define the business rules,
business events, and business activities that define object behaviors.
Behavior is identified by defining the different scenarios applicable to
each elementary use case. Scenarios are expressed as a series of
interactions. An interaction is defined as a message from an actor to a
class, from a class to another class, or from a class to itself. Behavioral
modeling includes the following diagrams:
2-15
UNIFACE V7.2
Interaction diagrams
Activity diagrams
Statechart diagrams
Interaction diagrams
Interaction diagrams show how a group of objects interact to produce
specific behaviors. There are two types of interaction diagrams:
Sequence diagrams
Sequence diagrams show the sequence of interactions between
classes that occur within a specific scenario. Typically, these
interactions are initiated by an actor with a message to a class. The
class, in turn, sends messages to other classes that receive and act
upon the messages and perform the requested functions. The
interactions between classes continue in this way until the goal of the
scenario has been satisfied (see figure 2-11).
2-16
UNIFACE V7.2
: Order Clerk
: PURCHASE_
ORDER
: COMPANY
: PURCHASE_
ORDER_LINE
: PR ODUCT
: CATALOG
Enter Or der ( )
As s ign Order Num ber (Orde r_Num )
Sel ect Compa ny(COMPAN Y)
Ad d O rder Line(COMPAN Y)
Select Product(PRODUCT)
G et Mater ial Pri ce( COMPANY, PRODU CT, pr ic e, date)
Com pute Lin e Am ount( Amoun t, q uantity_ord, pri ce)
[All Orderlines entered]
C om pute Ord er Total(total_am ount)
Figure 2-11 Sequence diagram for an Enter Order use case.
Collaboration diagrams
Collaboration diagrams depict the same information shown in the
sequence diagrams, but they present it from a different perspective.
In addition to the interactions shown in the sequence diagrams,
collaboration diagrams show the spatial relationships between
classes. Viewing the interactions from this perspective makes it
easier to understand how the classes are linked together.
2-17
UNIFACE V7.2
Activity diagrams
Activity diagrams combine the perspectives of use cases and interaction
diagrams by providing an aggregate view of all activities for a given use
case. Activity diagrams are similar to data flow diagrams and flow charts
because they show the flow and sequence of activities. However, while
data flow diagrams and flow charts are limited to describing only
sequential behavior, activity diagrams provide a means to describe
workflow, branching, and parallel behavior.
The content of activity diagrams is drawn from the elementary use case
diagrams and interaction diagrams. The elementary use cases identify
the elementary business functions in the system, and the interaction
diagrams define the behaviors required to complete these functions.
Activity diagrams blend the perspectives of function and behavior,
providing a unique, big picture view of the flow and behavioral
dependencies within an elementary use case.
2-18
UNIFACE V7.2
Figure 2-12 Activity diagram for the scenarios of an Enter Order use case.
Statechart diagrams
Statechart diagrams describe the possible states that a class can go into,
and the events or activities that cause changes in these states. Statechart
diagrams focus on the behaviors exhibited by each class.
2-19
UNIFACE V7.2
In comparison, interaction diagrams focus on the detailed behaviors of

classes within a specific scenario of an elementary use case, and activity
diagrams have a higher level of focus, showing the aggregate of all
behaviors contained in all scenarios for an elementary (or higher level)
use case.
Statechart diagrams provide a mechanism to verify that all of the
behaviors necessary to support the entire life cycle of each class have
been identified. They also provide a rigorous validation of the various
business rules that govern the state transitions that occur during this life
cycle.
Refinement of the diagrams
The analysis phase of the modeling process, using UML analysis
diagrams, realizes a gradual refinement of the structural and behavioral
requirements of the system. Much of this refinement is centered around
the evolution of the class diagram. As analysis progresses, more and
more system behavior requirements are specified and detailed. This
results in new information being added to the class diagram. For
example, as the behaviors required to satisfy the various use case
scenarios are defined using sequence or collaboration diagrams, new
operations and attributes which were not identified during object
modeling are discovered. It is also possible that new classes or
associations are needed to facilitate the required interactions discovered.
As a result, the class diagram acquires greater levels of detail and
completeness.
2-20
UNIFACE V7.2
2.4 Modeling processdesign
Figure 2-13 Design.
The next phase in the modeling process is design. During inception and
analysis, the structural and behavioral requirements for the system are
defined and refined. The purpose of the design phase is to translate these
requirements into the desired component architecture that fully supports
heterogeneity, reusability, scalability, and portability.
The major activities in the design phase are:
Component model designMapping the dynamic behavior of the
class diagrams to interfaces and components (interface diagram and
component diagram).
Relational model designMapping the static information of the class
diagrams to a relational data model (persistent data model).
Business rules designMapping the business rules to business logic
components.
2-21
UNIFACE V7.2
Inter-component communication designMapping the business

processes by linking the components (inter-component
communication diagram).
UNIFACE design implementationDefining the design deliverables
in the UNIFACE Development Environment.
2.4.1 Component model design

This section describes the following aspects of component model design:
Separation of specification and implementation

Component architecture
Presentation layer
Presentation components
Business logic layer
Controller components
Session components
Object service components
Data access layer
System services layer
Separation of specification and implementation

The specification and implementation of components should be two
separate processes.
The specification of a component is a distinct and separate process from
implementing the component. The process of defining component
specifications takes place during analysis, and results in the definition of
logical components, that is, a description of a component that does not
include implementation details. The specification of how the component
is to be implemented takes place during the design phase and results in
the specification of components fitting the required architecture.
The design process for defining component implementations is
technically oriented. The process involves determining the most effective
way to meet the functional specifications within the selected technical
and application architectures. The end result of this design process is a
fully defined set of components, component links, and a model of how
they are distributed across the application architecture.
2-22
UNIFACE V7.2
The separation of specification and implementation provides a number of

significant benefits:
Component specifications are developed to address the needs of the
business, and are separate from any technology or implementation
issues.
A single logical component can have multiple implementations, each
based upon the requirements of the application architecture.
Component architecture
The purpose of component model design is to define the appropriate
structure for reusable components that satisfy the designated business
needs. The process of defining these components must take into account
the characteristics and constraints of the application architecture. The
typical application architecture is composed of three different layers or
tiers (see figure 2-14):
Presentation layer
Data access layer
The function of each of these layers is described in the following sections,
along with the specialized components that are found within them.
2-23
UNIFACE V7.2
Figure 2-14 Example of a three-tier architecture.
Presentation layer
The presentation layer contains the graphical user interface (GUI) for an
application. The objects within the presentation layer provide a graphical
realization of the set of data elements and interfaces made available by
the applications business objects. However, they merely disclose these
data elements and interfaces and do not interact directly with
2-24
UNIFACE V7.2
application data sources; they request and receive data from objects
residing in the business logic layer. Objects residing in the presentation
layer are generically referred to as presentation components, even
though they can be implemented as browser-based server pages or GUI
forms.
Presentation components
Presentation components have the following characteristics:
Presentation components are typically resident or are downloaded to
the users computer.
Presentation components do not contain business rules. They allow
the user to enter, retrieve, change, and delete data. However, the
operations required to validate, process, and store this data reside
within components in the business logic layer rather than in the
presentation layer itself.
Presentation components do not maintain a constant connection to
components in the business logic layer. Instead, the business logic
layer sends a stream of data to, or receives a stream of data from these
components based upon the functions specified by the user. The
connection between the two components last only as long as needed to
pass the data stream, then the connection is terminated. The validity
of the data stream within the context of the function being performed
by the user is determined by the business logic components rather
than within the presentation component itself. This implies that the
presentation component does not contain any state behavior and is,
therefore, stateless.
Presentation components are not aware of the previous functions or
transactions performed by the user, so they do not maintain context
information.

The business logic layer contains the objects that realize an applications
business rules including:
process-based business rules

structural business rules
rules that apply to a particular class or collection of objects
rules that apply to particular occurrence of an object class
2-25
UNIFACE V7.2
These business rules are implemented as operations within several types

of stateful, black box components. These operations are accessible
through the public interfaces of these components.
The term stateful means that a component is aware of the state or status
of an occurrence or record set at the beginning of a transaction, and then
checks to ensure that any changes to the state of this data is valid before
concluding the transaction. To do this, the component must keep track of
the context, that is, the sequential history, of the functions performed
against the specific occurrence or record set over the course of the
transaction.
The basic types of business logic components include the following:
Session components
Controller components are the highest level components in the business
logic layer. Controller components can have the following
responsibilities:
Realize an applications business rules that control the flow and
relationships between tasks. These business rules are expressed as
pre-conditions, post-conditions and branching logic.
Activate one or more session components as needed to satisfy the
requirements of a task.
Maintain state and context information pertaining to the tasks they
manage.
Session components
Session components disclose task-specific business behavior of
hierarchical record sets to the presentation layer. Session components
can have the following responsibilities:
Define specific hierarchical record sets.
Implement and disclose specific business behaviors for these record
sets to the presentation layer, in a presentation-independent format.
Implement business rules that govern referential integrity for the
record set they define.
Supply data to the presentation layer.
2-26
UNIFACE V7.2
Maintain state and context information in order to manage

transactions and ensure referential integrity.
Object service components work together with session components to
disclose the business behavior of specific occurrences of business objects.
Object service components can have the following responsibilities:
Implement and disclose business behaviors pertaining to specific
attributes or occurrences of a business object or a collection of
occurrences of a business object.
Implement data access business rules for a business object.
Implement business rules pertaining to specific post-conditions of
attribute or occurrence level business rules, for example, the creation
of a Price History occurrence (post-condition) each time the Price
attribute is changed.
Implement business rules for specific occurrences of a business object,
so that they are stateful and maintain context information. They can
also share this state and context information with session
components.
Data access Layer
The data access layer contains the objects that provide transparent,
heterogeneous access to various application data sources. Primarily,
these objects are implemented as data access components, such as DBMS
drivers or ODBC drivers. Additionally, there can be other more complex
data access components such as UNIFACE PolyServer or encapsulated
DBMS stored procedures (components that provide a direct interface to
DBMS stored procedures).
System services layer
The system services layer contains the objects that implement functions
not owned by any specific application. Typically, these functions are more
general in nature, and provide basic services (such as security, technical
key generation, and error handling) needed to support any application.
The functionality provided by the system services are also encapsulated,
and are accessible only via the published interface of each component.
2-27
UNIFACE V7.2
2.4.2 Component design

Designing components is simplified by the separation of the application
in the distinct layers as described above. The method for defining
components is as follows:
1. Consider all operations for a given business object. These could
include operations from more than one class.
2. Determine the level of the operation (package, class, instance,
attribute) and the application layer in which it should reside
(presentation, business logic, or data access).
3. Typically, you do not have to develop components for the data access
layer because they are usually included within the component
architecture.
4. Presentation components should not contain any business logic, but
they can activate operations on components residing in the business
logic layer.
5. The business logic operations are allocated to controller components,
session components, or object service components as follows:
Operations that implement business rules pertaining to process
control between tasks (from pre-conditions, post-conditions, and
guards on activity diagrams) are placed into controller
components. There should be one controller component for each
component package.
Operations that implement business rules pertaining to
referential integrity and process control within a transaction are
placed into a session component. There will be one or more session
components for each business object.
Operations that implement occurrence-level or attribute-level
business rules pertaining to specific occurrences or a collection of
occurrences of a business object, including business rules for data
access, are placed in an object service component. There should be
one object service component for each business object.
6. Any operation or function not associated with a specific class or
business object should be placed in a global service component
residing in the system services layer.
2-28
UNIFACE V7.2
Component diagrams
Once the process of defining components has been completed, the
components can be represented graphically using component diagrams.
Component diagrams are related to package diagrams. Component
packages are the logical containers, or sub-systems for the components
for a given business object. Where is a one-to-one correspondence
between component packages and class packages.
Each component package contains a component diagram (see
figure 2-15). The Component diagram depicts the components residing
within the package and their links to one another. Links to components
in other packages can also be depicted. For clarity, it is recommended to
show all of the operations contained within each component.
Components in the component diagram are logical by nature, meaning
that they specify no details pertaining to implementation technology.
2-29
UNIFACE V7.2
<<frm>>
PPH110I
Index
Company
<<frm>>
PPH410I
Index
Material
<<html>>
<< svc >>

PPH430S
PPH020M
Maintain
Order
Service
Catalog
<< svc >>

PPH020S
Service Order
<< rpt >>
PPH020R
Report Order
Figure 2-15 Example of a component diagram.
2.4.3 Relational model design

After mapping the operations in a class diagram to interfaces and logical
components, the next step in the design phase is to map the structural
elements of the class diagram (classes, associations, and attributes) to
the relational model.
The class diagram represents the business in the real world and can be
used to communicate with the user. However, the class diagram does not
provide all of the necessary design information for a relational model.
The structural part of the class diagram must be mapped to a relational
model.
2-30
UNIFACE V7.2
This mapping process is based on simple, unambiguous rules that allow

for the definition of relational tables, attributes, and key structures from
the class diagram elements. Once the relational model has been created,
it is mapped into the UNIFACE application model during the UNIFACE
design implementation activity (see section 2.4.6 UNIFACE design
implementation).
2.4.4 Business rule design

Business rules embody the constraints under which the business
operates. Some business rules are applicable to the whole business and
others are statements that must be true so that two components can run
compatibly. Business rules must be implemented in the system, so they
must be clearly identified, categorized, and documented.
Many of these business rules have already been identified during the
previous analysis and design activities. It is best, early in analysis, to
establish a formal business rules repository where all types of business
rules can be documented in a standard format (see table 2-1). Tracking
the business rules in this way will help to ensure that they are defined
only once, in a clear and precise manner that is easily validated by users.
In addition, the business rules repository provides an excellent tool for
impact analysis when changes to business rules occur.
Until now, the majority of the business rules have addressed the
functionality within a single component or business process. The purpose
of the business rule design activity is to identify and define the rules that
govern the interaction between the components, often referred to as the
application workflow.
The business rules that govern the workflow must be modeled in the
same manner as those that apply to an applications business logic.
Therefore, an additional type of class (stereotype) called a controller
class, must be added to the class package for each business object. These
controller classes provide the mechanism for the workflow-related
business rules to be defined as behaviors (operations). A corresponding
controller component (see section 2.4.1 Component model design) must
be defined in each component package.
2-31
UNIFACE V7.2
2.4.5 Inter-component communication design

Once the design steps of component model design, relational model
design, and business rule design are completed, the complete set of
application components can be distributed over the different layers of the
architecture (see figure 2-16). When the distribution scheme has been
established, the actual interactions between the components in the
various layers of the architecture can be shown using an inter-component
communications diagram. This diagram provides a graphic view of how
the application components work together, how they exchange
information, and how they maintain process control information such as
state and context.
Presentation layer
: Order Clerk
: Maintain Order
: Index
Company
Business Logic layer

: Index Material
: Service
Catalog
: Order Session
Service
: Business Rule
: Order Object
Service
Add Order( )
Select Company(COMPANY)
Add Order Line(COMPANY, order date)
Select Material(COMPANY, MATERIAL)
Get Material Price(COMPANY, MATERIAL, order date, price)
Compute Order Total (ORDER)
Create(ORDER, ORDERLINE)
Validate Uniqueness(
ordernumber
)
Validate dates(
orderdate
, expect date)
Figure 2-16 Example of an inter-component communication diagram.
2-32
UNIFACE V7.2
2.4.6 UNIFACE design implementation

The previous design steps have demonstrated how components in a
layered architecture are created. Up to this point, the design deliverables
have been logical, meaning that they are technology-independent.
The construction and assembly of components, subsystems, or
applications is done during the construction phase. The technology used
to establish the construction environment is obviously up to the specific
organization involved.
The technology independence of a component-based approach represents
a major advantage over other development techniques. It does not matter
whether components are custom-developed, purchased, or harvested
from legacy applications, as long as they satisfy the specified functional
and interface requirements. However, the way in which components are
constructed and assembled can vary for each technology. These
differences need to be taken into consideration when planning the
construction phase.
The UNIFACE design implementation activity determines how the
design deliverables should be implemented in the UNIFACE
environment.
2-33
UNIFACE V7.2
2.5 Development
Figure 2-17 Development.
Once all of the components have been defined for a package, development
can begin. Because the component-based development process is
iterative, and components themselves are self-contained and
independently deployable, the development effort can be broken down
into pieces called increments. This technique is called incremental
development.
2-34
UNIFACE V7.2
2.6 Incremental development approach

Incremental development means that an application can be developed in
small pieces that each provide a complete section of functionality. These
sections correspond to class or component packages. In a large
application, each package can itself be an entire subsystem, and can be
broken down into smaller packages.
Each package must be prioritized based on the functionality it contains,
and its relative importance to the other packages, and the application as
a whole. For example, figure 2-18 shows that the components in the
Article and Vendor packages must be developed before the Purchase
Order packages (because they depend on the functionality in the other
packages).
Figure 2-18
Increments of a complete information system.
2-35
UNIFACE V7.2
Incremental development also allows for increments to be developed in

parallel. This means that development of several increments can take
place at the same time. While parallel development is an advantage in
reducing the overall development time, it does require that the staging of
the increments be well-planned and coordinated. It also requires that the
proper standards and guidelines be in place prior to the beginning of
development.
2.6.1 Incremental development process

The first step in the process of incremental development is to validate the
scope of the project (the project scope is defined during inception, but can
be refined at this point), which usually includes the following stages:
Stage 1Objectives
Stage 2Architectural visioning
Stage 3Planning
Stage 4Standards and guidelines
Stage 5Available resources
Stage 6Definition of the business functionality (contained within
the business use cases) to be developed
The second step is to begin working on the package that you have chosen
to be delivered first. The development of the first increment helps to
identify the following:
2-36
Planning
Quality of the standards and guidelines
Adequacy of the available resources
Design or technology issues relating to the application architecture
UNIFACE V7.2
Feedback
Scope
of
project
Resources
Development 1
Development 2
Objectives
Development 3
Standards
and
guidelines
Development 4
Planning
Development 6
Solutions
Development 5
Delivery
and
evaluation
Development 7
Components
Figure 2-19 Process of incremental development.
An evaluation after the second step identifies any changes that must be
made in the subsequent steps and, in doing so, minimizes the risks for
each step of the project.
The third step is to continue the development of the components
contained within the chosen package, and to evaluate the scope of the
project with its resources, objectives, standards and guidelines, planning,
and solutions.
2.6.2 Prioritizing increments

When defining the order in which the increments are to be developed and
delivered, there are some additional criteria that should be considered:
ValueThe value of a business use case to the organization can
usually be specified as:
Having a high political value within the organization
Having a high economic value to the organization
Having neither a high political nor economic value
2-37
UNIFACE V7.2
CostTo be successful, it is important to keep costs as low as possible.

Start with the development of packages that are relatively
inexpensive to implement. There is so much to learn at the beginning
of a project, so the scope of the project can need to be adjusted because
it is difficult to make accurate estimates of the time and resources
needed until some baseline measurements have been made.
On the other hand, the more expensive package can be considered
first if the organizations resources are experienced, and the smaller,
cheaper packages can be developed in parallel.
DependencyDependencies between the packages can influence the
order in which increments are developed. If, for example, package A
depends on services provided by package B, you could decide to
develop package B first.
Probability of failureThis can be determined by weighing the
complexity of the functionality, complexity of the architecture
(hardware, network, DBMSs, and so on) and, perhaps the most
important, your gut feeling.
Again, it is probably best to begin with the low probability of failure
increment first, especially when the development team is
inexperienced. However, if the team is more experienced,
mission-critical or higher probability of failure increments can be
given a higher priority.
2.7 Iterative development approach

Once the development plan for the increments has been defined, they can
be developed using iterative development techniques. Using an iterative
development approach, each increment is built and refined through a
series of iterations. During each iteration, components are constructed or
extended with specified attributes and behaviors.
2-38
UNIFACE V7.2
Figure 2-20 Incremental and iterative development combined.
Each iteration follows the overall CBD life cycle (see figure 2-20). During
the first iteration, the inception, analysis, and design activities are done
for the entire system (as defined by the scope of the project). Then, as
described in section 2.6 Incremental development approach, the
development effort is broken down into increments. From this point on,
the focus of each iteration is on the contents of the increment rather than
on the system as a whole. It is important to note, however, that changes
occurring within one increment can affect other increments.
2-39
UNIFACE V7.2
Each iteration follows the same basic steps:

1. The components within each increment are developed according to
the requirements defined during analysis and design.
2. Experimental prototypes can be used where needed (see section 2.8.2
Experimental prototyping) to assist in making component
implementation choices.
3. Perform quality assurance testing for each of the components
constructed (see section 2.9 Quality assurance).
Note: During the course of iterative development, quality assurance

primarily consists of unit testing and regression testing. When the
development of the increment is completed, quality assurance expands to
include performance testing, integration testing, and acceptance testing
prior to the deployment of the components.
4. Test results and user feedback are used to identify additional
requirements and refinements.
5. The analysis and design phases are repeated to model the changes
required to accommodate new requirements.
6. Steps 1 through 4 are repeated for each subsequent iterations.
When the final iteration has been completed and the components have
been fully certified, the increment can be deployed and integrated.
2.8 Prototyping approach

Prototyping is a useful tool in successful component-based development.
It is important to understand, however, that prototyping should be used
to augment the CBD analysis and design techniques described in this
document, not to replace them. Quality, reusable components cannot be
built through protoyping alone. Prototyping must therefore be used
within a fairly strict context and at specific points in the CBD life cycle.
There are two main categories of prototyping commonly used in CBD:
Exploratory prototyping
Experimental prototyping
2-40
UNIFACE V7.2
2.8.1 Exploratory prototyping

Exploratory prototyping is most commonly applied in the inception and
analysis phases. It is used to establish or clarify application
requirements interactively with users.
The exploratory prototyping technique involves the development of a
graphical or paper-based mock-up of the portion of an application that
the users interact with in order to perform a specific business function
(use case). The prototype should be basic, including only the business
objects, attributes, and functions described in the use case description for
the function (see figure 2-4 for an example). However, as the prototype is
simulating the user interface, any GUI standards in place should be used
to ensure the prototype has a consistent look and feel with other
applications.
Exploratory prototypes are most effective when used in a joint
application development (JAD) setting. The suggested guidelines for
using exploratory prototypes are as follows:
Develop a graphical or paper-based prototype from the requirements
defined within a use case description. The prototype should address
the functionality required to satisfy all scenarios of the chosen use
case.
The use case diagram, description, and exploratory prototype should
be packaged together and presented to the users in a JAD session.
The analysts who developed the prototype should facilitate this
session, and should explain the JAD process to the users and indicate
how they are expected to participate.
The facilitator should then review the use case and description under
discussion, and then demonstrate each of the scenarios using the
prototype as a visual guide.
As each step of a scenario is discussed, the prototype can be used to
indicate which business objects, attributes, and functions are
involved.
A detailed discussion should take place at every step to identify and
define each business rule required to complete the step, the level of
the business rule, and the timing of the business rule.
This process can identify many new business rules, and clarify the
definition of business rules that have already been identified.
This new information is used to update the use case diagrams and
descriptions. It is also used to extend and refine the business rules
catalog (see figure 2-5).
2-41
UNIFACE V7.2
Exploratory prototyping is a useful analysis tool. It is effective for

creating a detailed, common understanding of the requirements for both
users and analysts. The better the understanding of the requirements,
the easier it is to design and build components that satisfy those
requirements.
Figure 2-21 Use of Exploratory Prototyping.
2.8.2 Experimental prototyping

Experimental prototyping is most commonly used during the design and
development phases. Sometimes referred to as proof of concept
prototyping, it is used to determine the most effective implementation
method for a component.
2-42
UNIFACE V7.2
Often, a component or group of components must be deployed in multiple

architectures or must meet a variety of performance requirements.
Furthermore, there can be a number of possible ways in which the
components can be designed (layering of functions), constructed
(different development tools), or deployed (on the client or on a server).
Experimental prototyping provides a means to test the various
possibilities, compare the results and to identify the most appropriate
implementation. The suggested guidelines for experimental prototypes
are as follows:
Determine which component or components need to be involved in the
prototype.
Define a set of goals and boundaries for the prototype. These goals are
based upon the specified requirements of the components involved in
the prototype (such as support for multiple architectures,
performance, throughput, and fault tolerance).
Construct functional versions of the components, focusing on the core
functionality, avoiding anything extraneous or superficial.
Execute the components under the specified conditions and document
the results.
After all versions of the components have been executed, compare the
results. It is often most effective to put the prototype results into a
tabular format so the measurements and metrics can be easily viewed
and compared.
Evaluate the results based upon the stated goal of the prototype and
identify the most appropriate implementation.
Experimental prototypes can be helpful in making difficult design and
development decisions. However, they should never be considered as
production-quality code.
2-43
UNIFACE V7.2
2.9 Quality assurance
Figure 2-22 Quality assurance.
The components resulting from the iterative development efforts must be

thoroughly tested to determine whether they are ready for deployment,
or require further refinements. The activities of quality assurance are:
2-44
Testing
Deployment
Service level management
Usability measurement
UNIFACE V7.2
2.9.1 Testing
The constructed functionality must be tested against all requirements
and the agreed acceptance criteria, including completeness, robustness,
and stability. This means that the functionality should operate correctly
in all architectures in which it is deployed, and perform according to the
standards and measures established for the application.
A portion of testing is actually done during iterative development, and
other parts are done as part of quality assurance. Testing done during
development, called white box testing, is done by developers. Testing
done during quality assurance, called black box testing, is typically done
by users or with automated testing tools.
2.9.2 White box testing

The purpose of white box testing is to verify the accuracy and validity of
the internal organization and function of a component. It generally
requires detailed knowledge of the structural and behavioral
characteristics of business objects appearing in the component, and
mainly focuses on the identification of defects within the source code.
There are two main types of white box testing:
Unit testing
Unit integration testing
Unit testing
Unit testing is the most common type of testing. It involves testing a
component in isolation to validate that all of the functionality works
according to the relevant requirements, and does not produce any
run-time errors. This testing is best done by someone with a thorough
understanding of component development, but not the same person who
developed the component.
Unit integration testing
Unit integration testing involves testing a component as a part of a small
group of related components contained within a single increment. The
purpose of this testing is to verify that a component functions as required
within the larger context of specified business functions, and that it
integrates properly with its related components and does not cause any
2-45
UNIFACE V7.2
run-time failures. This testing can require the creation of stub programs
for any related components that are not yet completed. Again, this
testing is best done by someone with a thorough understanding of
component development, but not the same person who developed the
component.
2.9.3 Black Box Testing

Black box testing takes place when the development of an increment has
been completed. Where white box testing deals with the internal function
of a component, black box testing deals with its externally identifiable
function and interface. It focuses on identifying defects related to a
components function when interacting with users, the architecture, or
with other components. There are three main types of black box testing:
System testing
System integration testing
Acceptance testing
System testing
System testing takes place when an increment (a full system or
subsystem of components) has successfully completed unit testing and
system testing. The focus of the testing is not on the function of
individual components. It is concerned with validating that all
components within the increment function together as specified within
the context of the tasks performed by the users. For the system test to be
successful, all components must function correctly in their own right, and
interact correctly with one another through their interfaces. This testing
should take place in an environment that matches the intended
deployment architecture for the components. System testing can be done
by users, but can also be done effectively using automated testing
techniques. For more information, see section 2.9.4 Testing Techniques.
System integration testing
System integration testing takes place when system testing has been
successfully completed. It involves integrating the new components with
those already in the production library. The goal of system integration
testing is to validate that the new components interact correctly with the
existing components, both by providing functionality as specified in the
relevant requirements, and by effectively collaborating with other
2-46
UNIFACE V7.2
components through their interfaces without causing any run-time

failures. This testing should take place in an environment that matches
the intended deployment architecture for the components. System
integration testing can be done by users, but can also be done effectively
using automated testing techniques. For more information, see
section 2.9.4 Testing Techniques.
Acceptance testing
Acceptance testing is the final set of tests and takes place when all other
system testing has concluded. Testing thus far has focused on
functionality. Acceptance testing focuses on validating that the
components within an increment perform acceptably, within the
specified deployment architecture, according to the metrics outlined in
the systems non-functional requirements (defined during inception).
There are several types of acceptance testing used to validate various
aspects of the components performance:
Performance testing
Stress testing
Concurrency testing
Performance testing
Performance testing involves comparing the actual performance of a
component or set of components to a predefined set of performance
metrics. These metrics can include measurements such as response time,
data base I/O, memory or CPU utilization, network traffic, or package
size. For example, a user can have a requirement to retrieve all of the
account activity for a customer and display it on a Web page within five
seconds. Each transaction must be tested within the specified
deployment environment, under production conditions. The performance
data can be gathered manually, but it is helpful to have appropriate
system or network management tools for capturing this data. If the
components perform within the specified requirements, they are certified
to perform acceptably. If they do not perform acceptably, they require
further refinement or reengineering to improve their performance.
2-47
UNIFACE V7.2
Stress testing
Stress testing involves measuring the capacity of components to process
large volumes of transactions within a specified period of time. For
example, an Order Entry component can have a requirement to be able
to process 2000 orders per hour. To accurately perform volume testing,
exact production conditions must be simulated. The subject components
are used to process the specified number of transactions. At the
conclusion of the test, the actual time and throughput metrics from the
components are documented. If the components perform within the
specified range, they are certified to perform acceptably. If they do not
perform acceptably, they require further refinement or reengineering to
improve their performance.
Concurrency testing
Concurrency testing is an extension of volume and stress testing. It
involves measuring the performance of components while in use by a
specified number of concurrent users. A component can process an
acceptable volume of transactions when used by one or a few users, but
might not perform at the same level when used by many concurrent
users. Again, accurate multiuser testing requires an exact simulation of
production conditions, and that the specified number of users attempt to
perform a specified function simultaneously. If the components are able
to handle the volume of concurrent users within the specified
parameters, they are certified to perform acceptably. If they do not
perform acceptably, they require further refinement or reengineering to
improve their performance.
2.9.4 Testing Techniques

Much of quality assurance testing can be done manually. However, there
are several testing techniques that can make this testing consistently
repeatable, more effective and less time consuming. They are:
Regression testing
Automated testing
2-48
UNIFACE V7.2
Regression testing
Regression testing is appropriate when a component is modified, or a new
component is added to a group of existing components. Regression testing
involves running a set of components through a pre-set series of tests and
comparing the results to a master set of results. If all of the regression
test results match the master set, the new component or function is
working correctly. If any of the tests differ in result from the master,
there is a problem. Identifying which part of the regression test set failed
isolates the offending component(s) or operation(s), simplifying the
debugging process. Regression testing is usually done by testing
specialists or by automated testing tools.
Automated testing
Many of the tests described above can be automated with a testing tool.
Automated testing tools run predefined test sequences called test scripts.
These test scripts can be developed from various sources. However,
modeling deliverables, such as use cases, interaction diagrams, and
inter-component communications diagrams provide a wealth of
information that can easily be mapped into test scripts.
2.9.5 Deployment
When components have been accepted by the users and certified as being
ready for production, they can be deployed into the production
environment. Deployment involves the actual distribution of the new
components to the various physical nodes throughout a network. This
should be done in accordance with version control and release
management standards and procedures.
2-49
UNIFACE V7.2
2.9.6 Service level management

The performance metrics defined for components defined in the systems
non-functional requirements apply even after the components are
deployed into production. Service level management is the process of
periodically capturing the actual performance metrics of components and
comparing them with their specified standards. Although components
could have performed acceptably for some time, increases in transaction
volumes, concurrent users or changes in hardware and software
configurations could cause their performance to slip below an acceptable
level. Service level management must be an ongoing process.
Performance measurements can be taken at specified intervals, either by
manual testing or through the use of network management or
performance monitoring tools. These measurements are then compared
to the performance metrics established for the components. Any
components found to have slipped below acceptable levels require tuning
or additional refinement to improve their performance.
2.9.7 Usability measurement

Usability refers to how well the functionality of components fit the way
in which users do their jobs. When a set of components is originally built
and deployed, it presumably meets user needs and expectations. Over
time, however, the business can evolve, which can change the way in
which various business functions are performed. Eventually,
applications can become less usable to the users and begin to create
business problems (for example, a legacy application that does not
support e-commerce). Therefore, applications must be reviewed
periodically to ensure that their usability remains high and that their
functionality is still in line with the current business.
2.10 Summary
The component-based development methodology provides an effective
framework for the production of high quality, highly effective reusable
components.
2-50
UNIFACE V7.2
The CBD process is structured, with distinct phases that have specific
deliverables and goals. It is also iterative, featuring cycles of analysis and
design phases in conjunction with incremental development and delivery
approaches. This combination of structure and iteration provides the
optimum flexibility to accommodate a project of any size, using any
technology.
2-51
UNIFACE V7.2
2-52
UNIFACE V7.2
Appendix A Sample use case description

The use case in this appendix is an example of the format recommended
for describing use cases in a software development project using the
UNIFACE component-based methodology.
A.1 Example of a use case description
Use case
Process purchase orders
Actor(s)
Order Clerk, Order Manager
Goal
Manage the entry and maintenance of purchase orders for products. The
purchase orders are received from retailers.
Pre-conditions
Product and quantity needed for order must be known.
Business rules
The following business rules apply:

A purchase order can be for one or more products.
A-1
UNIFACE V7.2
A purchase order can be entered manually, or submitted online by a

retailer.
Each purchase order must have a valid contact.
Any purchase order received from a retailer totaling $10,000 or more
must be authorized by the retailers designated approval authority.
Authorization requests are sent to retailers via the Internet for online
orders, or by fax for manual orders.
Standard scenario
1. Enter purchase order.
2. Select company.
3. For each orderline:
Select product to be ordered.
Get current product price.
Compute order total.
Alternate scenario 1 (submit order using the Internet)

1. Submit purchase order.
3. Compute order total.
4. Assign order number.
Alternate scenario 2 (order total >= $10,000)

1. Submit purchase order.
Compute order total.
A-2
(Dec 2000) Sample use case description
UNIFACE V7.2
3. Assign order number.

4. Send authorization request.
Post-conditions
The following post-conditions apply:

Approved purchase orders can be shipped.
Orders requiring approval are pending until approvals are received.
Business objects
Company, Purchase Order, Product
A-3
UNIFACE V7.2
A-4
(Dec 2000) Sample use case description

Uniface Seven Development Methodology For Component-Based Applications

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uniface Seven Development Methodology For Component-Based Applications

Uploaded by

Copyright:

Available Formats

UNIFACE Component-based

24-hour online customer support and learning

Objects and components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3

Component-based development process

UNIFACE Component-based Development Methodology (Dec 2000)

Modeling processdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-21

Appendix A Sample use case description

UNIFACE Component-based Development Methodology (Dec 2000)

understanding of the internal workings and goals of the business must

UML provides an excellent means to model and communicate an

(Dec 2000) Introduction

The UNIFACE component-based development methodology enhances

1.1 Objects and components

1.2 What is an object?

1.2.1 Object structure

UNIFACE Component-based Development Methodology (Dec 2000)

1.2.2 Object behavior

(Dec 2000) Introduction

UNIFACE Component-based Development Methodology (Dec 2000)

Figure 1-3 Adding a new behavior.

1.3 What is a component?

(Dec 2000) Introduction

Figure 1-4 Implementing an operation within a component.

1.3.1 Design by Contract

UNIFACE Component-based Development Methodology (Dec 2000)

Development of components that accurately meet the needs of the

Standards for defining component requirements

1.3.2 Component interfaces

(Dec 2000) Introduction

The definition of published component interfaces can depend on the

1.3.3 Data hiding

UNIFACE Component-based Development Methodology (Dec 2000)

1.4 Why develop component-based applications?

1.4.1 Adding new functionality

1.4.2 Reusing components

(Dec 2000) Introduction

If you develop a number of small components (a small component would

Figure 1-5 Trade-off between reuse and productivity.

1.4.3 Easier maintenance of existing functionality

UNIFACE Component-based Development Methodology (Dec 2000)

1.4.4 Replacing components with other components

1.4.5 Separating application layers

(Dec 2000) Introduction

There is also another variety of high-level components, called system

1.4.6 Assembly of applications is simplified with components

UNIFACE Component-based Development Methodology (Dec 2000)

possible to open up previously closed, in-house systems to customers and

1.5 Why a new component-based modeling technique?

(Dec 2000) Introduction

Figure 2-1 Component-based development process.

Figure 2-1 provides an overview of the component-based development

UNIFACE Component-based Development Methodology (Dec 2000)

Smaller, more manageable development tasks

(Dec 2000) Component-based development process

Improved ability to plan and execute development projects

Figure 2-2 Inception.

UNIFACE Component-based Development Methodology (Dec 2000)

The inception phase takes place prior to modeling. The purpose of

(Dec 2000) Component-based development process

Additionally, you can be required to provide the project sponsors with a

Figure 2-3 Example of a business use case diagram.

UNIFACE Component-based Development Methodology (Dec 2000)

Figure 2-4 Example of a presentation prototype.