Modularization of a Large-Scale Business Application: A Case Study

Sarkar, Santonu; Ramachandran, S.; Kumar, Gireesh; Iyengar, M.K.; Rangarajan, K.; Sivagnanam, S.

doi:10.1109/ms.2009.42

Cited by 54 publications

(42 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…This has largely concentrated on using metrics such as coupling, number of defects, number of dependencies, etc. (MacCormack and Sturtevant 2016;Sarkar et al 2009). However, these metrics are not really visible to customers.…”

Section: Desired Features Of Ac and Current Tool Supportmentioning

confidence: 99%

“…While this finding is, to some degree, generic to all software reengineering efforts, only two such studies in architecture consistency have been performed (Knodel 2010;Sarkar et al 2009) and, because these studies are (by necessity) case studies, they have low external validity. Additional focus should be on more empirical case studies that serve to broaden the evidence base with respect to the tangible effects of increased architecture consistency.…”

Section: Desired Features Of Ac and Current Tool Supportmentioning

confidence: 99%

See 1 more Smart Citation

Architecture consistency: State of the practice, challenges and requirements

Alí

Baker

O’Crowley³

et al. 2017

Empir Software Eng

View full text Add to dashboard Cite

Architecture Consistency (AC) aims to align implemented systems with their intended architectures. Several AC approaches and tools have been proposed and empirically evaluated, suggesting favourable results. In this paper, we empirically examine the state of practice with respect to Architecture Consistency, through interviews with nineteen experienced software engineers. Our goal is to identify 1) any practises that the companies these architects work for, currently undertake to achieve AC; 2) any barriers to undertaking explicit AC approaches in these companies; 3) software development situations where practitioners perceive AC approaches would be useful, and 4) AC tool needs, as perceived by practitioners. We also assess current commercial AC tool offerings in terms of these perceived needs. The study reveals that many practitioners apply informal AC approaches as there are barriers for adopting more formal and Empir Software Eng (2018) 23:224-258 DOI 10.1007 The original version of this article was revised due to a retrospective Open Access order. Karlstad University, Karlstad, Sweden explicit approaches. These barriers are: 1) Difficulty in quantifying architectural inconsistency effects, and thus justifying the allocation of resources to fix them to senior management, 2) The near invisibility of architectural inconsistency to customers, 3) Practitioners' reluctance towards fixing architectural inconsistencies, and 4) Practitioners perception that huge effort is required to map the system to the architecture when using more formal AC approaches and tools. Practitioners still believe that AC would be useful in supporting several of the software development activities such as auditing, evolution and ensuring quality attributes. After reviewing several commercial tools, we posit that AC tool vendors need to work on their ability to support analysis of systems made up of different technologies, that AC tools need to enhance their capabilities with respect to artefacts such as services and meta-data, and to focus more on non-maintainability architectural concerns.

show abstract

Section: Desired Features Of Ac and Current Tool Supportmentioning

confidence: 99%

Section: Desired Features Of Ac and Current Tool Supportmentioning

confidence: 99%

Architecture consistency: State of the practice, challenges and requirements

Alí

Baker

O’Crowley³

et al. 2017

Empir Software Eng

View full text Add to dashboard Cite

show abstract

“…Traditionally, DSM used a "X" to indicate a dependency between two modules. However, Sangal et al in the LDM tool represent in the cells the number of references between two modules [SJSJ05]. In this tool, it is possible to distinguish the dependencies using design rules, which have two forms: A can−use B and A cannot−use B, indicating that module A can (or cannot) depend on module B. DSM has a more scalable output than the output generated by reflexion models based on graphs, since a matrix usually scales better than a graph.…”

Section: Architectural Conformance and Visualizationmentioning

confidence: 99%

“…Although we focus on architecture conformance checking process, we complement our textual report of violations by providing two high-level architectural models to better visualize the identified violations: (i) Reflexion Model in a subtle adaptation of the one originally proposed by Murphy et al [MNS95] and (ii) Dependency Structure Matrix (DSM) in a subtle adaptation of the one proposed by Sangal et al [SJSJ05].…”

Section: Architectural Visualizationmentioning

confidence: 99%

Architecture Conformance Checking in Dynamically Typed Languages.

Miranda¹,

Rodrigues²,

Valente³

et al. 2016

JOT

View full text Add to dashboard Cite

Architectural erosion is a recurrent problem faced by software architects, which might be even more severe in systems implemented in dynamically typed languages. The reasons are twofold: (i) some features provided by such languages make developers more propitious to break the planned architecture (e.g., dynamic invocations and buildings), and (ii) the developers' community lacks tool support for monitoring the implemented architecture. To address these shortcomings, this paper presents an architectural conformance and visualization approach based on static code analysis techniques and on a lightweight type propagation heuristic. The central idea is to provide the developers' community with means to control the architectural erosion process by reporting architectural violations and visualizing them in high-level architectural models, such as reflexion models and DSMs. This paper also describes a tool-called ArchRuby-that implements our approach. We evaluate our solution in three real-world systems identifying 48 architectural violations of which the developers had no prior knowledge. We also measure the effectiveness of our type propagation heuristic reporting that (i) the number of analyzed types raises 5% on the average and (ii) certain violations are only detected due to our heuristic.

show abstract

“…Essentially, this heuristic targets a common pattern of divergences: the use of frameworks and APIs by unauthorized components [6], [13]. For example, enterprise software architectures commonly define that object-relational mapping frameworks must only be accessed by components in the persistence layer.…”

Section: A Heuristic #1mentioning

confidence: 99%

Heuristics for discovering architectural violations

Maffort¹,

Valente²,

Bigonha³

et al. 2013

2013 20th Working Conference on Reverse Engineering (WCRE)

View full text Add to dashboard Cite

Abstract-Software architecture conformance is a key software quality control activity that aims to reveal the progressive gap normally observed between concrete and planned software architectures. In this paper, we present ArchLint, a lightweight approach for architecture conformance based on a combination of static and historical source code analysis. For this purpose, ArchLint relies on four heuristics for detecting both absences and divergences in source code based architectures. We applied ArchLint in an industrial-strength system and as a result we detected 119 architectural violations, with an overall precision of 46.7% and a recall of 96.2%, for divergences. We also evaluated ArchLint with four open-source systems, used in an independent study on reflexion models. In this second study, ArchLint achieved precision results ranging from 57.1% to 89.4%.

show abstract

Modularization of a Large-Scale Business Application: A Case Study

Cited by 54 publications

References 6 publications

Architecture consistency: State of the practice, challenges and requirements

Architecture consistency: State of the practice, challenges and requirements

Architecture Conformance Checking in Dynamically Typed Languages.

Heuristics for discovering architectural violations

Contact Info

Product

Resources

About