Вы находитесь на странице: 1из 13

Top of Form

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

Activity Diagram Examples


Here we provide several examples of UML activity diagrams:

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.

Single Sign-On (SSO) for Google Apps

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.

Online Shopping Activity Diagram


An example of activity diagram for online shopping. Online customer can browse or search items, view specific item, add it to shopping cart, view and update shopping cart, checkout. User can view shopping cart at any time. Checkout is assumed to include user registration and login. This example is not using partitions, most of the actions are assumed to be fulfilled by online customer.

An example of activity diagram for online shopping.

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.

Document Management Process


An example of formal Document Management Process activity. Partitions are shown here as horizontal swimlanes and represent different roles participating in the activity - Author, Reviewer, Approver, and Owner. 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. Alternative type of diagram - state machine diagram - could also be used in this case to show how document changes its state over time.

An example of Document Management Process activity.

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.

An example of activity to resolve an issue in software design.

Sentinel HASP SL - Manual Activation of Trial Product


An example of activity showing manual activation of trial (provisional) product which was protected by HASP SL soft license of Sentinel HASP software protection and licensing product. Three partitions shown here as vertical swimlanes represent actors participating in the activity Order Manager, Customer Service, and Customer. Customer has trial product installed and protected with HASP SL license. At some point customer decides to activate product by requesting permanent, full product license. Order Manager will have to create new product key while at the same time customer could create and deliver C2V file ("computer fingerprint"). Once both product key and C2V file are available

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.

Single Sign-On for Google Apps


An example of activity describing 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. Each partner provides Google with the URL of its SSO service as well as the public key that Google will use to verify SAML responses. When user attempts to use some hosted Google application, such as Gmail, Google generates a SAML authentication request and sends redirect request back to the user's browser. Redirect points to the specific identity provider. SAML authentication request contains the encoded URL of the Google application that the user is trying to reach. The partner identity provider authenticates the user by either asking for valid login credentials or by checking for its own valid authentication cookies. The partner generates a SAML response and digitally signes it. The response is forwarded to Google's Assertion Consumer Service (ACS). Google's ACS verifies the SAML response using the partner's public key. If the response is valid and user identity was confirmed by identity provider, ACS redirects the user to the destination URL. Otherwise user will see error message.

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.

UML activity diagram for the Enroll in University use case.

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.

Вам также может понравиться