xUML

Domain

A domain is a subject matter representing the rules and vocabulary of a real or abstract world.

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.

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

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

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.

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.

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.

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.

Association

An association is a relationship that holds systematically among instances.

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.

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.

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.

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

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.

Platform Independent Synchronization Rules

State Model (Assigner)

An assigner is a special state model that manages a competitive association. It follows all of the synchronization rules, but has no instances. Instead, a token moves through the states.

We need them when competition among instances makes it impossible for instances on either side of the association to avoid linking to the same instance.

Single Assigner

Multiple Assigner

Now let’s expand the scope to consider multiple departments in a store. In this case, there is localized competition among customers and employees within each department. This requires a multiple assigner.

The important concepts are 1) a single point of control is necessary to resolve competition in an asynchronous world and 2) the xUML synchronization rules make it possible to specify a platform-independent solution. The solution is not left as an “implementation detail.”

Polymorphic Events

A polymorphic event is declared on a superclass that does not define a response to the event and need not have a state model at all.

The event is delegated through each specialization branch originating from that superclass.

Each encountered subclass in each specialization hierarchy must either further delegate the event or respond to that event in its own state model.

In a single, or repeated specialization (same direction), exactly one state machine must respond to any runtime instance of the event.

If there are multiple specializations (different directions), the event is received by one state machine instance in each.

External Entity

An external entity serves as a proxy for runtime communication with external domains. It can be named to match the domain or it can represent a large-scale or abstract entity handled by the domain. (Care should be taken to avoid naming a specific model or code element in the other domain subject to change.)

An external entity operation is triggered by a synchronous or asynchronous call from inside a domain. The activity typically invokes a domain operation provided by another domain.

Principles

As with the class and state model facets of xUML, the action language must be executable and platform independent. Scrall is designed to be consistent with xUML execution semantics. At the same time, it strives to be easy to read and write.

Names

Scrall is designed to be readable without being needlessly verbose, delegating the hard work to the parser and advanced editing tools. The names of model elements, variables, and values may contain spaces, though care must be taken not to incorporate keywords delimited by spaces into names. To maximize the comfortable use of whitespace, effort is made to define as few keywords as possible. A variable name such as the shift spec is, therefore, perfectly legal. This approach differs from the design of a language that attempts to be readable by introducing wordy keyword phrases.

Variable Types

There are three kinds of variables: instance set, scalar, and relation. Only the first two are used in this book, so we only lightly describe the relation variable in this appendix.

acdata #= /R8/Aircraft.(ID, Altitude, Airspeed)

Data Types

A data type defines a set of scalar values and the operations that can be performed on members of that set. System-supplied data types are typically boolean, integer, real, and string. User types such as GPS Coordinate, Pressure, or License Number can be constructed based on restrictions, extensions, and structural combinations of these types.

Operations can be performed by using infix, prefix, and suffix operators and with names accessed using . notation. For example, the Count data type may be defined as an integer in the range [0..maxint] with the supported operations being incr , decr , and reset .

++cars passed or cars passed.incr might both invoke the increment operation defined for the Count type. cars passed.reset could set the value to zero.

current latitude = position.latitude invokes the latitude accessor on the GPS position type.

System Variables

System-supplied variables are prefaced with an underscore. _now , for example, provides the current time to models in any xUML domain. So that the models can be run on as many MX domains as possible, there are few system variables.

Time logged in = _now.HMS

Here the _now system variable invokes the system-defined HMS operator, which returns time in hours, minutes, and seconds. The assignment implicitly types the scalar variable on the left side.

No Literals

Literal values may not be specified in actions. The idea is to eliminate the encoding of data into action language rather than where it usually belongs, as instance data in the class models. Mechanisms are provided for allowing access to special values such as pi, zero, and so forth. In all cases, though, these are named values defined outside the action language itself. For example, default initial values can be specified with the standard UML notation on the class diagram. Double underscores reference a named value defined somewhere outside the state models __pi , __0 . Note that with a variable typed as Count described earlier, you can set it to zero by invoking the reset operation.

Boolean Values

The set and unset operations are used instead of explicit assignment to literal true and false values.

Examples:

• Injecting.set ⇒ set to true

• Injecting.unset ⇒ set to false

• if not Injecting ... ⇒ to test state

Enumerated Values

Although literal values are forbidden, you can define enumerated data type values. A Fluid State data type might enumerate the values low , very low , empty , and normal . To refer to an enumerated value, put a . in front of it.

Level = .very low

If the left side is an attribute, it is already typed, presumably as Fluid State in this example. With a scalar variable, it may be necessary to explicitly type it with the :: type declaration operator.

level var::Fluid State = .full

Spaces are allowed in enumerated values.

Attribute References

An instance refers to its own attribute values without qualification. So an ATC instance can refer to its Last shift ended attribute without the need for any kind of self-qualification. Input parameters are distinguished with the in . preface to avoid name collisions. And a variable name may not match any attribute name of the local class.

Assignment Operators

Variables are implicitly typed when first introduced on the left side of an assignment operator. It is also possible to explicitly type them by using the :: operator, though this is rarely necessary.

Instance Selection

To select an instance, specify a class name followed by optional selection criteria in parentheses.

the shift spec .= Shift Specification

all aircraft ..=Aircraft

my station .= Duty Station( Number: in.Station )

landing runway .= Runway( Airport: in.airport code, Runway ID: in.runway )

high fast aircraft ..= Aircraft( Altitude > high alt and Airspeed > high speed )

Relationship Navigation

The / symbol delimits hops across class model relationships. The leftmost / indicates the beginning of a relationship path expression beginning at the local instance.

hoff zone .= /R2/Control Zone( Name: in.Zone )

The path expression on the right-hand side starts at the local instance and hops across R2 to all related instances in the Control Zone class. The selection criteria narrows the set to the single instances whose Name attribute matches the in.Zone value. Assuming that the Name attribute is the identifier of Control Zone , either zero or one instances should be assigned to the left side.

Relationship names (R1, R2, and so forth), verb phrases, and class names may appear between the hop delimiters to define an unambiguous selection path.

Signaling

To send a signal, use the following expression:

<event name>(params) [after <duration>] -> instance set

For example:

Low injection pressure -> /R3/Reservoir

Here an event is sent to the linked instance. If multiple instances are in the target instance set, a separate event will be delivered to each.

An instance can send an event to itself by using the me keyword. This keyword represents the local state machine.

Injection canceled -> me

An assigner state model does not refer to any local instance, but because the me keyword refers to the local state machine, it can be used there also for self-directed events.

A delay can be specified as shown:

Good injection -> me after /R4/Injector Design.Good injection duration

Here the Good injection event is sent after the duration specified in the related Injector Design. The relationship along R4 is presumably to one unconditional. An error occurs if the path expression does not select exactly one instance.

Link/Unlink

The association operators are link & , unlink !& , and swap .

The form is as follows:

[<instance set>] & <association>/<instance set>

Each instance in the optional leftmost instance set is linked to each instance referenced by the set on the right across the path. If the instance set on the left is not specified, it is assumed to be the local instance.

& /R3/my station

This links the local instance to each instance referenced by the variable across R3.

If the association is formalized by an association class, an instance of the association class will be created for each link. The required referential attributes will be set to values referring to each participating class instance as appropriate. Any other attributes will be set to their default initial values.

Another way to link is to set the values of a set of each referential attribute on the association to match the values of corresponding identifier attributes on the other side of an association. In general, it is safer to use the link action.

The unlink operator is !& and uses the same form as the link action:

!& /R5/takeoff runway

This unlinks the local instance from all instances referred to by the takeoff runway variable across R5 .

Another way to unlink is to simply delete the instance holding the referential attributes referring to the other side of an association.

With an unconditional one association, it is important not to leave the association unconnected. To avoid this situation, use the swap operator instead of a pair of link and unlink actions:

swap /<association>/<old instance> with <new instance> [on <association>]
    !new missing: <action block>
    !old missing: <action block>

swap /R2/hoff zone with new controller    [handed  off]
    !new missing: UI.Unknown controller( Controller: in.Controller)
    !old missing: UI.Zone not handled by( Controller: ID)
!handed off {
    // further actions assuming handoff succeeded
}

The error conditions underneath the swap operation are explained next.

Error Handling

Some actions may trigger unrecoverable errors. Each such error sets a named guard. The names are predefined for the action. If the error is, in fact, recoverable, the modeler can specify an internal response and set an optional user-defined guard, with the [] guard set brackets to regulate downstream processing.

In the swap action example, two guards, new missing and old missing , are predefined for the action. A user-defined guard is set to the right of the swap action, which will be disabled if any error occurs. A single action is specified for each of the two possible errors, making them both recoverable. If neither error occurs, the handed off guard is not disabled, and an action block may be specified associated with that guard.

my station .= Duty Station( Number: in.Station ) [station OK]
    !empty: UI.No such station( Number: in.Station )
!station OK {
    // actions that assume a station has been selected
}

Here the .= assignment action has two errors predefined: empty and many . If both are ignored, they are unrecoverable. By inserting the !empty clause, the modeler indicates that the empty case is okay and there is a response. Note that in the earlier singleton selection example, the error should be unrecoverable. The station OK guard is disabled if empty occurs and can be used to enable further processing.

If there are several actions to perform, they can be enclosed in brackets to form an action block. Otherwise, a : follows the error name.

Subclass Migration

The migrate operation deletes the local instance in one subclass, creates it in another, and relates the new subclass instance to its parent superclass:

migrate [<instance set>] to <subclass name>

All instances in the set are migrated to the destination subclass. If the instance set is omitted, the local instance only is migrated:

migrate to On Duty Controller

If the local instance is an Off Duty Controller , it will be migrated to the On Duty Controller subclass.

This is a convenience action that replaces the corresponding create and delete actions that would be otherwise necessary and ensures that a correct migration occurs without breaking the integrity of the model by, say, leaving an illegal orphaned subclass instance behind.

Interaction with External Domains

Other than special access provided to system-supplied underscore variables, there are two ways to interact with other domains at runtime.

Start monitoring => SIO
<signal name><parameter list> => <ext entity name>

UI.Warning( MSG Control Zones Active, ID )
<EENAME>.<operation name><parameter list>

Self Reference

When sending a signal to self, the me keyword refers to the current state machine instance. In an instance life-cycle state activity, this corresponds to the local instance’s state machine. In an assigner state activity, there is no class instance, so me refers to the assigner state machine instance.

Events to Assigner State Machines

An assigner state machine is attached to a competitive association—that is, an association with constrained multiplicity (a 1 on one or both sides), where instances on both sides are concurrently attempting to link to one another.

In such a case, the association is bound to one or more state machines that resolve the competition. This is called a single assigner association . If all instances on one side can link to all instances on the other side, a single assigner suffices. But if an instance on one side of the association may link to only a subset of instances on the other side, a separate assigner state machine is required for each subset. This is called a multiple assigner association .

The format for sending an event to an assigner state machine depends on whether the target competitive association is a single or multiple assigner.

For a single assigner, do this:

<event name> -> <path to association>/assigner
Customer waiting -> /R2/assigner

For a multiple assigner:

<event name> -> <assigner association>(<partitioning instance>)
Group ready -> /R6/assigner(/R5/Signal Converter)

The partitioning instance is the one that breaks, via some association, one class participating in the competitive association into subsets.

In both cases, the event is addressed to a single assigner state machine and not to any instance life-cycle state machine.

allAircraft ..= Aircraft // All aircraft selected
allAircraft.verifyPosition() // is applied concurrently to each instance
Aircraft.verifyPosition() // does the same thing without the instance set variable

( <parameter name>: value, ... )

More Commands

Only the subset of Scrall necessary to follow the examples in this book has been covered in this appendix. A more complete (and evolving) specification is available online at www.executableuml.org .

Invocation

pycca ?OPTIONS? FILE ?FILE FILE ...?

The pycca program translates a specification of a domain into C code that is suitable for use with the ST/MX Model Execution domain. The language that pycca translates is a simple configuration language that allows the specification of domains, classes, state machines, and other model elements. Any associated processing is specified in ordinary C code.

Pycca generates two files from its input. One file is the generated C code, named by appending a .c suffix to the basename of the first input file. The other file is a generated header file that has an .h suffix. More than one input file may be given in the invocation. Subsequent files are processed as if all the files had been concatenated together. Typically, second and subsequent files hold domain population information so that a domain may be populated differently without modifying the file containing the translation of structural aspects.

Lexical Conventions

Pycca uses a several lexical conventions to distinguish language constructs for C code constructs.

Domain Definition

The pycca language allows the definition of domains . Domains consist of a set of components such as classes and operations. In this section, we show the syntax for defining domains.

domain lube
    # Put your domain definition here
end

class Air_Traffic_Controller
    # statements defining the Air Traffic Controller class
end

domain operation
Injector_max_pressure(
    InstId_t injId)
{
    PYCCA_checkId(Injector, injId) ;
    ClassRefVar(Injector, inj) = PYCCA_refOfId(Injector, injId) ;
    if (IsInstInUse(inj)) {
        InstOp(Injector, Max_system_pressure)(inj) ;
    }
}

external operation
SIO_Inject(InstId_t injectorId)
{
    // any code here is not passed through
}

extern int eop_lube_SIO_Inject(InstId_t injectorId) ;

interface prolog {
    #include "pycca_portal.h"
    #include <stdint.h>
    // Any additional interface includes, etc.
    typedef uint32_t Count ;
}

implementation prolog {
    struct Point {
        int x ;
        int y ;
    } ;
    static int multPoint(int a, Point *p) ;
}

interface epilog {
    #define POINT_DEFINED 1
}

implementation epilog {
    static int multPoint(
        int a,
        Point *p)
    {
        // implementation of multPoint
        p->x *= a ;
        p->y *= a ;
    }
}
end

instance
Injector_Design@ihn4
    (Model_Name Model)                  {"IHN4"}
    (MPa Min_delivery_pressure)         {19}
    (MPa Max_system_pressure)           {35}
    (MPa Max_dissipation_pressure)      {32}
    (Seconds Delivery_window)           {90}
    (Seconds Good_injection_duration)   {9}
end

table
Lubrication_Schedule
    (Name_t Name)
    (Duration Wait_interval)
    (Duration Monitor_interval)
    (Count Max_low_lube_cycles)
    (bool Default_continuous_operation)
    (Count Default_max_cycles)

@gearbox    {"Gearbox"}     {210}   {45}   {8}    {true}   {5000}
@generator  {"Generator"}   {120}   {25}   {10}   {true}   {10000}
@shaft      {"Shaft"}       {90}    {30}   {10}   {true}   {10000}
@test2      {"Test2"}       {20}    {15}   {1}    {false}  {200}
end

Class Definition

In this section, we describe the pycca statements that are used to define the properties of classes. Class definitions are contained within enclosing class and end statements. For brevity, from here on we omit the surrounding class and end statements.

attribute (Model_Name Model)
attribute (MPa Min_delivery_pressure)
attribute (MPa Max_system_pressure)
attribute (MPa Max_dissipation_pressure)
attribute (Seconds Delivery_window) default {30}
attribute (Seconds Good_injection_duration)

reference R4 -> Injector_Design

reference R2 ->> c1

reference R3 ->>c c5

reference R4 -20>> c7

reference R2 ->>l Control_Zone

subtype R1 reference
    Off_Duty_Controller
    On_Duty_Controller
end

subtype R1 union
    Off_Duty_Controller
    On_Duty_Controller
end

machine
    # statements to define a state model for the enclosing class
end

population dynamic

population dynamic
slots 5

class operation
findByName(
    char const *name) : (struct Lubrication_Schedule *) {
    ThisClassRefVar(ls) ;
    PYCCA_selectOneStaticInstOfThisClassWhere(ls, strcmp(ls->Name, name) == 0)
    return ls == ThisClassEndStorage ? NULL : ls ;
}

instance operation Max_system_pressure() {
    ExternalOp(ALARM_Set_pressure_error)(PYCCA_idOfSelf)    ;
    ClassRefVar(Autocycle_Session, acs) = self->R2 ;
    InstOp(Autocycle_Session, Deactivate)(acs) ;
}

polymorphic event
    e1
    e2
end

attribute (int count)
constructor {
    self->count = 0 ;
}

attribute (int count)
destructor {
    reportCount(self->count) ;
}

State Model Definition

The statements in this section are used to define a state model for a class. State model definition statements must appear in enclosing machine and end statements. For brevity, we omit the enclosing machine and end statements.

state BUILDING_PRESSURE()
{
    if (self->Pressure > self->R4->Min_delivery_pressure) {
        PYCCA_generateToSelf(Above_inject_pressure) ;
    }
}

transition BUILDING_PRESSURE - Above_inject_pressure -> INJECTING_AT_PRESSURE

default transition IG     # ignore unexpected events

initial state SLEEPING

final state perish

Activity Macros

This section gives a summary of the most frequently used preprocessor macros. This list is not comprehensive, and the full list can be found in the online materials. We divide the interface descriptions into groups according to the model elements upon which they operate.

MechEcb bark = PYCCA_newEvent(Bark, Dog, dog, self) ;
PYCCA_eventParam(bark, Dog, Bark, howLoud) = 20 ;
PYCCA_postEvent(bark) ;

ClassRefVar(Autocycle_Session, acs) ;
PYCCA_forAllInst(acs, Autocycle_Session) {
    if (IsInstInUse(acs)) {
        PYCCA_generate(Created, Autocycle_Session, acs, NULL) ;
    }
}

ClassRefConstSetVar(Injector, myinjs) ;
    PYCCA_forAllRelated(myinjs, self, R5) {
        ClassRefVar(Injector, inj) = *myinjs ;
        ClassRefVar(Autocycle_Session, acs) = inj->R2 ;
        InstOp(Autocycle_Session, Deactivate)(acs) ;
    }
}

rlink_t *czlink ;
PYCCA_forAllLinkedInst(ondc, R2, czlink) {
    ClassRefVar(Control_Zone, found) =
            PYCCA_linkToInstRef(czlink, Control_Zone, R2) ;
    if (strcmp(rcvd_evt->zone, found->Name) == 0) {
        hoff_zone = found ;
        break ;
    }
}

ExternalOp(ALARM_Clear_lube_level_very_low)(PYCCA_idOfSelf) ;

PYCCA_checkId(Autocycle_Session, sessionId) ;
ClassRefVar(Autocycle_Session, session) =
        PYCCA_refOfId(Autocycle_Session, sessionId) ;
if (IsInstInUse(session)) {
    InstOp(Autocycle_Session, Suspend)(session) ;
}

ClassRefVar(On_Duty_Controller, new_ondc) =
        PYCCA_unionSubtype(new_controller, R1, On_Duty_Controller) ;

PYCCA_migrateSubtype(self, Air_Traffic_Controller, R1, Off_Duty_Controller) ;

Books

• Stephen J. Mellor and Marc J. Balcer, Executable UML: A Foundation for Model-Driven Architecture , Addison-Wesley (2002), ISBN 0-201-74804-5.

• Chris Raistrick et al., Model Driven Architecture with Executable UML , Cambridge University Press (2004), ISBN 0-521-53771-1.

• Leon Starr, Executable UML: How to Build Class Models , Prentice Hall (2001), ISBN 0-13-067479-6. Note: This edition is out of print, but a new, extended edition covering all the model facets is in the works for 2018, publisher to be determined.

• Sally Shlaer and Stephen J. Mellor, Object-Oriented Systems Analysis: Modeling the World in Data , Prentice Hall (1988), ISBN 0-13-629023-X.

• Sally Shlaer and Stephen J. Mellor, Object Lifecycles: Modeling the World in States , Prentice Hall (1991), ISBN 0-13-629940-7.

• Lex de Hann and Toon Koppelaars, Applied Mathematics for Database Professionals , Apress (2011), ISBN 1-43024-248-1. 1430242841.

• Fredrick P. Brooks, The Mythical Man Month (Anniversary Edition with four new chapters ed.) , Addison-Wesley (1995).

• ACM Letters on Programming Languages and Systems 1, 3 (Sep. 1992), 213–226.

Papers

• E.F. Moore, “Gedanken-Experiments on Sequential Machines,” Automata Studies , Princeton University Press, Princeton, N.J. (1956), pp. 129–153.

• George H. Mealy, “A Method for Synthesizing Sequential Circuits,” Bell System Technical Journal (1955), pp. 1045–1079.

• Christopher W. Fraser, David R. Hanson and Todd A. Proebsting, Engineering a Simple, Efficient Code Generator Generator , ACM Letters on Programming Languages and Systems 1, 3 (Sep. 1992), 213-226.

• http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf

Articles

• Leon Starr, “ How to Build Articulate UML Class Models and Get Real Benefits from UML” (2008) Originally published at www.uml.org/news.htm . Also at www.modelint.com/mbse and www.executableuml.org .

• Leon Starr, “ Time and Synchronization in Executable UML ” (2008) Paper and video available at www.modelint.com/mbse and www.executableuml.org