APPENDIX A xUML Summary Here is a quick reference to the key features of the Executable UML we use in this book. At the time of this writing, the most complete description is available in the book. Executable UML: A Foundation for Model-Driven Architecture by Stephen J. Mellor and Marc J. Balcer (AddisonWesley Professional, 2002). Resources can also be found in the sites mentioned on the Contact Us page in the back of this book. xUML xUML is a subset of UML notation with platform-independent execution semantics. xUML supports object/data-oriented analysis without assuming any sort of object-oriented implementation. All model elements are executable in a platform-independent context. This means that you don’t need anything extra (for example, code inserted somewhere) to run a model. If you have a tool that executes the model rules, you can test a model on the computer. Otherwise, you must apply the rules by hand. Either way, the rules of execution are the same. They are never subject to interpretation! © Leon Starr, Andrew Mangogna and Stephen Mellor 2017 237 L. Starr et al., Models to Code, DOI 10.1007/978-1-4842-2217-1 APPENDIX A ■ XUML SummaRY Domain A domain is a subject matter representing the rules and vocabulary of a real or abstract world. 238 APPENDIX A ■ XUML SummaRY Bridge A bridge is a relationship between two domains: one domain requires a capability that it cannot perform itself from another domain. The domain that requires the capability plays the role of a client. The domain that provides the needed capability plays the role of a service. 239 APPENDIX A ■ XUML SummaRY Domain Chart The set of domains and their connecting bridges necessary to build an entire software system is shown on a domain chart. A domain may be modeled in xUML, partially modeled in xUML, modeled in another language, hand coded, created in existing legacy software, or acquired from a third party. Remember, any domain can be split across many processor/thread/task boundaries, or multiple domains can be put in the same implementation unit. A domain chart is platform independent, so platform- and other technology-specific boundaries are not shown on the domain chart 240 APPENDIX A ■ XUML SummaRY Class A class is a definition of a set of instances such that all members of the set: Have the same characteristics Have the same behavior Are subject to the same rules and policies 241 APPENDIX A ■ XUML SummaRY Attribute An attribute is a characteristic of something that has been abstracted as a class. It follows from the class definition that each instance must have a meaningful value for each of its attributes at all times. At all times: The meaning and use is explained in an associated attribute description. The values that may be assigned to an attribute are constrained by a data type. 242 APPENDIX A ■ XUML SummaRY Data Type A data type is a constraint on the real-world values that may be assigned to an attribute and the operations that may be applied to those values. Examples: Pressure, mpa Count Count can be defined as an integer [0..maxint] Even though it is based on integer, the only supported operations are increment, decrement, and reset. Aircraft tail number This is not defined as string, because many strings would be illegal. A regular expression could be defined to describe legal tail number names. Also, most string operations would not be allowed on such a value. Point A 2D point type could be defined with operations that produce either a Cartesian or polar point, thus encapsulating the internal representation. r, theta = Track.Origin.Polar x, y = Track.Origin.Cartesian Definition of types (type theory) is orthogonal to relational theory used for defining class and association structures and behavior. 243 APPENDIX A ■ XUML SummaRY Identifier An identifier is a constraint on a set of one or more attributes on the same class such that no two instances of a class share the same value. Real-world identifier Invented identifier An identifier can be a real-world identifier such Or it can be an arbitrary value invented for the as Tail Number. Real-world agencies establish purpose of uniqueness. In this case, the modeler this constraint. establishes the constraint. Formalizes a real-world constraint. It is useful in conjunction with referential attributes to formalize relationships and other constraints. Symbol Identifiers are numbered starting at 1 for each class. Each attribute component of an identifier is tagged with {I} or {In}, where {I} means ID 1 and {In} indicates the participating ID number. An identifier attribute may participate in one or more of its class’s identifiers. The greater UML community encourages the implicit assumption of an architecture-supplied handle to manage links among instances. In xUML, we rely on at least one explicit identifier on each class. This ensures that we have a consistent system of relationship references, and it gives us a powerful tool for expressing restrictive constraints on relationships. 244 APPENDIX A ■ XUML SummaRY Association An association is a relationship that holds systematically among instances. 245 APPENDIX A ■ XUML SummaRY Association Class An association class formalizes an association between two other classes. Always use an association class for many-to-many and any conditional-to-conditional or many-to-0..1 association to ensure that a referential attribute always has a non-null value. 246 APPENDIX A ■ XUML SummaRY Generalization/Specialization A set of instances may share properties and rules and at the same time have exceptions. To handle this situation, the set definition established by a class is partitioned into mutually exclusive subsets. At all times: An ATC cannot exist without being On or Off Duty. An On or Off Duty Controller is certainly an ATC. Each real-world object has simultaneous membership in the superclass and subclass sets. Consequently, one object = two connected instances in a generalization. Generalization, in this case, is employed to establish an exclusive OR constraint. 247 APPENDIX A ■ XUML SummaRY Other Activity Types In xUML, activities are primarily state activities. But they are also written in class methods, external entity operations, and domain operations. Class Method There are several reasons to put an activity in a class method rather than in a state. For example, an activity might be triggered from multiple states. Or a class may not have a state model, but still be subject to state-less processing. The model merely states that when a derived attribute is accessed, it provides a correct value according to a platform-independent formula. When and how frequently the value is updated, on the other hand, is platform specific and, hence, not in the model. 248 APPENDIX A ■ XUML SummaRY Domain Operation A domain operation provides a runtime, model-level API to external domains. The activities should do nothing more than validate incoming data, locate relevant model elements, and then issue an appropriate event or invoke a class method. Limitations: Cannot refer to self attributes because there are none. Domain operation in Lubrication domain invoked via bridge from UI domain 249 APPENDIX A ■ XUML SummaRY State Model (Instance Lifeycle) By definition, all instances of a class share the same behavior. This behavior follows a common life cycle that can be formalized with a state model. (There are many other uses of state models in software, but in xUML, we use them exclusively to capture instance life cycles). State Machine Behavior An instance remains in a state of its state machine for events to occur. When one or more events occur, one of them will be consumed according to the event synchronization rules. A consumed event results in one of three responses: Follow a transition (as shown on the state model diagram) The instance follows the transition and immediately begins executing the activity in the destination state (which may be the same state). Ignore the event The event is consumed and exists no longer. Can’t happen The event is not anticipated and constitutes an unrecoverable error in the model. The model execution domain is responsible for handling the error outside the model. 250 APPENDIX A ■ XUML SummaRY Platform Independent Synchronization Rules Events At some time after an event is generated, it is made available to the destination instance or external entity. Events are never lost: every event will be delivered to an instance or external entity to which it is directed. After an event is consumed by an instance, it no longer exists. Multiple events can be pending for a given instance. (For example, events may arrive for an instance while it is executing an activity. Or, multiple events may simply arrive concurrently.) If events are pending for an instance that were generated by different senders, it is indeterminate which event will be consumed first. An event to self is always consumed by the instance that sent it before that instance consumes any other event. If an instance generates multiple events to a target instance, the events will be received in the order generated. Activities An activity takes time, possibly none, to execute. (The actual duration depends on the platform.) Once initiated, an instance’s state activity must complete before another signal can be accepted by the same instance. An activity always runs to completion in xUML. So, if you need the ability to interrupt behavior at the model level, break it down into multiple activities spread across one or more state models. Only one state activity of a given instance can be in execution at any time, because an instance is in only one state at a time. Multiple actions in an activity can execute concurrently.