Architecture Modeling - SPES 2020
Architecture Modeling - SPES 2020
Architecture Modeling - SPES 2020
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Architecture</strong> <strong>Modeling</strong><br />
The semantics of HRC is defined such that behavior is always part of a RichComponent or<br />
specializations thereof. The connection of ports (syntactically described in Section 3.3.2.2) is<br />
semantically interpreted as the identity of the behavior observable at the connected ports. So if<br />
in the example sketched in Figure 3.8 the ports p1 and p2 would have been directly connected,<br />
then any event or data occuring at port p1 is at the same time observed at port p2. Thus, in<br />
order to be able to specify assumptions about communication latencies from a real-time aspect,<br />
one needs at least conceptionally a LogicalComponent. For that component contracts can<br />
again be used for the specification of the different aspects of the logical communication, e. g.<br />
expected latencies or failure hypothesis. Though conceptionally logical communcation has to<br />
be represented as a RichComponent, the user-representation can be different. For example<br />
a UML-profile based on the architecture meta-model, can introduce a stereotype, which is<br />
applicable to uml::Connector and is mapped to the concept of LogicalComponent.<br />
3.2.4 Technical Perspective<br />
In the technical perspective the electric/electronic architecture of the system is specified, which<br />
comprises mechanical and hydraulic components controlled by a network of control units, that<br />
the logical components shall be allocated to. The electronic control units may be softwareprogrammable<br />
hardware components or application specific integrated circuits (ASICs). Mechanical<br />
components are for example cams, shafts, switches and relays. Hydraulic components<br />
include for example valves and cylinders.<br />
The concepts provided for describing a view corresponding to the technical perspective are<br />
more specialized than those provided for modeling an operational, functional or logical perspective.<br />
That is because it is intended to apply dedicated analysis techniques for checking<br />
satisfaction of contracts (cf. Section 4.3) based on models of the technical perspective. In Section<br />
5.1.3.5 an example is presented how the concepts described in this section can be used to<br />
model a technical view.<br />
+part 0..*<br />
RichComponentProperty<br />
«isOfType»<br />
+component 1<br />
+type<br />
1<br />
RichComponent<br />
TechnicalComponent<br />
+aspect<br />
SystemArtefact Aspect<br />
Requirement<br />
+ rationale: String [0..*]<br />
SystemRequirement<br />
0..*<br />
+stakeholder<br />
0..*<br />
Stakeholder<br />
Figure 3.9: Meta-model integration of the concepts of TechnicalComponents<br />
The architecture meta-model provides concepts to specify the technical perspective of a system<br />
by means of TechnicalComponents (see Figure 3.9). While we do not provide specialized<br />
concepts in the meta-model for mechanical or hydraulic components, their aspects however<br />
can still be specified by means of contracts. That allows a characterization of their dynamics<br />
and to assess whether requirements on functions are fulfilled by the mechanical or hydraulic<br />
components and the electronic components controlling them.<br />
In <strong>SPES</strong> the focus is on software-intensive systems. Therefore the meta-model incorporates<br />
specialized concepts to describe the resources of a network of electronic control units, which<br />
21/ 156