Earlier activity diagrams focused on actions and decisions.
The same diagram type can help you reason about where information moves during a process.
Consider a soccer application where a user enters a short lineup note.
The application may:
An activity diagram can make that movement visible.
A simple process might begin:
Start
↓
Enter lineup note
↓
Store note in the running application
At this point, the information exists in the running program.
It has not necessarily been saved anywhere permanent.
If the application closes now, the information may disappear.
To preserve the note, the process needs a storage action.
Conceptually:
Start
↓
Enter lineup note
↓
Hold note in running application
↓
Write note to text file
↓
End
The important idea is that:
having information in memory is not the same as saving it to persistent storage.
The save step changes where the information exists.
A later process might be:
Start
↓
Open saved text file
↓
Read saved note
↓
Hold note in running application
↓
Display note
↓
End
Now information moves from persistent storage back into the running program.
These two flows answer different questions.
running program → file
file → running program
At this stage, you do not need to model:
The useful abstraction is much simpler.
Ask:
Is the information only part of the running application, or has it been written to persistent storage?
That distinction is enough to support the current learning goal.
Instead of vague labels such as:
Process information
use actions such as:
Enter lineup note
Store note in running application
Write note to file
Read note from file
Display note
The diagram should make the information path understandable without requiring someone to guess what each box means.
Suppose the coach enters:
Jordan starts at forward.
If the note exists only in the running application, closing the program may remove that state.
If the program writes the note to a file, the information can remain available after the application stops.
The storage action creates persistence.
That word means the information remains available beyond the current running session.
This module focuses on simple text-file storage.
A file is not the only form of persistent storage.
Software can also use databases and other storage systems.
Those are outside the current scope.
The important introductory idea is:
memory supports the running program; persistent storage preserves information beyond the current run.
The activity diagram might show:
Create note
↓
Write note to text file
Later C# code can implement the write action.
Another diagram might show:
Read note from text file
↓
Display note
Later C# code can implement the read action.
The diagram defines the process at a conceptual level.
The code supplies executable instructions.
A class diagram could describe:
What information does a Player or Match contain?
An object diagram could describe:
What values do specific objects contain right now?
An activity diagram can describe:
How does information move from one step or location to another?
For storage, the third question is especially useful.
It lets you visualize the difference between information that exists during execution and information that has been saved for later use.