UNIT 4 SPECIFICATION OF TECHNICAL SYSTEM INTERFACES Flashcards
What does the specification of technical interfaces do?
The specification of technical interfaces between components and systems (referred to collectively as “interfaces”) defines which messages can be exchanged between components (or systems) in which situations, as precisely as possible and in an appropriate format for the current communication situation.
The component diagram illustrates the use of technical interfaces, but the development team needs more information about which data are exchanged via the interface, and in which situations, in order to implement the components.
Unified Modeling Language (UML) activity diagrams and UML sequence diagrams are suitable for the structured documentation of which messages are exchanged between systems and when.
Why are UML Activity Diagrams good for specifying technical interfaces?
UML activity diagrams (ACD) are one option for specifying the exchange of messages at interfaces. Each component and its area of responsibility is depicted by a partition (“swimlane”). Each partition models the conceptual context, within which messages between components are exchanged. Which messages (i.e., which data structures) are exchanged is defined in the ACD using object nodes, ele-
ments in an activity diagram representing information that is required and output by actions.
Using partitions and object nodes in the activity diagram is a simple way of modeling complex operations while including the messages exchanged between systems. This creates a simple overview of the required message types. ACDs are less suitable for denoting the technical details of a specific message exchange or details about the content of individual
messages. While theoretically possible using the notation elements in UML, the UML sequence diagram is a more suitable form of documentation for this purpose.
Describe what an UML sequence diagram is.
A UML sequence diagram (SED) is suitable for the detailed modeling of technical protocols between systems or components. While activity diagrams focus on the conceptual perspective, sequence diagrams can be used to model every detail of technical communication. When refining system interfaces, it is often necessary to incorporate technical details, such as authentication, authentification, and establishment of a suitable communication channel, as well as status, test, and error messages. The sequence diagram supports this by illustrating the interaction between communication partners over time, with due regard for the exchanged data structures. The UML sequence diagram is a UML behavioral diagram, which models individual operations. In this way, system behavior can be specified and illustrated using examples. Generally speaking, a sequence diagram behaves toward an activity diagram just as an object diagram behaves toward a class diagram: The sequence diagram illustrates a particular operation, while the activity diagram represents the sum total of all possible operations.
What are the basic notations for UML Sequence Diagram?
- Interaction partner: box, actor who participates in the interaction, can be a system, class, user or specific object, typename preceded by a “:”.
- Lifeline: vertical dotted line, marks the interaction partner’s area of responsibility.
- Request: solid line with arrowhead connects lifelines of two interaction partners, an interaction partner activates a function of another interaction partner.
- Response: dotted line with arrowhead connects lifelines of two interaction partners, transfers the result of the request to the activating interaction partner.
- Activation bar: whitebox on the lifeline, indicates when the interaction partner is active in relation to the currently displayed operation.
- Combined fragment: frame with type labelling in the top left, used to model options and alternatives in the sequence diagram
What are some logical mistakes that can be made when creating a UML Sequence Diagram?
Two arrows cannot be positioned on the same (notional) horizontal line in a sequence diagram because it would then be impossible to decide which arrow should continue the communication. When creating a diagram, therefore, it is important to ensure that arrows are arranged across all lifelines in a clear sequence. The notation elements we have considered until now do not support the denotation of parallel operations or possible alternatives. In any case, this is not usually necessary because a sequence diagram generally models a specific operation. The statements derived from the sequence diagram concern the sequence of requests and responses only. A sequence diagram does not contain any information about particular processing times. The distances between the inquiry and the response are not indicative of the time taken to process a query. Only logical information about the request sequence
can be deduced from the diagram.
When are activation bars and combined fragments used in UML Sequence Diagrams?
Activation bars are optional and not compulsory. They are used to indicate who is currently working on a particular operation. The length of the activation bar is not indicative of the length of processing; larger activation bars in the diagram may well be faster than smaller ones.
Combined fragments are also commonly used alongside activation bars. Using combined fragments significantly enhances the expressiveness of a UML sequence diagram. An unlimited number of interaction steps may be modeled in the individual sections of combined fragments, so theoretically, the content of any UML activity diagram
could be denoted in a sequence diagram. However, the larger the combined fragments become and the more of them are used, the more confusing the model will be.
In summary, the use of UML sequence diagrams is appropriate when:
* denoting complex interactions and interaction cascades between components;
* the sequence of exchanged messages is crucial; and
* denoting procedural details for a special application, such as a particular path, in the form of an activity diagram.
What are some strengths and some weaknesses that every UML diagram has when specifying technical interfaces?
- UML use case diagram
Strengths: denotes at the highest level that interfaces exist, strengths when specifying interfaces
Weaknesses: No conceptual or technical details, weaknesses when specifying interfaces - UML activity diagram
Strengths: links conceptual operations with exchanged data structures, overview of required messages, denotes the purely conceptual level
Weaknesses: no technical details of the interface, no details of the message content - UML sequence diagram
Strengths: depicts complex interactions and technical interaction cascades in their precise sequence, links operation and data structure
Weaknesses: Focus on specific operations, operation isolated from the conceptual use case, can soon become highly complex and technical, only readable by those with
advanced knowledge of UML
What is the first step for specifying data structures at component interfaces?
Generally speaking, UML Class diagrams (as UML structure diagrams) are also suitable for the specification of data structures at component interfaces.
Before specifying the data structures, it is first necessary to identify the actual component interfaces. The modeled interfaces can be read directly from component diagrams, as already shown. In use case diagrams, the intersections between the communication relationship and the system boundary indicate an interface, while in activity diagrams, interfaces are indicated by the intersections between the control flow and the partition boundary. In every instance, technical interfaces must be given a unique, preferably meaningful name. For example, the interface names in allusion to the subject matter.
After components interfaces are identified, how are components interfaces specified?
Once an interface has been identified, a detailed specification is needed depending on the current project situation. Beginning with the component diagram, which names every interface, the interface definition is then extended to include specific responsibilities. In the simplest case, every interface is modeled in the component diagram by an appropriately named interface, together with the required messages and result types.
Pre-existing UML activity diagrams and sequence diagrams can help to identify the required functions, their parameters, and their return types. A suitable interface function must be allocated to each request in the sequence diagram. The messages rendered as object nodes in the activity diagram are modeled as parameters or return values of functions in the interface description. You cannot specify fewer parameters and results in the interface description than are found in the sum total of existing UML diagrams. Unlike the specification of object-oriented classes, component interfaces serve to elucidate responsibilities. The software architect is responsible for determining whether there is a specific implementation for each method in any given class. Components are expected to offer functions, but their internal implementation is not relevant from a specification perspective.
How are data structures specified, after component interfaces specification?
Once the specific functions and associated messages have been identified, the next step is to specify the message structure. As the project progresses, the software architects and developers draw on the specified data structures as the basis for reconstructing the business logic of communication between components or between systems. The specification
of data structures includes a detailed definition of the information available to the component and how it is structured. The attributes of these data types are derived, firstly, from the requirements already documented, and secondly, from the interface descriptions of existing components. Industry standards, guidelines, and corporate policies are often used as sources for the specific attributes of interface data structures.
Data structures are specified in the form of UML class diagrams. Additionally, information about interfaces can usually be given in the form of a table, text, or entity relationship diagram. However, as the UML class diagram notation may be integrated into other types of diagrams, we recommend the conceptual/technical specification of data structures in the form of class diagrams, as they are capable of modeling the most common data structures, and specific interface formats can often be derived directly during downstream development phases. The specification of data interfaces will produce at least one interface description for each technical interface in the component diagram with all the required functions and data structures, together with class diagrams specifying the particular data structure transmitted with each message.
