Realizing Model Transformation Chain interoperability

A single Model Transformation Chain (MTC) takes a high-level input model rooted in the problem domain and through one or more transformation steps produces a low-level output model rooted in the solution domain. To build a single “almighty” MTC that is in charge of every design, implementation and specific platform concern is a complex task. Instead, we can use several smaller MTCs that are easier to develop and maintain, because each MTC is independently developed focusing on a specific concern. However, the MTCs must interoperate to produce complete applications; this inherently creates dependencies between them, because each MTC generates a part of the final low-level model. In this paper, we propose an external and explicit mechanism to track dependencies between the MTCs (i.e., the MTCs are oblivious to the mechanism), which is used to automatically derive correspondence relationships between the final models generated by each MTC. The contribution of our mechanism is the reduction of complexity of building interoperable MTCs because the derived correspondences are resolved after the transformations execution, in the solution domain where the semantics of every concept is well-defined. The resolution process consists of (1) checking the consistency between the models, (2) producing communication bridges or (3) guiding the composition of the models. This paper presents three case studies to illustrate the derivation and resolution of correspondence relationships through the MTCs.     

Performing Problems on the Pavement: An Innovative Approach to Architectural Education in Post-Apartheid South Africa

In this article we interrogate the possibility and benefits of introducing alternative participatory pedagogies to architecture students at the University of KwaZulu-Natal, in order to mediate the gap between students' knowledge of the living environments they are expected to design and the authentic, lived realities of the inhabitants of those environments. Architecture students, assisted by applied theater students, devised participatory theater on the pavement of downtown Durban.¹1 1 Durban is a metropolitan city on the East Coast of South Africa.View all notes This approach encouraged in situ engagement between students and the typically marginalized inhabitants of that area. Moreover, these participatory performances served as a catalyst to disrupt some commonly held perceptions around the notion of “the expert” and provoked a possible reimagining of an architectural pedagogy that was responsive to the South African context.     

MMRUC3: A recommendation approach of move method refactoring using coupling,cohesion, and contextual similarity to enhance software design

Placement of methods is one of the most important design activities for any object‐oriented application in terms of coupling and cohesion. Due to method misplacement, the application becomes tightly coupled and loosely cohesive, reflecting inefficient design. Therefore, a feature envy code smell emerges from the application, as many methods use more features of other classes than its current class. Hence, development and maintenance time, cost, and effort are increased. To refactor the code smell and enhance the design quality, move method refactoring plays a significant role through grouping similar behaviors of methods. This is because the manual refactoring process is infeasible due to the necessity of huge time and most of the existing techniques consider only coupling‐based and/or cohesion‐based information of nonstatic entities (methods and attributes) for the recommendation. However, this article proposes an approach that uses contextual information, based on information retrieval techniques, along with dependency (coupling and cohesion)‐based information of the application for the recommendation. In addition, the approach incorporates both static and nonstatic entities in the recommendation process. For validation, the approach is applied on seven well‐known open source projects. The results of the experimental evaluation indicate that the proposed approach provides better results with an average precision of 18.91%, a recall of 69.91%, and an F‐measure of 29.77% than the JDeodorant tool (a widely used eclipse plugin for refactorings). Moreover, this article establishes several relationships between the accuracy of the approach and project standards and sizes.     

Synthesis and luminescent properties of ZrO2 and Dy3+-activated ZrO2 powders

Journal of Materials Science: Materials in Electronics - ZrO2 and ZrO2:Dy3+ (0.25, 0.5, 1, 1.5, 2, 2.5, and 3 mol%) powders are synthesized via solution combustion method. Structural,...     

Tucan

This paper presents Tucan, an approach to automatically create a virtual prototype (VP) and to support the analysis of VP testing results to validate time constraint requirements in real-time embedded systems. Virtual prototyping is a fast and reliable solution to facilitate system testing and time constraint validation. However, analyzing simulation results involves the visual inspection of timing diagrams, which is a time-consuming and complicated task. The complexity of the task grows depending on the number of signals present in a simulation; furthermore, their analysis is prone to errors due to the difficulty in identifying dependencies between the signals created by the system architecture. Our main contributions are: (1) the automatic generation of a high quality VP from a high level specification; (2) the specification of duration constraints, i.e., execution time of components that must be kept within an average time; and (3) duration requirement analysis based on predicted versus obtained behavior. We are able to predict system behavior by building a VP with a behavior model based on Time Petri Nets. We present the advantages of our method through a case study that illustrates the strength of Tucan in helping determine what variations at a specific component level allow the fulfillment of a set of time constraints.     

Cost comparison of running web applications in the cloud using monolithic,microservice, and AWS Lambda architectures

Large Internet companies like Amazon, Netflix, and LinkedIn are using the microservice architecture pattern to deploy large applications in the cloud as a set of small services that can be independently developed, tested, deployed, scaled, operated, and upgraded. However, aside from gaining agility, independent development, and scalability, how microservices affect the infrastructure costs is a major evaluation topic for companies adopting this pattern. This paper presents a cost comparison of a web application developed and deployed using the same scalable scenarios with three different approaches: 1) a monolithic architecture, 2) a microservice architecture operated by the cloud customer, and 3) a microservice architecture operated by the cloud provider. Test results show that microservices can help reduce infrastructure costs in comparison with standard monolithic architectures. Moreover, the use of services specifically designed to deploy and scale microservices, such as AWS Lambda, reduces infrastructure costs by 70% or more, and unlike microservices operated by cloud customers, these specialized services help to guarantee the same performance and response times as the number of users increases. Lastly, we also describe the challenges we faced while implementing and deploying microservice applications, and include a discussion on how to replicate the results on other cloud providers.