Architecture Modeling - SPES 2020

More documents

Recommendations

Info

Architecture Modeling F1 whenever event occurs event [does not] occur[s] [during interval] Phrases in square brackets are optional, bold elements are static keywords of the pattern, and elements printed in italics represent attributes that have to be instantiated by the requirements engineer. So a valid instance of the pattern F1 is: whenever p1.f1 occurs p2.f1 occurs during [8ms,10ms] The RSL provides patterns that have been categorized according to aspects they address. Despite that categorization they may also be used for the specification of other aspects. For example a Probability Pattern can be useful when specifying a failure hypothesis of components, which clearly is a Safety aspect. While the concept Contract (resp. SystemRequirement) and BlockOccurrence is directly expressed in the meta-model, this is not true for the syntax and semantics of RSL patterns. Figure 3.27 shows that an Assertion referenced in any of the three roles strongAssumption, weakAssumption or guarantee is a specialization of TextuallyRepresentedElement. The attribute textualRepresentation contains that text. Multiple instances of RSL patterns would then be entered in that text field. Thus, a set of pattern instances specifies a FormalAssertion of a contract, i. e. its strong and weak assumptions and its guarantee. See Section 6.1.1 for a formal definition of RSL. 3.3.2 Hierarchy and Composition Once components are defined by means of the RichComponent concept and their syntactical interface has been specified by Ports, components can be instantiated in the context of other components as parts forming a composition of components. That composition is again a component, whose behavior is given by the behavior of its constituting parts. 3.3.2.1 Hierarchy The instantiation of components in the context of other components is represented in the meta-model by the RichComponentProperty concept (see Figure 3.29). A component with its ports and contained behavior is referenced in the role of type by a RichComponentProperty. That RichComponentProperty is in turn aggregated by another RichComponent as one of its parts. The behavioral specifications characterized by contracts that are linked to a RichComponent and corresponding realizations are also instantiated in any RichComponentProperty typed by the RichComponent. It is allowed to have multiple instances of the same component in the context of a composition. As this concept can be applied recursively, it allows to construct deeply nested hierarchies of components. Note that this is consistent with type/part concepts found in e. g. UML [41] and SysML [39]. 3.3.2.2 Composition When components are used as parts in another component, they have to be interconnected by binding the flows and services contained in the ports. The concept of Interconnection is owned by the same component which also owns the parts. An interconnection is either a delegation connection or an assembly connection. The former links the interaction points of the outer component, i. e. the composition, with interaction points of its constituting parts. So the interaction points need to have the same direction. Assembly connections link the interaction points of parts of a composition to each other. So their directions must be reversed. 40/ 156
MultiplicityElement +part 0..* RichComponentProperty +component 1 +type 1 Architecture Modeling «isOfType» RichComponent +component 1 +component 0..1 Port + isConjugated: Boolean +attribute +port Figure 3.29: Meta-model integration of hierarchy concepts 0..* 0..* Variable In the meta-model there is no distinction between the two kinds because it can be deduced from the context the kind of the connection. Both kinds of connections between Ports is captured by the concept Connector (cf. Figure 3.31). In most other languages (also UML) the interconnection of components in compositions is done by binding of ports. Since the architecture meta-model allows to declare multiple InteractionPoints per Port the concept FlowBinding, resp. ServiceBinding, allows to only bind a subset of the flows or services defining a port. Thus, linking Ports by means of Connectors is semantically just a short-cut to bind all interaction points of the Ports. Note that a PortSpecification may either contain multiple Flows or multiple Services, but not both. Directions are defined by the InteractionPoints themselves. in, out or bidirectional are possible directions of Flows and provided or required are possible directions of Services. Ports typed by a PortSpecification carry an attribute isConjugated. If this attribute is set to true the directions of all InteractionPoints in the corresponding PortSpecification are treated as if reversed. By default the value of the attribute is false. This facility allows to specify peer ports, i. e. with the same flows or services, but complementary directions. CompC part1:CompA pA pB part2:CompB (a) assembly connection pC CompC pA part1:CompA (b) delegation connection Figure 3.30: Example for assembly- and delegation connections FlowBinding and compatibility of Flows There are two case distinctions for binding Flows by means of FlowBinding. If flows of different ports shall be bound establishing an assembly connection like illustrated in Figure 3.30a, then the directions of both flows need to be complementary (in for out, out for in, bidirectional for bidirectional). In the case of delegation connections like depicted in Figure 3.30b, the directions must be the same. Further the flows must be compatible. Two flows are compatible if they associate the same DataType and their kind is the same. 41/ 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 and 40: Architecture Modeling Shape that de
Page 41 and 42: Architecture Modeling Conjugation o
Page 43: RichComponent Architecture Modeling
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 89 and 90: Architecture Modeling However this
Page 91 and 92: Architecture Modeling The considera
Page 95 and 96:
Architecture Modeling Figure 5.21:
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:
Architecture Modeling Figure 5.24:
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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?