Model Snippet of the Day

[cort]

We teach Executable UML Modeling. We teach engineers and computer scientists, but we also teach managers, accountants, teachers and even nurses. In fact, it was a high school aged nurse-to-be that modeled the blood pressure cuff shown above on paper. The next day in class we entered the model into BridgePoint as shown below.

It is really fun to see someone grasp the concept of abstraction. Some people have knack for it and quickly learn to capture and communicate ideas with models. The nurse who built this model really disliked computer science and was mildly annoyed that she was so good at modeling!

Notice the “Class Blitz” list in upper left corner to assist in her brain-storming.

Look for another “model snippet of the day” like this in future posts.

[originally posted at http://onefact.net/blood-pressure-cuff/%5D

• This topic was modified 9 years, 4 months ago by cort.
• This topic was modified 9 years, 4 months ago by cort.

[cort]

In today’s model snippet of the day I post a first draft class diagram of an electric parking brake. The classes are rotor, caliper, gear box and motor. Attributes are placed such that the rotor has a diameter. The caliper is in a current_position. The gear box must have gears that provide a reduction. The motor has a power rating and generates a quantity of torque.

Although not shown, the motor and caliper have lifecycles defined by state machines. You can tell this because of the state machine glyph on the classes. The associations labeled R1, R2 and R3 relate instances of the classes together.

When the brake motor is activated it drives the gear box providing mechanical advantage through its reduction. The gear box closes the caliper changing its current_position. The caliper squeezes the rotor providing frictional forces to prevent the rotor from turning, and thus keeping the car in its parking space. Note that we can read the associations in the opposite direction and state that the rotor is squeezed by the caliper which is closed by the gear box which is driven by the motor.

• This reply was modified 9 years, 4 months ago by cort.

[Dan George]

Thanks, Cort. I hope we get to see the revised draft to get a sense of how models evolve incrementally.

Something I find challenging is coming up with asymmetric verb phrases. Lahman provides paid by/hires in contrast to employed by/employs. Another example can be taken from Balcer, Mellor, page 90. I think Lahman would have used one association with is rented by/lives in and then realized the need for a second association (for the reasons stated in the related text). Above, I wonder if

drags surface of/wears down

,

applies force to/is closed by

,

drives/multiplies torque of

would be appropriate and useful. I tried to think of phrased more pertinent that mechanical connectivity. I don’t intend any criticism; just looking to expand on the simple example. Thoughts?

Thanks again, Dan

[Lee Riemenschneider]

I added a wrong comment on the One Fact blog, so if you go over there, ignore it. I plead temporary insanity. :-)

+Dan one thing you don’t need to do is model every thing that is occuring in the system, only the things you want to control. The caliper wearing down the rotor is irrelevant to control of the brakes.

If there was a way to dynamically check the thickness of the rotor, then a minimum thickness attribute would probably exist in the model (most likely in a specification class for the rotor rather than the Rotor class. A sensor would also have to be added. If this dynamic sensing isn’t in the system, then the minimum thickness would not be needed in the model, so it would better reside in a service manual.

I’m not sure all of your verb phrases were targeted at additional relationships. The “drives/multiplies torque of” might be considered a better verb phrase for R3, because it helps to illustrate the need for the reduction and torque attributes.

For R2, “closes” is more descriptive than “applies force to”, because “applies force to” doesn’t give a reason. As an additional relationship, it would be redundant.

[Dan George]

Thanks, Lee. Ya, I was making things up with my examples trying to think of reverse roles. The R3 asymmetric phrases was the only one that didn’t feel forced.

I’m a little bugged about including both phrases when they are symmetric. On the plus side, you don’t have to wonder if the omitted one was an oversight or intentionally implied symmetric. On the down side, it clutters the model and violates, ironically, one fact, one place.

Another thing that I run into is not knowing how to say what’s in or out of scope for the model. IOW, just by looking at a model, how can I tell some aspect has been overlooked or if it is intentionally left out? My guess is that the domain diagram and descriptions resolve this issue.

Thanks again, Cort, for providing an example for us to discuss and learn from. I suspect that there are more would-be-xtUML users that struggle to learn because of isolation and lack of mentors.

[cort]

Good thoughts on symmetric versus asymmetric verb phrases. You can get yourself into trouble getting too creative trying to come up with the “other direction verb phrase”. In this particular model, I think it may be cleaner to leave some of the verb phrases off. Choose the direction of traversal and provide that verb phrase only.

My favorite example of multiple verb phrases deals with the relationship(s) between “car” and “person”. A rel-phrase combination “owns”/”transports” is just such a problem. I own the car in my garage, but my rental transports me. So, there would be 2 separate associations to link 2 separate instances of “car”.

[Domonkos Asztalos]

Dan, one must have a bunch of requiremnets specifying the scope of the model.

[Dan George]

Domonkos, well, at least some requirements, anyway :). Remember that Stephen Mellor is an original signatory of the Agile Manifesto for Software Development.

He expressed disappointment that the industry focused on 3GL Agile instead of Model Driven Agile here: http://www.softed.com/resources/docs/stephen%20mellor%20agile%20manifesto%2010%20years%20on.pdf

I suppose the answer to my question is “it depends” and you really cannot validate a model just by looking at it. You have to know the context and the purpose of the model. The insight can be gained face-to-face, from model notes, requirements, etc.

Cort, it would be great if you could give us a little blurb on the purpose of a particular snippet in future postings. It will help me learn how to do that for my own models.

[poj]

When it comes to asymmetrical phrases on relations, many of the best examples are just a tiny bit asymmetrical.
A Waypoint is first in a Route, but a Route starts with a Waypoint.

Remember to keep your phrases in the domain you’re modelling. Cort’s example of “owns”/”transports” somewhat mixes two things into the same relation. The ownership of a car is one kind of a relation to a Person, the actual ongoing transportation of Persons are another thing.

When trying to decide if phrases are correctly paired, I try to read it in one direction and then in the other and see if the statements contradict, have nothing to do with each other, or if they supports each other. Non-supporting phrases is an indication of domain mixup in the relation.

[cort]

[Lee Riemenschneider]

Domain mixup or an unspecified relationship within the domain. In either case, there’s an indication that the model needs to be revisited.

[Lee Riemenschneider]

On requirements and Agile: One of the discussions I’ve frequently had with co-workers concerns invariants in the system and known requirements. Most people could probably tell you a number of requirements for a (e.g.) radio off the top of their head, but I’ve heard developers claim those requirements don’t exist until a systems engineer writes them down. Not only that, but those known requirements are often not viewed as invariants that can be modeled and reused in every radio under development. The major problems with requirements change is the lack of recognition and capture of the invariants in the system and poor separation of concerns.

[cort]

[Travis London]

Father’s Day

Just thinking about how may day goes, and figured I would have some state machine fun :).

Maybe I could extend on this a build a robot to help out.

Enjoy,
Travis

[cort]

See Revision Control model snippet here: http://onefact.net/revision-control/

• This reply was modified 8 years, 11 months ago by cort.

[Author]

Posts