2017 IEEE International Conference on Software Architecture Workshops (ICSAW) 2017
DOI: 10.1109/icsaw.2017.54
|View full text |Cite
|
Sign up to set email alerts
|

Knowledge-Driven Architecture Composition: Case-Based Formalization of Integration Knowledge to Enable Automated Component Coupling

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1
1
1

Citation Types

0
5
0

Year Published

2018
2018
2022
2022

Publication Types

Select...
3
2
2

Relationship

1
6

Authors

Journals

citations
Cited by 12 publications
(5 citation statements)
references
References 17 publications
0
5
0
Order By: Relevance
“…id Switch2Light namespace de.ma.mappings description "A mapping which connects a switch to a light so that the light is toggled by the switch " infoModelReferences { using de.ma.informationmodels.Switch;1.0.0 as Switch using de.ma.informationmodels.Light;1.0.0 as Light } mappingBlocks { from Switch to Light: de.ma.mappingblocks. Switch2Dimmer } Listing 9: Switch to Light Mapping Limitations: Although the presented case study does not seem to improve the overall integration process in the given example a lot, the proposed language is a first technical step towards facilitating the presented, bottom-up integration methods based on incomplete integration knowledge [10] [13]. This means that with a high number of already integrated function blocks the described integration process can be automated based use-case specific semantics.…”
Section: Fig 4: Inmatch Prototype Utilized As Tool-support For Mappimentioning
confidence: 97%
See 1 more Smart Citation
“…id Switch2Light namespace de.ma.mappings description "A mapping which connects a switch to a light so that the light is toggled by the switch " infoModelReferences { using de.ma.informationmodels.Switch;1.0.0 as Switch using de.ma.informationmodels.Light;1.0.0 as Light } mappingBlocks { from Switch to Light: de.ma.mappingblocks. Switch2Dimmer } Listing 9: Switch to Light Mapping Limitations: Although the presented case study does not seem to improve the overall integration process in the given example a lot, the proposed language is a first technical step towards facilitating the presented, bottom-up integration methods based on incomplete integration knowledge [10] [13]. This means that with a high number of already integrated function blocks the described integration process can be automated based use-case specific semantics.…”
Section: Fig 4: Inmatch Prototype Utilized As Tool-support For Mappimentioning
confidence: 97%
“…Need: As a consequence, integration knowledge between provided and required interfaces is only persistent within software adapters and is currently not being captured, shared and reused [9]. Therefore, a novel engineering method called "Knowledge-driven Architecture Composition" (KDAC) for bottom-up IoT device integration was introduced [10]. The novelty of this method lies within the incremental formalization of semantic integration knowledge for IoT devices in addition to programming iterative software adapters.…”
Section: Introductionmentioning
confidence: 99%
“…Burzlaff and Bartelt [59] focus on the IoT's impact on production processes. Specifically, languages with normalized semantics may improve automation in the component integration process, thereby simplifying manual integration (e.g., a 'plug and play' approach).…”
Section: Yellow Clustermentioning
confidence: 99%
“…The dynamic view of our reference architecture is influenced by the applied integration method. Here, we use the "Knowledge-driven Architecture Composition" (KDAC) approach [17], [19]). The KDAC approach can be described as an interface integration method where integration knowledge is formalized per usecase.…”
Section: Dynamic Viewmentioning
confidence: 99%