Phase 1 - Core and Sequence Diagram


This phase is limited to developing toolkit core and functionality related to sequence diagrams. Within the scope of the phase the following items are to be developed:
  • Xml-based UML description language.
  • Core component which based on the xml-based UML model description will provide its graphical representation.
  • Console client tool for the mentioned component that will invoke the component functionality.
  • User guides for the language, component and client tool.


Xml-based Language Requirements
  • L0. Consider existing model describing languages like XMI.
  • L1. There must be an xml-schema defining the rules of the language.
  • L2. It must be possible to include several diagrams of different type (sequence, activity, class, etc.) into one xml file.
  • L3. Visual elements layout is not described by this version of the language, but it must be taken into account that in future versions it can be required.
  • L4. The order of elements in the diagram reflects the order of elements in the xml-file.
Core Requirements
  • C1. The core of the toolkit is a component which can be used from any client application.
  • C2. The core interface must be as simple as possible.
  • C3. There must be a possibility for external tools to pass a model in the form of a path to an xml-file, a string representation of an xml-file or the core must provide an API for building a UML model.
  • C4. The UML model visualization should be done in both vector and raster formats.
  • C5. When a model contains several diagrams they must be returned as separate images.
Sequence Diagram Requirements
SD1. Frame element.
This notation shows a rectangular frame arount the diagram with its name in the left upper corner.
SD2. Lifeline element.
Lifeline can be of different types. In the first phase there will be only a normal lifeline and actor lifeline notations.
Actor lifeline is always thick because an actor is always "alive".
Normal lifelines can have a type, defined through a colon. The lifeline name must be unique within a type.
Lifeline Actor lifeline
Lifeline Actor lifeline
SD3. Execution specification element.
Depicts the execution time on a lifeline.
SD4. Interaction use element.
This element allows to reference another sequence diagram. The element can span over several lifelines.
SD5. Combined fragment element.
Combined fragment allows to define groups of messages as a single entity. The element can span over several lifelines.
In the first phase only alt and loop will be implemented.
Alt allows to depict a choice between two alternatives. The notation can contain a predicate.
Loop depicts a group of messages repeated in a cycle.
Alt Loop
Alt Loop
SD6. State invariant element.
Allows definition of runtime constraints.
SD7. Continuation element.
Represents labels defining intermediate points in the flow of control. This element can span over several lifelines.
SD8. Destruction event element.
This element states that no more execution in current lifeline is possible.
SD9. Concurrent element.
Defeines that a section in a lifeline can be executed concurrently.
SD10. Duration constraint element.
This element defines duration of a time-consuming operation. Can be applied only to duration messages.
SD11. Time constraint element.
Allows to define timepoints on a sequence diagram.
SD12. SD12. Message element.
Connects two lifelines, or a lifiline with itself. Each message can have a label. Checking syntax of the label messages will be implemented in the next phases. There can be different types of messages:
call message Call messages represent a method call. Can be either synchronous or asynchronous.
return message Defines the reply to a method call. The return message from a method has a dashed line.
self-message Represents an object's call to itself. Can be either synchronous or asynchronous.
recursive message Defines a recursive method call. Can be either synchronous or asynchronous.
duration message Allows to specify calls which have specific duration. Can be either synchronous or asynchronous. The duration message is a slanting line.
create message Defines a call to object constructor. A lifelne, to which this call is addressed, begins only after this call. Object creation Message has a dashed line with an open arrow.
found message Is a message where the origin of the message is outside the scope of the description. Found Messages are described as a small black circle at the starting end of the Message.
lost message Is a message that never reached its destination. Lost Messages are described as a small black circle at the arrow end of the Message.
synchronous message Synchronous Messages typically represent operation calls and are shown with a filled arrow head.
asynchronous message Asynchronous Messages have an open arrow head.

Message notations.
Call message synchronous call_message_sync.jpg
Call message asynchronous call_message_async.jpg
Return message return_message.jpg
Self message self_message.jpg
Recursive message recursive_message.jpg
Duration message duration_constraint.jpg
Create message create_message.jpg
Found message found_message.jpg
Lost message lost_message.jpg
SD13. Stereotypes.
It must be possible to define stereotypes for lifelines and for message elements. The names of stereotypes appear in double angle brackets.
Parser Requirements
  • P1. Check that each element has a unique name.
  • P2. While parsing an xml-file, it must be verified that all the references to other elements reference existing elements.
  • P3. Check that either a lifeleine or an interaction element can be invoked as a target of a message element.
  • P4. Make sure that the target of a self message or a recursive message is the same lifeline as the source.
  • P5. Check that the target of a lost message and the source of a found message is empty.
  • P6. Veirfy that in a concurrent element no sequential messages are called between concurrent ones.
  • P7. Check that a message is present at least in one of the sections of a combined element.
Client Tool Requirements
  • CT1. Client tool must provide the possibility to use the functionality of the core by means of command line arguments.
  • CT2. Client tool will accept the following arguments: path to model xml-file, image type, path to output file. If there are several output files, the diagram name will be appended to the filename.
  • CT3. If client tool is started without parameters, it must show help. If it is started with wrong parameters, the user must be informed about it.
User Guide Requirements
  • UG1. All model description language constructs must be documented with examples.
  • UG2. Client tool must be documented.
  • UG3. Product installation and deployment require a description.
  • UG4. Developer guide for the core-functionality users needs to be created.

Last edited Mar 2, 2010 at 1:13 PM by helios12, version 14


No comments yet.