October 27, 2015 at 4:42 pm #5417pojParticipant
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
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 #5419Dan GeorgeParticipant
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 #5420johnParticipant
I tried to do it in python:
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’,
date=’December 7 and 8′,
relate(me, conf, 1, ‘is going’)
but I ran into some trouble:
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 #5422October 28, 2015 at 6:44 am #5423johnParticipant
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
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 interestedJanuary 6, 2016 at 2:44 pm #5479February 2, 2016 at 2:52 pm #5554
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
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
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
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.April 28, 2016 at 1:52 pm #5579
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
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?
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
- You must be logged in to reply to this topic.