Figure 4 - uploaded by Camilo Castellanos
Content may be subject to copyright.
Component diagrams of NMAC Use Cases

Component diagrams of NMAC Use Cases

Source publication
Conference Paper
Full-text available
Big data analytics (BDA) applications use advanced analysis algorithms to extract valuable insights from large, fast, and heterogeneous data sources. These complex BDA applications require software design, development, and deployment strategies to deal with volume, velocity, and variety (3vs) while sustaining expected performance levels. BDA softwa...

Contexts in source publication

Context 1
... and micro-batch processing. In UC1, the application computes NMAC alerting levels over a large dataset at rest to offer a consolidated report on a wide range of time. On the other hand, UC2 application consumes ADS-B data every minute to generate near real-time alerts to support avionics operation. The software component diagrams are detailed in Fig. 4. These use cases represent BDA applications since they combine semi-structured, near real-time data sources and analytics models to predict alerting levels. In this experimentation, we have used ADS-B exchange API 5 , which generates live position data each minute. Live ADS-B position data are encoded in JSON responses which contain ...
Context 2
... UC1 (see Fig 4a), ADS-B data of eight-hours are stored in a distributed file system to be loaded by JSON Ingestor component. This reader component calls NMAC detector (Estimator) which classifies the alert level. ...
Context 3
... UC2 (see Fig 4b), the Ingestor component consumes data through REST service of ADS-B exchange's API. ADS-B data are pushed in a message queue to be consumed by the NMAC detector component which classifies NMAC alerts. ...

Citations

... For example, [SP38] extended the hybrid architecture analysis and design language to support the modeling of environmental uncertainties and performed quantitative evaluations against various performance queries. In [SP50], the authors proposed a domain specific model approach to design, deploy, and monitor the performance quality in applications related to big data analytics. [SP46] proposed a domainspecific language that allowed for the modeling of workload specifications of session-based systems for load testing and performance prediction. ...
... The papers that considered software model as input fully investigated this aspect in most cases; some of these studies ( [SP61]) proposed automated techniques based on model transformations to develop software model as a firstclass artifact in the software engineering process. The results here also provide evidence that data analytics have not yet been largely considered in this domain (9 papers, including [SP50], [SP41], and [SP21]). However, interest in data analytics has grown over time; thus, data analytics is expected to become a primary source of inputs in the next few years. ...
... The results obtained suggest an interest in a culture of quality, indicating that analysis and verification occur early in the CSE pipeline (as for testing in DevOps), making it easier to discover and fix defects with a collaborative approach to product improvement. In order to bring up the quality characteristics of software (architecture) and its continuous improvement (and rearchitecting), QoS analysis must become an integrated activity in the entire lifecycle of software development lifecycle, which requires continuous exposure of quality characteristics exposed to analysis ( [SP36] and [SP50]). As discussed earlier, most of the selected studies focused on a few of the performance properties. ...
Preprint
Full-text available
The continuous software engineering paradigm is gaining popularity in modern development practices, where the interleaving of design and runtime activities is induced by the continuous evolution of software systems. In this context, performance assessment is not easy, but recent studies have shown that architectural models evolving with the software can support this goal. In this paper, we present a mapping study aimed at classifying existing scientific contributions that deal with the architectural support for performance-targeted continuous software engineering. We have applied the systematic mapping methodology to an initial set of 215 potentially relevant papers and selected 66 primary studies that we have analyzed to characterize and classify the current state of research. This classification helps to focus on the main aspects that are being considered in this domain and, mostly, on the emerging findings and implications for future research