Activity diagram modelling

[crj18]

I am trying to do a use-case diagram for a graphics application with activity diagrams to describe each use-case.
The problem is that to carry out an action such as "draw a circle", you must first log on the system and open a file.  
1) I do not want to have "log on" and "open a file" at the start of every activity diagram.
2) Generally, when a user decides to "draw a circle", he will already be logged on with a file already open.

So is there some standard common way to model a use-case without having to put "log on" and "open file" at the beginning of every activity diagram?

Cheers,
Charles

[sargasso]

A precondition constraint on the entire use case of "User logged in and file open" ought to do the trick.

b

[TrtnJohn]

This is also where your Use Case diagram is useful.  I use the Use Case <<Include>> association to denote inclusion of common use cases.  For example:  Login.  The Use Case diagram can show the relationships between all Use Cases and the Activity Diagrams will show the details for each.

[jwhart001]

Model organization is key when it comes to satisfying your client's need to view and understand your modeling effort.   I begin by using packages to establish a model taxonomy through the Project Browser that represents the project scope:

Project View
|___P---Actors
|___P---Transactions
|               |___P---Transaction #1 Use Case
|               |         |___Transaction #1 Use Case Diagram
|               |         |___P---Transaction #1 Process
|               |                                            |___Transaction #1 Activity Diagram

Where P represents a package.  This approach allows me to define actors, use cases, and activities once and then reuse them through the entire project.  It also allows me to select at the package-level how I want to generate documentation.  

By creating Use Case and Activity diagram stubs at the beginning of the project, I can reference them as hyperlinks as I'm building out the model.  In the end, this allows the user to easily traverse the model and understand where they are at any point in time.

When I'm working on an activity diagram (process flow for the use case) I reference "included" use cases by dragging and dropping their corresponding diagrams on the page and referencing them as a hyperlink.  These links are inline and have no special criteria to determine execution.  I reference "extended" use cases by first establishing the criteria for execution through a decision object, then drag and drop the corresponding diagram on the page, referencing it as a hyperlink.  

This approach allows me to flush out the entire project, work on one use case at a time and have the ability to reference other use cases, develop underlying activity diagrams and reference related use case activities, regardless of whether they have been completed or not.
As each diagram is completed the hyperlinks allow the user to traverse the model.

I hope this helps.  Let me know if you would like more information.