User Tools

Site Tools


an_architectural_revere_engineering_environment

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
an_architectural_revere_engineering_environment [2013/09/06 01:12]
yann
an_architectural_revere_engineering_environment [2019/10/06 20:37] (current)
Line 1: Line 1:
-====== ​Abstract ​======+====== ​Fiutem, R.; Antoniol, G.; Tonella, P. & Merlo, E. ART: An Architectural Revere Engineering Environment. Journal of Software Maintenance:​ Research and Practice, Wiley, 1999, 11, 339-364 ​====== 
 + 
 +===== Abstract ​=====
  
 When programmers perform maintenance tasks, program understanding is often required. One of the first activities in understanding a software system is identifying its subsystems and their relations, i.e., its software architecture. Since a large part of the effort is spent in creating a mental model of the system under study, tools can help maintainers in managing the evolution of legacy systems by showing them architectural information. When programmers perform maintenance tasks, program understanding is often required. One of the first activities in understanding a software system is identifying its subsystems and their relations, i.e., its software architecture. Since a large part of the effort is spent in creating a mental model of the system under study, tools can help maintainers in managing the evolution of legacy systems by showing them architectural information.
Line 9: Line 11:
 The results obtained show that cliché-based architectural recovery is feasible and the recovered information can be valuable support in reengineering and maintenance activities. The results obtained show that cliché-based architectural recovery is feasible and the recovered information can be valuable support in reengineering and maintenance activities.
  
-====== Comments ​====== +===== Comments ===== 
-//​Yann-Gaël Guéhéneuc,​ 2013/09/06//+ 
 +//​Yann-Gaël Guéhéneuc,​ 2013/08/30// 
 + 
 +In this paper, the authors introduce the problem of architecture recovery. They also recall the problem of identifying the connections among components. To recover components and their connections,​ they devise a hierarchical component model and adapt the taxonomy of inter-process connectors (IPC) first proposed by [[A Syntactic Theory of Software Architecture|Dean and Cordy]] to describe the possible connections among components. The considered types of connections are: 
 +    * **Shared-file**:​ a data repository shared by several components. This type of connections is nowadays probably realised through the use of a database. 
 +    * **Shared-memory**:​ a data repository in which data can be accessed randomly and that is shared by components. This type of connections recalls the "black board" architectural style. It assumes that the components have access to a shared memory and are, probably, on a same physical machine. Nowadays, such a use of shared memory probably translates into the use of a database or object store, such as [[https://​www.facebook.com/​note.php?​note_id=76191543919|Haystack]]. 
 +    * **Remote-procedure call**: a procedure call-like mechanism between components. Nowadays, most components interact through RPC, in particular with the advent of service-oriented architectures. **How components can know about one another and invoke their procedures are interesting questions. Also interesting questions pertain to the data passed back and forth among components and the use of this data by components.** 
 +    * **Stream**: a unidirectional or bidirectional ordered exchange of data between components. This is implemented through "​piping"​ between components. Nowadays, piping is heavily used in Unix-like systems but probably not so much in more "​general"​ component-based systems. 
 +    * **Message**:​ a data exchange among an arbitrary number of components. This type of connections also recalls the "black board" architecture but it may be about having a "​software bus" shared by components. 
 +    * **Invocation**:​ a connector that represents one component starting another component. This type of connection is probably implemented using ''​fork()''​ (C/C++) or ''​Runtime.exec()''​ (Java) or similar mechanisms. 
 + 
 +This set of types of connections can account for the interactions among components in simultaneous mixed-language software systems (SIMILAS) through the "​shared-file",​ "​shared-memory",​ and "​remote procedure call" connection types. It is also possible that SIMILAS use "​stream"​ and "​message"​ connection types. Yet, in the context of SIMILAS, it seems that some types of connections must be considered as one, e.g, "​shared-file"​ and "​shared-memory",​ while other should be introduced to account for possible specific behaviour: interactions through a shared virtual machine, through an invoked interpreters,​ through plug-ins, and so on.
  
-In this paper, the authors introduce the problem of architecture recovery. They also recall the problem of identifying the connections among components. To recover components and their connections,​ they devise a hierarchical component model and adapt the taxonomy of inter-process connectors (IPC) first proposed by [[A Syntactic Theory of Software Architecture|Dean and Cordy] to describe the possible connections among components. The connections can be: +The hierarchical component model is not recursive, meaning ​that it is truly hierarchical,​ while components ​at different level of abstractions can probably implement ​the same type of connectionsThe clichés illustrated ​in the paper are similar to implementation patterns ​in that they are described ​in terms of constituents ​of abstract-syntax trees (ASTs).
-    * Shared-file:​ a data repository shared by several components. This type of connections ​is nowadays probably realised through the use of a database. +
-    * Shared-memory:​ a data repository in which data can be accessed randomly and that is shared by components. This type of connections recalls ​the "black board" architectural style. It assumes that the components have access to a shared memory and are, probably, on a same machine. Nowadays, such a use of shared memory probably translate into the use of a database or object story, such as Haystack. +
-    * Remote procedure call: a procedure call-like mechanism between components. Nowadays, most components interact through RPC, in particular with the advent of service-oriented architectures. How components can know about one another and invoke their procedures ​are interesting questions. +
-    * Stream: a unidirectional or bidirectional ordered exchange of data between components. This is implemented through "​piping"​ between components. Nowadays, piping is heavily used in Unix-like systems but probably not so much in more "​general"​ component-based systems. +
-    * Message: a data exchange among an arbitrary number ​of components. This type of connections also recalls the "black board" architecture but it may be also about having a "​software bus" shared by components. +
-    * Invocation: a connector that represents one component starting another component. This type of connection is probably implemented using fork() (C/C++) or Runtime.exec() (Java) or similar mechanisms.+
  
 +The detection of the types of connections and components is performed on an AST, which hint at a unified AST among components to recognise, for example, occurrences of the "​client-server"​ implementation pattern. Recovering and unifying ASTs may be too difficult in the context of SIMILAS because reconciling an AST for JavaScript and another for C++ may just be overly complicated without providing much benefits. Using a common meta-model describing only the constituents needed in both programming languages to identify interested implementation patterns should be viable.
  
 +The experiments report occurrences of various implementation patterns found in systems written in the same programming language, C (for Unix). It is unclear how the tool would work on components written in (very) different programming languages, such as JavaScript and C/C++.
an_architectural_revere_engineering_environment.1378429927.txt.gz · Last modified: 2019/10/06 20:37 (external edit)