UML Lovers group
there's a group I created two years ago with some (I hope) interesting
discussions and links.
We are interested in UML and our contributions are mostly about the
UML ad used by Analysts and Business Analysts, a little less on the
pure technical side.
Everyone is welcome
RE: [UML Forum] Understanding Relationships for Class Diagram
Regards,
Sanjay Amin
Wipro Technologies
+91-20 30 96 02 07 (O) | +91-95 27 00 27 37 (M) | 8540207 (VOIP)
-----Original Message-----
Behalf Of H. S. Lahman
Sent: Wednesday, July 14, 2010 8:47 PM
To: umlforum@googlegroups.com
Responding to sanjay.amin...
And it was answered in my previous message. Evidently I was not clear
AW: [UML Forum] Understanding Relationships for Class Diagram
If you're creating a global attribute of Class B within Class A, this can be
achieved by an association. But an association doesn't indicate the calling
of an operation. Therefore, you must make use of a behavioral description in
the classifier behavior. Within classifier behavior you're able to describe
Microsoft dropping Quadrant - Another step backwards in its MDD strategy
After "refocusing" Oslo (in short, the Microsoft strategy for model-driven development consisting in the M modeling language + the Quadrant modeling environment + a model repository) we were left wondering if Microsoft still believed in model-driven development .
-->Open Health Tools - Model-Driven Health Tools project (MDHT)
The Open Health Tools - Model-Driven Health Tools project (MDHT) aims to provide modeling tooling extensions to the Eclipse Modeling Project for healthcare applications, and in particular, to produce implementations for the HL7 standard .Another interesting project to follow!
-->Re: [UML Forum] Understanding Relationships for Class Diagram
And it was answered in my previous message. Evidently I was not clear
enough, so I will try again...
This *sounds* like composition; B is part of A's implementation and
therefore A control's B's disposition (life cycle). But, as I explained
in my previous message, it depends on the OOPL you are modeling (i.e.,
RE: [UML Forum] Understanding Relationships for Class Diagram
My question is very simple.
- I have a class named A
- I have a class named B
- I am creating an instance of class B inside class A
- I am calling a method of class B inside class A after
creating an instance of class B
- I am using an output of the operation of B in class A for
Re: [UML Forum] Understanding Relationships for Class Diagram
For myself if I would usually expect a Java instance variable that refers to
some classes to be an association of some type (providing that class isn't
just a data type).
With your example though you have an instance variable that isn't actually
being used by any method. It such it serves no purpose as object state so I
No two programmers use the same notation (experiment)
Zuzel Vera Pacheco, a Master Student at the University of Toronto under the supervision of Greg Wilson has been working on the Back-annotation of data models at run-time . For a short description of her project see also this presentation on slideshare.
-->Model interpretation vs. code generation? Both.
Model interpretation vs. code generation? There were recently two great posts by Johan den Haan and Jordi Cabot on this topic, both generating interesting discussions. I am not going to try to define or do an analysis of pros and cons of each approach as those two articles already do a good job at that (make sure to read them). What I have to add is that if you use model-driven development, even if you have decided for code generation to take an application to production, it still makes a lot of sense to adopt model interpretation during development time.
For one, model interpretation allows you to execute a model with the fastest turnaround. If the model is valid, it is ready to run. Model interpretation allows you to:
- play with your model as you go (for instance, using a dynamically generated UI, like AlphaSimple does)
- run automated tests against it
- debug it
All without having to generate code to some target platform, which often involves multiple steps of transformation (generating source code, compiling source code to object code, linking with static libraries, regenerating the database schema, redeploying to the application server/emulator, etc).
But it is not just a matter of turnaround. It really makes a lot more sense:
- you and other stakeholders can play with the model on day 1. No need to commit to a specific target platform, or develop or buy code generators, when all you want to validate is the model itself and whether it satisfies the requirements from the point of view of the domain. Heck, you might not even know yet your target platform!
- failures during automated model testing expose problems that are clearly in the model, not in the code generation. And there is no need to try to trace back from the generated artifact where the failure occurred back to model element that originated it, which is often hard (and is a common drawback raised against model-driven development);
- debugging the model itself prevents the debugging context from being littered with runtime information related to implementation concerns. Anyone debugging Java code in enterprise applications will relate to that, where most of the frames on the execution stack belong to 3rd-party middleware code for things such as remoting, security, concurrency etc, making it really hard to find a stack frame with your own code.
Model-driven development is really all about separation of concerns, obviously with a strong focus on models. Forcing one to generate code all the way to the target platform before models can be tried, tested or debugged misses that important point. Not only it is inefficient in terms of turnaround, it also adds a lot of clutter that gets in the way of how one understands the models.
In summary, regardless what strategy you choose for building and deploying your application, I strongly believe model interpretation provides a much more natural and efficient way for developing the models themselves.
What are your thoughts?
RE: [UML Forum] Understanding Relationships for Class Diagram
There are some problems with your example. Create it, compile it, and see
if it works.
I think the point you are asking is whether A is Dependent upon B's name.
Am I correct?
"A dependency is a relationship that signifies that a single or a set of
model elements requires other model elements for their specification or
Bill Gates says that better software modeling is the solution
to many hard problems, from using nuclear power to combating diseases. He also said that it´s surprising that there's no disease-modeling software and, more importantly, he aims to make sure that gap is filled, supporting development of the tools needed to do such modeling.
Gates plans to offer up the modeling software package for free for others to use. He conceded that the models never get things right exactly, but he said, "You are a hundred times smarter doing it that way than just going out there (without such models)."
-->Silverlight ViewModel UserControl
ViewModel UserControl is what we call the UserControl that given an ecospace type and a ViewModel name already in design time can derive a UI based on the UI-hints that the ViewModel definition might have, and in runtime, given an EcoSpace and a Root object, turns into a fully bound UI; derived purely from a declarative idea about what you want to achieve.
The ViewModel UserControls have different implementations for different UI-architectures of course. I have described the ViewModel UserControl for ASP.NET here; http://theblog.capableobjects.com/2010/02/viewmodels-in-aspnet.html .
The ViewModel UserControl for WindowsForms UserControl I have not really written anything about – but we use them frequently in Modlr – like in the Actions-dialog.
The ViewModel UserControl for WPF I have written about on numerous occasions, for example here; http://theblog.capableobjects.com/2010/01/viewmodel.html and not to mention that the WPF ViewModel UserControl is core to WECPOF / AppComplete that is discussed here http://theblog.capableobjects.com/2010/05/wecpof-icing-on-model-driven-cake.html
And earlier this week I wrote about the ViewModels now being consumable in Silverlight via generated code ; http://theblog.capableobjects.com/2010/07/silverlight-and-viewmodels-and-eco-and.html in the available beta builds of ECO6 for Visual Studio 2010.
Today we present the ViewModel UserControl for Silverlight – named ViewModelSLUserControl. That we were about to present such a control must have been obvious to everyone but today it is actually here.
The demo project is in the Demos folder named SLDemo20100806_UserControl
In the solution explorer this looks neat an tidy:
Click open the EcoModel1:
Clicking on the ViewModels button brings up the ViewModel editor:
I wanted to show a somewhat complex sample and at the same time really test the Silverlight implementation of the ViewModel UserControl. So I added comboboxes, and master detail grids in two steps followed by a detailing of the selected row of the last grid in discrete components.
I also added columns to the ViewModel for each of the auto created/ auto maintained vCurrent_ variables that comes with the ViewModel.
Even if this sort of UI is considered advanced by many standards (never mind the look of it just now) it is easy to produce and maintain in the ViewModel editor. And this is the whole point of the ViewModel UserControls – fast as your thoughts. The interesting part is really what you do with the time you do not spend in the ViewModel editor – the time you have gained by not being forced to create standard UI’s manually, and not needing to maintain them manually.
Consuming this in Silverlight is easy (from today and forward)1: public Page()
2: {
3: InitializeComponent();
4:
5: DequeuerSL.Active = true;
6: _ecoSpace = new EcoSilverlightDemoEcoSpace();
7: _ecoSpace.Active = true;
8: ViewModelDefinitionsInApplication.Init(_ecoSpace);
9:
10:
11: CreateDemoData();
12:
13: ccc = new ViewModelSLUserControl();
14: ccc.EcoSpaceType = typeof(EcoSilverlightDemoEcoSpace);
15: ccc.SetEcoSpace(_ecoSpace);
16: ccc.ViewModelName = "TestViewModel";
17: TOPPanel.Children.Insert(0,ccc);
And you get this in runtime:
And I could not resist to spend some time to find out how far of WECPOF for Silverlight was now that the ViewModelSLUserControl was in place. It turned out that the biggest challenge was the Menus. Main menu is not in Silverlight (or the toolkit), and the ContextMenu’s that are in the Toolkit does not support hierarchical menu items – crap. I found a good start of implementing the Menus at CodePlex - http://sl3menu.codeplex.com/ , I will use this until the Toolkit catches on…
WECPOF / AppComplete for Silverlight actually works!
I added the sample to a server with IIS7 : http://lulea.dyndns.org/EcoSilverlightDemo.Web/EcoSilverlightDemoTestPage.aspx
As always – typos –> email me and I will fix & comments appreciated
The build that contains the sample and the necessary ECO6 versions is posted at the end of this topic: http://www.capableobjects.com/apps/InstantForum414/FindPost5469.aspx , if there are newer builds when you read this – use them instead…
AW: [UML Forum] Understanding Relationships for Class Diagram
Your snippet represents neither an association nor a dependency. As I
mentioned in my previous mail, a dependency is more or less a meta-concept,
indicating that a class is using another class. For my understanding a
dependency would result in the javadoc of class A.
Look to a similar snippet of your's:
Wasting Time With Test Driven Development?
TextUML Toolkit 1.6 declared!
The TextUML Toolkit version 1.6 has been released. It is the same RC1 build mentioned here a week ago. The listing on the Eclipse Marketplace has been updated, so in addition to the regular update site (http://abstratt.com/update/), if you are using Eclipse 3.6, you can get it even more conveniently using the brand new Eclipse Marketplace Client.
Take a look at the new notation features:
- preconditions on operations
operation withdraw(amount : Real);
precondition { amount > 0 and amount < self.balance; }
begin
self.balance := self.balance - amount;
end;
- derived properties
reference employees : Employee[*]
/* calculated field */
derived attribute employeeCount : Integer := ():Integer { return self->employees.size(); };
- initial values on properties
attribute available : Boolean := true;
You can also try these new features online on AlphaSimple. Sign up or start a guest session to create, validate and run your models on the spot, there is nothing to install!
Executable models vs code-generation vs model interpretation
An executable model is a model complete enough to be executable. I´m fully aware that this definition is kind of useless but the executability of a model depends more on the execution tool we use than on the model itself (e.g. some tools may require a more complete and precise model specification while others may be able to "fill the gaps" and execute more incomplete models).
-->




