Search

IoT devices are diverse in their characteristics and made by many vendors, hence the inter-operation among them is difficult. Especially, end users can't make their own programs by do-it-yourselves. IFTTT and Zapier platforms are designed to help end users to make them inter-operable easily and prevail in these days. Their approach is categorized into a Trigger-Action-Programming, in which trigger conditions and actions are already made by professional programmers of several IoT vendors and end users composite them into their own applications easily. But, their drawback is that the composition can be made at once in the first level, hence end users can't make more complicated applications. Our approach is based on a dataflow programming paradigm which resembles the TAP in that the internal actions are triggered when all the inputs of a node are prepared. In our approach, a composition of some atomic nodes becomes another atomic node, so the composition would continue iteratively. This feature is so generous that several visual programming languages like LabView are relied on the approach for various fields. We propose the overall architecture of our system and explain them. We also present Internet of Things examples of our approach, which shows that atomic dataflow objects can be associated to produce composite dataflow objects. And they are also composited to make more complex applications iteratively. We compare IFTTT, Zapier, and our approach qualitatively and show that end users can make more diverse and flexible applications in our approach. [ABSTRACT FROM AUTHOR]

Although numerous empirical studies have been conducted to measure the fault detection capability of software analysis methods, few studies have been conducted using programs of similar size and characteristics. Therefore, it is difficult to derive meaningful conclusions on the relative detection ability and cost-effectiveness of various fault detection methods. In order to compare fault detection capability objectively, experiments must be conducted using the same set of programs to evaluate all methods and must involve participants who possess comparable levels of technical expertise. One such experiment was ‘Conflict1’, which compared voting, a testing method, self-checks, code reading by stepwise refinement and data-flow analysis methods on eight versions of a battle simulation program. Since an inspection method was not included in the comparison, the authors conducted a follow-up experiment ‘Conflict2’, in which five of the eight versions from Conflict1 were subjected to Fagan inspection. Conflict2 examined not only the number and types of faults detected by each method, but also the cost-effectiveness of each method, by comparing the average amount of effort expended in detecting faults. The primary findings of the Conflict2 experiment are the following. First, voting detected the largest number of faults, followed by the testing method, Fagan inspection, self-checks, code reading and data-flow analysis. Second, the voting, testing and inspection methods were largely complementary to each other in the types of faults detected. Third, inspection was far more cost-effective than the testing method studied. Copyright © 2002 John Wiley & Sons, Ltd. [ABSTRACT FROM AUTHOR]

Focuses on a study which proposed an efficient delay-constrained multicast routing algorithm computing low cost delay constrained multicast trees with small algorithm complexity. Uses of the algorithm; Performance studies; Conclusions.