UNIFACE Component-based Development Methodology UNIFACE V7.2 151157206-00 Revision 0 Dec 2000 UMET UNIFACE V7.2 UNIFACE Component-based Development Methodology Revision 0 Restricted Rights Notice This document and the product referenced in it are subject to the following legends: © 1997-2000 Compuware Corporation. All rights reserved. Unpublished - rights reserved under the Copyright Laws of the United States. U.S. GOVERNMENT RIGHTS-Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in Compuware Corporation license agreement and as provided in DFARS 227.7202-1(a) and 227.7202-3(a) (1995), DFARS 252.227-7013(c)(1)(ii)(OCT 1988), FAR 12.212(a) (1995), FAR 52.227-19, or FAR 52.227-14 (ALT III), as applicable. Compuware Corporation. This product contains confidential information and trade secrets of Compuware Corporation. Use, disclosure, or reproduction is prohibited without the prior express written permission of Compuware Corporation. Trademarks Compuware is a registered trademark of Compuware Corporation and UNIFACE is a registered trademark of Compuware Europe B.V. CICS, DB2, IBM, and OS/2 are trademarks of International Business Machines Corporation. SOLID Server (TM), SOLID Bonsai Tree (TM), SOLID Remote Control (TM), and SOLID SQL Editor (TM) are trademarks of Solid Information Technology Ltd. All other company or product names used in this publication are trademarks of their respective owners. 24-hour online customer support and learning MyUNIFACE is an Internet-based support and learning environment which provides real-time access to a wealth of UNIFACE product and technical information. Features include online product documentation, technical tips and know-how, up-to-date platform availability, product fixes, course information, online training, and live communication with fellow developers. You can obtain full access privileges for MyUNIFACE by completing an online registration form (customer license information is required) at http://myuniface.com/. For the latest version of the documentation always check the UNIFACE Library on the MyUNIFACE site. Your suggestions and comments about UNIFACE documentation and course material are highly valued. Please send your reactions to: Compuware Europe B.V. Delivery Methods & Practices P. O. Box 12933 1100 AX Amsterdam e-mail: DM&[email protected] The Netherlands fax: +31 (0)20 311-6213 UNIFACE V7.2 Contents 1 Introduction 1.1 Objects and components . .1-3 1.2 What is an object? . .1-3 1.2.1 Object structure . .1-3 1.2.2 Object behavior . .1-4 1.2.3 Encapsulation. .1-4 1.3 What is a component?. .1-6 1.3.1 Design by Contract . .1-7 1.3.2 Component interfaces. .1-8 1.3.3 Data hiding. .1-9 1.4 Why develop component-based applications? . .1-10 1.4.1 Adding new functionality. .1-10 1.4.2 Reusing components. .1-10 1.4.3 Easier maintenance of existing functionality . .1-11 1.4.4 Replacing components with other components. .1-12 1.4.5 Separating application layers. .1-12 1.4.6 Assembly of applications is simplified with components . .1-13 1.4.7 Scalability . .1-13 1.5 Why a new component-based modeling technique? . .1-14 2 Component-based development process 2.1 Inception . .2-3 2.2 The Modeling Process . .2-8 2.3 Modeling process—analysis . .2-10 2.3.1 Business function modeling. .2-11 2.3.2 Object modeling . .2-13 2.3.3 Behavioral modeling . .2-15 UNIFACE Component-based Development Methodology (Dec 2000) iii UNIFACE V7.2 2.4 Modeling process—design . .2-21 2.4.1 Component model design . .2-22 2.4.2 Component design . .2-28 2.4.3 Relational model design . .2-30 2.4.4 Business rule design . .2-31 2.4.5 Inter-component communication design . .2-32 2.4.6 UNIFACE design implementation . .2-33 2.5 Development . .2-34 2.6 Incremental development approach. .2-35 2.6.1 Incremental development process. .2-36 2.6.2 Prioritizing increments. .2-37 2.7 Iterative development approach . .2-38 2.8 Prototyping approach . .2-40 2.8.1 Exploratory prototyping . .2-41 2.8.2 Experimental prototyping . .2-42 2.9 Quality assurance . .2-44 2.9.1 Testing . .2-45 2.9.2 White box testing . .2-45 2.9.3 Black Box Testing . .2-46 2.9.4 Testing Techniques. .2-48 2.9.5 Deployment . .2-49 2.9.6 Service level management . .2-50 2.9.7 Usability measurement . .2-50 2.10 Summary . .2-50 Appendix A Sample use case description iv (Dec 2000) UNIFACE V7.2 Chapter 1 Introduction Component-based development represents a significant paradigm shift in application development. While component-based development techniques have been used effectively in engineering and manufacturing circles for many years, their application to software development is relatively recent. The techniques came about in response to many of the issues facing IT organizations today: reducing time to market, responding more rapidly to change, and providing the flexibility to change the scale or scope of functionality to keep pace with changes in the business. There are some inherent challenges in applying component-based development techniques to software development. Until now, it has been usual practice to design and build large, monolithic systems that perform very specific functions. Component-based development, however, employs a three-phase approach of modeling reusable, interchangeable components, constructing the components, and assembling them into a complete application. Component-based applications are quite different from those developed in the past, and the process for developing component-based applications is also very different. Therefore, Compuware has developed a new methodology to address the particular demands of component-based development. A software engineering methodology is a process for the organized production of software using a collection of predefined techniques and notation conventions. A methodology is usually presented as a series of steps, with techniques and deliverables associated with each step. The UNIFACE component-based development methodology uses industry-standard object-oriented modeling techniques and notation incorporated in the Unified Modeling Language (UML). This component-based methodology addresses the entire system development life cycle, conceived specifically to deliver the optimum design for component-based applications. To achieve this goal, a thorough UNIFACE Component-based Development Methodology (Dec 2000) 1-1 UNIFACE V7.2 understanding of the internal workings and goals of the business must first be established. UML provides a means to model and communicate an understanding of the business through a standard set of techniques and notations. Ultimately, UML deliverables are used to populate the UNIFACE application models and component models. This methodology embodies the UNIFACE 3D paradigm of component-based development, component-based deployment and component-based delivery. It is designed to provide a high degree of productivity and rapid response to change. Component-based development is divided into the following main activities: • Modeling •Construction •Assembly Figure 1-1 shows the relative effort required in each of the activities during the application development cycle. Modeling (Analysis & Design) Construction t r Assembly o f f E Elapsed time Figure 1-1 Component-based development. UML provides an excellent means to model and communicate an understanding of the business. Before discussing where UML techniques are specifically applied in component-based modeling, refer first to section 1.1 Objects and components. 1-2 (Dec 2000) Introduction UNIFACE V7.2 The UNIFACE component-based development methodology enhances 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. 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 Component-based Development Methodology (Dec 2000) 1-3 UNIFACE V7.2 •Cost • Retail Price The structure defined for an object must be consistent for all occurrences of that object. 1.2.2 Object behavior The behavior of an object is defined as ‘operations’. Operations are the distinct functions performed by an object within the scope of the business. For example, the behavior of the Computer Equipment object can include the following: • Order Equipment • Receive Equipment • Sell Equipment The behavior defined for an object must be consistent for all occurrences of the object. 1.2.3 Encapsulation From the descriptions in section 1.2.1 Object structure and section 1.2.2 Object behavior, you might conclude that the 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).