I have a MyAccount application, that is consists of MyOrders, MyCases, and other MyXXX microservices.
MyOrders communicates with SAP, so on the low level design I specify the relation between MyOrders and SAP.
I would also like to have a high level diagram, where I only show MyAccount box (without all its internals), but still would like to have visible all the external dependencies, so the MyAccount would appear to have relation to SAP.
Question: is it possible to achieve that without the need to maintain 2 relationships explicitly, so that high level diagram is really a derivative on the lower level?
No, derived relations such as that is not supported by Enterprise Architect.
You might be able to write an add-in of some sorts to add support for it yourself though.
Related
Imagine that we are building a Library system. Our use cases might be
Borrow book
Look up book
Manage membership
Imagine that we can fulfill these use cases by a librarian person or a machine. We need to realize these use cases.
Should we draw different use case realizations for different flows?
If not, it is very different to borrow a book from a machine and a person. How can we handle it?
Moreover, what if we have updated version of library machines some day? (e.g. one with keyboard and the other is with touch screen) What should we do then? The flow stays the same, however the hardware and the software eventually be different.
What would you use to realize use cases and why?
It might be a basic question, but I failed to find concrete examples on the subject to understand what is right. Thank you all in advance.
There is no single truth or one way you "should" do it. I will give you my approach, based on the Unified Process.
The use case technique is primarily used to describe a dialog between a human user (actor) and an application. It is modeled as an ellipse and further specified as an activity diagram or just a list of steps: 1 The actor does A, 2 The system does B, 3 The actor does C etc. In this approach, the application is regarded as a black box.
A "use case realization" describes how the system performs its steps (white box), e.g. in terms of collaborating components, transparent to the user.
It is possible, but much less common, to have so-called business use cases. In that case, the "system" represents an enterprise or a business unit. In your case, it would be the library. The "actor" represents an external person or organization, e.g. a client or a supplier. In your case, it would be a client. With business use cases, the library is regarded as a black box. The steps are still in format "actor does A; system does B", but here, it is not specified which of the library's actions are performed by humans and which by applications. The system is the organization, interfacing with external actors, regardless of whether this is implemented by employees or by applications.
A "business use case realization" specifies how the system performs its steps (white box) and specifies which parts are done by employees and which parts by machines.
Now, let me answer you questions one by one.
Question 1.
If you have described your use case as a business use case, and it is at such a high level of abstraction that the steps for client-librarian interaction are the same as for client-machine interaction, then you will have one business use case "Borrow book" and two business use case realizations for this business use case.
However, it is more common practice to have only use cases for user-application interaction. If the client interacts with the system in the same way as a librarian would do on behalf of the client, then you will have only one use case "Borrow book", with actor "Person". This actor has two specializations: "Client" and "Librarian". There will be only one use case realization per use case.
Otherwise, you would have one use case "Borrow book online" describing the flow of events when a client interacts directly with the application, connected to actor "Client" and another use case "Borrow book for client" describing the flow of events when a librarian interacts with the application while talking to the client. The latter use case has "Librarian" as its actor. Again, there will be only one use case realization per use case.
You may choose to model the Client-Librarian interaction separately, or not at all, depending on the purpose of your model.
Question 2.
Let's take use case "Borrow book online". You may have two use case realizations for this use case: one for the keyboard machine and one for the touch screen machine. If these use case realizations are very similar, then I would just make only one use case realization and describe the fact that there are two possible input devices inside that single realization.
Question 3.
For a business use case realization, I would use BPMN 2.0 or a UML activity diagram. These are well suited for business workflow specification.
For a normal use case realization, I usually make a sequence diagram, where the lifelines in those diagrams refer to components defined in a common component diagram. In the left margin of the sequence diagrams, I usually write the steps of the use case in UML note symbols. The sequence diagram focuses on the interaction between components, using their interfaces. This gives a nice overview of the collaboration between components in the context of a particular use case.
For more information, please refer to my white paper Which UML models should we make?. The use case realization is described on page 19.
UML is method-agnostic. Even when there are no choices to make, there are different approaches to modeling, fo example:
Have one model and refine it succesfully getting it through the stages requirements, analysis (domain model of the problem), design (abstraction to be implemented), implementation (classes that are really in the code).
Have different models for different stage and keep them all up to date
Have successive models, without updating the previous stages.
keep only a high level design model to get the big picture, but without implementation details that could be found in the code.
Likewise, for your question, you could consider having different alternative models, or one model with different alternatives grouped in different packages (to avoid naming conflicts). Personally, I’d go for the latter, because the different alternatives should NOT be detailed too much. But ultimately, it’s a question of cost and benefits in your context.
By the way, Ivar Jacobson’s book, the Object advantage applies OO modeling techniques to business process design. So UML is perfectly suitable for a human solution. It’s just that the system under consideration is no longer an IT system, but a broader organisational system, in which IT represents some components among others.
UML has collaboration elements to show different implementations. The use cases are anchors since the added value for the actors does not change. However, you can realize these use cases in different ways. And that is where the collaborations come into play. A collaboration looks like a use case but has a dashed border. And you draw a realize relation from one or many collaborations towards a use case. Inside the collaborations you show how the different implementation's classes collaborate (hence the name).
P.213 of UML 2.5 in paragraph 11.7 Collaborations:
The primary purpose of Collaborations is to explain how a system of communicating elements collectively accomplish a specific task or set of tasks without necessarily having to incorporate detail that is irrelevant to the explanation. Collaborations are one way that UML may be used to capture design patterns.
A CollaborationUse represents the application of the pattern described by a Collaboration to a specific situation involving specific elements playing its collaborationRoles.
I need to create an expense tracking tool. This tool will allow an individual user to keep a record of their expenses and also to predict financial status at a certain date.
User Interface
This will be built as a .NET C# windows forms desktop application. You are free to design the user interface as you wish but here are the minimal requirements.
The interface must have at least these views:
A contacts view for entering and updating the details of contacts (payers
or payees).
An expenses entry view for entering and updating expense details for a
certain day.
A financial report view – showing all expenses for a chosen date range.
A view that enables the user to see their predicted financial state at a
certain date.
For extra credit:
A view for entering events: appointments and tasks.
A weekly view displaying daily events and expenses.
It is up to you how you design your forms. We are purposely not giving you a
design example to avoid everyone having the same design. You are advised to
create mockups and storyboards and modify them iteratively as you develop your design document.
Your design decisions should be included in your report.
Persistent storage of run time data
The data for the expenses will be created by a view that allows the
specification of the expenses to be entered for a date, and this should be a programmatic dynamic interface. Once the user has finished you need to save
the expense data as an XML file and in a database of your choice. When the
application is run again (after closing) the system shall use the XML data to
populate the data on your interface. It should use the database data for the
financial report. When writing to or reading from the database the activity
should be threaded (to enable the interface to be useable while writing to an
external database)
My UML diagram
Can you please review the following diagram ?
Are use case suitable for UI requirements ?
A use case represents a goal that an actor wants to achieve. It is a behavior (in general an action). It's not how the user shall achieve the goal; not either the description of the user interface; and even less a data model.
If you have to design a user interface (as the narrative of your exercise seems to require), you might not need UC but rather wireframes to sketch the UI.
What are the UC in your requirements ?
With this in mind, I would identify the following UC in your requirements:
Manage contact details (#1) - I used Maemphasized textnage to shorten Enter or update -Open question: maybe two UC after all: Manage Payer details + Manage payee details.
Manage expenses for a day (#2) - the selection of date is a detail of the UI, not a UC !
Report expenses (#3) - the selection of date range is a detail of the UI, not a UC !
Forecast financial situation (#4)
Enter (maintain?) events (#5)
Report weekly situation (#6)
What can be improved in your diagram ?
Now a review of your own UC diagram:
Select data range could be an include for Add transation and Generate reports (caution: typo), since it is a part of the behavior and the including UC are incomplete without the included UC. Note that having it as a separate UC seems to me artificially detailed and not to be recommended.
Select data range should in principle not be an extension for Add transation, because an extension is optional and the extended UC should be complete without the extension. And here, it makes no sense to Add a transaction without knowing the date.
I'd suggest to change the UC name from to an active behavior: Chose/select data range, Generate/Report weekly view
You currently use generalization in your use case. Although it is not the most common practice, this is perfectly legal: the UC is a classifier and classifiers can be generalized. However, when generalization is used in an UC, it's generally with the same graphical flavour as all the other "links", separate and between only two elements, and usually not in the shared target form (example). Note that the naming of your specializations sound like nouns corresponding to data objects (e.g Payer) rather than behaviors (e.g. Manage payers). Note also that a typo caused Payee to be there twice
Edit: more about generalization in UC
There is some controversy on use of inheritance in UC since its practical meaning is not as intuitive as the other kind of relations.
Inheritance could be useful when there are several variants of the same UC. It's the principle of abstraction. But a UC should give an easy overview without loosing readers in details. So a better practice would be to keep your diagram without showing the specialisations, and have a second diagram dedicated to these details.
But personally (and looking at the comments and other answers, I'm not alone) I recommend not to use it. It makes a simple and easy to understand diagram, in something more complex with different levels of abstraction. In this reagard, it's worth to mention Ivar Jacobson, the inventor of UC:
He didn't use inheritance in his UC before they were included in UML.
He does not either use it in his most recent work on Use Case 2.0, where he promotes the use of use-case slices to cope with variants.
Use verb to name your UCs, income, expense, payee, Data Range and Weekly View are not UC but they correspond mainly to data.
Some UCs are missing, all what a user can ask to the system is not covered
I do not know what is the right UC for DataRange so difficult to check your extend / include but as Thomas Kilian I have a doubt about them
I am complete beginner in uml and need to make diagrams to show use and structure of current information system in organization. They use one system for manufacturing and one for accounting, warehousing and HR. First I want to do use cases with description. First question is should i do it by module (each area of business they cover)?
Then i need a diagram to view connections between the systems. Is it okay to use component diagram or which diagram is more appropriate? If company uses Office 365 does it show in diagram? Also if system supports EDI should i also include it?
Thanks for help.
As always: It depends.
Use cases are about added value. If you are going to document a complex system it's a good idea to group things. For a company a grouping by organizations would be reasonable. Though there are often horizontal (single focus) and vertical (needed in multiple area) departments. If the focus is to "re-invent" you should probably decouple your view. Anyhow, finding real use cases is a difficult task. So during synthesizing them you will likely find out how to group them logically.
Starting with components is also a good idea. You can use component instances showing concrete uses (with locations shown via packages). These concrete components can be abstracted to general components so you known which different basic components are used (package them centrally). Interfaces between components can be shown by assembly connectors (those with socket/lollipop). Later you can detail important components using ports and interfaces. Other components can be left peripherally without more details. Whether EDI/Office are "important" depends. Include them generally and find out in discussions during analysis whether details are needed.
I am creating application for Diabetes log system. I am confused whether database in UML -Use case diagram count as actor or not ?
the application is recording the diabetes glucose reading which will be saved in firebase and it can also retrieve the readings for showing the progress in chart format.
please can someone help me?
thank you.
No, databases should not be included in a Use Case Diagram of an isolated system. Databases are a static internal part of a system and do not directly take part without a front interface (i.e. your system itself).
However, if your database is an external entity i.e. it is being shared between different systems then maybe it would be wise to show it as an actor.
That depends on what use case diagram are you working on. UML standard does not attach diagrams to levels of abstraction.
You can create a use case for the behaviour of the whole product with the whole surrounding system and all human users - from the point of view of an external user. And you can create it for a better explanation of behaviour of a small sub-sub-subsystem.
In the first case, even the main application won't appear as an agent or meant as a subject. In the second case, if that subsystem works with DB, DB will be an agent.
UML is a free enough standard and rarely strictly forbids something.
Firstly, I'm still quite new to UML; but, highly interested and am attempting to learn as much about it as I can.
With that said, I’m in a situation where I’m directed to assemble a ‘Context Diagram’. I feel as though I understand the concept of what a context diagram is and how to create one, so I think I’m ok there. Basically it is identifying the system and the components or actors it will interact with. It applies the focus on the system, and not the actors. Kind of like a Use case diagram, but not focusing on the actors. If I’m wrong, please tell me.
I read somewhere that Context Diagrams are not actually part of UML. I also read, somewhere, that, if you use a Context Diagram, it falls into the Component side of things. When I read about Domain models, it seems like it should be there.
For my current situation, I know a simple answer is to simply create the diagram and move on, as that is all that is required. But, for my interest to better understand and leverage UML, I know there is a right way and a wrong way. If I were in a case of a bigger project, what would be the right way?
Now here is where my question begins. I’m using Enterprise Architect, create my project, and start to create a model. Does it belong in a Domain Model or Component Model? What is the difference between these two? Or even more. As it is an aide to help identify requirements, should it go there? Or does is just simply depend on what and how I want to convey it?
The Domain Model is where you standardize the vocabulary that everyone on the project will use to communicate in a consistent manner. The development team are experts at software development, but they may not have any experience in the domain (e.g. banking, air traffic control, healthcare) in which they are being asked to work. So you get domain experts and modelling experts together to build a model that describes the domain, answering important questions like "how are account fees calculated?" and "how does a pilot know what route to follow?" and then this model is then passed to the development team to provide them with the important domain knowledge that they will need. I would use UML class diagrams to create a domain model.
A Context Diagram shows the system being modeled in relationship to external systems. It could show data flowing in from and out to external systems, modeled by a data flow diagram (not part of UML). It could show behavioral interactions between the system and external "actors", modeled by a UML use case diagram. It could show the system's physical connections to other systems, modeled by a SysML block diagram. Whichever you choose, it will be on page 1 of your design document, so choose wisely!
You (can) create context diagram by making any element composite. Then drag the element itself onto that diagram as link (not instance!) and highlight it by making the border a bit thicker. Finally insert related elements from the context menu (differs from EA version to version). Layout the diagram and now you have your element in the context.
A domain model is usually a class diagram showing the (business) domain on a higher abstraction level.
As you have said, Context Diagrams per se are not part of the UML spec. There are plenty of ways to do a context diagram, but the UML way is to use a Use Case diagram, with or without supporting narratives and scenarios. Start with this, which is a broad overview of different types of Context Diagrams. Then, investigate use case diagrams, use case narratives, and activity diagrams. If you need to go into more detail than a use case narrative can easily do, get into use case scenarios and sequence diagrams. Here is a pretty good use case narrative template (feel free to leave out sections such as "scope and level" if they are more than you need, and consider adding information about what triggers the use case and where you go when you finish it--these two are required for scenarios if you go that far).
Keep in mind that use case narratives and use case scenarios are often confused. (Some people will say that I am the confused one; I will invite you to judge the matter for yourself.) A narrative is an explanation of an entire (single) use case, and may be supported with an activity diagram. A scenario is an explanation of a single path through a single use case, and may be supported with a sequence diagram.
For example, a use case will generally have a basic flow of events, along with a number of alternate flows. The narrative describes the entire process. The basic flow and each alternate flow would each be a separate use case scenario.
I suspect that it's unlikely that you will have to get down to the level of use case scenarios. You will probably want to put a use case diagram together, and possibly prepare narratives and activity diagrams for each of the use cases in the diagram.