Architecture Modeling - SPES 2020

More documents

Recommendations

Info

3.3.1.1 Ports Architecture Modeling Ports are the interaction points of a component. The set of all ports of a component constitutes its syntactical interface. Figure 3.24 depicts how the port concept is embedded in the architecture meta-model. Each Port of a component has a name and is typed by a PortSpecification, which declares the Flows or Services required or provided at some port. A flow is a data-oriented interaction point and services model services a component provides or requires. The PortSpecification is either a set of flows or a set of services, but not both. Port + isConjugated: Boolean +port +component 1 RichComponent FlowDirection in out bidirectional 0..* FlowKind discrete continuous event +portSpecification +type PortSpecification 0..* InteractionPoint «isOfType» 1 1 +interactionPoint Flow + direction: FlowDirection + kind: FlowKind Serv iceDirection provided required «isOfType» 1 Serv ice + direction: ServiceDirection «isOfType» +returnType 1 +type DataType +type +service 0..1 1 «isOfType» Figure 3.24: Meta-model integration of the concept of Ports 0..* Parameter +formalParameter Flows have a name, a direction (in, out or bidirectional) and are typed by a DataType. The DataType concept is explained in [50] and is out of the scope of this document. A flow declares the kind of a data-exchange of an owning component. Along with the DataType and direction, its kind can be specified, which is either event, discrete or continuous (see Figure 3.25). Declaring an event flow means there is a value available on the flow only at certain time instants and the value can change from instant to instant. In a discrete flow the value is always available, even between the time instants at which the value changes. In a continuous flow there is also always a value available, but it can evolve continuously during time durations and also change discretely at time instants. The trajectory of a continuous flow can be described by a piecewise continuous function. val event t val discrete Figure 3.25: The different kinds of flows t val continuous Services have a name and a direction (provided or required). A Service is typed by multiple DataTypes, that constitute the signature of the service. As shown in Figure 3.24 a service owns a set of DataTypes, that define the parameters of the service and a DataType in the role of returnType, that defines the return value of the service declaration. t 36/ 156
Architecture Modeling Conjugation of Ports is a concept to reverse the directions of all InteractionPoints of a port. As the direction of a flow or service is specified by the flow or service itself, the direction of the port is defined by the direction of its InteractionPoints. When ports of components inside a composition are being connected (see Section 3.3.2.2), the attribute isConjugated of a Port can be used in order to avoid defining two PortSpecifications, which only differ in the directions of their InteractionPoints. 3.3.1.2 Aspects An aspect defines a viewpoint which is orthogonal to the structure of the system, and describes aspects of functional and/or non-functional properties of component models. Being orthogonal to the structure of the system-model means, that the underlying component-model and interfaces of each component are the same for all aspects. Currently we consider three aspects for a component: functional behavior, real-time and safety. However the meta-model allows to define additional aspects according to the needs of a company or application domain. Aspect +aspect 0..1 Behavior +aspect 0..* 0..* +behavior Behav iorImplementation +component 0..1 BehaviorBlock +type 1 «isOfType» BlockOccurrence RichComponent 1..* Satisfy +component SystemArtefact +satisfies 1..* Requirement + rationale: String [0..*] SystemRequirement Figure 3.26: Meta-model integration of the concept of Aspects For each Aspect a RichComponent can have a specification and a realization. The specification of an aspect is given by a SystemRequirement, that is associated with one or more Aspects. The Satisfy-trace link allows to associate a set of RichComponents with one or more SystemRequirements that the components shall satisfy. A realization of an aspect is given by a Behavior, that is eventually associated with an Aspect. A realization can be modelled in any behavior modeling tool or provided as implemented source code. The latter would correspond to the specialized BehaviorImplementation. If a behavior modeling tool is used and it has a trace-based semantics, then the modeled behavior can be interpreted as a BlockOccurrence. A realization of an aspect provided as a BlockOccurrence can be verified against the specification (see Section 4.3). The BlockOccurrence is typed by an HRC state machine, which is also defined in the meta-model but not described here (cf. [50]). 3.3.1.3 Contracts A contract is a triple (As,Aw,G). As is the strong assumption of a contract, Aw the weak assumption and G the guarantee. A strong assumption characterizes the allowed design context of the component, i. e. the environment from the point of view of the component. If the design 37/ 156
Page 1 and 2: Architecture Modeling ∗ Andreas B
Page 3 and 4: Contents 1 Introduction 1 2 Quick-T
Page 5 and 6: 1 Introduction This document propos
Page 7 and 8: Architecture Modeling allowing to m
Page 9 and 10: Architecture Modeling creating a vi
Page 11 and 12: Architecture Modeling the design it
Page 13 and 14: Architecture Modeling of the logica
Page 15 and 16: Architecture Modeling realization o
Page 17 and 18: Architecture Modeling can usually o
Page 19 and 20: 3 The Architecture Meta-Model In Se
Page 21 and 22: Abstraction-Levels (detail increase
Page 23 and 24: 3.2.2 Functional Perspective Archit
Page 25 and 26: Architecture Modeling The semantics
Page 27 and 28: Architecture Modeling expressed by
Page 29 and 30: Architecture Modeling computing cap
Page 31 and 32: 3.2.5 Geometrical Perspective Archi
Page 33 and 34: ShapeCompositionOperator intersecti
Page 35 and 36: Architecture Modeling The constrain
Page 37 and 38: Architecture Modeling of particular
Page 39: Architecture Modeling Shape that de
Page 43 and 44: RichComponent Architecture Modeling
Page 45 and 46: MultiplicityElement +part 0..* Rich
Page 47 and 48: ComponentC Architecture Modeling pa
Page 49 and 50: 4 Steps in Component-Based Design T
Page 51 and 52: Architecture Modeling Assume/guaran
Page 53 and 54: Architecture Modeling When specifyi
Page 55 and 56: Architecture Modeling next selectio
Page 57 and 58: Architecture Modeling ports must ha
Page 59 and 60: established if (and only if): Archi
Page 61 and 62: 12°C < tempSelect < 35°C actTemp
Page 63 and 64: Architecture Modeling The component
Page 65 and 66: Architecture Modeling 4.3.2 Establi
Page 67 and 68: Architecture Modeling a mapping is
Page 69 and 70: Architecture Modeling Another impor
Page 71 and 72: 5 Using the Architecture Meta-Model
Page 73 and 74: Architecture Modeling Design proces
Page 75 and 76: Architecture Modeling abstraction l
Page 77 and 78: Pwr1 Pedal_Pos1 Pwr2 Pedal_Pos2 CMD
Page 79 and 80: Architecture Modeling Figure 5.4: O
Page 81 and 82: Architecture Modeling Figure 5.7: L
Page 83 and 84: Architecture Modeling Figure 5.9: T
Page 85 and 86: Architecture Modeling Figure 5.12:
Page 87 and 88: Architecture Modeling Figure 5.14:
Page 89 and 90: Architecture Modeling However this
Page 91 and 92:
Architecture Modeling The considera
Page 93 and 94:
Architecture Modeling Figure 5.18:
Page 95 and 96:
Page 97 and 98:
Architecture Modeling tasks Command
Page 99 and 100:
Architecture Modeling of the V, suc
Page 101 and 102:
Architecture Modeling thus decorate
Page 103 and 104:
Architecture Modeling In summary, P
Page 105 and 106:
Architecture Modeling OEMs are incr
Page 107 and 108:
Architecture Modeling provide effec
Page 109 and 110:
Page 111 and 112:
Architecture Modeling patterns, cap
Page 113 and 114:
Architecture Modeling 6.1 Syntax an
Page 115 and 116:
6.1.1.1.1 Attribuute Definit tion a
Page 117 and 118:
Constrrain Eventts with Co ondition
Page 119 and 120:
These events used in the “and the
Page 121 and 122:
Formalization: whenever StartButton
Page 123 and 124:
Architecture Modeling Basic bloock
Page 125 and 126:
6.1.1.1.1.3 Conditions Conditions c
Page 127 and 128:
6.1.1.1.2.2 Seammless Con ncatenati
Page 129 and 130:
e3 && (clk==0) e1 idle pre e1 idle
Page 131 and 132:
Pattern whenever event occurs condi
Page 133 and 134:
If the brake force is above 80% for
Page 135 and 136:
Pattern S3: Failure shall not be ca
Page 137 and 138:
Pattern S9: failureCondition failur
Page 139 and 140:
Pattern R2: Event occurs each perio
Page 141 and 142:
idle e1 |clk:=0 e2 && (l
Page 143 and 144:
The function : allocates a singl
Page 145 and 146:
Examplees of clocks: • Run: {c=0@
Page 147 and 148:
Architecture Modeling 1. For σ ∈
Page 149 and 150:
Architecture Modeling Traces accord
Page 151 and 152:
Architecture Modeling Definition 6.
Page 153 and 154:
Architecture Modeling the one given
Page 155 and 156:
Architecture Modeling Decomposition
Page 157 and 158:
Bibliography [1] ARINC 653 - Avioni
Page 159 and 160:
Architecture Modeling [26] Holger G
show all

Architecture Modeling - SPES 2020

Create successful ePaper yourself

Delete template?

Save as template?