I am building a system with no classes and objects, only a database. And I was wondering if it is correct to implement the sequence diagram with System and Database as the only objects in the diagram as shown in the picture.
Extract of My Sequence Diagram
You can use a sequence diagram to model exchanges not only between instances of classes, but also between instances of components or subsystems. This can be extended to systems if you’re modelling a system of systems. So your approach is perfectly acceptable (and it can really help).
By the way, the fact that a DBMS is not an object in the sense of OOP, does not prevent you from modeling it as an object, since it is encapsulated, has an internal state, and offers behavior via a well-defined interface.
The only ambiguous thing in your diagram is the actor, since lifelines should be internal to the system whereas actors are external. But it’s a common practice, even if messages exchanged are not as formally defined as one would expect in a traditional sequence diagram.
Related
The picture is taken from the book "UML # Classroom". The text says "the registration is via e-mail, that is, asynchronous".
In actuality, I believe, there would be no "Student" and "Professor" objects involved in the process. Rather an interface, a call to a mail server and in general, nothing that would tell the viewer of the diagram what is really going on.
That makes sense to me because it has an illustrative purpose. The methods of the classes in the sequence diagram would only resemble the methods in a class diagram at a low level.
If I am tasked with a high level view of class diagram and high level sequence diagrams of a particular interaction, if I am then asked why the classes of the class diagram don't have any of the methods of the sequence diagram, am I right to say that they simply don't have to?
Should I reach a compromise with the sequence diagram wherein I try to make the calls similar to what will be going on in the program?
The methods of the classes in the sequence diagram would only resemble the methods in a class diagram at a low level.
Not necessary, all depends on the goal of the sequence diagram, you can have classes at design level (may be allowing to generate code) but having them in a sequence diagram giving a semantic (high) level. You can also show these classes in class/package/... diagrams without low detail so not at design level.
The only rule is to have diagram saying something useful, and following UML specification of course. Do not forget UML is not a method but a language, it does not indicate how it must be used.
Remark you can put note in a diagram to help saying explicitly its level/goal in case you are afraid it is confusing because not 100% limited/dedicated to design even using classes part of the design.
if I am then asked why the classes of the class diagram don't have any of the methods of the sequence diagram, am I right to say that they simply don't have to?
yes, because the goal is not necessary to show a sequence of calls but for instance a higher level.
Should I reach a compromise with the sequence diagram wherein I try to make the calls similar to what will be going on in the program?
Of course you can do too.
Notice a sequence diagram (so in fact an interaction) has limited features, while for instance an activity allows to model a behavior in detail without the same limitations.
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.
According to UML context diagram context diagram doesn't exists.
So my question is which one of UML diagrams is good to show something like this and how to paint this?
I've just found the following definition: http://en.wikipedia.org/wiki/System_context_diagram
That's probably what you need. :)
A context diagram defines a boundary between the system, or part of a system, and its
environment, showing the entities that interact with it.
There is no single diagram in UML that would map to this definition, but I have some good news - there are several diagrams (out of total of 14) that can show the frontier between the system and its surrounding world from different perspectives. This is much more flexible than only a context diagram.
First of all, I would mention a special UML element - a boundary. It can be used in any diagram type to show some kind of delimitation. You might want to optionally use it to visually delimit between the system and its environment, especially in situations when this is not explicit.
The following diagrams can show the boundary between the system and its environment:
Use case diagram (your example) support the context explicitly on the functional level. Use cases are elements of the system under development, while the actors are extern entities (systems or human users). Before mentioned boundary is often used to visually delimit between the system and its environment.
Component diagram is used to model some kind of software modules (applications, DBs, external systems, libraries, etc). You can use it to show both internal and external components and the way they interact. A boundary can be used to clearly draw the separation line.
Activity diagram can show your system/business/usage processes. Some activities can be performed internally, others externally. Here you don't need the boundary, but the so called swimlanes to depict who does what.
Sequence/collaboration diagrams are another option. They show the communication sequences between several objects. If you split those objects in internal and external ones and wrap them up with the boundaries, there is another context diagram. :)
UML is flexible, there are probably further options, but I think this is enough to get the idea.
Names of your association are services. UseCase in center of diagram is context of services definition. See usecase diagram:
It could be done with a use case
http://en.wikipedia.org/wiki/Use_case
EDIT:
Reconsidering it, use case diagram should be the next step once the operations are defined so first you shouls make a system sequence diagram.
http://en.wikipedia.org/wiki/System_sequence_diagram
If you're happy with going into the not complete superset of UML that is SysML, you can have proper Context diagrams there.
However, context diagrams in SysML are simply Block Diagrams showing system context… and Block Diagrams happen to be the same as UML2 Class diagram, where the classes are of stereotype «SysML::Block».
So you can define your context diagram in terms of aggregation of blocks to your system, with the relevant stereotypes, basing it on UML2 Class diagrams.
I tend to use collaboration diagrams for this. So for each major scenario of each use case, draw a collaboration diagram showing the actors, with the application as a single entity in the middle, and messages travelling around that show how the application interacts with the actors in order to fulfil the scenario.
(I don't put too much detail in the messages -- I only want to show that there is a delegation of responsibility and some kind of interaction, but I don't care about details of actual messages, views, data etc.)
I find the context diagram does have a particular appeal. It sits well with business users, showing them the scope & parties of a system in a very easy way. So, I tend to create a context diagram, even in contexts where UML is prevalent.
If I create a conceptual class diagram such that each class captures 'name' and 'attributes' but not 'operations', have I not basically created what would be otherwise considered an ERD? I'm trying to gain an understanding of what the differences are between creating a conceptual class diagram as I have described versus calling it a ERD? If these are still two different animals, can somebody please explain what the differences are?
The class diagram contains just the classes in your object model with eventual links/relationships connecting diagram elements. However those links don't necessarily correspond to physical relationships like in an ERD diagram, but instead they represent logical connections.
The class diagram is just the object model of your application and does not contain any persistence-specific information. When you think about the class diagram forget about the database or any other storage you may use.
The ERD diagram on the other side, is a persistence-specific diagram which display the entities (tables) existing in a (most often) relational database. It also displays the physical relations (and cardinalities) between those tables and all other database-specific information. The ERD diagram can sometimes look similar to the class diagram, but that doesn't mean is the same as a class diagram.
There´s little difference in the expressiveness of both (if we just focus on the attributes, classes and associations part) if you use Extended Entity Relationship diagrams (the most common case nowadays)
True, they look very different at the graphical level since they use different symbols for the elements but the "semantics" are quite similar. They both allow inheritance (again, I´m talking about EER), n-ary associations, association classes, ...
The ER diagrams I've seen (most frequently ERWin IE notation) have focused on the design for a database. They are concerned with primary keys, foreign keys, have unnamed relationships, and usually have no generalization / specialization.
A good UML conceptual class diagram, on the other hand, is not concerned with keys, reflects the problem domain, and has association-end properties that at least hint at the semantics of why things are related. This helps communicate the domain down to more junior developers so they don't have to guess.
It depends on the situation where you may not like to do the ER-D. But imagine if you have a seperate data layer where the data logic is handled. In this case many details of data shall not be shared with the application layer. And you class diagram shall not go beyond the application layer. I must stress that both the diagrams are not equal. And there are situations where you need to do both, mainly in multi-tier architecture, and there are situations where you may be able to just use class diagram; e.g. single-tier application.
I strongly advocate the view that class diagram doesn't abrogate the E-R diagram.
Design class diagrams are made from conceptual model and collaboration diagrams.
Design class diagrams include:
Classes, associations and attributes
Methods
Types of attributes
Navigability
Dependencies
IMO In Simple terms
Class diagram depicts the details of how will the system work.
ER diagram depicts how the system persists 'state' as a blue print.
Goal:
Detail out state and behavior of the components(classes) of the system.
Design 'efficient', flexile system(less coupling and more cohesion) using Solid principles.
Goal:
Design a blue print of how to 'efficiently' persist the state of the system.
Consider what kind of queries will be made (read vs write), are there any joins required
consequently figure out the columns for indexing
Use Normalization, ACID properties.
PS: notice the both the diagram tries to efficiently do thing in their on respect.
Is an activity diagram is considered algorithmic?
Strange question indeed. Taking a look at dictionary definitions:
Algorithmic: of or relating to or having the characteristics of an algorithm
Algorithm(1): a precise rule (or set of rules) specifying how to solve some problem
Algorithm(2): an effective method for solving a problem expressed as a finite sequence of steps.
So: can Activity Diagrams be used to describe "a method for solving problems expressed as a finite sequence of steps"? Yes - that's their purpose. They support all the usual control structures required to describe algorithms: sequence (A followed by B), alternation (either A or B), iteration. They also provide explicit support for parallel activity.
Areas where they may be considered weak:
The execution semantics are not precisely and unambiguously defined. Whilst the UML spec does provide some semantics, it leaves some points open.
There's no pre-defined set of primitive types defined for Activity Diagrams. Thus, the lowest level primitive activities (adding integers, concatenating strings, etc.) aren't pre-defined. In that sense Activity Diagrams on their own aren't computationally complete.
However: those are nitpicking theoretics. In practice, Activity Diagrams are a popular means to represent algorithms: from the design of software procedures to specifying business processes.
Of course, it all comes down to your definition of algorithmic. If you go with the general definitions above then ADs are algorithmic. If you go with something more specific they might not be.
hth.
OMG Meta-Models (i.e. UML, SysML, etc.), starting from the Meta-Meta-Modeling language by means of which they are described (MOF), consists of two different classes of models respectively aimed at definining:
The static structure of a system, or architecture (i.e. Class Diagram, Component Diagram, Block Diagram, etc.);
The dynamic of the system, or behaviours (i.e. sequence diagram, activity diagrams, state machine diagrams, object interaction diagrams, etc.)
Activity diagrams belong to the second class so they are aimed at describing behaviours.
an algorithmic is only of type of behaviour that can be described by means of an activity diagram
Activity diagrams complemented with the new UML executable standards can be used to represent any algorithm. Activity diagrams alone can be used to represent the overall control flow but not really the details of data management