What is a profile diagram in UML? More specifically what is the role of this diagram? And what can we use it for (problems we can solve with it, or solutions we can simplify more with it)?
A profile diagram lets you define an extension to UML by defining your own stereotypes and a couple of other similar elements. The idea is to tailor the expressivity of UML diagrams to a specific domain.
Here you can find some examples, such as:
enriching the class diagram with symbols or stereotypes that correspond to a framework (for example EJB components) or a method (for example the Boundary-Control-Entity design that is used to transform use cases in a systematic manner into a class diagram).
adding stereotypes to allow to represent more precisely nodes of a deployment diagram according to a better network typology.
adding tagged values to enrich diagrams with ownership, authorship, or configuration management information.
Related
So I'm currently studying UML and I have a question regarding the difference between a Domain Model how this is compared with an Activity Diagram. I a bit confused with the following terms:
Activity Diagram (AD)
Domain Model (DM)
OO Domain Model (OO DM)
Class Diagram (as a term)
Domain Class Diagram (CD)
Design Class Diagram (DCD)
In Visual Paradigm, you have two the option between Activity & Class Diagrams to draw out your designs. So far I have been using Class Diagrams for my Domain Model but a friend of mine told me you should not be using Class Diagrams for your Domain Model. So my question what's the difference and how does a program like Visual Paradigm differentials with the standards of the subject I'm trying to learn.
Domain model and domain diagram do not exist in UML, so all depends on the definition you use.
If I look at the literature it seems the 'standard' diagram to show a domain model is a class diagram, may be associated with object diagram to show example of instances.
An activity is a behavior, to use common word an 'algorithm'. An activity can be used to model the body of an operation. The goal of an activity and a class are totally different, one cannot replace the other.
Even the definition in Wikipedia is a domain model is a conceptual model of the domain that incorporates both behaviour and data the associated diagram in the article is a class diagram. In the article the word behaviour visibly refer to the rules the business uses in relation to that data.
Anyway, whatever, all depends on what you have to model, there is no definitive rules saying in case 1 use only class diagram, in case 2 use only activity diagram, and so on. You use all the diagrams you want while they are adapted for to say something useful
Activity diagrams are used for represent the behavior which shows flow of control or object flow with emphasis on the sequence and conditions of the flow.
Example:
The class diagram is used to specify the relations that exist between the classes from your model, also you can represent their attributes and methods.
Example:
Going back to your question, if you want to represent the behavior of your model, I should recommend using an activity diagram, but if you only want to specify classes that you want to use and their relation then you can use a class diagram.
up until now, I always ignored the UML Metamodel, but now that I've taken a closer look at it, I have a question which isn't answered by the standard books which I have at hand.
The Metamodel describes elements and their associations per diagram. So, it defines for instance what kind of relationship an actor can have with a use case in a use case diagram.
But does it also describe the relationships / associations between diagrams? Or maybe better expressed between elements of different diagrams?
Example:
In a class diagram, I define how I structure my code. This is defined by the metamodel
In a deployment diagram, I specify how I deploy artifacts to execution nodes. Also defined by the metamodel
But does the metamodel also define relationships with which I can specify how I derive the artifact (which I deploy, maybe a .jar file) from my code?
Diagrams are only a view onto the model. So you can show any arbitrary part of your model. Preferably you create a number of different structural diagrams to explain your model structure. Those are later augmented with behavioral diagrams which show how certain elements collaborate.
tl;dr UML is not about diagramming.
Yes, metamodel explains how various elements of a model can be connected. Diagrams itself represent poets puff the model and it is also described in a metamodel. While it's not always clearly shown how to actually represent that, for example each behavioral model represent behavior of something. What can have this type of behaviour is part of metamodel.
Let's look at specific example.
Consider State Machine. Metamodel defines which elements can have State Machines (e.g. A class). So if you have a certain class you can draw a diagram of State Machine owned by this class. How to show that this SM is owned by that class is a different story but that is also possible with UML.
Then on a state machine you can have activities which according to metamodel have to be owned by the same class etc.
One remark - it's spread over the whole specification. But look at definitions of elements like classifier, behaviour, state machine etc. That's where your answer is.
Can someone give me an example of when is better to use State Diagram and when Class Diagram. Tnx in advance!
For what type of software system would you use state machine diagrams to model functional requirements?
For what type of software system is data modeling via UML class diagrams suitable?
A class diagram shows classes in their relation and their properties and methods.
A state diagram visualizes a class's states and how they can change over time.
In both cases you are talking about diagrams which are only a window into the model. The class relations define how the single classes relate to each other. A state machine can be defined for each class to show its states. In embedded systems you use state machines almost all the time but there are also state machines for business applications (you can do this if that).
This question reveals a very common misunderstanding. There are only thirteen types of diagram in UML. They're not used to describe different types of system, but to describe different aspects of the system you are documenting. Which you pick in any given situation is more a question of style, what you want to emphasize.
It is better to use state diagrams if you want to focus on how the system can go into different states in response to various events. Activity diagrams are better if you want to focus on activities being carried out in some order, sequence diagrams are better if you want to show messages being sent between entities.
The above are all types of diagram which show behaviour. Class diagrams are a different type of beast altogether, and show how structures of things fit together (as do package diagrams and component diagrams).
It might be worth pointing out that while UML does not include a "requirement" element type, the related modelling language SysML does. If you want to express a number of functional requirements on the form "the system shall" in a model, SysML is a better fit.
A state diagram shows the behavior of the class. A class model shows the relationship between two or more classes. It includes its properties/attributes...
A state is an allowable sequence of changes of objects of a class model.
i'm php developer using MVC architecture that i'm new to UML
i know use-case , class , object , activity, sequence diagrams but i don't know for modeling a application where i should start.
i know use-case and class diagrams are structural diagrams and activity and sequence are behavior diagrams
but my questions are:
1. for modeling a app when i should use use-case diagram and when i should use class diagram?
2. does class diagram has abstract concept? because when i'm developing web app i have some controller and model or view also several classes that i use for different purpose (like insert data to database - validate form inputs and so on) but they don't look like to examples of class diagram that i'v seen until now so my question is class diagram is used for show concept of our system and it doesn't need to generate real class code form it ?
for example modeling a ticket reservation that may have some classes like this:
but we don't write class codes like this and it can be different in programming but for view the concept we are using class diagrams . is it true ?
Use-case diagram is usually used for representing the business of the project, indicate who(actor) are going to utilize the system and what services(cases) does program provide?
The class-diagram is used for specifying the whole system structure, but there no code and exact behavior will be provided by the class, generally developers don't specify the exact behavior with each module in-detail.
for example, consider a simple login module. in use-case diagram, we just mention that user logins into the system.
In class diagram we specify the possible base classes are needed, in other word we apply the architecture (we are planning) basis.
In sequence diagram we focus more on what is going on each method(while this is not necessary).
In fact UMl is used for representing the system as abstract, not the exact(in-detail) functionality.
for example I pass the above class-diagram to a developer, and tell him about the detail login process as a separated document.
Im a bit uncertain about the relation between the Unified Modeling Language (UML) and the different modelling perspectives (conceptual, specification and impelementation) endorsed by (R)UP among other OOA/D methodologies.
From what I understand the same type of diagram using the same notation can have different meaning depending on the perspective* being used. For instance the class diagram can represent an abstraction of real world systems / phenomena in the conceptual perspective and when perspective is later changed to specification/implementation the class diagram is used to abstract constructs of a computer program.
Questions:
1) It is my understanding that certain rules exist for a UML class diagram in general. For instance that a class can extend another class but that it can't extend an association. Where are the entities of the class diagram and the rules about how they can relate defined? Does it all take place at the M2 layer in the UML metamodeling architecture
(see wikipedias illustratio of metamodel architecture)?
2) A related question. The way I see it, the general rules for a specific diagram span the modelling perspectives (again, it is absurd for a class to extend an association), but the different modelling perspectives will superimpose certain meaning to a particular type of diagram. For instance an association in the class diagram of the domain model (conceptual perspective) will inherently be bidirectional whereas it can be either bi- or unidirectional in the class diagram of the design model (specification / implementation perspective).
In the scenario just described the rule superimposed limits the properties of an association. Is it a correct assumption that rules superimposed by perspectives will always be a subset/limitation of the rules defined by the uml metamodel and never a superset?
Are these rules/limitations defined by the perspectives formalized (in a way similar to the metamodel) or are they mere conventions described in the OOA/D litterature?
* Perspectives are explained in paragraph 10.8: http://books.google.co.uk/books?id=r8i-4En_aa4C&printsec=frontcover&hl=da&source=gbs_v2_summary_r&cad=0
1) Your first question is quite clear. The rules that you are looking for are called a "metamodel". And yes, they are documented as what the OMG (the creators of UML, basically) call "MOF" or "meta-object facility". It is an OMG standard.
2) Your second question is a bit more confusing. I'll try to answer here. Diagrams are just views on an underlying model. The model is overarching and all-encompassing, if you wish. But diagrams are not. The perspectives that you mention are related to diagrams. But the model that underlies is multi-perspective, in the sense that all the elements form a connected mesh, without isolated "islands". Does this make sense? :-)