ITM305 Week 7 PDF
Document Details
Uploaded by MemorableRadiance
Tags
Summary
This document presents an overview of message formats in system sequence diagrams (SSDs), system events, system operations, and the concepts for extending/integrating software requirements models using UML diagrams and diagrams like use case diagrams, activity diagrams, and systems sequence diagrams..
Full Transcript
# Message Formats in SSD - UML format for a message consist of a message name followed (in parentheses) by a parameter list. - All names begin with a lowercase letter. - No spaces in a name Upper-case letters separate the word within a name. - Names in the parameters list are separated by commas. -...
# Message Formats in SSD - UML format for a message consist of a message name followed (in parentheses) by a parameter list. - All names begin with a lowercase letter. - No spaces in a name Upper-case letters separate the word within a name. - Names in the parameters list are separated by commas. - Even if there are no parameters, an empty () is used. # Outgoing messages (System outputs) - A response of the system which completes and event. - A message form the system to an external system requiring action and a reply. - Every output must be derivable from the input to the use case combined with stored data. # Message notation for SSD [true/false condition] return-value := message-name (parameter-list) - An asterisk (*) indicates repeating or looping of the message. - Brackets [] indicate a true/false condition. This is a test for that message only. If it evaluates to true, the message is sent. If it evaluates to false, the message isn't sent. - Message-name is the description of the requested service written as a verb-noun. - Parameter-list (with parentheses on initiating messages and without parentheses on return messages) shows the data that are passed with the message. - Return-value on the same line as the message (requires :) is used to describe data being returned from the destination object to the source object in response to the message. # System events and system operations - System operations are the operations that the system as a black box component offers in its public interface. These are high-level operations triggered by an external input event/system event generated by an external actor. - During system behaviour analysis, system operations are assigned to a conceptual clas system # Extending and Integrating Requirements Models - **Use cases**: - Use case diagram - Use case description - Activity diagram - System sequence diagram (SSD) - **Domain classes**: - Domain model class diagram - Use case realizations The image shows a diagram representing the different types of diagrams used in a system model, with the relationships between them. The diagram shows the following: - **Use case diagram:** It is at the top of the hierarchy and feeds into the "use case descriptions", "activity diagrams", and "system sequence diagrams" - **Use case descriptions:** Are connected with an arrow to "activity diagrams" - **Activity diagrams:** Are connected with an arrow to the "system sequence diagrams" - **System sequence diagrams:** Are connected with an arrow to the "domain model class diagram" - **Domain model class diagram:** Are connected with an arrow to the "use case realizations". - **Use case realizations:** Are the bottom layer of the hierarchy.