Het oude systeem: BPA, BPI, BPR

SYSTEM PROPOSAL
We (Taco en Marilou) hebben ervoor gekozen
om het systeem proposal aan het einde van de
design op te leveren, omdat tijdens de design
fase de modellen nog worden aangepast.
De systeem proposal gaat dus het
eindresultaat van de modellen bevatten i.p.v.
een tussenversie die bij de design worden
hergebruikt.
1
Taken ......................................................................................................................... 3
Gedetailleerde requirements .................................................................................... 4
Requirements voor versie 1 ................................................................................... 4
Het inlezen van mzXML en pepXML. ............................................................... 4
Visualisatie......................................................................................................... 4
mzXML : inlezen .............................................................................................. 4
Bovenaanzicht ................................................................................................. 4
Dwarsdoorsneden ............................................................................................ 4
Pijlknopje ......................................................................................................... 5
Statusbalk ........................................................................................................ 5
pepXML ........................................................................................................... 5
MS/MS ............................................................................................................. 5
Het oude systeem: BPA, BPI, BPR ........................................................................... 6
Uitleg BPA, BPI, BPR ........................................................................................... 6
Toepassing in het project ...................................................................................... 6
Informatieverzameling ............................................................................................. 7
Modellen .................................................................................................................... 8
Functioneel modelleren: ........................................................................................ 8
Activity diagram ................................................................................................ 8
Structureel ........................................................................................................... 18
CRC Cards ........................................................................................................ 18
Class Diagrams ................................................................................................ 24
Gedragsmatig....................................................................................................... 30
Sequence diagrams .......................................................................................... 30
Communication diagrams................................................................................ 35
Communication diagrams................................................................................ 35
Gedragsmatige state machines ....................................................................... 40
2
Taken
De analyse hebben we als een geheel team doorlopen, werkend in paren.
Uiteindelijk kwam naar voren dat het beter was de analyse versneld door te lopen en
dan meer tijd te gaan besteden aan design, waar we de diagrammen aanpassen
door te kijken in hoeverre het voorstel haalbaar en verstandig is.
Tijdens de design lopen eerst gezamenlijk de fasen door die sequentieel plaats
vinden. Bij HCI layer en DB layer, splitsen we op in twee groepen: het blauwe en het
rode team. Behalve zorgdragen voor de HCI, regelt het blauwe team ook de Class
and Method Design voor zover mogelijk, rekening houdend met de nog niet bedachte
datastructuur.
Voorlopige takenverdeling:
Rode Team
Blauwe Team
Joris
Marnix
Michel
Roeland
Steven
Taco
Albert Jan
Marilou
3
Gedetailleerde requirements
Requirements voor versie 1
Het inlezen van mzXML en pepXML.
Hierbij is het belangrijk dat de parser gemakkelijk kan worden aangepast. Het inlezen
van pepXML is niet per se nodig. Let op: binnenkort komt er een nieuwe parser voor
mzXML versie 3!
Visualisatie
mzXML : inlezen
-
We gebruiken workspaces
Je kunt meerdere samples inlezen.
Het inlezen van een sample doe je dmv file > load sample
Er komt dan een popup schermpje zoals Screenshot2.
Dit schermpje kun je minimaliseren door op het hoofdscherm te klikken.
Je kunt een sample verwijderen door op delete te drukken.
Vervolgens volgt er ‘weet u het zeker ’
Ook kun je op samples die zijn ingeladen de rechtermuisknop gebruiken waar
een soort snelkoppelingen staan zoals ‘add’ en delete.
Na het inlezen van mzXML wordt een bovenaanzicht van het 3d beeld
weergegeven. Als er meerdere samples zijn geselecteerd, vind er stacking
plaats in het bovenaanzicht.
Deze kun je vervolgens met een checkbox (?) aan en uitzetten (zodat deze
wel of niet zichtbaar wordt in het bovenaanzicht)
En met een dropdown menu kunnen we de kleur selecteren.
Bovenaanzicht
-
-
-
Meerdere samples: geef mengkleuren weer, en dus geen zwart (Een manier
om automatisch kleuren toe te kennen is het totale kleurbereik op te delen
tussen het aantal samples die getekend moeten worden.)
Bovenaanzicht - Bij normale mode: klik in bovenaanzicht levert twee
dwarsdoorsneden (verticaal en horizontaal). Als er van een piek een ms/ms
beschikbaar is, zet om het geklikte punt een gekleurd vierkantje. Om het
vierkantje dubbelklikken levert linksonder in het scherm een msms-spectrum.
Bovenaanzicht - Bij zoom on selection mode: door met de muis te slepen kan
een deel van het scherm geselecteerd worden. Als je binnen dat kader klikt,
wordt er ingezoomd, klik je erbuiten, verdwijnt het kader. Ben je ingezoomd,
verschijnen er schrollbars horizontaal en verticaal. Een klik met de rechtermuis
zorgt weer teruggaan naar het oude scherm.
Bovenaanzicht - Magnifying glass: klik met linkermuis knop is inzoomen op
geklikte punt, anders uitzoomen.
Klikt de gebruiker op een piek waar veel andere pieken zich bevinden: neem
dan de hoogste piek.
Dwarsdoorsneden
-
Dwarsdoorsneden – zijn op de zelfde manier interactief als bovenaanzicht.
4
Pijlknopje
Pijlknopje: om assen te draaien (tijd verticaal, m/z horizontaal omdraaien).
Statusbalk
Informatie over welke modus, welk punt geklikt, hoever is het inladen, etc.
pepXML
De gehaalde informatie uit de grafiek + de informatie van pepXML wordt in het
scherm boven de ms/ms weergegeven. Samen levert dit een zeer waarschijnlijke
peptide die als sample is ingeladen.
Als er meerdere goede matches zijn voor een piek in het pepXMLbestand,
altijd de beste score kiezen. Als waarden heel dicht bij elkaar liggen (van best
scorende), kan er eventueel gedacht worden aan een waarschuwingsbericht, maar
dit is een extraatje.
MS/MS
Als je in de normale mode zit bij het bovenaanzicht zijn er vierkantjes zichtbaar
(zowel in bovenaanzicht als misschien in de dwarsdoorsneden). Hierop kun je klikken
en dan wordt er in dit MSMSschermpje een spectrum weergegeven.
Mogelijkheid om in msms scherm uit te vergroten.
Met kleur moeten we in het bovenaanzicht aangeven welke een goede identificatie
geven (bijv. als deze boven een bepaalde (ingestelde? ) mascot score komen )
- Het moet mogelijk zijn van meerdere samples een msms weer te geven (ook
deze kun je aan en uitzetten in het spectrum).
- Vervolgens komt hier nog wat muisfunctionaliteit: als een tweede muisklik in
het bovenaanzicht een zelfde piek, maar dan in een ander sample betreft,
wordt deze samen met de oude msms weergegeven in de msmsspectra. Gaat
het hier om een andere piek, dan kunnen we geen reactie geven.
5
Het oude systeem: BPA, BPI, BPR
Uitleg BPA, BPI, BPR
BPA – kleine verandering maken in het oude systeem. Het oude systeem wordt veel
onderzocht. Er zijn twee technieken: Problem Analysis (user vertelt het probleem) en
Root Cause Analysis (pak het probleem bij de wortel aan).
BPI – efficiëntie (do things right) en doeltreffendheid (do right things) verhogen. Hier
is minder onderzoek naar het oude systeem. Een aantal technieken: Duration
Analysis (bekijk oude systeem en hoeveel tijd die processen duren), Activity Based
Costing (bekijk oude systeem en hoeveel die processen kosten), Information
Benchmarking (kijken naar andere bedrijven).
BPR – veel verandering, weinig onderzoek naar het oude systeem. Er zijn drie
technieken: Outcome Analysis (de outcomes die wat betekenen voor de klanten),
Technologiy Analysis (nieuwe technieken toevoegen), Activity Elimination (in
business process proberen taken weg te halen).
Er is sprake van BPA, BPI of BPR afhankelijk van: Business Value, Project Cost,
Breadth of Analysis (scope of analysis) en risk.
Toepassing in het project
In hoeverre gebruiken we het oude systeem? Nauwelijks, we bouwen een nieuw
programma en gebruiken daarbij wel enkele al bestaande ideeën. Met het begrip ‘het
systeem’ moeten we wel duidelijk onderscheid maken tussen enerzijds de hele
analysecyclus (van het moment dat de eiwitten verwerkt worden in de
massaspectrometer tot de export van piekverschillen die ons programma gevonden
heeft), en anderzijds alleen de visualisatiestap (wat ons programma moet gaan doen,
maar wat nu bijvoorbeeld alleen gedaan kan worden met MSight). In het eerste geval
spreken we van BPI (Business Process Improvement), dus een verbetering van het
huidige systeem. In het tweede geval spreken we van BPR, dus een radicale nieuwe
aanpak.
De term die het meest van toepassing is, is Business Process Reengineering
6
Informatieverzameling
Informatieverzameling is nodig om de requirements duidelijk te krijgen. In februari
hebben we twee meetings gehad met de klant. We hebben toen een lijst met
requirements opgesteld en om goedkeuring gevraagd.
Verdere informatieverzameling zou nog kunnen, maar is van latere zorg.
7
Modellen
We houden in principe nog geen rekening met de implementatie tijdens de analyse.
Bij de design fase zullen we deze modellen aanpassen. Hieronder staat het
eindresultaat.
Functioneel modelleren:
We weten nu de requirements van het nieuwe systeem. We gaan nu de verzamelde
informatie organiseren en representeren in activity diagrams en use cases.
Activity diagram
Waarom: Dit is een logisch model van processen en work flows, een formele manier
om weer te geven hoe een business systeem interacteert met de omgeving (de
activiteiten van de user).
Uitleg diagram:
= een action of groep van activiteiten (of een state, zoals in
het geval van Magnifying Glass)
= het begin van de diagram
= het einde van de diagram
= een keuzeoptie voor de gebruiker
= de volgorde van de uitvoer.
Verantwoording keuzes
Bij het opstarten, start je in de normal mode. Je kunt alleen in de normal mode een
msms spectrum opvragen. Vanaf de normal mode kun je in de andere modes komen.
In alle drie de modussen kun switch axes, close workspace, save workspace, load
workspace, create workspace, load sample en delete sample uitvoeren.
Versie: 2006-02-27 posted by Marnix
8
9
Use case en use case beschrijving
Waarom: begrijpen van functies van het systeem. De basis functies van het systeem
worden functioneel gemodelleerd. De beschrijving geeft op een simpele manier de
systeem functies, gezien vanaf de gebruiker. Ook wordt er rekening gehouden met
het feit dat er meerdere soorten gebruikers bestaan. De diagrammen zijn functioneel
en geven ook de basisfuncties weer: wat kan de user doen en wat is hierop de
reactie van het systeem. Elk diagram geeft één functie weer.
Uitleg diagram:
Actor1
= een persoon of systeem.
UseCase1
= representeert een belangrijk stuk van de functionaliteit van
het systeem.
= relatie van het typ associatie
*
*
«extends»
= representeert een extensie van een use case om optioneel
gedrag te includen. De pijl loopt van de basis use case naar de
geincluded use case.
10
Use case diagram:
Versie: 2006-02-27 posted by Marnix
Verantwoording keuzes – Use case diagram
De gebruiker interacteert met de volgende use cases: load sample, delete sample,
create, load, close en save workspace, normal, magnifying glass en zoom on
selection mode, switch axes en MSMSspectrum.
Bij het sluiten van een workspace kan er gevraagd worden of de wijzigingen moeten
worden opgeslagen: uitvoer van de close workspace use case.
Bij het laden en sluiten van een workspace, kan gevraagd worden eerst de
betreffende te sluiten. Dit is niet verplicht, er mogen meerdere workspaces worden
geopend.
Bij het laden van een sample kan het zijn dat ook de use case create of load
workspace wordt gedraaid, als er geen workspace geopend is.
11
Verantwoording keuzes - Use case description:
We hebben de volgende use cases gemaakt:
 load sample, delete sample
 create workspace, load workspace, save workspace, close workspace
 change mode, switch axes, user interaction
Dit zijn de wat oudere use cases maar die wat specifiekere informatie bevatten:
 MSMS Spectrum
 normal mode, magnifying glass mode, zoom on selection mode
Versie: 2006-02-27 both posted by Marnix
Use Case Name: Load sample
ID: 1 Importance level: high
Primary Actor: User
Use Case Type: Detail, essential
Stakeholders and Interests:
User – Wants to analyse an extra sample in Spectre.
Brief description: The User chooses a file which contains data of a sample, and loads it into the
program.
Trigger: The User decides that he needs the information of an extra sample for analysis.
Type: External
Relationships:
Association: User
Include:
Extend: Create New Workspace, Load Workspace
Generalization:
Normal Flow of Events:
1. The User presses the button ‘load sample’ or selects a corresponding menu option.
2. The User selects which file to load, and presses the load button.
If there is no workspace currently loaded, then execute the Select Workspace
Exceptional Flow.
3. Spectre parses the data of the sample.
If the User clicks the “In background” button, then execute the In
Background Alternate Flow.
4. Spectre visualizes the parsed data on the main screen, and adds the sample to the
checkbox list of currently loaded samples.
Subflows:
Alternate/Exceptional Flows:
2a. Select Workspace
Spectre asks the User if he/she wants to create or load a workspace.
If the User wants to create a new workspace,
execute the Create Workspace Use Case.
If the User wants to load an existing workspace,
execute the Load Workspace Use Case.
3a. In Background
The “Load sample” window disappears and the progress bar is moved to the status bar, at
the bottom of the screen.
If the User double-clicks on the progress bar, the “Load sample” window reappears.
Use Case Name: Delete sample
Primary Actor: User
Stakeholders and Interests:
User – Wants to remove a sample.
ID: 2 Importance level: high
Use Case Type: Detail, essential
12
Brief description: The User removes the selected sample from the current workspace.
Trigger: The User does not need to analyze a sample (anymore), and wants to delete it.
Type: External
Relationships:
Association: User
Include:
Extend:
Generalization:
Normal Flow of Events:
1. The User selects the corresponding menu option.
2. The User confirms.
Subflows:
Alternate/Exceptional Flows:
13
Use Case Name: Create workspace
ID: 3 Importance level: med
Primary Actor: User
Use Case Type: Detail, essential
Stakeholders and Interests:
User – Wants to create a workspace.
Brief description: The User chooses a name for the workspace and confirms the new
workspace.
Trigger: The User needs a new workspace, because he/she wants to analyse new samples.
Type: External / internal
Relationships:
Association: User
Include:
Extend: Close Workspace
Generalization:
Normal Flow of Events:
1. The User selects the corresponding menu option, or wants to load a sample when no
workspace is currently loaded.
2. The User is prompted for a name for the workspace.
3. The User confirms the creation of the new workspace.
Subflows:
Alternate/Exceptional Flows:
Use Case Name: Load workspace
ID: 4 Importance level: med
Primary Actor: User
Use Case Type: Detail, essential
Stakeholders and Interests:
User – Wants to load a workspace.
Brief description: The User chooses the name of the workspace to load, and confirms the
selected workspace.
Trigger: The User needs an existing workspace, because he/she wants to continue analysing
some samples.
Type: External / internal
Relationships:
Association: User
Include:
Extend: Close Workspace
Generalization:
Normal Flow of Events:
1. The User selects the corresponding menu option, or wants to load a sample when no
workspace is currently loaded.
2. The User selects the workspace file.
3. The User confirms.
Subflows:
Alternate/Exceptional Flows:
14
Use Case Name: Save workspace
ID: 5 Importance level: med
Primary Actor: User
Use Case Type: Detail, essential
Stakeholders and Interests:
User – Wants to save a workspace.
Brief description: The User chooses a name for the workspace that has to be saved, and stores
it.
Trigger: The User needs to store which samples are loaded and analyzed.
Type: External / internal
Relationships:
Association: User
Include:
Extend:
Generalization:
Normal Flow of Events:
1. The User selects the corresponding menu option, or wants to exit Spectre without having
saved the current workspace.
2. The User selects the file to which to save, or types a new name for the workspace.
3. The User confirms.
Subflows:
Alternate/Exceptional Flows:
Use Case Name: Close workspace
ID: 6 Importance level: med
Primary Actor: User
Use Case Type: Detail, essential
Stakeholders and Interests:
User – Wants to close a workspace.
Brief description: The User closes a workspace because it is no longer needed.
Trigger: The User wants to shut down the program or decides the workspace is no longer
needed.
Type: External / internal
Relationships:
Association: User
Include:
Extend: Save Workspace
Generalization:
Normal Flow of Events:
1. The User selects the corresponding menu option or exits the program.
2. If some changes were made since the last save: the User is asked if he/she wants to save
the current workspace.
If the User wants to save the current workspace,
execute the Save Workspace Use Case.
3. The User confirms.
Subflows:
Alternate/Exceptional Flows:
15
Use Case Name: Change mode
ID: 7 Importance level: high
Primary Actor: User
Use Case Type: Detail, essential
Stakeholders and Interests:
User – Wants to select cross sections or view msms-spectra of certain peaks.
Brief description: The User works in normal mode, selecting points for cross section graphs and
viewing msms-spectra.
Trigger: The User starts up the program, or switches to normal mode during analysis.
Type: External / internal
Relationships:
Association: User
Include:
Extend:
Generalization:
Normal Flow of Events:
1. The User presses a mode button or selects the corresponding menu option, or an action of
the Users results in an automatic mode switch.
2. The current mode changes to the selected mode.
Subflows:
Alternate/Exceptional Flows:
Use Case Name: Switch axes
ID: 8
Importance level: low
Primary Actor: User
Use Case Type: Detail, essential
Stakeholders and Interests:
User – Wants to switch the time and m/z axes in the main screen.
Brief description: The User clicks a button to switch the two axes.
Trigger: The User clicks the “switch axes” button.
Type: External
Relationships:
Association: User
Include:
Extend:
Generalization:
Normal Flow of Events:
1. The axes of “time” and “m/z” in the main screen are switched, and the two cross section
graphs are switched correspondingly.
Subflows:
Alternate/Exceptional Flows:
16
Use Case Name: User Interaction
ID: 9 Importance level: high
Primary Actor: User
Use Case Type: Detail, essential
Stakeholders and Interests:
User – Wants to interact with the graphs in the program.
Brief description: The User does some mouse operations on graph screens in the program, and
the program responds accordingly.
Trigger: Mouse operations by the User, in one of the graphs.
Type: External
Relationships:
Association: User
Include:
Extend:
Generalization:
Normal Flow of Events:
1. The User clicks or drags the mouse in/on one of the graphs.
2. The program decides which mode to select.
3. The program executes the selected mode with the mouse input.
Subflows:
Alternate/Exceptional Flows:
17
Structureel
Beschrijving van de structuur van de data die door het business proces wordt
ondersteund. Structurele modellen representeren de logische organisatie van
data.
CRC Cards
Waarom: Een model waar componenten van de software in voorkomen. De crc cards
bevatten uiteindelijk alle informatie om een logische structuur als model te bouwen.
Uitleg diagram: (Dit spreekt op zich)
Verantwoording: (Dit spreekt op zich)
Versie: 2006-03-07, posted by Albert Jan.
Class name: Sample
ID: 1
Description:
Associated Use Cases:
An internal data structure that holds all
knowledge about one sample/experiment
Responsibilities:
Collaborators:
Gives access to MS data points
Gives access to MS/MS data points
Gives access to Peptide data points
Can indicate availability of pepData
Can save its data to a file
SampleWriter
Attributes:
Relations:
-mzData
-SampleWriter
-pepData
-VirtualSample (extends)
-ID
-RealSample (extends)
-Workspace
Class name: SampleWriter
ID: 2
Description:
Associated Use Cases:
An entity capable of writing sample data to
various file formats
Responsibilities:
Collaborators:
Write sample data to a file
Sample
Relations:
-Sample
18
Class name: RealSample
ID: 3
Description:
Associated Use Cases:
A sample data structure based on an input
file
Responsibilities:
Collaborators:
Is bound to a file (cannot be changed)
SampleParser
Relations:
-Sample (Generalization)
-SampleParser (Aggregation)
Class name: VirtualSample
ID: 4
Description:
Associated Use Cases:
A sample that exists solely within the
program
Responsibilities:
Collaborators:
Can return a selection of itself
VitualSample
Can modify its own data points
Upon a save becomes a RealSample
RealSample
Relations:
-Sample (Generalization)
Class name: SampleParser
ID: 5
Description:
Associated Use Cases:
An entity which can read various file
formats and parse them into a RealSample
Responsibilities:
Collaborators:
Must be bound to a file
Get (parse) all data from a file
Get (parse) a arbitrary data point
Relations:
-RealSample
19
Class name: Workspace
ID: 6
Description:
Associated Use Cases:
An environment for the user to work in
Responsibilities:
Collaborators:
Can return current visual settings
VisualSettings
Can return currently loaded samples
Sample
Can remove an arbitrary sample
Can add a sample
Sample
Can set visual settings
VisualSettings
Attributes:
Relations:
-ID
-Processor
-Samples
-Sample (Aggregation)
Class name: VisualSettings
ID: 7
Description:
Associated Use Cases:
An entity which remembers an user's
settings of all modifiable visualisation
parameters
Responsibilities:
Collaborators:
Can set its variables
Can return its variables
Attributes:
-samples (to be drawn)
-colors
-axis orientation
-zoom
-viewports heights/widths for all graphs
-currently displayed ms/ms diagram
Relations:
-Workspace
Class name: GUI
ID: 8
20
Class name: GUI
ID: 8
Description:
Associated Use Cases:
An entity which handles all user interaction
Responsibilities:
Collaborators:
Keeps track of user's mouse activity
Can summon a (magnifying) window
Can set additional info in pepData
Sample, via Processor
Relations:
-Processor
Class name: Mode
ID: 9
Description:
Associated Use Cases:
Represents a mode of the GUI which can
be set by the user. This also contains the
mode's caption; meaning the responses of
the GUI given its current mode
Responsibilities:
Collaborators:
The current mode can be changed
The mode can respond to events
GUI, via processor
Contains a 'normal' mode
VisualSettings, via Processor
Contains a 'zoom' mode
VisualSettings, via Processor
Contains a 'magnify' mode
VisualSettings, via Processor
Knows all possible modes
Attributes:
Relations:
-PossibleModes
-Processor
Class name: Graph
ID: 10
Description:
Associated Use Cases:
Represents all kinds of graphs
Responsibilities:
Collaborators:
Can paint itself
Can paint its axis
21
Class name: Graph
ID: 10
Attributes:
Relations:
-Image
-MSGraph
-Width
-MSMSGraph
-Height
-CrossSectionGraph
-Zoomvariables
-Processor
Class name: MSGraph
ID: 11
Description:
Associated Use Cases:
Represents an m/z / time graph
Responsibilities:
Collaborators:
Can paint itself
Relations:
-Graph (Generalization)
Class name: CrossSectionGraph
ID: 12
Description:
Associated Use Cases:
Represents both time/intensity and m/z /
intensity 2D Graphs
Responsibilities:
Collaborators:
Can paint itself
Relations:
-Graph (Generalization)
Class name: MSMSGraph
ID: 13
Description:
Associated Use Cases:
Represents a 2D MSMS Graph
Responsibilities:
Collaborators:
Can paint itself
Relations:
-Graph (Generalization)
Class name: Processor
ID: 14
22
Class name: MSMSGraph
ID: 13
Description:
Associated Use Cases:
Handles all communication between
modular parts of this system. Responsible
for providing a clear and robust interface,
with reliable interaction
Responsibilities:
Collaborators:
Keeps track of currently active workspace
Workspace
Can change currently active workspace
Workspace
Can update relevant modules
-(currently only Graphs)
Graph
Gives access to the GUI
GUI
Keeps track of currently active graphs
Graph
Can add a new graph
Graph
Can add remove a graph
Graph
Can return the current Mode
Mode
Can remove workspaces
Workspace
Can create new workspaces
Workspace
Can change active mode
Mode
Attribute:
Relations:
-Graphs
Workspace
-Workspaces
Graph
Mode
GUI
23
Class Diagrams
Waarom: Dit diagram laat de klassen en de relaties tussen de klassen die blijven
tijdens het runnen van het systeem.
Uitleg diagram:
GUI
+MAIN(in args : object)
+init()
= een klasse
1
1
= een associatie?
= Overerving - (klasse onderin extends abstracte klasse bovenin)
= een associatie??
Methode/ attribuut:
+ is public – not hidden to other objects
# is protected – wel hidden, behalve voor een subklasse
- is private – wel hidden, dit is de default.
Verantwoording keuzes: (spreek voor zich)
Versie 2006-04-06 posted by Joris
24
25
26
27
28
29
Gedragsmatig
Hoe zal het systeem reageren.
Sequence diagrams
Waarom: het onderliggende business proces weer te geven. Het is een illustratie van
de objecten die participeren in een use case. Ook de berichten die tussen de
objecten bewegen tijdens één use case worden weergegeven.
Uitleg diagram:
= de lengte van een execution
Workspace
= de lifeline van workspace
Workspace(id)
= een message
= een return message
Verantwoording keuzes (spreek voor zich)
30
31
32
33
34
Communication diagrams
Waarom: het onderliggende business proces weer te geven. In feite is een
communication een object diagram dat berichten weergeeft.
Uitleg diagram:
User
= een actor
2: changeMode(id)
= een association met een message
GUI
= een object
Verantwoording keuzes: (spreekt voor zich)
35
ChangeMode en switchAxes en algemene interactie
36
Load Sample, delete sample
37
Save workspace, close workspace
38
createWorkspace, loadWorkspace.
39
Gedragsmatige state machines
Dit diagram hebben we niet gemaakt.
40