Uml 2 toolkit phần 4 pot

Figure 4.61 Example of port notation showing a cable box as a component with requirements in the external environment. Figure 4.61 provides an example of a port. In the example, a television requires signal input from an external source, and a cable company wants to be able to track the usage of the television set. So, the cable box port provides this interface, while also implementing interfaces that allow the cable company to charge the user and track his or her television-watching history. Packages A package provides a grouping mechanism for organizing UML elements. In UML, a package is used to group elements and to provide a namespace for the grouped elements. All model elements that are owned or referenced by a pack- age are called the package contents. As a grouping mechanism for model orga- nization, the package does not have an instance. Thus, the packages often have a meaning during modeling that is not necessarily translated into the exe- cutable system. A package owns its model elements, and a model element can- not be owned by more than one package. If the package is removed from the model, then its owned elements are also removed. See Figures 4.62 through 4.66 for examples. The package is shown as a large rectangle with a smaller rectangle (a tab) attached on the upper-left corner of the large rectangle (the common folder icon). If the contents (such as classes) of the package are not shown, then the name of the package is given inside the large rectangle; otherwise the name is given inside the small rectangle. Owned and imported elements may each have a visibility that determines whether they are available outside the package. The visibility of a package ele- ment may be indicated by preceding the name of the element with a plus sign (+) for public, a minus sign (–) for private. The public contents of a package are always available through the use of qualified names. Television Track Usage, Billing Information Signal Cable Box [1] Classes, Objects, and Their Relationships 135 Figure 4.62 Package E is dependent on package B. Package C is dependent on packages B and D. Packages B, C, and E are inside package A. Figure 4.63 Two notations for indicating that package A contains classes B and C. A A Class B Class C Class B Class C B C A D E 136 Chapter 4 Figure 4.64 Packages D and E are specialized from the generalization package C. Packages B, C, D, and E are in package A. Package C depends on B (it typically has imported elements from it). Figure 4.65 Elements defined in package A are imported publicly to package C. Elements in package B are imported privately to package C. Elements of packages A and C are imported into and are available to package D. C D A B «access»«import» «import» BC DE A Classes, Objects, and Their Relationships 137 Figure 4.66 Package X contains classes P and S. Package A has an interface I. Class S inside package X is dependent on interface I in package A. As is the case with most other model elements, you can have relationships between packages. The allowed relationships between packages are depen- dency, refinement, and generalization. Packages can import model elements from other packages. A package import (a dependency stereotyped as <<import>> for public import or <<access>> for private import) allows one package to import the members of another package, thereby making it possi- ble to refer to elements of the imported package as if they were defined in the importing package (that is, without using qualified names). Apackage merge (a dependency stereotyped as <<merge>>) allows the con- tents of the target package to be merged with the contents of the source pack- age. It should be used when you intend to merge elements with the same name into a single element (see Figure 4.67). Merging two elements with the same name is a generalization from the source to the target. The source package also imports any elements that do not yet appear in the source package. See Figure 4.68 for the results of merging packages F, G and H from Figure 4.67. The package has similarities to aggregation. If a package owns its contents, it is composed aggregation; and if it refers to its contents (that is, imports ele- ments from other packages), it is shared aggregation. X A B D C Class S I Class P 138 Chapter 4 Figure 4.67 Source package H is merging all contents of target packages F and G. Figure 4.68 The transformed package H. Note that class A has merged classes F::A and G::A into H::A. Classes B and C are imported into package H. H C A a : String b : String op1() op2() B D F B A a : String op1() G C A b : String op2() H DA «merge» «merge» Classes, Objects, and Their Relationships 139 A package may have visibility just like classes, showing how other packages can access its contents. UML defines four degrees of visibility: public, private, protected, and package. ■■ The default visibility for a package is public. Public visibility means that other elements can see and use the contents in the package. ■■ Private means that only the package that owns an element or a package that imports the model element can use it. ■■ If the visibility is protected, the package that owns or imports the model element can use it, and it is also possible for specialized pack- ages to access the model elements inside the generalized packages. The difference between private and protected visibility for packages is the inheritance: Only packages with the protected visibility can use model elements from the generalization package. ■■ The last visibility is package. Package visibility is similar to private, but model elements that have a dependency to a package cannot use the elements inside that package if it has package visibility. Importing from a package is described as a dependency (with the stereotype <<import>> or <<use>>), which means that if a package has package visibility, no other package can import from that package. A package may have an interface that publishes its behavior. The interface is shown with a small circle connected via a solid line to the packages. Typically one or more classes within the package then implement that interface. Templates In UML, a modeler can use a template to show a class or set of classes not fully specified. Parameters to the template provide the final specification of the class. These parameters can be classes or primitive types. A parameterized class can also be an array. The created classes of the template then are also arrays, providing a set of cars, a number of different colors, and so on depend- ing on the parameters passed to the template. If a class is like the cookie cutter that produces specific types of objects, then a class template acts like a machine that makes cookie cutters according to the instructions (or parameter) sent to the machine. So, for example, a cookie cutter template could produce a snow- man cookie cutter class when passed the proper parameter. The class pro- duced by the template is called a derivation, or derived class. This derived class functions like any other class. In this case, the class produces the snowman cookie objects just as if it had been created without a template. 140 Chapter 4 Figure 4.69 A parameterized class Array with the parameters T (a class) and n (an integer). Two instantiations are shown, one just by specifying the name of the template and the parameters within a class symbol, and the other by specifying a refinement relationship from the instantiated class to the template. Figure 4.69 shows a template. UML displays a template with a small dashed rectangle containing the relevant parameter list placed on the upper-right cor- ner of the class. This parameter list starts with the parameter-kind (a class if left blank), followed by the parameter name, followed by the type constraint on the parameter, optionally followed by a default value. A template parame- ter can include 1 * parameters in the list. A relationship between a derived class and the template is shown by a refinement relationship, using the stereo- type <<bind>> followed by the actual parameters used in the class. Relevant Changes in UML 2 Although the basic concept of class and association has not changed much from UML 1.x, a number of features make the description options more robust. ■■ The generalization set provides a tool for clarifying the different types of generalizations. A class can clearly have two or more types of gener- alization relationships to different sets of classes. The powertype allows for further definition of the generalization relationship. The generaliza- tion set replaces the “discriminator” attribute of a generalization from UML version 1.x. ■■ An interface can now use “ball-and-socket” notation to show a usage relationship between a class and an interface, in addition to the imple- mentation relationship. ■■ The port provides a feature of a class to show environmental dependen- cies and links to internal behavior. The port can also be used with a pro- tocol state machine to show the deployment rules for a component, based on the state of the application as well as the environment (see Chapter 6 for more on protocol state machines). ArrayArray<Car,100> ColorArray «bind» <Color,50> T,n:integer Classes, Objects, and Their Relationships 141 ■■ Packages can take a standard stereotype <<merge>> to better show the type of dependency relationships in a package diagram. ■■ Many elements have features that now more explicitly apply to a num- ber of classifiers in addition to class. Other UML elements can take advantage of generalization hierarchies and defined relationships. For example, signals as well as state machines can be redefined through inheritance, as shown in Chapter 6. Many of these features further the UML 2 goal for enhanced support of components. Summary When you model, you portray the details of what you are analyzing. Thus, it is very important that the model capture the essence of the object of study. An object is something you can say things about and manipulate (in some way). An object exists in the real world (or more precisely, your understanding of the real world). An object can be a part of any system in the world—a machine, an organization, or a business. A class is a description of zero, one, or many objects with the same behavior. You use classes and objects to discuss systems. UML provides the syntax and semantics to create a model. The modeling language, however, cannot tell you whether you have done a good job. You must strive to make all models easy to communicate, verify, validate, and maintain. UML supports static, dynamic, and functional modeling. Static modeling is supported by class diagrams, which consist of classes and relationships between them. The relationships could be associations, generalizations, dependencies, or abstractions of some kind. ■■ An association is a connection between classes, which means that it is also a connection between the objects of those classes. ■■ A generalization is a relationship between a more general element and a more specific element. The more specific element can contain only addi- tional information, while inheriting the elements from the parent class. An instance (an object is an instance of a class) of the more specific ele- ment might be used where an instance of the more general element is allowed. ■■ Dependency is a relationship between elements, one independent and one dependent. A change in the independent element affects the depen- dent element. ■■ An abstraction shows the relationship between two descriptions of the same thing, but at different levels. Abstractions such as realizations help maintain model consistency and clarity. 142 Chapter 4 UML also allows the specification of constraints and rules to provide greater detail on how to implement a software system. Interfaces and ports are fea- tures that allow a modeler to focus on the specification of one class, leaving the implementation details of the environment and other interfaces to one side. So long as other software units abide by the specification, the relationships func- tion without error. Package diagrams also help the analyst organize the model into coherent units. UML also includes features for modeling templates of classes. Classes, Objects, and Their Relationships 143 [...]... 5 .23 is semantically the same as 5 .22 Displayer Sampler Sampler.Run (channel, frequency) Initiate Updating displayer Measuring Figure 5 .22 The Updating displayer action is performed within the Displayer The Initiate and Measuring actions are performed within the Sampler 167 168 Chapter 5 Sampler.Run (channel, frequency) (Sampler) Initiate (Displayer) Updating displayer (Sampler) Measuring Figure 5 .23 ... however, Figure 5. 12 illustrates the principles for implementing a state machine directly in the operations of the class 157 158 Chapter 5 inc/minutes = minutes + 1 modulo 60 inc/hours = hours + 1 modulo 24 Display do/display current time Set hours mode_button do/display hours Set minutes mode_button do/display minutes mode_button Figure 5. 12 A state machine for a digital watch UML does not give any... transition These state machines have also provided the foundation for “executable” UML, or xUML, when connected to an action language See Chapter 9 for more on xUML Protocol state machines are used to express the legal transitions that might occur in an abstract classifier such as an interface or a port Several extensions were made to UML 1.x to support guidelines for working with components Protocol state machines... underlying model of UML, the arrowed line between an action and an object is considered an object flow rather than an activity edge But they are visually the same, and we do not distinguish between them here An object can be used represent a datastore that retains values created by one action to be consumed by another See Figure 5 . 24 for some basic usage of a datastore object, and see Figure 5 .26 later in... language that conforms to the UML action semantics The action language has the precision needed to produce executable code in some circumstances For more on using UML to produce executable code, see Chapter 9 Examples of state transitions with an action-expression are as follows (:= is used for assignment): increase () / n := n + 1 / m := m + 1 add (n) / sum := sum + n /flash 153 1 54 Chapter 5 Moving up go... whereby internally the state has its own substates that can be shown in other state machines UML 2 defines orthogonal (more clearly understood as “or-substates”) and nonorthogonal (“andsubstates”) substate machines ■ ■ An or-substate indicates that a state has substates, but only one at a time, as shown in Figure 5. 14 For instance, a car may be in the running state, which has two different substates: forward... a corresponding operation that receives the signal object as an argument The Java code for a class with the state machine shown in Figure 5. 12 looks something like the following: public class State { public final int Display = 1; public final int Set_hours = 2; public final int Set_minutes = 3; public int value; } public class Watch { private State state = new State(); private DigitalDisplay LCD =... as shown in Figure 5 .4 ■ ■ The first compartment shows the name of the state, for example, idle, paid, and moving ■ ■ The second compartment is the optional activity compartment, which lists behavior in response to events You can define your own event, such as selecting a Help button, as well as the activity to respond to that event Three standard events names are reserved in UML: entry, exit, and... labeled connector with an outgoing edge Figure 5 .21 is semantically the same as Figure 5.19, but the connector was just used to allow the reorganization of the diagram visually, and the decision node was reworked to remove the need for the decisionInput note 165 166 Chapter 5 Sampler.Run (channel, frequency) Initiate Updating displayer Measuring Figure 5 .20 When the Run operation is called, the first... them as “swimlanes” drawn as vertical rectangles The actions belonging to a swimlane are placed within its rectangle The swimlane is given a name that is placed at the top of the rectangle (see Figure 5 .22 ) Activity partitions can be organized in other ways When one is modeling business flows, it is common to use left-to-right lanes Partitions might be further broken down into composite subpartitions . different levels. Abstractions such as realizations help maintain model consistency and clarity. 1 42 Chapter 4 UML also allows the specification of constraints and rules to provide greater detail on how. coherent units. UML also includes features for modeling templates of classes. Classes, Objects, and Their Relationships 143 145 All systems have static structure and dynamic behavior; the UML provides diagrams. package A contains classes B and C. A A Class B Class C Class B Class C B C A D E 136 Chapter 4 Figure 4. 64 Packages D and E are specialized from the generalization package C. Packages B, C, D, and