How I can illustrate Akka actors in UML diagrams? Especially how to illustrate messages passed between actors? Any example will be fine. Thanks.
Be careful, Akka actors and UML actors mean two very different things. For UML, an actor is something (a human or another system) interacting with the system. For Akka, it is an active object.
So, you can use either, a sequence diagram if you want to illustrate the interaction during the time, or communication diagram if you need only to illustrate messages order.
Aka Actors are self-contained entities with their own lifecycle. Akka actors interact by sending each other messages.
Replace "Akka Actors" with "Objects" in the above statement and you have a pretty good description of the OO model underpinning UML. So you can use Class Diagrams, State Diagrams, Sequence Diagrams etc. to model Actor-based systems.
You could make various refinements depending on your needs. For example, each class that represents an actor is <<active>>. Or you could go further and introduce an <<Actor>> stereotype. Depends on your audience & model purpose.
hth.
Related
I'm working on sequence & class diagram for education website, should all objects in sequence diagram be a class in Class diagram?
For example in sequence diagram for registration process I need an object called "Data Base" which needed for saving information of user, should "Date base" be a class in class diagram? and what can be its functions? Is it just load & save?
I think it depends on the level of formality, abstraction, and the purpose of your UML model.
Martin Fowler talks about UML as Sketch, UML as Blueprint, and UML as Programming Language.
The terminology has gotten some good usage; and I think 'UML as Sketch' in particular has emerged as a popular mode, with the goal of human-to-human communication about the design of a system; not necessarily a formal engineering specification (i.e. a blueprint), nor suitable as an input to a code generator (i.e. a programming language).
If you want to use UML in Sketch mode, which is perfectly valid, then it's not a requirement for your sequence diagrams to use only the classes defined in your class diagram. In fact, some of the objects/lifelines in a sequence diagram aren't class instances at all:
They may be "actors" defined in a use case diagram (or not). Actors are often people, and as such are represented as stick figures. "End user" is a common actor to include in a sequence diagram. Plenty of examples here.
They may be external systems, like a database, that are not defined in your class model. Your system might have a class, or set of classes, to abstract the database, i.e. a "data access layer" or DAL. But then again, your system might not have a DAL; and even if it does, you might still want your sequence diagram to show the interactions across the boundary, between the DAL and the actual database.
Using UML as a sketch, the methods implemented by external actors or system components are really up to you. You could show a database query as execute query, or something more specific, like an actual SQL statement. The "correctness" of your diagram is in its ability to communicate effectively with your audience, at the right level of detail and formality.
Yes, the Database would be a class in Class Diagram and its functions can be validation() , generatingErrorMessage() etc.
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.
I would like to know if somebody has a good sample about how to organize a UML class diagram when using Domain-Driven Design.
I really don't know how to make fit entities with repositories and services.
The UML diagrams that I end up with for DDD are usually hand drawn, informal and don't strictly adhere to all the guidelines. From the perspective of UML, entities, repositories and services are all simply classes; classes could be marked with a stereotype for clarity.
Furthermore, I don't place too much emphasis on class diagrams alone. It is often more fruitful to consider the model from a behavioral perspective, which is where sequence diagrams can be helpful, though they can quickly become too technical. Class diagrams can help you identify aggregates and entities, but they can also lead you astray by placing too much emphasis of the nouns as opposed to the verbs.
Another important type of diagram in DDD is a context map which can be viewed as a class diagram for bounded contexts. There aren't any explicit UML practices for expressing context maps and as a result an informal approach works best.
Overall, what has worked for me is low friction, low ceremony, and informal. Use boxes to represent concepts and lines between them to represent relationships. Anything beyond that can certainly be helpful but it shouldn't be at the cost of the other aspects.
You should also understand the purpose of the diagram. Are they for facilitating the design and modeling process? Are they for documentation? For sparking conversation? For communication? Each of those reasons may have specific constraints.
my suggestions: build stereotype for each DDD building block (e.g. <>, <, <> e.t.c.), sign each class by one of this stereotypes, use only "use" connection... (composite only for aggregate)
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.
What would be the best UML diagram to show decoupling of two multithreaded classes, joined
by a producer consumer queue.
I've done a whole bundle of class diagrams in the past, but they seem to be really static.
Is it possibly the case that UML is not very good at modelling threading.
Thanks.
Standard UML doesn't support well concurrency. So UML has defined "profiles" for specialized needs. See Real time UML: advances in the UML for real-time systems
http://books.google.com/books?id=LewzKVv3A20C&printsec=frontcover&dq=UML+REAL+TIME&source=bl&ots=VcKe_Lj8_P&sig=fpZ8hmokNe-rNUR4WlqTM1_1Fds&hl=en&ei=XIY5TLqrBpiTONnL7IoK&sa=X&oi=book_result&ct=result&resnum=6&ved=0CDIQ6AEwBTgK#v=onepage&q&f=false
Use a sequence diagram. One lifeline for each class, one lifeline for the queue.