Model Snippet of the Day

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

This topic contains 44 replies, has 10 voices, and was last updated by  cort 2 years, 4 months ago.

Viewing 15 posts - 31 through 45 (of 45 total)
Author Posts
Author Posts
October 27, 2015 at 4:42 pm #5417

poj
Participant

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…

October 27, 2015 at 5:45 pm #5418

cort
Keymaster

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” :)

October 27, 2015 at 6:29 pm #5419

Dan George
Participant

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?

October 27, 2015 at 7:45 pm #5420

john
Participant

I tried to do it in python:

 Code: model_snippet.py (select
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

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: stdout (select
1.
2.
3.
4.

Traceback (most recent call last):
  File "model_snippet.py", line 12, in <module>
    relate(me, conf, 1, 'is going')
ModelException: Unable to attend conference: its location is to far away.

:)

October 28, 2015 at 3:02 am #5422

cort
Keymaster

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.

October 28, 2015 at 6:44 am #5423

john
Participant

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.

October 28, 2015 at 12:43 pm #5424

cort
Keymaster

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.

Thoughts?

(…still interested

January 6, 2016 at 2:44 pm #5479

cort
Keymaster

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

February 2, 2016 at 2:52 pm #5554

cort
Keymaster

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: http://onefact.net/2-views/

February 10, 2016 at 4:30 pm #5560

cort
Keymaster

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.

March 22, 2016 at 1:29 pm #5570

courtney1291
Keymaster

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.

April 26, 2016 at 2:18 pm #5576

courtney1291
Keymaster

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’?

April 28, 2016 at 1:52 pm #5579

cort
Keymaster

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.

May 5, 2016 at 10:31 am #5583

courtney1291
Keymaster

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.

January 3, 2017 at 6:15 pm #5729

cort
Keymaster

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.