Fig 1 - uploaded by Indika Perera
Content may be subject to copyright.
A layered software architecture with product perspectives 

A layered software architecture with product perspectives 

Source publication
Conference Paper
Full-text available
Many software companies use the popular method of layered architecture to develop their software products resulting in code to be more generic. This generalization introduces a lot of unnecessary elements which make the system architecture to be heavy and less elegant. To overcome this challenge, a concept of feature oriented software development (...

Context in source publication

Context 1
... most of the product-based software development organizations, there is a hierarchical code structure, which has several layers included. One layer is built on top of another by using the capabilities provided by the previous or below layer as per in Fig. 1. This hierarchical model helps the developers to use the abstractions and lower level code segments to customize their own code. Many organizations use this method in order to reuse common software components, which later could be customized at higher levels. Hence the lower level coding must be done very carefully, because if there is ...

Similar publications

Conference Paper
Full-text available
Domain Specific Languages have many applications. They provide a way to abstract domain concepts and express these concepts in a more expressive way when compared with general-purpose languages. Recently the Object Management Group has released the beta version of its Interaction Flow Modeling Language standard to model user interaction in applicat...

Citations

... To summarize our findings in terms of principles, we have adopted the guidelines of Systematic Literature Reviews [169] for finding and aggregating the data found in the documents included in the review (i.e., primary studies). The presented principles come from the following 83 primary studies: [2,8,13,15,16,18,19,20,21,22,24,25,26,27,28,30,31,33,37,39,40,41,42,43,47,57,60,63,64,71,72,74,86,89,94,95,96,98,100,101,102,103,104,105,106,107,109,110,111,113,114,115,116,117,118,121,123,124,125,126,127,128,129,130,131,133,134,135,136,137,138,139,140,141,142,144,145,151,152,153,156,162,171]. These studies include: 1) peer-reviewed papers that we retrieved either from well-known databases or from the manual search, and that we retained because they explicitly discuss some layering principles; 2) technical reports; 3) and a couple of software engineering books focusing on the layered pattern. ...
... This is related to the "ideal layering" property that states (e.g., [8,26,33,64,107,110,117,121,123,124,127,135,141,144]): ...
Preprint
Full-text available
Architectural reconstruction is a reverse engineering activity aiming at recovering the missing decisions on a system. It can help identify the components, within a legacy software application, according to the application's architectural pattern. It is useful to identify architectural technical debt. We are interested in identifying layers within a layered application since the layered pattern is one of the most used patterns to structure large systems. Earlier component reconstruction work focusing on that pattern relied on generic component identification criteria, such as cohesion and coupling. Recent work has identified architectural-pattern specific criteria to identify components within that pattern. However, the architectural-pattern specific criteria that the layered pattern embodies are loosely defined. In this paper, we present a first systematic literature review (SLR) of the literature aiming at inventorying such criteria for layers within legacy applications and grouping them under four principles that embody the fundamental design principles underlying the architectural pattern. We identify six such criteria in the form of design rules. We also perform a second systematic literature review to synthesize the literature on software architecture reconstruction in the light of these criteria. We report those principles, the rules they encompass, their representation, and their usage in software architecture reconstruction .