UNIFACE Component-based. Development Methodology UNIFACE V Revision 0 Dec 2000 UMET

Transcription

1 UNIFACE Component-based Development Methodology UNIFACE V Revision 0 Dec 2000 UMET

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: 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 (a) and (a) (1995), DFARS (c)(1)(ii)(OCT 1988), FAR (a) (1995), FAR , or FAR (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 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 AX Amsterdam DM&P-Hotline@nl.compuware.com The Netherlands fax: +31 (0)

3 Contents 1 Introduction 1.1 Objects and components What is an object? Object structure Object behavior Encapsulation What is a component? Design by Contract Component interfaces Data hiding Why develop component-based applications? Adding new functionality Reusing components Easier maintenance of existing functionality Replacing components with other components Separating application layers Assembly of applications is simplified with components Scalability Why a new component-based modeling technique? Component-based development process 2.1 Inception The Modeling Process Modeling process analysis Business function modeling Object modeling Behavioral modeling UNIFACE Component-based Development Methodology (Dec 2000) iii

4 2.4 Modeling process design Component model design Component design Relational model design Business rule design Inter-component communication design UNIFACE design implementation Development Incremental development approach Incremental development process Prioritizing increments Iterative development approach Prototyping approach Exploratory prototyping Experimental prototyping Quality assurance Testing White box testing Black Box Testing Testing Techniques Deployment Service level management Usability measurement Summary Appendix A Sample use case description iv (Dec 2000)

5 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 UNIFACE Component-based Development Methodology (Dec 2000) 1-1

6 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) Construction Assembly Effort 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

7 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 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 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 Component-based Development Methodology (Dec 2000) 1-3

8 Cost Retail Price The structure defined for an object must be consistent for all occurrences of that object 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 Encapsulation From the descriptions in section Object structure and section 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. 1-4 (Dec 2000) Introduction

9 Order Equipment Receive Equipment Computer Equipment à Serial Number Model Number Manufacturer Cost à Retail Price Sell Equipment 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: UNIFACE Component-based Development Methodology (Dec 2000) 1-5

10 Order Equipment Receive Equipment à à Computer 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 (Dec 2000) Introduction

11 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 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: UNIFACE Component-based Development Methodology (Dec 2000) 1-7

12 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 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. 1-8 (Dec 2000) Introduction

13 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) 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 Component-based Development Methodology (Dec 2000) 1-9

14 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 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 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 (Dec 2000) Introduction

15 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 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. UNIFACE Component-based Development Methodology (Dec 2000) 1-11

16 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 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 (Dec 2000) Introduction

17 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 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 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 Component-based Development Methodology (Dec 2000) 1-13

18 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 (Dec 2000) Introduction

19 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. UNIFACE Component-based Development Methodology (Dec 2000) 2-1

20 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. 2-2 (Dec 2000) Component-based development process