References to elements in other packages can be imported, but the definition of each element must exist in just one place. Each modeling element is owned by exactly one package. In the Rational Rose, a package is "a logical collection of classes and/or other packages." So, we can partition our system model among a set of packages. Packages represent the parts or components of a system. The package is a UML construct used to organize a system at a high level.
Now we can componentize our system model by using packages.
#Rational rose package code#
Because of this, the names you choose during analysis and design should be consistent with how you want code elements named.įor this example, our design phase consists of the following tasks: In object oriented development, the class structures and names created during the analysis and design phase become code elements during the coding phase. (Note that you do not change the object notation when you move from analysis to design.) The focus shifts from the logical relationships between objects to the physical layout of the system. In the design phase, we work mainly in the Logical view in Rational Rose to extend the diagrams used in analysis and add information. An association line simply indicates that the objects of the two classes will send messages to each other. Note that we show relationships between the classes in our ideal object model with association lines. Generally, these objects do not keep track of information that must be stored between uses of the application-these classes are called handlers in some object-oriented methodologies or mediators in Design Patterns. The labels Boundary, Control, and Entity indicate the stereotype we associated to each class.įigure 2-4 Class Diagram Showing the Ideal Object Model (with Stereotypes) for the Withdraw Money Use CaseĬontrol classes are typically used to deal with transactions. (The ideal object model is distinguished from the more specific implementation model we will build later.) We call our Control Class TellerHandler. We are still working mainly in the Use Case view in this phase.)įigure 2-4 shows the ideal object model for our Withdraw Money use case. (Rational Rose lets you create and assign a class diagram for a use case. Based on this, we create a class diagram to represent the classes and the stereotypes of the classes. To do this, we examine our use case to discover the classes it suggests. Now we can convert the use case diagram into an ideal object model using UML stereotypes. Perform Analysis with Class Diagrams Showing Ideal Object Model We can also assign additional diagrams to a use case (such as class, sequence, state, and collaboration diagrams). Figure 2-3 shows the specification documentation for the Bankapp use case.įigure 2-3 Specification for the Withdraw Money Use Case We document each use case with the use case specification tool. Our goal is to create a BEA TUXEDO client/server system that lets a bank customer deposit money, withdraw money, or transfer money between accounts.įigure 2-2 Main Use Case Diagram for Bankapp A use case diagram provides a functional specification of a system and its major processes, and describes the problem that needs to be solved.įigure 2-2 shows a use case diagram for our example BEA TUXEDO application, Bankapp. The use case diagrams are stored in the Use Case View folder.
#Rational rose package how to#
For information on how to use the Rational Rose, refer to the Rational Rose online help or other related documentation.ĭuring the requirements phase, we use the Rational Rose to develop use cases. We do not describe how to use the Rational Rose. The static structure is the cornerstone of an application-all dynamic features such as behavior and persistence are based on it. This prototyping process focuses on defining the static (logical) structure of an application, and linking the application tiers using BEA TUXEDO.
This section describes the first iteration of a development process and steps needed to develop the prototype of a BEA TUXEDO/C++ based application. In future iterations, you can add to and refine your diagrams, developing testable systems that are closer and closer to the finished product. You can begin by creating a limited version of the planned system for the first iteration, only developing the diagrams you need to understand your prototype system.
#Rational rose package software#
However, you do not have to develop all of the possible diagrams before you begin developing and generating code, and testing your assumptions via a prototype of your software system. (See the section What is the Unified Modeling Language? for a brief explanation of the diagrams.) Using Rational Rose to Model a TUXEDO Applicationĭeveloping a large system in the Rational Rose means you need to prepare many different versions of the various types of UML diagrams.
0 kommentar(er)
