More Like this

1. Constructing a Shared Infrastructure for Software Architecture Analysis and Maintenance

   Garcia, Joshua; Mirakhorli, Mehdi; Xiao, Lu; Zhao, Yutong; Mujhid, Ibrahim; Pham, Khoi; Okutan, Ahmet; Malek, Sam; Kazman, Rick; Cai, Yuanfang; et al (March 2021, 2021 IEEE 18th International Conference on Software Architecture (ICSA))

   Jansen, Anton; Lewis, Grace A. (Ed.)

   Over the past three decades software engineering researchers have produced a wide range of techniques and tools for understanding the architectures of large, complex systems. However, these have tended to be one-off research projects, and their idiosyncratic natures have hampered research collaboration, extension and combination of the tools, and technology transfer. The area of software architecture is rich with disjoint research and development infrastructures, and datasets that are either proprietary or captured in proprietary formats. This paper describes a concerted effort to reverse these trends. We have designed and implemented a flexible and extensible infrastructure (SAIN) with the goal of sharing, replicating, and advancing software architecture research. We have demonstrated that SAIN is capable of incorporating the constituent tools extracted from three independently developed, large, long-lived software architecture research environments. We discuss SAIN’s ambitious goals, the challenges we have faced in achieving those goals, the key decisions made in SAIN’s design and implementation, the lessons learned from our experience to date, and our ongoing and future work. 

   more » « less
2. Reproducible Software Environment: a tool enabling computational reproducibility in geospace sciences and facilitating collaboration

   https://doi.org/10.1051/swsc/2020011  

   Bhatt, Asti; Valentic, Todd; Reimer, Ashton; Lamarche, Leslie; Reyes, Pablo; Cosgrove, Russell (January 2020, Journal of Space Weather and Space Climate)

   The Reproducible Software Environment (Resen) is an open-source software tool enabling computationally reproducible scientific results in the geospace science community. Resen was developed as part of a larger project called the Integrated Geoscience Observatory (InGeO), which aims to help geospace researchers bring together diverse datasets from disparate instruments and data repositories, with software tools contributed by instrument providers and community members. The main goals of InGeO are to remove barriers in accessing, processing, and visualizing geospatially resolved data from multiple sources using methodologies and tools that are reproducible. The architecture of Resen combines two mainstream open source software tools, Docker and JupyterHub, to produce a software environment that not only facilitates computationally reproducible research results, but also facilitates effective collaboration among researchers. In this technical paper, we discuss some challenges for performing reproducible science and a potential solution via Resen, which is demonstrated using a case study of a geospace event. Finally we discuss how the usage of mainstream, open-source technologies seems to provide a sustainable path towards enabling reproducible science compared to proprietary and closed-source software. 

   more » « less
3. Software development data for architecture analysis: expectations, reality, and future directions

   https://doi.org/10.1145/3377813.3381357  

   Cai, Yuanfang; Kazman, Rick (June 2020, Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: Software Engineering in Practice)

   Recently we have worked with a dozen industrial collaborators to pinpoint and quantify architecture debts, from multi-national corporations to startup companies. Our technology leverages a wide range of project data, from source file dependencies to issue records, and we interacted with projects of various sizes and characteristics. Crossing the border between research and practice, we have observed significant gaps in terms of data availability and quality among projects of different kinds. Compared with successful open source projects, data from proprietary projects are rarely complete or well-organized. Consequently, not all projects can benefit from all the features and analyses we provide. This, in turn, made them realize they needed to improve their development processes. In this talk, we categorize the commonly observed differences between open source and proprietary project data, analyze the reasons for such differences, and propose suggestions to minimize the gaps, to facilitate advances to both software research and practice. 

   more » « less
4. PyRTL in Early Undergraduate Research

   https://doi.org/10.1145/3338698.3338890  

   Mirza, Diba; Dangwal, Deeksha; Sherwood, Timothy (July 2019, Workshop on Computer Architecture Education (WCAE’19))

   Undergraduate research experiences are a promising way to broaden participation in computer architecture research and have been shown to improve student learning, engagement, and retention. These outcomes can be more profound and lasting if students experience research early. However, there are many barriers to early research in computer architecture some of which include the gap between pedagogy and research, the lower emphasis on hardware design compared to software in first-year courses, and the lack of online resources. We propose lowering these barriers through a methodical approach by involving undergraduates in early research and by creating freely available and innovative educational tools for designing hardware. We present the experience of a team of undergraduate students with research over one academic year using a Python hardware description language, PyRTL. PyRTL was developed to enable early entry into digital design. Its overarching goals are simplicity, usabil- ity, clarity, and extensibility, a stark contrast to traditional languages like Verilog and VHDL that have a steep learning curve. Instead of introducing traditional languages early in the undergraduate curriculum, PyRTL takes the opposite approach, which is to build on what students already know well: a popular programming language (Python), software design patterns, and software engineering principles. The students conducted their research in the context of the Early Research Scholars Program (ERSP), a program designed to expand access to research among women and underrepresented minority students in their second year through a well-designed support structure. 

   more » « less
5. Exploring the Architectural Impact of Possible Dependencies in Python Software

   https://doi.org/10.1145/3324884.3416619  

   Jin, Wuxia; Cai, Yuanfang; Kazman, Rick; Zhang, Gang; Zheng, Qinghua; Liu, Ting (December 2020, 2020 35th IEEE/ACM International Conference on Automated Software Engineering)

   null (Ed.)

   Dependencies among software entities are the basis for many software analytic research and architecture analysis tools. Dynamically typed languages, such as Python, JavaScript and Ruby, tolerate the lack of explicit type references, making certain syntactic dependencies indiscernible in source code. We call these possible dependencies, in contrast with the explicit dependencies that are directly referenced in source code. Type inference techniques have been widely studied and applied, but existing architecture analytic research and tools have not taken possible dependencies into consideration. The fundamental question is, to what extent will these missing possible dependencies impact the architecture analysis? To answer this question , we conducted an empirical study with 105 Python projects, using type inference techniques to manifest possible dependencies. Our study revealed that the architectural impact of possible dependencies is substantial-higher than that of explicit dependencies: (1) file-level possible dependencies account for at least 27.93% of all file-level dependencies, and create different dependency structures than that of explicit dependencies only, with an average difference of 30.71%; (2) adding possible dependencies significantly improves the precision (0.52%∼14.18%), recall(31.73%∼39.12%), and F1 scores (22.13%∼32.09%) of capturing co-change relations; (3) on average, a file involved in possible dependencies influences 28% more files and 42% more dependencies within architectural sub-spaces than a file involved in just explicit dependencies; (4) on average, a file involved in possible dependencies consumes 32% more maintenance effort. Consequently, maintainability scores reported by existing tools make a system written in these dynamic languages appear to be better modularized than it actually is. This evidence strongly * with the Ministry suggests that possible dependencies have a more significant impact than explicit dependencies on architecture quality, that architecture analysis and tools should assess and even emphasize the architectural impact of possible dependencies due to dynamic typing. 

   more » « less