=Paper=
{{Paper
|id=Vol-1463/paper4
|storemode=property
|title=Towards a Generic Modeling Language for Contract-Based Design
|pdfUrl=https://ceur-ws.org/Vol-1463/paper4.pdf
|volume=Vol-1463
|dblpUrl=https://dblp.org/rec/conf/models/IberHRK15
}}
==Towards a Generic Modeling Language for Contract-Based Design==
https://ceur-ws.org/Vol-1463/paper4.pdf
Towards a Generic Modeling Language for
Contract-Based Design
Johannes Iber, Andrea Höller, Tobias Rauter, and Christian Kreiner
Institute for Technical Informatics
Graz University of Technology
Inffeldgasse 16, Graz, Austria
{johannes.iber, andrea.hoeller, tobias.rauter, christian.kreiner}@tugraz.at
Abstract—Component-based and model-driven engineering are component-based system predictable and safe. Management
key paradigms for handling the ever-increasing complexity of of extra-functional properties is thus still one of the core
technical systems. Surprisingly few component models consider challenges faced by component-based design [6].
extra-functional properties as first class entities.
Contract-based design is a promising paradigm, which has Contract-based design is a promising paradigm for filling or
the potential to fill this shortage of methods for dealing with narrowing this gap, [7]. It captures the behavior of a specific
extra-functional properties. By defining the concept of using functional or extra-functional property in relationship with
assumptions in order to determine the environment, and by using the environment of a component. Despite the existence of a
the concept of guarantees to state what a component provides to
mathematical groundwork [7] [8] and exemplary applications,
the environment, it enables the analyzability of components and
compositions in advance and during system execution. a standard and generic metamodel for contract-based design
With this work, we aim to create the base for a pragmatic does not yet exist.
model-driven method that provides reusable modeling concepts With this work, we provide pragmatic modeling concepts
for contracts targeting arbitrary extra-functional properties. that pave the way for integrating contract-based design into
Furthermore, we expand the current state-of-the-art of contract-
based design by introducing the concept of a finite state machine,
component models of systems. We present a metamodel
where single states consist of several valid contracts. It is also fragment for contracts which target arbitrary single extra-
assumed that these modeling language features will ease the functional properties. Furthermore, we introduce the concept
use of contract-based design. Additionally, we demonstrate the of a finite state machine, where single states constitute valid
applicability of the presented modeling concepts on an exemplary contracts. This concept extends the current state-of-the-art
use case from the automotive domain.
Index Terms—Metamodeling, contract-based design, extra-
regarding contract-based design. We show the applicability
functional properties, component models of these modeling concepts by using an example from the
automotive domain. The target component of the use case
I. I NTRODUCTION is a simplified electronic steering column lock, which we
Numerous industrial sectors are currently confronted with examine with respect to the extra-functional properties safety
massive difficulties originating from managing the increasing and timing.
complexity of systems. The automotive industry, for instance, The remainder of this paper is structured as follows: the
has an annual increase rate of software-implemented functions next Section provides a brief overview of the background
of about 30% [1]. This rate is even higher for avionics to this work. In Section III the proposed modeling concepts
systems [2]. Additionally, this development of systems is not are introduced. Subsequently, a use case demonstrating the
restricted to software, as we are facing a so-called Internet of applicability of these concepts is described in Section IV.
Things, where the number of physical devices is expected to Finally, concluding remarks and future research opportunities
expansively explode [3]. New challenges regarding complexity are given in Section V.
of systems emerge caused by this dramatic increase of diverse
hardware/software, possible interactions and distributed intel- II. BACKGROUND AND R ELATED W ORK
ligences [4]. Here, we give an overview of system abstractions and
Component-based engineering is today a widely recognized properties. After this, we briefly explain contract-based design.
and well-established paradigm for tackling complexity of Finally, we summarize the related work concerning contract-
systems [5]. Together with model-driven engineering, it forms based design, which is also the motivation setting for this
a potentially powerful union to construct, analyze, and deploy work.
systems.
But still, modern component models are flawed. As shown A. System Abstractions and Properties
by Crnković et al. [5], astonishingly few (software) compo- According to Jantsch [9], there are four main different
nent models are addressing extra-functional properties (e.g. abstraction models or views concerning embedded system
timing, safety, memory consumption, etc.) as first class enti- engineering. First is the computational model, which describes
ties. However, these properties are essential for composing a the observable behavior of a system or of its single parts
(hardware, software components), i.e. the relationship between
inputs and outputs [10]. Second, a data model exists that From/by higher design levels
Design level n-1
provides notations for information (e.g. integer, boolean).
Third, a time model is needed to constitute the causality
of events. Fourth, a communication model is established to Design level n Assumed Guaranteed
specify how components interact. This model forms the top- Component
from neighbours
level system behavior.
In the context of the properties of systems the literature Design level n+1
distinguishes between functional and extra-functional (also From/by lower design levels
known as non-functional) properties. Functional properties
describe the function of a system or component, i.e. behav-
ior, input or output data types. Extra-functional properties Fig. 1. Contract assumptions and guarantees for a component (Adapted from
[15])
provide additional information and give a better insight into
the behavior and capability of a system or component [6].
A wide range of such properties exists, e.g. safety, security, interaction between software modules, hardware devices, etc.).
portability, performance. Since these issue from humans, there It also enables analyzing to take place on a vertical level
is no method to determine a priori which extra-functional between different kinds of abstraction [7].
properties exist in a system [6] [11]. A solid mathematical groundwork already exists for this as
B. Contract-based Design provided by several authors, including Benveniste et al. [7],
and Sangiovanni-Vincentelli et al. [8].
Contract-based design usually sees a component as an Promising applications of contract-based design have been
abstraction, a hierarchical entity that represents a single unit shown for several domains. For instance, this paradigm has
of design [8] [12]. Therefore in the context of contract-based been demonstrated for smart integrated energy management
design a component can represent, for instance a module, a systems [16], aircraft electric power systems [12], mixed-
composition, a complex system or even a physical device. signal integrated circuits [17], and automotive [18] [7]. Despite
The essence of this paradigm is to decompose a component these examples, contract-based design is still at its infancy
into different independent views referred to as contracts, which [19].
capture the behavior of a target functional or extra-functional Little work has been done towards establishing a generic
property under certain conditions [12] [13]. This approach standard metamodel for contract-based design. Warg et al. [20]
significantly reduces the complexity of design and verification, presents a prototype modeling tool for contracts, but their work
because the single properties become manageable. solely focuses on safety integrity levels.
Informally, a contract is a set of assumptions and guarantees.
An assumption asserts what a contract expects from the C. Summary of Contract-Based Design
component environment (this can include interactions with There exist a few approaches for realizing contract-based
other components). Additionally, an assumption provides a design, for instance the contract-based model developed in the
certain context for the guarantees. The condition contained framework of the SPEEDS project [13]. The problem is that
in an assumption can reference for instance input data, events state-of-the-art approaches either tackle single extra-functional
or system properties. In general, the available variables are set properties, or take a relatively theoretical approach without
or inferred by the analysis environment. concrete modeling examples or tool implementations. A sur-
A guarantee describes what a component provides to the vey concerning the certification of safety-relevant systems,
environment if the corresponding assumptions become valid. carried out by the SafeCer consortium [21], shows that only
In the simplest case a guarantee states that a component just a few companies are actually using contracts for components.
works under the constrained context. More complex contracts And where this is the case they are relying on Meyer’s design-
define limits for instance for output data, environment charac- by-contract principle on a programming language level.
teristics or extra-functional properties such as timing.
Historically, contract-based design is influenced by Meyer’s III. P ROPOSED M ODELING L ANGUAGE C ONCEPTS
design-by-contract principle [14] for object-oriented software In this section, we explain concepts which are necessary
[7]. The main difference is that contract-based design goes for a pragmatic modeling language that targets contract-based
much further and provides means to integrate components in design.
the design hierarchy [10]. This is achieved through capturing
the context by assumptions (which may include platforms, A. Target System Abstractions and Properties
other components, etc.), under which a component behaves With the following concepts, we aim at enriching the
as specified by the guarantees. Furthermore, a system can be computational, time, and communication models of a system.
viewed by selecting only appropriate contracts of interest. Furthermore, the data model plays an important role, as it
Fig.1 illustrates that contract-based design not only allows provides data types and notations, which could be used by
the analyzing of components on a horizontal design level (e.g. contracts.
In the context of properties, our intention is to capture extra- Fig.3 illustrates our proposed metamodel for such a state
functional properties and not necessarily functional behavior. machine. We again use the concept of declaration and defini-
We take the view that functional behavior is better described tion in order to separate the specification and actual instance
by other well-established methods than by the use of many of a so-called contract state machine.
different contracts. A Contract State Machine Declaration constitutes allowed
The issue of what extra-functional properties we are aiming Contract Declarations, concrete parameters and declarations
at, is dependents on the specific use case or context under of parameters which need to be defined by corresponding
which the following language features are used. These con- Contract State Machine Definitions.
cepts may be applied for a wide range of different extra- Parameters are supposed to be used by Contract State
functional properties (e.g. security, safety, timing, expected Machine Events within constraint expressions, which trigger
hardware/platform, memory consumption, many-core environ- transitions to other Contract State Machine States. Such a state
ment, etc.). But certainly not for all of them, since no silver contains zero to infinite Contract Definitions.
bullet exists for dealing with every extra-functional property Again, the metamodel elements Variable, DataType and
[11]. Expression, refer to an arbitrary constraint language.
The actual semantics of a contract state machine depends
B. Pragmatic Modeling Langugage Features on the target extra-functional properties and is determined by
In the following, we present a modeling concept for con- convention. It may be that entering a state implies that only
tracts. Additionally, we introduce the concept of a finite state those Contract Definitions it contains are valid. An alternative
machine for contracts. convention would be, that all visited Contract Definitions are
1) Contract: Fig.2 illustrates our proposed metamodel for valid except that a current Contract Definition overrides a
contracts. We separate a contract into two parts. A Contract former visited one by using the same Contract Declaration.
Declaration represents a type for Contract Definitions. It
states the available parameters, assumptions and guarantees. IV. U SE C ASE
Furthermore, it represents the target extra-functional property. In this Section we show the application of our modeling
A Contract Definition captures the unique behavior concerning concepts as presented on an exemplary use case from the
the target extra-functional property of a component in relation- automotive domain. First we give an overview of the target
ship to its environment. component and system. After that, we apply contracts together
Parameters can represent properties of the execution envi- with a contract state machine. Finally, we discuss the use case
ronment, data ports or events. They can be used by Constraint presented.
Definitions in order to set the specific assumption or guarantee.
Parameter Declarations are used to specify that a variable of A. Example - Electronic Steering Column Lock
a specific data type may exist, but the concrete value has to be Fig.4 illustrates a simplified electronic steering column lock
defined by the realizing Contract Definition. This can be useful (ESCL). Such locks are mandatory for cars in many countries.
for data arrays where the data points contained are individual The Electronic Control Unit (ECU) decides whether to lock
for each component. the steering column based on the input signals Key State and
In the context of assumptions and guarantees, it is possible Velocity. These signals may be transmitted by a CAN bus or
for a Constraint Declaration to set expected data types. The separate connections. If the ECU decides to lock the steering
associated Constraint Definition must provide an expression column, an actuator is activated which inserts the bolt into the
where the resulting data type equals one of the expected types. steering column. Otherwise, the ECU decides to hold or eject
As we can see in Fig.2, we use the placeholders Variable the bolt.
for parameters, DataType for data types, and Expression for There are several extra-functional properties which are
constraint expressions. These elements should be provided by worth considering in a system of this kind. In the following, we
a suitable constraint language or referable by the language that apply the modeling concepts presented for the extra-functional
is used for the Constraint Definition expressions. properties safety and timing. In the safety context we capture
2) Finite State Machine for Contracts: Single contracts are the data on whether the component ESCL is performing
sometimes not adequate for representing extra-functional prop- normally, is in a failure state, or recovering from a failure
erties. As we explain with our presentation in the following state. A failure state can be induced for instance by faulty
Section IV, cases exist where the behavior of a component - transmitted data or other misbehaving components. Further to
including extra-functional properties - changes over time or this we capture the data on how long it takes to execute the
as a result of specific events. We thus expand the theory of lock or unlock mechanism in two separate contract definitions.
contract-based design and capture such differences concerning
contracts by applying the concept of a finite state machine. B. Declarations
The idea is to have a finite state machine, where the single According to our metamodel concepts, the first step is to
states may contain several currently valid contracts. The state specify general declarations for components. Such declara-
machine itself operates on parameters provided by the envi- tions are known to contract checkers, interpreters or model
ronment or the internal states of a component. transformers in advance. Fig.5 illustrates declarations for a
Fig. 2. Proposed Metamodel for Contract Declarations and Definitions
Fig. 3. Proposed Metamodel for Contract State Machine Declarations and Definitions
Contract Declaration "Component Contract State Machine Declaration
Safety Status" "Component Contract Behavior"
Key State Assumption Enabled : Boolean Uses contract declaration "Component Safety
Steering Status“
Guarantee State : SafetyStateEnum Uses contract declaration "Component Timing“
Wheel
Parameter declaration key_state : Boolean
Contract Declaration "Component
Parameter declaration velocity : Float
Timing"
Parameter component_restart : Boolean = false
Actuator ECU Velocity Parameter key_state : Boolean = false
...
Parameter velocity : Float = 0.0
Component ...
Electronic Steering Column Lock Assumption Environment : Boolean
Guarantee Execution Time : Time
Fig. 4. Example Component - Electronic Steering Column Lock Fig. 5. Use Case Declarations for the target extra-functional properties
component’s safety status and timing. Additionally, we specify a certain safety state to the environment. The available types
a contract state machine declaration that is used to capture the for this guarantee are restricted by the data type SafetySta-
behavior of a component in order to set valid contracts. teEnum, which contains the literals NORMAL, FAILURE, and
The contract declaration Component Safety Status assumes RECOVER (not shown in Figure 5).
whether the component of interest is enabled and guarantees The contract declaration Component Timing is used to
guarantee a specific execution time for certain assumed envi- The initial state of this example is state Normal. Within this
ronments. The parameters key state and velocity are provided state, we can guarantee the execution time in respect to the
by the analysis environment. The boolean parameter key state locking and releasing mechanism. Furthermore, the contract
indicates whether the ignition system is activated (boolean ESCL Normal determines the safety state NORMAL to the
value true), while the parameter velocity states the current environment. Whenever an abnormal event occurs such as
speed of the car. A comprehensive contract declaration would there is no key but the car is moving, the contract state machine
provide several other parameters, which may be obtained changes to the state Failure. In this state we cannot constitute
for instance by a CAN bus or observed from the condition the execution time of the ECSL and the contract ESCL Safe
of a system. The issue of which of these parameters are State becomes valid. After the component ESCL restarts, the
actually used by the assumption Environment depends on the state machine changes to the state Repair, which is reflected
component. When this assumption results in a boolean true, by the contract ESCL Recover. When the recover procedure
the guarantee Execution Time becomes valid. was successful, the state machine changes to the state Normal,
Furthermore, contract definitions of these declarations can where the contained contracts become valid again, otherwise
be used by the single states of the contract state machine the state machine switches back to state Failure.
Component Contract Behavior. Here again the parameters con-
tained are obtained by the analysis environment or transmitted D. Discussion of the Use Case
by the available connections. For instance, the parameter We have shown how our contract modeling features can be
component restart must be set by the analysis environment used as presented on a simplified use case. It is imaginable
or by the described component. These parameters are used that this example can be further advanced to capture the target
by a contract state machine definition in order to specify the and other extra-functional properties in more detail.
events for state transitions. Note that we do not capture the actual functional behavior
C. Definitions of the component ESCL. We rather use the functional behavior
of the environment in order to determine how the target extra-
We now present how the declarations from above are used.
functional properties timing and safety status of the component
are changing and what guarantees are valid in that state. The
Contract State Machine "Component ESCL Contract Behavior" : "Component Contract Behavior"
Parameter key_state = false
semantics of the contract state machine we present is such
Parameter velocity = 0.0 that a new state invalidates the former visited contracts. The
assumptions and guarantees of the Contract Definitions must
be either automatically gathered by a measurement software
or issued by humans.
Normal Failure
Such a contract state machine can be used for two purposes.
Contract "ESCL Normal" Event: not key_state && velocity > 0.0 Contract "ESCL Safe State"
Contract "ESCL Lock" One purpose is that a system becomes analyzable in ad-
Contract "ESCL Unlock"
vance, also with respect to composability. A model checker
Event: not key_state && velocity > 0.0
could simulate such a system and calculate the different
expected safety states. Another model checker would be able
Event: (key_state && velocity >= 0.0) || to estimate the overall timing of a system.
(not key_state && velocity == 0.0)
Repair The second purpose would be that a detection mechanism
Event: component_restart
Contract "ESCL Recover" observes and constitutes the single states during runtime of a
system and takes appropriate action based on predetermined
contracts.
Contract "ESCL Normal" : Contract "ESCL Safe State" : Contract "ESCL Recover" :
"Component Safety Status" "Component Safety Status" "Component Safety Status" V. C ONCLUSION AND F UTURE W ORK
Assumption Enabled = true Assumption Enabled = true Assumption Enabled = true
Guarantee State = NORMAL Guarantee State = FAILURE Guarantee State = RECOVER
In this paper, we presented concepts for modeling contracts
and showed in a use case how these concepts can be applied.
Contract "ESCL Lock" : "Component Timing" Contract "ESCL Unlock" : "Component
Timing" The vision is to have a generic modeling language for
Assumption Environment = not key_state && velocity == 0.0 Assumption Environment = key_state specifying contract types and contract instances. By using the
Guarantee Execution Time = 100 ms Guarantee Execution Time = 80 ms term generic we mean contracts that are suitable for at least a
substantial number of extra-functional properties.
Fig. 6. Contract State Machine and Contract Definitions of the ESCL Example We introduced the concept of splitting a contract into a
declaration and a definition. For analysis purposes a specific
Fig.6 illustrates a contract state machine definition which contract declaration would be known by a model checker or
sets the valid contract definitions according to the current state. code generator beforehand. It declares the available parame-
The parameters are realizations of the parameter declarations ters, assumptions and guarantees, while a contract definition
declared by the contract state machine declaration Component uses such a declaration to define the actual behavior of a target
Contract Behavior and are initialized to default values. extra-functional property.
Furthermore, we introduced the concept of a contract state [5] I. Crnkovic, S. Sentilles, V. Aneta, and M. R. Chaudron, “A Classifica-
machine which is basically a finite state machine where the tion Framework for Software Component Models,” IEEE Transactions
on Software Engineering, vol. 37, no. 5, Sep. 2011.
single states represent different contract definitions. This con- [6] S. Sentilles, P. Štěpán, J. Carlson, and I. Crnković, “Integration of Extra-
cept is necessary, because a component may behave in differ- Functional Properties in Component Models,” in Component-Based
ent ways depending on the input data, environment properties Software Engineering. Springer Berlin Heidelberg, 2009.
[7] A. Benveniste, B. Caillaud, D. Nickovic, R. Passerone, J.-B. Raclet,
or specific events. For instance, the timing of a component P. Reinkemeier, A. L. Sangiovanni-Vincentelli, W. Damm, T. Henzinger,
may be different depending on its previous processed data. It and K. Larsen, “Contracts for Systems Design,” INRIA, Rennes, France,
may also be different if the environment has changed. Such Tech. Rep., 2012.
[8] A. Sangiovanni-Vincentelli, W. Damm, and R. Passerone, “Taming
changes may require different valid contracts. Dr. Frankenstein: Contract-Based Design for Cyber-Physical Systems,”
Concerning our future work, we are currently working European Journal of Control, vol. 18, no. 3, Jan. 2012.
on a configurable constraint modeling language, inspired by [9] A. Jantsch, Modeling Embedded Systems and SoCs: Concurrency and
Time in Models of Computation. San Francisco, Amsterdam: Morgan
OCL [22], which we want to use for setting assumptions and Kaufmann, 2004.
guarantees. The idea is to have a constraint language where [10] N. Kajtazovic, “A Component-based Approach for Managing Changes
language elements, such as an if expression or a boolean in the Engineering of Safety-critical Embedded Systems,” Ph.D. disser-
tation, Graz University of Technology, 2014.
operation, can be disabled and is afterwards not usable by [11] I. Crnkovic, M. Larsson, and O. Preiss, “Concerning Predictability
an assumption or guarantee. This is useful, in our opinion, to in Dependable Component-Based Systems: Classification of Quality
simplify the construction of contract checkers or interpreters, Attributes,” in Architecting Dependable Systems III. Springer Berlin
Heidelberg, 2005.
because not all concepts of an expression language need to be [12] P. Nuzzo, Huan Xu, N. Ozay, J. B. Finn, A. L. Sangiovanni-Vincentelli,
considered and handled properly. It would also provide a user R. M. Murray, A. Donze, and S. A. Seshia, “A Contract-Based Method-
with direct feedback concerning what language elements are ology for Aircraft Electric Power System Design,” IEEE Access, vol. 2,
2014.
allowed for use. [13] A. Benveniste, B. Caillaud, A. Ferrari, L. Mangeruca, R. Passerone,
Additionally, the presented modeling features for contracts and C. Sofronis, “Multiple Viewpoint Contract-Based Specification and
do not consider composition, refinement, and conjunction of Design,” 2008.
[14] B. Meyer, “Applying ’design by contract’,” Computer, vol. 25, no. 10,
contracts as described theoretical by Benveniste et al. [7]. We Oct. 1992.
are still working on finding pragmatic and usable metamodel [15] A. Rajan and T. Wahl, Eds., CESAR - Cost-efficient Methods and
solutions for these concepts. Processes for Safety-relevant Embedded Systems. Vienna: Springer
Vienna, 2013.
After building this in a form suited to our use case meta- [16] M. Maasoumy, P. Nuzzo, and A. Sangiovanni-Vincentelli, “Smart Build-
model for contract-based design, we are planning to develop a ings in the Smart Grid: Contract-Based Design of an Integrated Energy
thin generic UML profile [23] for contracts and contract state Management System,” 2015.
[17] P. Nuzzo, A. Sangiovanni-Vincentelli, Xuening Sun, and A. Puggelli,
machines. “Methodology for the Design of Analog Integrated Interfaces Using
This profile will be aligned with the existing OMG specifi- Contracts,” IEEE Sensors Journal, vol. 12, no. 12, Dec. 2012.
cations MARTE [24] and SysML [25]. As mentioned by Selić [18] N. Kajtazovic, C. Preschern, A. Höller, and C. Kreiner, “Constraint-
Based Verification of Compositions in Safety-Critical Component-Based
and Gérard [26], a natural complementarity exists between Systems,” in Software Engineering, Artificial Intelligence, Networking
these two profiles. We are of the view that a UML profile for and Parallel/Distributed Computing, ser. Studies in Computational In-
contract-based design would benefit from concepts such as the telligence. Springer International Publishing, 2015.
[19] P. Nuzzo and A. Sangiovanni-Vincentelli, “Lets Get Physical: Computer
physical types of MARTE or the constraint blocks of SysML. Science Meets Systems,” in From Programs to Systems. The Systems
Not using such existing and standardized modeling concepts perspective in Computing. Springer Berlin Heidelberg, 2014.
would be like reinventing the wheel. [20] F. Warg, B. Vedder, M. Skoglund, and A. Soderberg, “Safety ADD: A
The advantages of such a UML profile for contracts could Tool for Safety-Contract Based Design,” in 2014 IEEE International
Symposium on Software Reliability Engineering Workshops, Nov. 2014.
be manifold. The most important one is, that it would allow [21] O. Bridal, R. Mader, A. Geven, E. Schoitsch, H. Martin, M. Larramendi,
the rise of specialized analyzing tools of different vendors A. Aristimuno, A. Fritsch, E. Vaumorin, M. Bordin, A. Solinas,
which target single extra-functional properties. The input of A. Martelli, I. Korago, A. Levcenkovs, F. Joakim, R. Land,
A. Söderberg, P. Conmy, and M. Illarramendi, “State-of-practice
such tools would depend, in such an ideal ecosystem, on the and state-of-the-art agreed over workgroup,” Tech. Rep., 2011.
same UML profile for contract-based design. [Online]. Available: http://www.safecer.eu/images/pdf/pSafeCer\ D1.0.
1StateOfThePracticeAndTheArt.pdf
R EFERENCES [22] Object Management Group (OMG), “Object Constraint Language
[1] C. Ebert and C. Jones, “Embedded Software: Facts, Figures, and Future,” Version 2.4,” 2014. [Online]. Available: http://www.omg.org/spec/OCL/
Computer, vol. 42, no. 4, Apr. 2009. 2.4/
[2] P. Feiler, J. Hansson, D. de Niz, and L. Wrage, “System Architecture [23] ——, “Unified Modeling Language (UML),” 2015. [Online]. Available:
Virtual Integration: An Industrial Case Study,” Software Engineering In- http://www.omg.org/spec/UML/Current
stitute, Carnegie Mellon University, Pittsburgh, Pennsylvania, CMU/SEI- [24] ——, “UML Profile for MARTE: Modeling and Analysis of Real-
2009-TR-017, 2009. Time Embedded Systems Version 1.1,” 2011. [Online]. Available:
[3] M. Miller, The Internet of Things: How Smart TVs, Smart Cars, Smart http://www.omg.org/spec/MARTE/
Homes, and Smart Cities Are Changing the World. Pearson Education, [25] ——, “OMG Systems Modeling Language (OMG SysML) Version
2015. 1.3,” 2012. [Online]. Available: http://www.omg.org/spec/SysML/1.3/
[4] D. Miorandi, S. Sicari, F. De Pellegrini, and I. Chlamtac, “Internet of [26] B. Selić and S. Gérard, Modeling and Analysis of Real-Time and
things: Vision, applications and research challenges,” Ad Hoc Networks, Embedded Systems with UML and MARTE, 2014.
vol. 10, no. 7, Sep. 2012.