Modelling consists on the elaboration of a model of the system using a modelling tool and/or language (e.g. SYSML, UML, SpecTRM-RL, etc.). The primary target of this method is to help in identifying missing and incomplete requirements. Modelling can be used to cover a broad range of analysis or sub-tasks such as, data flow analysis, control flow analysis, state machine diagrams, etc. The method may be applied to all or specific parts of the system under verification.
OMG Systems Modelling Language (OMG SysML™) is a general-purpose modelling language for systems engineering applications. It can be used for requirements modelling and analysis. It also allows an efficient and straightforward identification of test cases.
SysML supports the specification, analysis, design, and verification & validation of a broad range of complex systems. These systems may include hardware, software, information, processes, personnel, and facilities.
The origins of the SysML initiative can be traced to a strategic decision by the International Council on Systems Engineering’s (INCOSE) Model Driven Systems Design workgroup in January 2001 to customize the Unified Modelling Language (UML) for systems engineering applications. This resulted in a collaborative effort between INCOSE and the Object
Management Group (OMG), which maintains the UML specification, to jointly charter the OMG Systems Engineering Domain Special Interest Group (SE DSIG) in July 2001.
Currently it is common practice for systems engineers to use a wide range of modelling languages, tools and techniques on large systems projects. In a manner similar to how UML unified the modelling languages used in the software industry, SysML is intended to unify the diverse modelling languages currently used by systems engineers.
SysML reuses a subset of UML 2 and provides additional extensions needed to address the requirements in the UML for Systems Engineering Request for Proposal (RFP).
SysML is designed to provide simple but powerful constructs for modelling a wide range of systems engineering problems. It is particularly effective in specifying requirements, structure, behaviour, and allocations and constraints on system properties to support engineering analysis.
UML 2 defines 13 basic diagram types, divided into two general classes:
• Structural diagrams. This class comprises diagrams that define the static architecture
of a model (elements of a specification that are irrespective of time). These diagrams are used to model the building blocks that make up the full model – classes, objects, interfaces and physical components. Structure diagrams are also used to model the relationships and dependencies between elements. It includes class, component, composite structure, deployment, object and package.
• Behavioural diagrams. This class comprises diagrams that depict behavioural
features of a system or business process. It includes activity, state machine, and use case diagrams as well as the interaction diagrams.
The Behavioural class is further divided in a subclass named Interaction Diagrams. This subclass is defined as a subset of behaviour diagrams which emphasize object interactions. This includes communication, interaction overview, sequence, and timing diagrams.
The next table presents the UML 2 diagram types grouped by class.
Diagram Type UML 2
Description Structural Diagrams
Class Diagram Shows a collection of static model elements such as classes and types, their contents, and their relationships. This type of diagram defines the basic building blocks that are used to build the full model.
Component Diagram
Depicts the components that compose an application, system, or enterprise. The components, their
interrelationships, interactions, and their public interfaces are depicted. This type of diagram is used to model higher level or more complex structures, usually built up from one or more classes, and providing a well defined interface. Composite
Structure Diagram
Depicts the internal structure of a classifier (such as a class, component, or use case), including the interaction points of the classifier to other parts of the system. It provides means of layering an element's structure and focusing on inner detail, construction and relationships.
Deployment Diagram
Shows the execution architecture of systems. This includes nodes, either hardware or software execution environments, as well as the middleware connecting them. By other words, this type of diagram shows the physical disposition of significant artefacts within a real-world setting.
Object Diagram Depicts objects and their relationships at a point in time, typically a special case of either a class diagram or a communication diagram. Shows how instances of structural elements are related and used at run-time. Package Diagram Shows how model elements are organized into packages as well as the dependencies between packages.
Diagrams of this type are used to define the high level architecture of the system.
Behavioural Diagrams
Activity Diagram Depicts high-level business processes, including data flow, or to model the logic of complex logic within a system. This type of diagram has a wide number of uses, from defining basic program flow, to capturing the decision points and actions within any generalized process.
Communication Diagram
Shows instances of classes, their interrelationships, and the message flows between them. Communication diagrams typically focus on the structural organization of objects that send and receive messages. Formerly called a Collaboration Diagram in UML 1.x.
Interaction Overview Diagram
A variant of an activity diagram which overviews the control flow within a system or business process. Each node/activity within the diagram can represent another interaction diagram.
Sequence Diagram Models the sequential logic, in effect the time ordering of messages between classifiers. It is closely related to Communication diagrams and show the sequence of messages passed between objects using a vertical timeline. State Machine
Diagram
Describes the states an object or interaction may be in, as well as the transitions between states. Formerly referred to as a state diagram, state chart diagram, or a state-transition diagram.
Timing Diagram Depicts the change in state or condition of a classifier instance or role over time. Typically used to show the change in state of an object over time in response to external events.
Use Case Diagram Shows use cases, actors, and their interrelationships. This type of diagram is used to model user/system interactions. They define behaviour, requirements and constraints in the form of scripts or scenarios.
Table 12: UML 2 diagram types
OCL [OCL] can also be used when modelling techniques are mentioned in the ISVV activities. It is a formal language used to describe expressions on UML models. The traditional formal languages have the disadvantage that they are usable to persons with a strong mathematical background, but difficult for the average system modeller to use. OCL has been developed to fill this gap since it is a formal language that remains easy to read and write.
OCL is not a programming language; therefore, it is not possible to write program logic or flow control in OCL. OCL is a typed language so that each OCL expression has a type. To be well formed, an OCL expression must conform to the type conformance rules of the language. For example, you cannot compare an Integer with a String. Each Classifier defined within a UML model represents a distinct OCL type.
OCL can be used for a number of different purposes: • As a query language
• To specify type invariant for Stereotypes
• To describe pre- and post conditions on Operations and Methods • To describe Guards
• To specify target (sets) for messages and actions • To specify constraints on operations
• To specify derivation rules for attributes for any expression over a UML model.