SSD::="System Sequence Diagram", a way of using the UML to model the sequences of events flowing between actors and the system under development.
SSD's clarify the steps in use cases and prepares you to design
collections of objects that realize a use case.
Each SSD should show a scenario with one event/response for each interaction
between an actor and the system. These events should be thought of
as coming from the user interface into the heart of the software.
We will work out what happens inside this next week.
We will use sequence diagrams with similar form but more objects
to design our software.
The messages in the SSD will be the incoming "found" messages that we
will use to work out how objects in our program will "collaborate" to
give the response that the user/stakeholders require.
It shows a single box(object) for the whole system. It does not show
any internals of the system. It is a black box model of the system.
Messages
Messages turn up a lot in OO programs: in SSD, interaction diagrams, and in design class diagrams.
You should use a strict syntax for messages in UML diagrams.
login(id,password)
logout()
findClassesWith(name)
registerIn(me, class)
pick(itemNumber)
createMailMessage(subject, replyTo, message, signature)
You aim to be a precise as possible. The idea is to uncover the details that can kill
a project, not slide them underneath a rug.
Here is the syntax of function calls:
10.11 History. I knew Derek Coleman and have the Fusion book in my office...
you can forget this:-(
SSDs and C++ Testing
You can quickly create a main program that will test your design directly
from the SSD becasue testing doesn't have a complex User Interface.
For example the SSD above would lead to a C++ main Program like this
...
#include <WhereTheClassesAreDeclared.h>
int main()
{
SomeClass * testObject = new SomeClass(someValues);
testObject->event();
someType response = testObject->event2(data);
assert ( someProperty(response) );
}
However.... you don't know what "SomeClass" will be until you've
designed the internal interactions. See
[ 10.html ]
later.