Design rule spaces: a new form of architecture insight

Xiao, Lu; Cai, Yuanfang; Kazman, Rick

doi:10.1145/2568225.2568241

Cited by 85 publications

(84 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Xiao et al [1] recently proposed DRSpaces as a method to gain architectural insight. They used a tool called Titan to parse source code for DRs and attribute files to DRSpaces.…”

Section: Related Workmentioning

confidence: 99%

“…Xiao et al [1] observed that DRSpaces were stable over time and that buggy files within them are architecturally connected. They also observed lots of files changed together despite not being structurally related and suggested that these files may have "shared secrets" that cannot be determined from structure.…”

Section: Related Workmentioning

confidence: 99%

“…Their concept was used by Xiao et al [1] to propose DRSpaces, which are graphs that represent overlapping collections of programs within an architecture. Each space must have one or more leading classes that relate to DRs.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

An Evaluation of Design Rule Spaces as Risk Containers

Leigh

Wermelinger

Zisman

2016

2016 13th Working IEEE/IFIP Conference on Software Architecture (WICSA)

View full text Add to dashboard Cite

Abstract-It is well understood that software development can be a risky enterprise and industrial projects often overrun budget and schedule. Effective risk management is, therefore, vital for a successful project outcome. Design Rule Spaces (DRSpaces) have been used by other researchers to understand why implemented software is error-prone [1, 2]. This industrial case study evaluates whether such spaces are durable, meaningful, and isolating risk containers. DRSpaces were created from UML class diagrams of architectural design artefacts. In our study, object orientated metrics were calculated from the UML diagrams, and compared to the error-proneness of the DRSpace implementation, to determine whether architectural coupling translated into implementation difficulties. A correlation between architectural coupling and error-proneness of DRSpaces was observed in the case study. Software developers were asked to identify DRSpaces they found difficult to implement, in order to understand which factors, other than architectural coupling, were also important. The qualitative results show agreement between the code areas developers found difficult to implement and the error-prone DRSpaces. However, the results also show that architectural coupling is just one risk factor of many. The case study suggests that architectural DRSpaces can be used to facilitate a targeted risk review prior to implementation and manage risk.

show abstract

“…Xiao et al [1] recently proposed DRSpaces as a method to gain architectural insight. They used a tool called Titan to parse source code for DRs and attribute files to DRSpaces.…”

Section: Related Workmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

An Evaluation of Design Rule Spaces as Risk Containers

Leigh

Wermelinger

Zisman

2016

2016 13th Working IEEE/IFIP Conference on Software Architecture (WICSA)

View full text Add to dashboard Cite

show abstract

“…2) A toolcalled Titan [28] will be used to identify architectural structures that are potentially implicated in the targeted vulnerabilities, to locate the design flaws within these structures, and to identify the specific files within these structures that have the highest probability of experiencing a security bug. The Titan tool chain takes, as input, a project's source code, its revision history (from a configuration management tool such as SVN), and its issues (from an issue-tracking system such as Jira) and, based on this input, clusters the architecture into a set of overlapping DRSpaces.…”

Section: Developing Countermeasuresmentioning

confidence: 99%

Can Cybersecurity Be Proactive? A Big Data Approach and Challenges

Chen

Kazman

Monarch

et al. 2017

Proceedings of the 50th Hawaii International Conference on System Sciences (2017)

Self Cite

View full text Add to dashboard Cite

The cybersecurity community typically reacts to attacks after they occur. Being reactive is costly and can be fatal where attacks threaten lives, important data, or mission success. But can cybersecurity be done proactively? Our research capitalizes on the Germination Period-the time lag between hacker communities discussing software flaw types and flaws actually being exploited-where proactive measures can be taken. We argue for a novel proactive approach, utilizing big data, for (I) identifying potential attacks before they come to fruition; and based on this identification, (II) developing preventive countermeasures. The big data approach resulted in our vision of the Proactive Cybersecurity System (PCS), a layered, modular service platform that applies big data collection and processing tools to a wide variety of unstructured data sources to predict vulnerabilities and develop countermeasures. Our exploratory study is the first to show the promise of this novel proactive approach and illuminates challenges that need to be addressed.

show abstract

“…Wilkie and Kitchenham (2000) and Sosa et al (2013) show that higher levels of component coupling are associated with more frequent changes and higher defect levels. Cai et al (2013) and Xiao, Cai and Kazman (2014) show that defects often cluster within groups of components that depend on the same higher-level component. Finally, MacCormack et al (2012) show that the mean level of coupling varies widely across similar systems, the differences being explained, in part, by differences in the way system development is organized.…”

Section: Design Structure Matrices (Dsms)mentioning

confidence: 99%

Hidden Structure: Using Network Methods to Map Product Architecture

Baldwin¹,

MacCormack²,

Rusnak

2013

SSRN Journal

View full text Add to dashboard Cite

In this paper, we describe an operational methodology for characterising the architecture of complex technical systems and demonstrate its application to a large sample of software releases. Our methodology is based upon directed network graphs, which allows us to identify all of the direct and indirect linkages between the components in a system. We use this approach to define three fundamental architectural patterns, which we label core-periphery, multi-core, and hierarchical. Applying our methodology to a sample of 1,286 software releases from 17 applications, we find that the majority of releases possess a "core-periphery" structure. This architecture is characterized by a single dominant cyclic group of components (the "Core") that is large relative to the system as a whole as well as to other cyclic groups in the system. We show that the size of the Core varies widely, even for systems that perform the same function. These differences appear to be associated with different models of development-open, distributed organizations develop systems with smaller Cores, while closed, co-located organizations develop systems with larger Cores. Our findings establish some "stylized facts" about the fine-grained structure of large, real-world technical systems, serving as a point of departure for future empirical work.

show abstract

Design rule spaces: a new form of architecture insight

Cited by 85 publications

References 29 publications

An Evaluation of Design Rule Spaces as Risk Containers

An Evaluation of Design Rule Spaces as Risk Containers

Can Cybersecurity Be Proactive? A Big Data Approach and Challenges

Hidden Structure: Using Network Methods to Map Product Architecture

Contact Info

Product

Resources

About