I'm trying to design a UML class diagram that represents Users that interact with other classes based on their roles, I've chosen to represent Roles as an enum class like so :
What i'd like to represent is that only a user with a Role ADMIN can create a project, only a MANAGER can modify it and every CONSULTANT can only participate in it, can this be achievable with enum representation for Roles?
A solution is to use uml constraints like so:
Being an enumeration RoleName is better drawn with <<enumeration>> (like in the Figure 7.1 - Class Diagram Example page 7 of Object Constraint Language - formal/2014-02-03 )
If Role is only an envelop for RoleName that class is useless (this is what I suppose in the diagram below)
The relations create, manage, participate do not represent attributes, the multiplicities have non sense in that context. The relation role has the default multiplicity 1
Your constraints are pre-conditions, their context is the class User and in OCL the equality operator is "=", so your diagram can be :
You are mixing static representation and behavior. The User has one association to Project (not 3 different ones):
The different behavior (derived from some UC) can be shown in a collaboration. E.g. in an AD like this:
Just a sketch, but that should give you the gist.
Related
First, context:
We're developing some applications using QP Framework from quantum leaps.
QP is basically an event manager for state machines.
Our approach:
Since we're using QP, our modules interact with events and signals (classes/structs and enums) except some very specific modules that interact by methods.
Problem:
For those last modules, interfaces are easy, just a collection of all the public methods in said module, however, how about the others? Can we say an interface is a composition of other classes and enumerations?
Since the modules interact by sending/receiving events, both should know what kind of data packets (events) can travel through that interface.
Can we represent an interface like this? or should an interface only be a collection of methods?
edit 1:
Replying to the comments below, I don't want to say the interface had nested classes, but that the interface would define said classes so they could be used as events, but from your answers, seems using signals would be a better approach. (The ADC:: prefix and the name of the interface are not the same, just some bad naming choices, as the package name was ADC and so was the interface)
edit 2:
From the comments and answers below, I had no knowledge of the signal stereotype, so updating the question, I think it would become something like this?
This solves the classes and signals problem, however, the enum remain...
My intention was to say the interface would define this keywords, i.e. the module that implements the interface, should define this enum and their values.
Is this the correct approach?
The interface in your diagram is perfectly legit. UML interfaces do not have the constraints of Java interfaces: they can have operations, attributes, and all kind of associations (btw, the aggregation does formally not add any semantics to associations, and you could safely consider to remove the white diamonds), including composition (black diamond).
However it might not represent what you are looking for: interfaces express a contract. It means that the classes implementing it must provide those attributes and associations, and not that the classes will get all these features by a kind of “inheritance”.
Moreover, I’m not sure if you try to express some complex interface, or just found no better way to represent event consumption/generation. In the latter cse it would be an overcomplex and misleading approach.
For event based design, you may be interested in using signals. Signals are like classes, but there are UML elements to express the ability to process a family of events, and/or to generate events. It moreover facilitates the link between sequence diagrams and class diagrams, as a message can correspond directly to an event instance.
The model per se is legit. However, it's likely not what you intended. The shared aggregation has no defined meaning. See p. 110 of UML 2.5
shared | Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
So unless you define the meaning of them the model has no defined meaning.
If you intend to inherit operations/attributes you would draw an open triangle arrow towards other classes. Enumerations should simply be an attribute (simple association with role).
P.S. As per Geert's comment I notice the nesting too. So you obviously over-define this by adding the (meaningless) shared aggregation. You could represent the nested classes by showing them inside the enlarged «interface». Or you use (as suggested by Geert) the nesting relation (personally I use that rarely, but it's an alternative).
Here's my classdiagram:
In my perspective (since each cannot function without the next one):
models compose the repositories,
repositories compose the services,
the services compose the controllers.
I think I'm wrong in my understanding of UML relationships.
What is the right way to make a class diagram in MVC?
Terminology and semantics
If classes cannot function without another one, there is a dependency. A dependency does absolutely not imply composition.
In object oriented programming, we often refer to composition, in the sense object composition. This relationship is stronger than a simple dependency. It means that each object of the class may need to knwow objects of the other class. In UML we represent this with an UML association.
In some case, the links between objects are stronger, and may have UML aggregation or UML composition semantics. But it's not because you compose objects, that there is an UML composition. Same term, different meaning (some more advice on using UML association and composition and avoiding UML aggregation: here).
In MVC, the Controller is associated with the Views and the Model, and each Views is associated with the Model as well. There is no UML composition.
Notation
You cannot compose a class with a package. Packages describe namespaces and can be nested. They can contain other UML elements. But they cannot be associated/aggregated/composed with classes.
What you are looking for seems to be a component diagram: components can be nested, and be relate to other components via interfaces. And a component can contain classes.
Content of your diagram
There seem to be a slight confusion between the DDD domain model and the MVC model. Despite the same term, the two concepts are different.
In MVC, the Model manages the knowledge, meaning the domain model and everything needed to cope with the domain model:
User, Transfer and Tax are DDD domain entities/aggregates and belong to the MVC model
Everything needed to persist this knowledge, such as UserRepository, TransferRepository, TaxRepository also belongs to the MVC model. If you'd use another persistance approache (e.g. table gateways, or active objects) you would not have repositories but other objects.
The MVC Controller processes the user input, and sends commands to views and the model. It is not a repetition of the domain objects.
Where are the views ? What is the purpose of your services ?
are they domain service, i.e. operation that involve several aggregates and do not naturally belong to any single one of them ?
are they a service layer of an application, meant to link it with the outside world?
I'm using IBM Rational Rose, but I'm not sure if I'm able to model/design the methods/procedures which are known as "operations" within a class onto "UML User Class Diagram". Is there any way to model the algorithm or the code of 'operations' (i.e something like flowchart) via the software? If so, is there any possibility to get the methods design auto-implementation integrated via code generation in order to define them within a java source file?
Another way to model behavior is to use StateMachine, Constraints, Sequence and Timing diagrams. Of course, you can simply write Notes describing behavior in plain words.
You can use activity diagram, activity diagrams are near a flow chart.
See rsa activity diagram
On your activity diagram, you create a partition and you can link your partition to you operation. Then you create callOperation action which can be linked to method call.
I create a class diagram with 4 class Class1, Class2, Class3, Class4, each one containing a method operationx.
And here is a simple example modeling operation1. The important point is that the partition named Operation1 is linked in the UML model to Class1:operation1 and the 3 actions are linked to method operations. This is not a "typo" tips.
You can look also to sequences diargam but it does not look like a flow chart.
when I visualize the well known koala.owl ontology I see in the hierarchy the class Student as subclass of Person and MaleStudentWith3Daughters is a subclass of Student. I wrote a code which extract a hierarchy of a given class, i.e. when I choose the class all its superclasses and subclasses are stored in a separated model. It works with other classes but it seems having a problem with Student, Person and MaleStudentWith3Daughters.
Here is the code:
//here is the code which determines all superclasses of a given class c
//adding a class and its superclasses to new model
public void ajouterHierarchieSupAuModel(OntClass c){
ArrayList listesuperdirect = new ArrayList();
OntClass sup;
//adding super classes
listesuperdirect = lamere.getSuperClasseDirecte(c);
if(listesuperdirect!=null){
for(int i=0;i<listesuperdirect.size();i++)
{
sup = (OntClass) listesuperdirect.get(i);
OntClass supp = module.createClass(sup.toString());
OntClass classmodule= module.createClass(c.toString());
classmodule.addSuperClass(supp);
}
for( int j=0;j<listesuperdirect.size();j++){
c=(OntClass) listesuperdirect.get(j);
ajouterHierarchieSupAuModel(c);//recursive call
}
}
}
// the same thing for subclasses of a given class c
When I experimented it through classes as Marsupials or Forest it works very well but It seems that Person and Student are not belonging to the same hierarchy although they appear belonging to the same hierarchy in Protégé.
Any answer will be welcome ! Thanks.
I am compiling my comments into an answer because there is a lot of information there and it is becoming unwieldy to limit myself to 500 characters.
The reason you're having trouble with Person and Student is that the heirarchy is inferred. If you look at the actual .owl file, you will see that Student is not defined as owl:subClassOf Person. Rather Student is defined as a class that is equivalent to Person having property restrictions hasHabitat some University and isHardWorking value true
A property restriction is a special kind of class description. It describes an anonymous class, namely a class of all individuals that satisfy the restriction.
Look here for more information on property restrictions
To ease your confusion a bit, think of owl classes as a sets and subclasses as subsets. In this particular case we have defined the class (set) of Student as the intersection of the class(set) Person and the classes(sets) given by the two mentioned property restrictions. We have not explicitly stated that Student is a subclass(subset) of Person, however since Student is a more restricted version of Person, it is inferred to be a subclass(subset).
The main difference being the explicit use of the rdfs:subClassOf or owl:subClassOf tag. If you look at the file, both Marsupials and Forest, both have the rdfs:subClassOf tag. However Student does not, however since it is a restricted version of a Person it is inferred to be a subclass of Person. Look here for more information.
Look through Jena's ontology API here or the Javadoc here for more Jena code specific information.
A Suggestion from my side is try running a reasoner on this ontology in Jena before you try to use your code to get subclasses, it might work out better. For steps on how to do that go here
When designing a class diagram for a theoretical MVC-Pattern-based system, is it best to use List classes?
For example:
With List class:
Without list class:
I personally feel the latter is a better approach due to less code duplication, is there a better approach to this?
I don't think there is a need for a list class. Your controller can hold all references to the model.
Regardless of that, your UML models have a problem: in both cases you have an attribute customers:Customer[] and an composition link. This means that you have TWO references from the controller (or list) to the model. Either remove the attribute or the link.
I would suggest you to use swimlanes, one lane per structure component (MODEL / VIEW / CONTROLLER) and a separate lane for the database
a sample example would look like this