I could not understand what u say here. Can u provide a complete
example for my scenario.

I also check your blog but found nothing useful.

Thanks.

--
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To post to this group, send email to umlforum@googlegroups.com.

Hi. I can see how this would work, but it seems like such an indirect
way to show the dynamic usage of an actor's contract, i.e., the usage
of the actor's interfaces required and provided by the System Under
Development. However, I suppose that's just how the UML Spec
crumbles. :)

Maybe UML 3.0 would consider allowing a port on an actor and an

It's always nice to have good examples of domain models. Jukka Tamminen is releasing from time to time models for well-known domains in his blog , the latest one a class diagram and a communication diagram for the airline business domain.

Models can be downloaded in XMI (StarUML format) to facilitate their reuse/modification

-->

 

read more

BALTIMORE, MD and LONDON, UK – May 12, 2010 – Metastorm, a leading provider of Business Process Management (BPM), Business Process Analysis (BPA), and Enterprise Architecture (EA) software for aligning strategy with execution, today announced today announced Logica, a leading business and technology service provider, has selected the Metastorm Business Process Management suite. The product suite will be used in Logica’s Business Process Outsourcing (BPO) business across the globe. The product’s functionality allows for enhanced client participation and service visibility enabling Logica to further build on its client intimacy strategy.

Last week, the École des Mines de Nantes organized the seminar “Future Challenges of Information Systems in Bank and Insurance companies”.

Three topics were constantly raised by the participants (basically, heads of IS departments of Bank and Insurance companies): cloud computing, development of multi-channel applications and model-driven development.

-->

 

read more

Our research yields these results:

1. Applications have three kinds of forms

The seek form that from nothing can search objects in persistent storage and show them in a list

The document form that is designed for a specific use case and shows information based on a root object and its associations, in as many navigational steps as necessary

The Report form that differs from the document form by being non interactive, paginated and by expanding all combinations in master detail relationships at once (non cursored)

2. The seek form can be used in two different modes

The first mode is typically reached from the main menu as in a context-less seek operation restricted by any number of filtering parameters

The second mode we call “Seek and pick” and is a modal form that aims to seek out one or several objects for a specific reason; such as assignment to some association. The “Seek and pick” is commonly used to set a 0..1 association end when a combo box would not suffice due to too large data quantity

3. Applications has three kinds of actions

Actions that act on an object based on its class

Actions that act in a given context or use case; a document or seeker form

Actions that are global and acts on neither of the above context’s, like main menu actions

4. Actions can be organized in structures; like sub menus

5. Any action can either be enabled or disabled based on state from the context

6. When an action is executed to following things can happen

Some code is executed

A Form may be opened

The opened form gets assigned an optional root object by execution of some code

The opened form can be opened Modal or not and if Modal an optional piece of code will be executed when the Modal form closes with OK (like with seek and pick)

7. Forms have UI-Validations to communicate rule breaks in the current input

8. Objects follow business rules by implementing state machines with guards

This is what we want to offer with the WECPOF prototyping framework. Following this simple manifesto we will reach far in our quest for the fully declarative application.

Here’s a common scenario for many of us who have learned about uses cases but haven’t written one yet: You’ve identified the actors for your project. You’ve brainstormed a list of goals for each actor. You’re ready to create your first set of use cases. And you feel stuck. Or at least uncertain. Call it use case writer’s block. You could point to a use case if you saw one, but what are your use cases?

When this happens, remember that use cases are based on actor goals. If a use case doesn’t describe how an actor gets something done, it’s not really a use case. Does that mean that every goal becomes use case? Not necessarily. Goals address needs at many levels – from very high levels to very low levels and infinite shades in between. Consider the following goals:

• Relax
• Plan a vacation
• Reserve a room
• Find a resort
• Pick a destination
• Type the name of a city into a text box
• Open a web browser

These are all related goals, but at different levels. Not all of them will make for a good use case. Pick a high level goal and the use case will either be too big to comprehend or too imprecise to guide decisions. Pick a low level goal and the use case will be too small and you’ll need too many of them to describe the system. This is starting to sound like a fairy tale involving three bears, but – you guessed it – the best goals are neither too high, nor too low, but just right.

If you’re wondering what goal levels are just right, here’s a more concrete guideline from Craig Larman’s Applying UML and Patterns: Write use cases at the level of the elementary business process (EBP):

A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state.

There are exceptions to this guideline, of course. You might want a high-level use case that puts context around the EBP use cases. You might occasionally want a low-level use case that describes a complex sub-process. When you’re identifying the bulk of your use cases, however, most will address goals at the EBP level – something one actor can complete in one place at one time.

To identify the use cases in your system, look at the list of goals you’ve brainstormed. Is each goal written at the elementary business process level? For goals that are written at a level lower than a business event, consider why the actor wants to achieve that goal. It’s probably just a step towards a higher level goal. For goals that are written at a level higher than a business event, consider how the actor would go about achieving that goal. There’s probably an intermediate step that has more business meaning in the system you’re defining.

So, back to our use case writer’s block. You’ve just broken through. Each of the EBP-level goals you identified answers the question: What are your use cases?

I keep noticing that everyone claims to be successful and, more often than not, sucessful only...
How good someone really is who has never experienced failure?

We all have strengths and weaknesses, and this means we perform better in some situations than others.

Have you ever noticed that when their is a problem (and there's always one), most consider self as being outside of the problem, while everybody else considers you as being part of it?

Sucessful people take ownership of the problem at hand.

Hello,

if you you need to use the UML2 Metamodel in some way for your work you will have noticed, that it is not easy to develop an understanding of the Metamodel, even less to learn quickly about the classes, their attributes and their relations to other classes. Basically there are only the official specifications from the OMG which are a bit dry to read.

Enter our new, free UML2  Metamodel Viewer!

The UML2 Metamodel Viewer is a standalone Windows application that can be used to browse the package structure of the UML2 Metamodel and explore the contained classes. In addition, it is possible to draw diagrams from these classes in a semi automatic way.

Here is a screenshot of the main window:

Main Window of the UML Metamodel Viewer

To create a diagram simply add a new diagram to your project and drag one or more classes from the Model Explorer to the diagram. For example, here is a diagram with the class Kernel::Classes::Class:

UML Metamodel Viewer with a diagram

One of the neat features is that the related classes (superclasses and classes that are used in relations) are automatically added to the diagram. This is an easy way to see the “context” of a given class.

The installer comes with a manual that should get you started using the UML2 Metamodel Viewer.

There is a catch: currently UML2 Metamodel Viewer relies on some third party software (namely the Graphviz package and the UmlGraph package – the latter additionally requires a Java Development Kit) that must be installed and configured so that diagrams can be created.

This is a 1.0 release,  so you will surely find bugs using this software.  Please report bugs and feature suggestions to support@empowertec.de. We definitely appreciate your feedback! We plan to actively support this software, which means of course fixing bugs but also implementing new features depending on demand and effort.

The software is based on the cmof-files that define the UML2 Metamodel.

Best regards,
Andreas

Technorati Tags: UML, Metamodel, Diagrams