Click Submit to View Solution

Consider a bulb with a push down switch. The bulb initially remains off. When the switch is pushed down, the bulb is on. Again when the switch is pushed up, the bulb turns off. The lifecycle of the bulb continues in this way until it gets damaged.

Think about these points:
  • What are the different states of the bulb?
  • What activities are performed in each state?
  • What action does make the bulb move from one state to another?
Learning Objectives:
  • Identifying different states of a system
  • Identifying activities performed in each state

Limitations: A complex system often has sub-states, which is not covered as a part of this lab. The following interface only let you represent simple states. Please check out the references section to know more about them.

State Name Add
State Name Action Label Action Expression Add
State Name Note Add
State Activities Note Remove
Current State Next State Event Gaurd Condition Action Add
Current State Event Gaurd Condition Action Next State Remove

Let us consider the development activities of SE Virtual Labs. The process begins by checking out the code from Subversion repository. Necessary modifications are then made to the checked out code (local copy). Once the developer is done with his changes, the application has to be tested to verify whether the new functionality are working fine. This test has to be performed with two of the more popular web browsers: Firefox and Internet Explorer, to support cross-browser accessibility. If testing fails in at least one of the two browser, developer goes back to his code, and fixes it. Only when all the browsers pass the test, a patch is generated from the local copy, and applied to the production code. The local copy is then committed resulting in update of the SVN repository. Note that, if the local copy is committed before generating a patch file, then local changes would get registered, and one won't be further able to generate the patch file. Note: For further clarification, at any point of time there exists three versions of the source code: Production copy, local copy, and copy in SVN repository.

Think over the following questions:
  • How would you represent testing of the application with multiple browsers?
  • Can generation of the patch file and update the Subversion repository be done concurrently?
  • Can patching the production code and updating the Subversion repository be done in parallel?
Learning Objectives:
  • Identify the basic units of work, and visualize the work flow
  • Identify activities that could be done in parallel
  • Identify stages from where progress could be made only after a list of criteria is satisfied

Limitations: The objective of this system is to provide knowledge on the fundamental aspects of activity diagrams. As such, it lacks certain features as listed below, which a dedicated UML Diagram editor should have.

  • This system lets you represent two parallel activities
  • Nested decisions could not be taken here, which might be quite essential in complex workflows
  • A decision could not be taken immediately after a merge point
  • Nested activity diagrams have not been implemented
Activity Decription Add
Current Activity Next Activity Gaurd Condition Add
Current Activity Next Activity Gaurd Condition Remove
Type Current Activity(ies) Synchronization Bar Following Activity(ies) Add
Create parallel activities

NOTE: Please specify separate synchronization bars for fork and merge

Merge parallel activities
Current Activity Fork Point Fork to Activities Merge Point Merge to Activities Remove
Current Activity Condition & Subsequent Action Add
IF THEN
Gaurd Condition

ELSE
Gaurd Condition
Current Activity Condition If TRUE Gaurd Condition If FALSE Gaurd Condition Remove
solution 1
solution 2