Tool Mentor: Identifying Design Elements Using Rational XDE Developer var backPath = './../../../'; var imgPath = './../../../images/'; var nodeInfo=[{view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_gpYSoAILEdq-_NKqZM1EhA", "_qS-iwAIOEdqTna4sZVFRow", "{303A82D2-E3AB-4501-8563-0D4D43782AF9}", "{E6727D13-BE7B-4025-AD39-ECD6FA074D73}"]}, {view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_zRigkAILEdq-_NKqZM1EhA", "_U5tiUAISEdqTna4sZVFRow", "{303A82D2-E3AB-4501-8563-0D4D43782AF9}", "{E6727D13-BE7B-4025-AD39-ECD6FA074D73}"]}, {view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_AUv4MAIMEdq-_NKqZM1EhA", "_5ZuQsAIUEdqEutyfYo0quQ", "{303A82D2-E3AB-4501-8563-0D4D43782AF9}", "{E6727D13-BE7B-4025-AD39-ECD6FA074D73}"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_jD8dUAIbEdqEutyfYo0quQ", "_F1OgYAIbEdqEutyfYo0quQ", "{303A82D2-E3AB-4501-8563-0D4D43782AF9}", "{E6727D13-BE7B-4025-AD39-ECD6FA074D73}"]}]; contentPage.preload(imgPath, backPath, nodeInfo, '', false, false, false); Tool Mentor: Identifying Design Elements Using Rational XDE Developer This tool mentor describes how to perform Identifying Design Elements with Rational XDE Developer. Tool: Rational XDE Developer Relationships Related Elements Identify Design Elements Main Description Overview  This tool mentor supports Identifying Design Elements with Rational XDE Developer - Java Platform Edition.   The steps in this tool mentor match those in the corresponding task. Links to topics in XDE online Help are marked with . In the tool mentor, the following steps are performed for the use cases to be designed in the current iteration: Identify Events and Signals Identify Classes, Active Classes and Subsystems Identify Subsystem Interfaces Identify Capsule Protocols Architecturally significant design elements may be documented in a separate Logical View, that is maintained as design elements are identified. See Rational XDE Model Structure Guidelines. Identify Events and Signals The characteristics of events should be captured as needed to drive the identification of the design elements that handle them. This information can be captured informally, such as in a separate document, rather than as part of a Rational XDE model. Asynchronous communication events can be modeled as signals to express the data that they carry, or to express relationships between signals, such as a generalization relationship. The following substeps describe how to model signals: Create class diagrams as needed. See Adding Diagrams . Add signals. See Adding Shapes to Diagrams . Add a brief description to each design element. See Documenting Model Elements . Add generalization relationships between signals, if applicable. See Adding Generalization Relationships . For more information about class diagrams, see Working with Class Diagrams . For more information about signals, see Signals . Identify Classes, Active Classes and Subsystems Design elements are generally created in the following three ways: modeling (by adding to a class diagram) expanding a pattern coding and reverse engineering These approaches are explained in the sections that follow. Expanding a Pattern You can use design patterns to identify design elements. Reference: Implementing Design Patterns Identify candidate patterns that may be useful. Refer to the following topics in the Rational XDE online Help: Applying the Gang of Four Sample Patterns Store and Retrieve Patterns Pattern Libraries Import Patterns from RAS Assets Import and Export Pattern Libraries Apply Patterns Modeling Create class diagrams in the Design Model to capture design elements. If you decide to maintain the analysis classes, then you may want to establish traceability dependencies to the analysis classes. Create class diagrams as needed. See Adding Diagrams . Add subsystems and classes. See Adding Shapes to Diagrams . Add a brief description to each design element. See Documenting Model Elements . (optional) Add traceability to analysis classes. See Adding Abstraction Relationships . Organize the design elements into packages. See Grouping Model Elements in Packages . Also refer to the white paper Rational XDE Model Structure Guidelines. For more information about class diagrams, see Working with Class Diagrams . For more information about Java modeling, see the following topics in the Rational XDE online Help: Understanding Java Modeling Modeling Java Elements Modeling JavaBeans Modeling EJBs Modeling EJB Properties Modeling Servlets Modeling JavaServer Pages Developing HTML Documents Coding and Reverse Engineering Another approach is to sketch out the design in code form, reverse engineer it to create a skeletal implementation model, and then drag and drop these classes onto diagrams in the Design Model. Once you have made the decision that a design class will map to an implementation-specific class, this approach has the following advantages: As an optional alternative, a code editor can be used to sketch out interfaces, methods, and attributes using reverse engineering to reflect these elements in the model. Existing code assets can be reverse engineered and contribute to the Design Model. Selected elements can be prototyped to validate a complex concept, while using round-trip engineering to keep those prototypes consistent with the Design Model. EJBs can be created using J2EE patterns in Rational XDE. Refer to the following topics in the Rational XDE online Help: To See Create EJBs EJB Creation Create a BMP Entity Bean Creating BMP Entity Beans Create a CMP 1.1 Entity Bean Creating CMP 1.1 Entity Beans Create a CMP 2.0 Entity Bean Creating CMP 2.0 Entity Beans Specify an EJB Primary Key Adding Primary Keys to Entity Beans Add a Field to a CMP Entity Bean Adding Container-Managed Fields to Entity Beans Create a Stateful Session Bean Creating Stateful Session Beans Create a Stateless Session Bean Creating Stateless Session Beans Create a Message-Driven Bean Creating Message-Driven Beans Create an EJB from an Existing Java Class Creating EJBs from Existing Classes Create an EJB's Deployment Descriptor (Without Deploying It) Creating EJB Deployment Descriptors For more information, refer to the following topics in Rational XDE online Help: Working with Class Diagrams Modeling Java and Web Applications Modeling Java Elements Modeling EJBs Identify Subsystem Interfaces The following steps apply to large-granularity subsystems (larger than individual EJBs): For each subsystem, identify a set of candidate interfaces. Add interfaces to an existing class diagram, or create new class diagrams as needed. (See Adding Shapes to Diagrams .)  Make certain that you use the Java tab of the toolbox, rather than the UML toolbox, to add Java-specific elements.  Add interface dependencies. See Adding Dependency Relationships . Map subsystems to interfaces by adding a realization relationship from the subsystem to the interface. See Adding Realization Relationships . Document the interface, including required behavior. See Documenting Model Elements . Add methods to the interface. See Adding Operations to Classifiers . Add a description to each operation. See Documenting Model Elements . Add parameters to each method. See Adding Parameters to Operations . Organize the interfaces into packages. See Grouping Model Elements in Packages . For EJBs, the following steps apply: EJB interfaces are generated when the EJB is created, so no separate creation of EJB interfaces is required. Add interface dependencies. See Adding Dependency Relationships . Add methods to the interfaces. See Adding Methods to an EJB . Add a description to each operation. See Documenting Model Elements . Add parameters to each operation. See Adding Parameters to Operations . Identify Capsule Protocols if applicable Capsule and protocol modeling is not supported by Rational XDE. ©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved. contentPage.onload();