Академический Документы
Профессиональный Документы
Культура Документы
Bottom of Form
UML diagrams Activity diagrams Activity examples Online shopping Process order Electronic prescriptions Document management Resolve issue Single Sign-On for Google Sentinel HASP SL All UML Examples UML index
Online shopping activity diagram Online customer can browse or search items, view specific item, add it to shopping cart, view and update shopping cart, do checkout. User can view shopping cart at any time.
Business flow - Process order Order processing example. Requested order is input parameter of the activity. After order is accepted and all required information is filled in, payment is accepted and order is shipped.
Business flow - Document management process An example of document management activity. Document is created, reviewed, updated, approved, and at some point archived. This activity diagram shows responsibilities of different roles and flow or sequence of document changes. Partitions represent different roles participating in the activity - Author, Reviewer, Approver, and Owner.
Electronic prescriptions Electronic prescriptions activity diagram example - prescribers could send prescriptions electronically to a pharmacy of the patient's choice where patient can pick it up.
Software design - Resolve issue An example of activity to resolve an issue in software design. After ticket is created by some authority and the issue is reproduced, issue is identified, resolution is determined, issue is fixed and verified, and ticket is closed, if issue was resolved.
Sentinel HASP SL - manual activation of trial product Example of activity of manual activation of trial (provisional) product which was protected with the HASP SL soft license of Sentinel HASP software protection and licensing product.
Activity which describes Single Sign-On (SSO) to Google Apps. To interact with partner companies Google uses single sign-on based on OASIS SAML 2.0 protocol. Google acts as service provider with services such as Gmail or Start Pages. Partner companies act as identity providers and control user names, passwords, and other information used to identify, authenticate and authorize users for web applications that Google hosts.
Process Order
An example of business flow activity of order processing, based on the Example 12.35 from [UML 2.4.1 Specification]. Requested order is input parameter of the activity. After order is accepted and all required information is filled in, payment is accepted and order is shipped. Note, that this business flow allows order shipment before invoice is sent or payment is confirmed.
An example of business flow activity to process order. This example is not using partitions, so it is not clear who is responsible to fulfill each specific action.
Resolve Issue
An example of activity to resolve an issue in software design. After ticket is created by some authority and the issue is reproduced, issue is identified, resolution is determined, issue is fixed and verified, and ticket is closed, if issue was resolved. This example is not using partitions, so it is not very clear who is responsible to fulfill each specific action.
to customer service, it could activate product, generate V2C file and deliver it back to the customer. The customer applies license and activates installed trial product to become full product.
An example of activity for manual activation of trial product protected by HASP SL.
The following example shows an activity diagram that depicts the rules and the process of reserving a car. In the following example, StattAuto will not accept a reservation if vehicles are not available, etc. Take a closer look for yourself in order to become more familiar with the notation. Figure 10-8. An Activity diagram.
Figure 1 is notable for several things: 1. It depicts the notation that youre likely to use 90% of the time (Ill discuss the more esoteric notation later).
2. It is incorrect. You can enter the join but never get out of it. When you look at the logic,
you see that you'll either Create a Student Record and then enter the join, or you could enter the join directly from Display List of Potential Matches when the applicant is on the list. One but not both of these things will happen, but both are required for you to exit the join. I really should have used a merge (a diamond) instead of a join bar. Should I update the diagram? No, because agile models are just barely good enough to get the job done (this one is, IMHO) and because agile modelers follow the practice update only when it hurts, and there isn't enough motivation to update this diagram (chances are very good that once you implemented the logic contained within it that you'd simply erase it anyway).
3. The use of diamonds for decisions and merges is visually wordy but unfortunately all too
common. In Figure 2 I address this issue by placing conditions on flows leaving activities instead of introducing additional diamonds to represent decision points.
4. It uses a fork to indicate parallel processing, in this case weve decided that we can
perform some of the checks on the applicant in parallel, something that wasnt easy to indicate using flow charts. 5. It shows how activity diagrams can get large very quickly. Even though it models the logic of a single use case I was forced to have it wind around the whiteboard because I ran out of space. Ideally the diagram should be wider, with the logic going from left-toright across the board. Better yet, it would be nice to have more whiteboard space.
6. It includes a common mistake. At the very end I applied a decision just before the
Process Payment and Print Receipt processes to indicate that they can be done in parallel. I should have used a fork, not a decision, for that. I should also use a balancing join, instead of a merge, although either one would be allowed. The join or merge is required because both processes need to finish before the overall process ends, without doing this a race condition effectively exists where the first process to finish would end things.