uniface component-based development methodology...computer equipment object. for example, the...

151157206-00Revision 0Dec 2000 UMET

UNIFACE Component-based

Development Methodology

UNIFACE V7.2

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) athttp://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 & PracticesP. O. Box 129331100 AX Amsterdam e-mail: DM&[email protected] Netherlands fax: +31 (0)20 311-6213

UNIFACE Component-based Development Methodology (Dec 2000) iii

UNIFACE V7.2

Contents

1 Introduction1.1 Objects and components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-31.2 What is an object? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3

1.2.1 Object structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-31.2.2 Object behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-41.2.3 Encapsulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-4

1.3 What is a component?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-61.3.1 Design by Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-71.3.2 Component interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-81.3.3 Data hiding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-9

1.4 Why develop component-based applications? . . . . . . . . . . . . . . . . . . . . . . .1-101.4.1 Adding new functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-101.4.2 Reusing components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-101.4.3 Easier maintenance of existing functionality . . . . . . . . . . . . . . . . . . .1-111.4.4 Replacing components with other components. . . . . . . . . . . . . . . .1-121.4.5 Separating application layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-121.4.6 Assembly of applications is simplified with components . . . . . . . . .1-131.4.7 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-13

1.5 Why a new component-based modeling technique? . . . . . . . . . . . . . . . . . .1-14

2 Component-based development process2.1 Inception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-32.2 The Modeling Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-82.3 Modeling process—analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-10

2.3.1 Business function modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-112.3.2 Object modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-132.3.3 Behavioral modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-15

UNIFACE V7.2

iv (Dec 2000)

2.4 Modeling process—design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-212.4.1 Component model design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-222.4.2 Component design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-282.4.3 Relational model design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-302.4.4 Business rule design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-312.4.5 Inter-component communication design . . . . . . . . . . . . . . . . . . . . .2-322.4.6 UNIFACE design implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-33

2.5 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-342.6 Incremental development approach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-35

2.6.1 Incremental development process. . . . . . . . . . . . . . . . . . . . . . . . . . .2-362.6.2 Prioritizing increments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-37

2.7 Iterative development approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-382.8 Prototyping approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-40

2.8.1 Exploratory prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-412.8.2 Experimental prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-42

2.9 Quality assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-442.9.1 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-452.9.2 White box testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-452.9.3 Black Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-462.9.4 Testing Techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-482.9.5 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-492.9.6 Service level management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-502.9.7 Usability measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-50

2.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-50

Appendix A Sample use case description

Chapter

UNIFACE V7.2

UNIFACE Component-based Development Methodology (Dec 2000) 1-1

1 IntroductionComponent-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

UNIFACE V7.2

1-2 (Dec 2000) Introduction

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.

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.

Construction

Assembly

Elapsed time

Eff

ort

Modeling(Analysis & Design)

UNIFACE V7.2


The UNIFACE component-based development methodology enhances Compuware’s 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 componentsBefore 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

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 object’s structure is similar to data specifications, and that the object’s 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 object’s 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.

UNIFACE V7.2


Figure 1-2 The computer equipment object’s behavior encapsulates its data.

Advantages of encapsulation

In today’s 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:

ComputerEquipment

�

�

Serial NumberModel NumberManufacturerCostRetail Price

Order Equipment

ReceiveEquipment

Sell Equipment

UNIFACE V7.2


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:

ComputerEquipment

�

�

Serial NumberModel NumberManufacturerCostRetail Price

Order Equipment

ReceiveEquipment

Sell Equipment

RepairEquipment

Warranty TypeWarranty Length

UNIFACE V7.2


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 component’s contract and consist of the following:

• Preconditions—conditions that must be true before an operation can be executed

• Business rules—functional requirement for each operation• Signatures—set of input and output parameters for each operation• Post conditions—output conditions for each operation• Invariants—global 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:

ComputerEquipment

�

�

Serial NumberModel NumberManufacturerCostRetail PriceWarranty typeWarranty length

ReceiveEquipment

Sell Equipment

RepairEquipment

Order Equipment

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 operation’s 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 component’s 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.

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 application’s 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.

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.

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.

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.

Packaged applications

Application components, subsystems

Business components,subsystemsReuse Productivity

Objects, controls,class libraries

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 user’s 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.

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 component’s 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

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.

Chapter

UNIFACE V7.2


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.

UNIFACE V7.2

2-2 (Dec 2000) Component-based development process

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:

• Inception—gather business requirements from users and stakeholders

• Analysis—produce and validate UML analysis models from business requirements

• Design—apply the properties of the application architecture to the analysis models to produce the UML design models

• Development—develop components based on the analysis and design models

• Quality assurance—test 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.

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.

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 statement—A clear, concise definition of the business problems, objectives and scope of the proposed application.

• Actor analysis—A precise definition of the roles and responsibilities of all actors that interact with the proposed application.

• Business use cases—Graphical 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 prototypes—A 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 catalog—A 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 requirements—definition 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.

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.

UNIFACE V7.2


Figure 2-4 Example of a presentation prototype.

UNIFACE V7.2


Figure 2-5 Example format for a business rules catalog.

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:

• 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 architecture’s 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.

UNIFACE V7.2


2.3 Modeling process—analysis

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)

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).

UNIFACE V7.2


Figure 2-8 Elementary use case diagram.

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.

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.

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:

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 diagramsSequence 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).

UNIFACE V7.2


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.

: Order Clerk : PURCHASE_

ORDER : COMPANY : PURCHASE_

ORDER_LINE : PR ODUCT : CATALOG

Enter Order ( )

Select Compa ny(COMPAN Y)

Ad d Order Line(COMPAN Y)

Select Product(PRODUCT)

Get Mater ial Pri ce(COMPANY, PRODU CT, pr ice, date)

C om pute Ord er Total(total_am ount)

As s ign Order Number (Orde r_Num )

*

[All Orderlines entered]

Compute Lin e Amount(Amoun t, q uantity_ord, pri ce)

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.

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.

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.

UNIFACE V7.2


2.4 Modeling process—design

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 design—Mapping the dynamic behavior of the class diagrams to interfaces and components (interface diagram and component diagram).

• Relational model design—Mapping the static information of the class diagrams to a relational data model (persistent data model).

• Business rules design—Mapping the business rules to business logic components.

UNIFACE V7.2


• Inter-component communication design—Mapping the business processes by linking the components (inter-component communication diagram).

• UNIFACE design implementation—Defining 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.

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• Business logic 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.

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 application’s business objects. However, they merely disclose these data elements and interfaces and do not interact directly with

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 user’s 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.

Business logic layer

The business logic layer contains the objects that realize an application’s 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

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:

• Controller components• Session components• Object service components

Controller components

Controller components are the highest level components in the business logic layer. Controller components can have the following responsibilities:

• Realize an application’s 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.

UNIFACE V7.2


• Maintain state and context information in order to manage transactions and ensure referential integrity.

Object service components

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.

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.

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.

UNIFACE V7.2


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.

PPH020M

Maintain Order

PPH110I

<<frm>>

Index Company

Index Material

PPH430S<< svc >>

Service Catalog

PPH020S<< svc >>

Service Order

PPH020R<< rpt >>

Report Order

PPH410I

<<html>>

<<frm>>

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 application’s 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.

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.

Figure 2-16 Example of an inter-component communication diagram.

: Business Rule : Order ObjectService : Order Clerk

: Maintain Order : Index Company

: Index Material : Service Catalog

: Order SessionService

Compute Order Total (ORDER)

Add Order( )

Add Order Line(COMPANY, order date)

Create(ORDER, ORDERLINE)

Select Company(COMPANY)

Select Material(COMPANY, MATERIAL)

Get Material Price(COMPANY, MATERIAL, order date, price)

Validate dates(orderdate, expect date)

Validate Uniqueness(ordernumber)

Presentation layer Business Logic layer

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.

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.

UNIFACE V7.2


2.6 Incremental development approachIncremental 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.

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 1—Objectives• Stage 2—Architectural visioning• Stage 3—Planning• Stage 4—Standards and guidelines• Stage 5—Available resources• Stage 6—Definition 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:

• Planning• Quality of the standards and guidelines• Adequacy of the available resources• Design or technology issues relating to the application architecture

UNIFACE V7.2


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:

• Value—The 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

Resources

Objectives

Standardsand

guidelines

Planning

Solutions

Scopeof

project

Development 1

Deliveryand

evaluation

Feedback

Development 2

Development 3

Development 4

Development 5

Development 6

Development 7

Components

UNIFACE V7.2


• Cost—To 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 organization’s resources are experienced, and the smaller, cheaper packages can be developed in parallel.

• Dependency—Dependencies 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 failure—This 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 approachOnce 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.

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.

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).

i 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 approachPrototyping 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

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).

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.

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.

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:

• 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

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 component’s 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

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 system’s 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.

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

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.

UNIFACE V7.2


2.9.6 Service level management

The performance metrics defined for components defined in the system’s 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 SummaryThe component-based development methodology provides an effective framework for the production of high quality, highly effective reusable components.

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.

UNIFACE V7.2


UNIFACE Component-based Development Methodology (Dec 2000) A-1

UNIFACE V7.2

AppendixA Sample use case descriptionThe 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.

UNIFACE V7.2

A-2 (Dec 2000) Sample use case description

• 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 retailer’s 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.2. For each orderline:

• Select product to be ordered.• Get current product price.

3. Compute order total.4. Assign order number.

Alternate scenario 2 (order total >= $10,000)

1. Submit purchase order.2. For each orderline:

• Select product to be ordered.• Get current product price.• Compute order total.

UNIFACE V7.2

UNIFACE Component-based Development Methodology (Dec 2000) A-3

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

UNIFACE V7.2

A-4 (Dec 2000) Sample use case description

uniface component-based development methodology...computer equipment object. for example, the...

Documents