Model Snippet of the Day

homepage Forums Executable UML and xtUML Methodology Model Snippet of the Day

Viewing 15 posts - 31 through 45 (of 45 total)
  • Author
  • #5417

    I would argue that the phrases for R1 in that model is a little bit vague. The phrase ‘is going’ should really be ‘is going to’.

    Also, in which contexts is it OK with a conference without attendees? A conference without attendees is a sad conference…


    Agreed on all points. A conference with zero attendees is not even a conference at all…

    ‘is going’ was shorted from ‘is going to’ for social media posting reasons. “self … is going” sounded better than “self … is going to” :)

    Dan George

    Well, doesn’t it depend on the state model? Surely it would not be a good idea to have a Conference in the Participants Mixing state with no Attendees. But, how does the first prospective Attendee find a conference?


    I tried to do it in python:
    [code title=””]
    from xtuml import relate
    from xtuml import where_eq as where

    from components import community

    me = community.select_any(‘attendee’, where(name=’john’))
    conf = community.select_any(‘conference’,
    where(name=’xtUML 2015′,
    date=’December 7 and 8′,
    location=’Lafayette, IN’))

    relate(me, conf, 1, ‘is going’)

    but I ran into some trouble:

    [code title=”stdout”]
    Traceback (most recent call last):
    File “”, line 12, in <module>
    relate(me, conf, 1, ‘is going’)
    ModelException: Unable to attend conference: its location is to far away.



    O.K. I need some input and plan to discuss this model leading up to a significant write-up. See if the following makes sense.

    model abstracts application
    model conforms to method
    method applies standard
    tool enforces standard
    tool manifests method
    tool edit model

    This is just a starting point.


    I tend to see a tool as an automated process governed by user input, unless we are talking AI. So perhaps the tool itself does no do the manifestation, but a user, that uses a tool to automate some task in the methodology.


    Thanks, John. Agreed.

    A point that I want to make about modeling is the following:
    – applications first
    – then models (based on a method)
    – then tools and standards

    The application, the problem to be solved, is the basis.
    Models represent captured IP and hold great value.

    Everything else must follow as stewardship of the model-encoded applications.

    Models are more important than tools.


    (…still interested


    Happy New Year 2016!
    May your labors in 2016 select many bright opportunities.


    When modeling an application, you may encounter subject matters that deal with the same information but addressing different requirements. When the requirements are varied enough, it may make sense to model parts of the application on separate class diagrams… each with its own view of the data.

    For example, here is a model of the syntax of a language. This model focuses on the content, form and inter-relationships of the elements of the language.

    This language can be marked with options that affect its translation. Marking deals with the same information but is addressing a separate and substantially different requirement. So, a new view of the data is modeled that focuses on the requirements of providing the needed translation options. In xtUML, this is done with an imported class (or class reference) that is depicted on more than one class diagram.

    originally posted here:


    xtUML interfaces can be uni-directional or bi-directional. From this graphic you can see small arrows in the port boxes indicating whether the port contains messages that are inbound, outbound or both. The LocationProvider and LocationUtil interfaces are uni-directional and on the Tracking component the messages are all outbound. The UI and HeartRateProvider interfaces contain messages in both directions.


    Model Snippet of the Day: Graphics Elements

    xtUML has a model of graphics. Here is a simplified version of it. This model abstracts out very far and distinguishes only diagram, widget, figure, connector and junction.

    A diagram depicts widgets. A widget is either a figure (shape) or a coupler (connector). Couplers connect widgets together, meaning that a coupler can have junctions between figures and/or other couplers.

    Example figures are class, component, state.
    Example couplers are association and transition.


    Dog owner owns one to many dogs. Dog is owned by zero or one dog owner.

    Relationships in xtUML are a first-class part of the language. Also called associations, these constructs are more than documentation. They are part of the language and constrain the population of instances of the various classes. Associations also allow for quick traversal from an instance of one class to the instances of related classes.

    For example, if you know a particular dog owner, you can traverse across R1 to get the set of dogs owned by that dog owner.

    Quiz question: Does the model depicted here support the concept of a ‘stray dog’?


    Conditionality and Multiplicity
    The answer to the quiz question from yesterday is, “yes”. The model allows for a stray dog (a dog without an owner, poor thing).
    The way that the model shows this is by the ‘conditionality’ of the association. On the dog owner end of the relationship ‘0..1’ is shown. This means that a ‘dog is owned by 0 to 1 dog owner’. A dog with zero owners is a stray dog. The relationship is said to be ‘conditional’ on this end.
    Also encoded into the ‘0..1’ and ‘1..*’ are the ‘multiplicities’ of this association. We can understand from the multiplicity that a dog owner can own more than one dog. A dog owner must own at least 1 dog. We can also tell that a dog cannot be owned by more than one dog owner.


    Modeling an Association

    Look around the room you are in. You will see plugs and sockets. Some plugs are in service (plugged in to a socket) and some are not. Some sockets are being used (occupied by a plug) and some are not (except at the airport, where it seems _all_ of them are being used).

    ‘plug’ ‘is plugged in to’ zero-or-one ‘socket’. ‘socket’ ‘is occupied by’ zero-or-one ‘plug’.
    This is a one-to-one bi-conditional association. For any instance of plug, we can find out if it is plugged in and to which instance of socket it is connected. If we have an instance of socket “in hand”, we can find the related plug if one is there. Association R1 gives us a lot information about the instance populations of ‘plug’ and ‘socket’.

    Consider modeling current flow. In which class do we want to model the current flow?

    Associative Classes

    Also called “ternary associations” and “link classes”, associative classes model relationships as data. Instead of just a line with role phrases, the full power of class, attributes and state modeling can be applied to clearly specify the relationship. Associative classes also can participate in other associations.

    In our ‘plug’ and ‘socket’ model, we could have modeled ‘current_flow’ on either or both of ‘plug’ and ‘socket’, although it is more clear to model the flow of current through the connection since this flow is through both. ‘Resistance’ would not make sense on the ‘plug’ or the ‘socket’. The resistance to current flow is a function of a particular ‘plug’ being connected to a particular ‘socket’.

    In complex systems, the relationships between resources in the system are often a focus on study. In such systems there are limited resources that must be allocated and shared. One object in a system will “want to be associated” with another object, but it is busy. Such patterns can leverage associative classes nicely.


    This is a model of “marking” (linking model compiler features to application model elements). Most development starts like this with a rough sketch on scrap paper and reviewed over soup and fries at lunchtime.

    BTW, a marking editor is being added BridgePoint.

Viewing 15 posts - 31 through 45 (of 45 total)
  • You must be logged in to reply to this topic.