1: \documentstyle[ntcs]{article}
2: \thispagestyle{empty}
3: \newtheorem{definition}{Definition}[section]
4: \input epsf
5:
6: \renewcommand{\thefootnote}{\fnsymbol{footnote}}\newcommand{\qqquad}{\quad\qquad}
7:
8: \title{\Large\bf Using Dependence Analysis to Support Software \\Architecture
9: Understanding}
10:
11: \author{\large \it{Jianjun Zhao}\\
12: \normalsize Department of Computer Science and Engineering\\
13: \normalsize Fukuoka Institute of Technology\\
14: \normalsize 3-10-1 Wajiro-Higashi, Higashi-ku, Fukuoka 811-02, Japan\\
15: \normalsize zhao@cs.fit.ac.jp
16: }
17:
18: \date{}
19: %\setcounter{page}{312}
20:
21: \begin{document}
22:
23: \maketitle
24:
25: \thispagestyle{empty}
26: %\thispagestyle{copyright}
27:
28:
29: \baselineskip 2.7mm
30: \abstract
31: {
32: Software architecture is receiving increasingly attention as a
33: critical design level for software systems. As software architecture
34: design resources (in the form of architectural descriptions)
35: are going to be accumulated, the development of techniques and tools
36: to support architectural understanding, testing, reengineering,
37: maintaining, and reusing will become an important issue.
38: In this paper we introduce a new dependence analysis technique, named {\it
39: architectural dependence analysis} to support software architecture
40: development. In contrast to traditional dependence analysis, architectural
41: dependence analysis is designed to operate on an architectural
42: description of a software system, rather than the source code of
43: a conventional program. Architectural dependence analysis provides
44: knowledge of dependences for the high-level architecture of
45: a software system, rather than the low-level implementation details
46: of a conventional program.}
47:
48: \vspace{2mm}
49: \section{Introduction}
50: \label{sec:intro}
51: \vspace{2mm}
52:
53: Software architecture is receiving increasingly attention as a
54: critical design level for software systems \cite{Shaw96}. The software
55: architecture of a system defines its high-level structure, exposing
56: its gross organization as a collection of interacting components.
57: A well-defined architecture allows an engineer to reason about system
58: properties at a high level of abstraction. The importance of software
59: architecture for practicing software engineers is highlighted by the
60: ubiquitous use of architectural descriptions in system documentation.
61:
62: Architectural description languages (ADLs) are formal languages that
63: can be used to represent the architecture of a software system.
64: They focus on the high-level structure of the overall application
65: rather than the implementation details of any specific source module.
66: ADLs are intended to play an important role in the development of
67: software by composing source modules rather than by composing
68: individual statements written in conventional programming languages.
69: Recently, a number of architectural description languages
70: have been proposed such as ACME \cite{Garlan97}, Rapide \cite
71: {Luckham95}, UniCon \cite{Shaw95}, and Wright \cite{Allen96} to
72: support formally representation and reasoning of software architectures.
73: As software architecture design resources (in the form of
74: architectural descriptions) are going to be accumulated,
75: the development of techniques and tools to support understanding, testing,
76: reengineering, maintaining, and reusing of software architectures
77: will become an important issue.
78:
79: One promising way to support software architecture development
80: is to use dependence
81: analysis technique. Program dependences are dependence relationships
82: holding between program statements in a program that are determined
83: by the control flows and data flows in the program.
84: Usually, there are two types of
85: program dependences in a conventional
86: program, {\it control dependences} that represent the control
87: conditions on which the execution of a statement or expression
88: depends and {\it data dependences} that represent the flow of
89: data between statements or expressions. The task to determine a
90: program's dependences is called {\it program dependence analysis}.
91: We refer to this kind of dependence analysis
92: as {\it traditional dependence analysis} to distinguish it
93: from a new form dependence analysis introduced later.
94:
95: Traditional dependence analysis has been primarily studied
96: in the context of conventional programming languages.
97: In such languages, it is typically performed
98: using {\it program dependence graphs}
99: \cite{Cheng97,Horwitz90,Ottenstein84,Zhao96a,Zhao96b}. Traditional
100: dependence analysis, though originally proposed for complier
101: optimization, has also many applications in software engineering
102: activities such as program slicing, understanding, debugging, testing,
103: maintenance and complexity measurement
104: \cite{Agrawal93,Bates93,Cheng97,Ottenstein84,Podgurski90,Zhao96a,Zhao96b}.
105:
106: Applying dependence analysis to software architectures promises benefit
107: for software architecture development at least in two aspects.
108: First, architectural understanding and maintenance
109: should benefit from dependence analysis. To understand a software
110: architecture to make changes during maintenance, a maintainer
111: must take into account the many complex dependence
112: relationships between components and/or connectors in the architecture.
113: This makes dependence analysis an essential step to architectural
114: level understanding and maintenance. Second, architectural reuse should benefit from
115: dependence analysis. While reuse of code is important, reuse of software designs
116: and patterns may offer the greater potential for return on investment
117: in order to make truly large gains in productivity and quality.
118: By analyzing dependences in an architectural description of a software system,
119: a system designer can extract reusable architectural descriptions from it, and
120: reuse them into new system designs for which they are appropriate.
121:
122: While dependence analysis is useful in software architecture development,
123: existing dependence analysis techniques for conventional programming
124: languages can not be applied to architectural descriptions
125: straightforwardly due to the following reasons. The traditional
126: definition of dependences only concerned with programs written in
127: conventional programming languages which primarily consist of
128: variables and statements as their basic language elements,
129: and dependences are usually defined as dependence relationships
130: between statements or variables. However, in an architectural
131: description language, the basic language elements are primarily
132: components and connectors, but neither variables nor statements
133: as in conventional programming languages. Moreover, in addition
134: to definition/use binding relationships, an architectural description
135: language topically support more broad and complex relationships
136: between components and/or connectors such as pipes, event broadcast,
137: and client-server protocol. As a result, new types of dependence
138: relationships in an architectural description must be studied based on
139: components and connectors.
140:
141: In this paper we introduce a new dependence analysis technique,
142: named {\it architectural dependence analysis} to support software architecture
143: development. In contrast to traditional dependence analysis, architectural
144: dependence analysis is designed to operate on an architectural
145: description of a software system, rather than the source code of
146: a conventional program. Architectural dependence analysis provides
147: knowledge of dependences for the high-level architecture of
148: a software system, rather than the low-level implementation details
149: of a conventional program.
150:
151: The purpose of development of architectural dependence analysis
152: is quite different from the purpose for development of traditional
153: dependence analysis. While traditional dependence analysis
154: was designed originally for supporting compiler optimization of
155: a conventional program, architectural dependence analysis
156: was primarily designed for supporting architectural understanding and
157: reuse of a large-scale software system. However, just as traditional
158: dependence analysis has many other applications in software
159: engineering activities, we expect that architectural dependence
160: analysis has also useful in other software architecture development
161: activities including architectural testing, reverse engineering, reengineering,
162: and complexity measurement.
163:
164: The rest of the paper is organized as follows.
165: Section \ref{sec:acme} briefly introduces the ACME: an
166: architectural description language. Section \ref{sec:depen}
167: presents a dependence model for software architectures. Section
168: \ref{sec:use} discusses some applications of the model.
169: Concluding remarks are given in Section \ref{sec:final}.
170:
171: \vspace{2mm}
172: \section{Architectural Descriptions in ACME}
173: \label{sec:acme}
174: \vspace{2mm}
175:
176: We assume that readers are familiar with the basic concepts of
177: architectural description languages, and in this paper, we use
178: ACME architectural description language \cite{Garlan97} as our target
179: language to represent software architectures. The selection of the
180: ACME is based on its potentially wide use because ``it is being
181: developed as a joint effort of the software architecture research
182: community to provide a common intermediate representation for a wide
183: variety of architecture tools.'' \cite{Garlan97}
184:
185: There are seven design elements in ACME that can be used to represent
186: software architectures which include components, connectors, systems,
187: ports, roles, representations, and bindings. Among them, the most
188: basic elements of architectural description are {\it components}, {\it
189: connectors}, and {\it systems}. Readers can refer \cite{Garlan97}
190: for more details of the language description, and we briefly introduce
191: these design elements here.
192:
193: {\it Components} are used to represent the primary computational
194: elements and data stores of a system. Intuitively, they correspond to
195: the boxes in box-and-line descriptions of software architectures.
196: Typical examples of components include clients, servers, filters,
197: objects, and databases. Each component has its
198: interface defined by a set of {\it ports}. A component may
199: provide multiple interfaces by using different types of ports.
200: Each port identifies a point of interaction between the component and its
201: environment. A port can represent a simple interface such as
202: procedure signature, or more complex interfaces, such as a
203: collection of procedure calls that must be invoked in certain
204: specified orders, or an event multi-cast interface point.
205:
206: {\it Connectors} are used to represent interactions between components.
207: Connectors mediate the communication and coordination activities
208: between components. Intuitively, they correspond to the lines
209: in box-and-line descriptions. connectors may represent simple forms
210: of interaction, such as pipes, procedure calls, event broadcasts, and
211: also more complex interactions, such as a client-server protocol
212: or a SQL link between a database and an application. Each connector
213: has its interface defined by a set of {\it roles}.
214: Each role of a connector defines a participant of the interaction
215: represented by the connector. Connectors may have two roles such as
216: the {\it caller} and {\it callee} roles of an RPC connector,
217: the {\it reading} and {\it writing} roles of a pipe, or the {\it
218: sender} and {\it receiver} roles of a message passing connector, or
219: more than two roles such as an even broadcast connector which
220: might have a single {\it event-announcer} role and an arbitrary number
221: of {\it event-receiver} roles.
222:
223: {\it Systems} represent configurations of components and connectors.
224:
225: \begin{figure}[t]
226: % \begin{center}
227: \hspace*{.7cm}
228: \epsfbox{fig1.eps}
229: \caption{\label{fig:sys} The architecture of the LAS system.}
230: % \end{center}
231: \end{figure}
232:
233: Figure \ref{fig:acme} (a) shows the ACME architectural description of
234: a simple London Ambulance Service dispatch system (LAS system) which
235: is taken from \cite{Monroe96}, and Figure
236: \ref{fig:sys} shows its architectural representation.
237: The architectural representation contains five components which are
238: connected by six connectors. For example, in the representation, the
239: component \verb+call_entry+ and the component \verb+incident_mgr+ is
240: connected by the connector \verb+call_info_channel+. Each component
241: is declared to have a set of ports, and each connector is declared to
242: have a set of roles. For example, a component \verb+incident_mgr+
243: has four ports designed as \verb+map_request+, \verb+incident_info_request+,
244: \verb+send_incident_info+, and \verb+receive_call_msg+, and a
245: connector \verb+call_info_channel+ has two roles designed as
246: \verb+from+ and \verb+to+. The topology of the system is declared
247: by a set of attachmentses. For example, an attachments
248: \verb+incedent_info_path+ represents the connections from calls to
249: incident\_manager, incident updates to resource manager, and dispatch
250: requests to dispatcher.
251:
252: In order to provide more information about architectural descriptions,
253: ACME also supports annotation of architectural structure with lists of {\it
254: properties}. Each property has a name, an optional type, and a value,
255: and each ACME architectural design entity can be annotated.
256: For example, in Figure \ref{fig:acme}, the connector
257: \verb+call_info_channel1+
258: has a set of properties that state the connection type is massage
259: passing channel and the message flow is from the role \verb+from+
260: to the role \verb+to+.
261:
262: In order to focus on the key idea of architectural dependence
263: analysis, we assume that an ACME architectural description contains
264: these basic elements including {\it component} whose interface is
265: defined by a set of {\it ports}, {\it connector} whose interface is
266: defined by a set of {\it roles} and {\it system} whose topology is declared by
267: a set of {\it attachmentses} each including a set of attachments.
268: {\it Representations} and {\it bindings} will not be considered here,
269: and we will consider them in our future work.
270: %In the rest of the paper, we assume that an architectural description be
271: %devoted by $(C_{m}, C_{n}, A_{m})$ where $C_{m}$, $C_{n}$,
272: %%1997.10.16!!!! 5and $A_{m}$ are the set of components, connectors, and attachmentses
273: %of the description respectively.
274:
275: \vspace{2mm}
276: \section{A Dependence Model for Software Architectures}
277: \label{sec:depen}
278: \vspace{2mm}
279:
280: In this section we first introduce three types of
281: dependences in an architectural description, then present a
282: dependence graph for architectural descriptions.
283:
284: \subsection{Dependences in Architectural Descriptions}
285:
286: Traditional dependence analysis has been primarily studied in the
287: context of conventional programming languages. In such languages,
288: dependences are usually defined between statements or variables.
289: However, in an architectural description language, the basic language
290: elements are components and connectors, but neither statements nor
291: variables.
292: %Therefore, new definition of dependences must be studied
293: %for architectural descriptions. On the other hand,
294: Moreover, in an architectural description languages,
295: the interactions among components and/or
296: connectors is through their interfaces that are usually defined to be a set
297: of ports (for components) and a set of roles (for connectors).
298: As a result, it is not enough to define dependences
299: just between components and/or connectors in an architectural description.
300: In this paper, we define dependences in an
301: architectural description as dependence relationships between ports
302: and/or roles of components and/or connectors. In the following, we
303: present three types of dependences in an architectural description.
304:
305: \subsubsection{Component-Connector Dependences}
306:
307: The first type of dependence relationship in an architectural
308: description is called {\it component-connector dependences}
309: which can be used to represent dependence relationships
310: between a port of a component and a role of a connector in the
311: description. Informally, if there is an information flow from a port
312: of a component to a role of a connector, then there exists a
313: component-connector dependence between them. For example,
314: in Figure \ref{fig:acme} (a), there is a component-connector
315: dependence between the port \verb+receive_incident_info+ of the
316: component \verb+resource_mgr+ and the role \verb+to+ of the
317: connector \verb+incident_update_channel+ since there is a message
318: flow from the role \verb+to+ to the port \verb+receive_incident_info+.
319:
320: \begin{figure*}[t]
321: \begin{center}
322: \epsfxsize=\hsize \epsfbox{fig2.eps}
323: \caption{\label{fig:graph} The dependence graph of the architectural
324: description in Figure {\protect\ref{fig:acme}}.}
325: \end{center}
326: \end{figure*}
327:
328: \subsubsection{Connector-Component Dependences}
329:
330: The second type of dependence relationship in an architectural
331: description is called {\it connector-component dependences}
332: which can be used to represent dependence relationships between
333: a role of a connector and a port of a component. Informally,
334: if there is an information flow from a role of a connector to a port
335: of a component, then there exists a connector-component dependence
336: between them. For example, in Figure \ref{fig:acme} (a), there is a
337: connector-component dependence between the role
338: \verb+from+ of the connector \verb+call_info_channel+ and
339: the port \verb+send_call_msg+ of the component \verb+call_entry+
340: since there is a message flow from the port \verb+send_call_msg+ to
341: the role \verb+from+.
342:
343: \subsubsection{Additional Dependences}
344:
345: The third type of dependence relationships in an architectural
346: description is called {\it additional dependences} which can be
347: used to represent dependence relationships
348: between two ports or roles within a component or connector.
349: Informally, for a component or connector there are additional
350: dependences from each port or role as input to other ports or roles as
351: output. For example, in Figure \ref{fig:acme} (a), there is an additional
352: dependence between the roles \verb+client_end+ and
353: \verb+server_end+ of the connector \verb+map_request_rpc2+ and also an
354: additional dependence between the ports \verb+map_request+ and
355: \verb+receive_incident_info+ of the component \verb+resource_msg+.
356:
357: \subsection{Software Architectural Dependence Graph}
358:
359: It has been shown that a dependence graph representation such as
360: the {\it program dependence graph} (PDG) \cite{Ferrante87,Horwitz90} for
361: programs written in conventional programming languages, has many
362: application in software engineering activities since it provides
363: a powerful framework for control flow and date flow analysis.
364: This motivates us to present a similar representation to explicitly
365: represent dependences in an architectural description. In this
366: section, we present a dependence graph named {\it software
367: architectural dependence graph} (SADG for short) for architectural
368: descriptions to explicitly represent three types of dependences
369: in an architectural description introduced above.
370: The SADG of an architectural description is an arc-classified digraph
371: whose vertices represent the ports of components and the roles of the
372: connectors in the description, and arcs represent three types of
373: dependence relationships in the description.
374:
375: %To understand how a component interacts with the
376: %other components or connectors for making changes, a maintainer must
377: %examine each port of the component of interest. Moreover, it has been
378: %frequently emphasized that connectors are as important as components for
379: %architectural design, and a maintainer may also modify a connector
380: %during the maintenance.
381: %however, it not
382: %enough to define dependences between components and/or connectors
383: %because in an architectural description, although components and
384: %connectors are its basic language elements, usually, a
385:
386: \begin{figure*}[t]
387: \begin{center}
388: \epsfbox{fig3.eps}
389: \caption{\label{fig:graph.slice} A slice over the ADDG of the
390: architectural description in Figure {\protect\ref{fig:acme}}.}
391: \end{center}
392: \end{figure*}
393:
394: Figure \ref{fig:graph} shows the SADG of
395: the architectural description in Figure \ref{fig:acme}. In the figure,
396: large squares represent components in the description, and small
397: squares represent the ports of each component. Each port vertex has
398: its name described by {\it component\_name.port\_name}. For example,
399: $pv8$ (\verb+resource_mgr.receive_incident_info+) is a port vertex
400: that represents the port \verb+receive_incident_info+ of the
401: component \verb+resource_mgr+.
402: Large circles represent connectors in the description,
403: and small circles represent the roles of each connector. Each role
404: vertex has its name described by {\it connector\_name.role\_name}.
405: For example, $rv7$ (\verb+incident_info_request_rpc.client_end+)
406: is a role vertex that represents the role
407: \verb+client_end+ of the connector \verb+incident_info+ \verb+request+. The
408: complete description of each vertex is shown in the bottom of the
409: figure.
410:
411: Bold arcs represent component-connector dependence arcs that
412: connect a port of a component to a role of a corresponding connector.
413: Bold dashed arcs represent connector-component dependence arcs that
414: connect a role of a connector and a port of a corresponding component.
415: Thin dashed arcs represent additional dependence arcs that connect two
416: ports or roles within a component or connector. For example,
417: $(pv8,rv4)$ and $(pv3,rv8)$ are component-connector dependence arcs.
418: $(rv5,pv9)$ and $(rv9,pv2)$ are connector-component dependence arcs.
419: $(rv2,rv1)$ and $(rv6,rv5)$, and $(pv2,pv5)$ and $(pv7,pv8)$ are
420: additional dependence arcs.
421:
422: Note that there are some efficient algorithms to compute program
423: dependences and construct the dependence graph representations
424: for programs written in conventional programming languages
425: \cite{Harrold93,Ottenstein92}. These algorithms can easily be modified
426: to compute dependences in an architectural description and construct
427: the SADG representation as well.
428:
429: \vspace{2mm}
430: \section{Applications}
431: \label{sec:use}
432: \vspace{2mm}
433:
434: As dependence graph representations for conventional programming
435: languages have many applications in software engineering
436: activities, the dependence model presented in this paper
437: should have similar applications in practical development of
438: software architectures.
439:
440: \subsection{Architectural Slicing and Understanding}
441: \label{subsec:slicing}
442:
443: Program slicing, originally introduced by Weiser \cite{Weiser84},
444: is a decomposition technique which extracts program elements
445: related to a particular computation. A {\em program slice} consists of those
446: parts of a program that may directly or indirectly affect the values
447: computed at some program point of interest, referred to as a {\em
448: slicing criterion}. We refer to this kind of slicing as {\it
449: traditional slicing}. Traditional slicing has been widely studied
450: in the context of traditional programming languages and has many
451: applications in software engineering activities such as program
452: understanding \cite{DeLucia96}, debugging \cite{Agrawal93},
453: testing \cite{Bates93}, maintenance \cite{Gallagher91} and complexity
454: measurement \cite{Ottenstein84}.
455:
456: Having SADG as a representation of architectural descriptions, we can
457: apply traditional slicing technique to software architectures. We
458: presented an entirely new form of slicing named {\it architectural
459: slicing}, to slicing software architectures in order to support
460: architectural understanding and reuse \cite{Zhao97}. Architectural
461: slicing is designed to operate on the architectural description of a
462: software system and can provide knowledge about the high-level
463: architecture of a software system.
464:
465: Intuitively, an {\it architectural slice} may be viewed as a subset
466: of the behavior of a software architectural description,
467: similar to the original notion of the traditional static slice.
468: However, while a traditional slice intends to isolate the behavior
469: of a specified set of program variables, an architectural slice intends
470: to isolate the behavior of a specified set of a component's
471: ports or a connector's roles.
472: Given an architectural description $P=(C_{m}, C_{n}, A_{m})$ of a
473: software system, our goal is to compute a slice
474: $S_{p}=(C_{m}', C_{n}', A_{m}')$ that should be a ``subset'' of $P$
475: that preserves partially the semantics of $P$.
476: In \cite{Zhao97}, We use a dependence graph based approach
477: to compute an architectural slice, that is based on the SADG of
478: the description. Our slicing algorithm contains
479: two phases:
480:
481: \begin{itemize}
482: \item[]{\bf Step 1:} Computing a slice $S_{g}$ over the SADG of an architectural
483: description,
484: \end{itemize}
485:
486: Figure \ref{fig:graph.slice} shows a slice over the ADDG in Figure
487: \ref{fig:graph}. The slice was computed with respect to the slicing
488: criterion $(\verb+resource_mgr+, V_{c})$ such that
489: $V_{c}=\{pv7, pv8\}$.
490:
491: \begin{itemize}
492: \item[]{\bf Step 2:} Constructing an architectural description slice
493: $S_{p}$ from $S_{g}$.
494: \end{itemize}
495:
496: Figure \ref{fig:acme} (b) shows a slice of the
497: ACME description in Figure \ref{fig:acme} (a) with respect to
498: the slicing criterion (\verb+resource_mgr+, E) such that
499: E=\{\verb+incident_info_request+, \verb+receive_incident_info+\}
500: is a set of ports of component \verb+resource_mgr+.
501: The small rectangles represent the parts of description that have been
502: removed, i.e., sliced away from the original description.
503: The slice is obtained from a slice over the ADDG in Figure
504: \ref{fig:graph.slice} according to the mapping process described above.
505: Figure \ref{fig:sys-slice} shows the architectural representation of
506: the slice in Figure \ref{fig:acme} (b).
507:
508: \begin{figure}[t]
509: \begin{center}
510: \epsfbox{fig4.eps}
511: \caption{\label{fig:sys-slice} The architectural representation of
512: the slice in Figure {\protect\ref{fig:acme}} (b).}
513: \end{center}
514: \end{figure}
515:
516: In the following, we present a simple example to show how
517: architectural slicing can be used to aid architectural
518: understanding of a software system.
519:
520: Consider a simple London Ambulance Service dispatch system (LAS
521: system) whose ACME description is shown in Figure \ref{fig:acme}
522: (a). This example is taken from \cite{Monroe96}.
523: Suppose a maintainer needs to modify two ports
524: \verb+incident_info_request+ and \verb+receive_incident_info+ of the
525: component \verb+resource_mgr+ in the architectural description
526: in order to satisfy new design requirement, the first thing he/she has
527: to do is to investigate which components and connectors interact
528: with component \verb+resource_mgr+ through these two ports.
529: A common way is to manually check
530: the source code of the description to find such information. However,
531: it is very time-consuming and error-prone even for a small size
532: description because there may be complex dependence relations
533: between components and/or connectors in the description.
534: However, if the maintainer has an architectural slicer in hand,
535: The work may probably be simplified and automated without the
536: disadvantages mentioned above. In such a scenario, he/she only
537: needs to invoke the slicer, which takes as input a complete
538: architectural description of the system and the set of ports of the
539: component \verb+resource_mgr+, i.e., \verb+incident_info_request,
540: receive_incident_info+ (this is an {\it architectural slicing
541: criterion}). The slicer then computes an architectural slice
542: with respect to the criterion and outputs it to the maintainer.
543: Such a slice is a partial description of the original one which
544: includes those components and connectors that might affect the
545: component \verb+resource_mgr+ through ports in the criterion.
546: The other parts of the description that might not affect the component
547: \verb+resource_mgr+ have been removed, i.e., sliced away from the original
548: description. The maintainer can thus focus his/her attention
549: only on the contents included in the slice to investigate the impact
550: of modification.
551:
552: \subsection{Architectural Reuse}
553: \label{subsec:reuse}
554:
555: While reuse of code is important, in order to make truly large gains
556: in productivity and quality, reuse of software designs and patterns may
557: offer the greater potential for return on investment.
558: Although there are many researches have been proposed for reuse of
559: code, little reuse method has been proposed for architectural reuse.
560: By slicing an architectural description of a software system,
561: a system designer can extract reusable architectural descriptions from it, and
562: reuse them into new system designs for which they are appropriate.
563:
564:
565: %In the following, we present a simple example to explain the basic
566: %idea of architectural reuse via slicing.
567: %During design process, suppose a system designer wishes to reuse
568: %existing design resources for new system design. Suppose he/she has an
569: %architectural description of the LAS system which shown
570: %in Figure \ref{fig:acme} (a), and wishes to reuse the architectural
571: %description. However, instead of reusing the complete description,
572: %he/she just wishes to use a partial part of the description,
573: %that is, a functionality which is concerned with the component
574: %\verb+resource_mgr+. A common way to do this is to manually check the
575: %source code of the description to get those codes satisfying design requirement.
576: %However, this may lead to similar problems as we mentioned above.
577: %If he/she has an architectural slicer in hand, the work may probably
578: %be simplified and automated without the disadvantages mentioned above.
579: %To do so, he/she only needs to invoke the slicer, which takes as input the complete
580: %architectural description of the system and the ports of the component
581: %\verb+resource_mgr+, i.e., \verb+map_request,incident_info_requests,
582: %send_incident_info,receive_call_msg+ this is a {\it architectural
583: %slicing criterion}. The slicer then computes an architectural slice
584: %with respect to the criterion and outputs it to the designer.
585: %For a designer, such a slice is a reduced description of the original
586: %one which includes those components and connectors that satisfy the
587: %functionality for design requirement. The other parts of the
588: %description has been removed since it is useless for the new design
589: %functionality. The designer can thus reuse this partial description
590: %into his/her new system design.
591:
592: \vspace{2mm}
593: \section{Concluding Remarks}
594: \label{sec:final}
595: \vspace{2mm}
596:
597: Software architecture is receiving increasingly attention as a
598: critical design level for software systems. As software architecture
599: design resources (in the form of architectural descriptions)
600: are going to be accumulated, the development of techniques and tools
601: to support architectural-level understanding, testing, reengineering,
602: maintaining, and reusing will become an important issue.
603: In this paper we introduce a new dependence analysis technique, named {\it
604: architectural dependence analysis} to support software architecture
605: development. In contrast to traditional dependence analysis,
606: architectural dependence analysis is designed
607: to operate on an architectural description of a software system,
608: rather than the source code of a conventional program. Architectural
609: dependence analysis provides knowledge of dependences for the
610: high-level architecture of a software system, rather than the
611: low-level implementation details of a conventional program.
612: In order to perform architectural dependence analysis, we also
613: presented the {\it software architectural dependence graph} to
614: explicitly represent various types of dependences in an architectural
615: description of a software system. While our initial exploration used
616: ACME as the architectural description language, the concept and
617: approach of architectural dependence analysis are language-independent.
618: However, the implementation of an architectural dependence analysis
619: tool may differ from one architecture description language to another
620: because each language has its own structure and syntax which must be
621: handled carefully.
622:
623: In architectural description languages, in addition to provide both
624: a conceptual framework and a concrete syntax for characterizing
625: software architectures, they also provide tools for parsing,
626: displaying, compiling, analyzing, or simulating architectural
627: descriptions written in their associated language. However,
628: existing language environments provide no tools to support
629: architectural understanding, maintenance, testing, and reuse
630: from an engineering viewpoint. We believe that a dependence analysis
631: tool such as an architectural dependence analyzer introduced in this paper
632: should be provided by any ADL as an essential means to support
633: software architecture development activities.
634:
635: As future work, we would like to extend our approach presented in
636: this paper to handle other constructs in ACME language such as
637: {\it templates} and {\it styles} which were not considered here, and
638: also to extend our approach to handle other architecture description
639: languages such as UniCon and Wright. Moreover, to demonstrate the
640: usefulness of our dependence analysis approach, we are implementing
641: an architectural dependence analyzer for ACME architectural
642: descriptions to support architectural understanding and reuse.
643: The next step for us is to perform some experiments to evaluate the
644: usefulness of architectural dependence analysis in practical
645: development of software architectures.
646:
647: \vspace{3mm}
648:
649: \noindent
650: {\large \bf Acknowledgements}
651:
652: \vspace{1mm}
653: The author would like to thank Prof. Jingde Cheng and Prof. Kazuo
654: Ushijima at Kyushu University for their helpful discussion and
655: continuing encouragement.
656:
657: \vspace*{1.5mm}
658:
659:
660: \begin{figure*}[t]
661: \begin{center}
662: \epsfxsize=0.75\hsize \epsfbox{fig5.eps}
663: \caption{\label{fig:acme} An architectural description in ACME and a
664: slice of it.}
665: \end{center}
666: \end{figure*}
667:
668: \baselineskip 2mm
669: {\small
670: \begin{thebibliography}{99}
671:
672: \bibitem{Agrawal93}
673: H. Agrawal, R. Demillo, and E. Spafford,
674: ``Debugging with Dynamic Slicing and Backtracking,''
675: {\it Software-Practice and Experience}, Vol.23, No.6, pp.589-616, 1993.
676:
677: \bibitem{Allen96}
678: R. Allen and D. Garlan,
679: ``The Wright Architectural Specification Language,''
680: Technical Report CMU-CS-96-TBD, Carnegie Mellon University, School of
681: Computer Science, 1996.
682:
683: \bibitem{Bates93}
684: S. Bates, S. Horwitz, ``Incremental Program Testing Using Program
685: Dependence Graphs,'' {\em Conference Record of the 20th Annual ACM
686: SIGPLAN-SIGACT Symposium of Principles of Programming Languages},
687: pp.384-396, Charleston, South California, ACM Press, 1993.
688:
689: \bibitem{Cheng97}
690: J. Cheng,
691: ``Dependence Analysis of Parallel and Distributed Programs and Its
692: Applications,''
693: {\it Proceedings of 1997 IEEE-CS International Conference on Advances
694: in Parallel and Distributed Computing}, pp.370-377, March 1997.
695:
696: \bibitem{DeLucia96}
697: A. De Lucia, A. R. Fasolino, and M. Munro,
698: ``Understanding function behaviors through program slicing,''
699: {\it Proceedings of the Fourth Workshop on Program Comprehension},
700: Berlin, Germany, March 1996.
701:
702: \bibitem{Ferrante87}
703: J.Ferrante, K.J.Ottenstein, and J.D.Warren,
704: ``The Program Dependence Graph and Its Use in Optimization,''
705: {\it ACM Transaction on Programming Language and System}, Vol.9, No.3, pp.319-349, 1987.
706:
707: \bibitem{Gallagher91}
708: K. B. Gallagher and J. R. Lyle, ``Using Program Slicing in Software Maintenance,''
709: {\it IEEE Transaction on Software Engineering}, Vol.17, No.8, pp.751-761, 1991.
710:
711: %\bibitem{Garlan93}
712: %D. Garlan and M. Shaw,
713: %``An Introduction to Software Architecture.''
714: %In V. Ambriola and G. Tortora (ed.), {\it Advances in Software
715: %Engineering and Knowledge Engineering}, Vol 2, pp.1-39, World
716: %Scientific, 1993.
717:
718: \bibitem{Garlan97}
719: D. Garlan, R. Monroe, and D. Wile, ``ACME: An Interchange Language for
720: Software Architecture,'' 2nd edition, Tech. Report, Carnegie Mellon
721: University, 1997.
722:
723: \bibitem{Harrold93}
724: M. J. Harrold, B. Malloy, and G. Rothermel,
725: ``Efficient Construction of Program Dependence Graphs,''
726: {\it ACM International Symposium on Software Testing and Analysis},
727: pp.160-170, June 1993.
728:
729: \bibitem{Horwitz90}
730: S. Horwitz, T. Reps, and D. Binkley,
731: ``Interprocedural Slicing Using Dependence Graphs,''
732: {\it ACM Transaction on Programming Language and System}, Vol.12,
733: No.1, pp.26-60, 1990.
734:
735: \bibitem{Luckham95}
736: D. C. Luckham, L. M. Augustin, J. J. Kenney, J. Veera, D. Bryan, and
737: W. Mann,
738: ``Specification Analysis of System Architecture Using Rapide,''
739: {\it IEEE Transaction on Software Engineering}, Vol.21, No.4,
740: pp.336-355, April 1995.
741:
742: \bibitem{Korel87}
743: B. Korel,
744: ``Program Dependence Graph in Static Program Testing,''
745: {\it Information Processing Letters}, Vol.24, pp.103-108, 1987.
746:
747: \bibitem{Kuck81}
748: D. Kuck, R.Kuhn, B. Leasure, D. Padua, and M. Wolfe,
749: ``Dependence Graphs and Compiler and Optimizations,''
750: {\it Conference Record of the 8th Annual ACM Symposium on Principles
751: of Programming Languages}, pp.207-208, 1981.
752:
753: \bibitem{Monroe96}
754: B. Monroe, D. Garlan, and D. Wile,
755: ``ACME BNF and Examples,''
756: {\it Microsoft Component-Based Software Development Workshop}, June
757: 3-5, 1996.
758:
759: \bibitem{Ottenstein84}
760: K. J. Ottenstein and L. M. Ottenstein,
761: ``The Program Dependence Graph in a software Development
762: Environment,''
763: {\it ACM Software Engineering Notes}, Vol.9, No.3, pp.177-184, 1984.
764:
765: \bibitem{Ottenstein92}
766: K. J. Ottenstein and S. Ellcey,
767: ``Experience Compiling Fortan to Program Dependence Graphs,''
768: {\it Software - Practice and Experience}, Vol.22, No.1, pp.41-62, 1992.
769:
770: \bibitem{Podgurski90}
771: A. Podgurski and L. A. Clarke,
772: ``A Formal Model of Program Dependences and Its Implications for
773: Software Testing, Debugging, and Maintenance,''
774: {\it IEEE Transaction on Software Engineering}, Vol.16, No.9, pp.965-979, 1990.
775:
776: \bibitem{Shaw95}
777: M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. Young, and G.
778: Zelesnik,
779: ``Abstractions for Software Architecture and Tools to Support Them,''
780: {\it IEEE Transaction on Software Engineering}, Vol.21, No.4,
781: pp.314-335, April 1995.
782:
783: \bibitem{Shaw96}
784: M. Shaw and D. Garlan,
785: ``Software Architecture: Perspective on an Emerging Discipline,''
786: Prentice Hall, 1996.
787:
788: \bibitem{Weiser84}
789: M. Weiser,
790: ``Program Slicing,''
791: {\it IEEE Transaction on Software Engineering}, Vol.10, No.4, pp.352-357, 1984.
792:
793: \bibitem{Zhao96a}
794: J. Zhao, J. Cheng and K. Ushijima,
795: ``Program Dependence Analysis of Concurrent Logic Programs and Its
796: Applications,'' {\it Proceedings of 1996 International Conference on
797: Parallel and Distributed Systems}, pp.282-291, IEEE Computer
798: Society Press, June 1996.
799:
800: \bibitem{Zhao96b}
801: J. Zhao, J. Cheng and K. Ushijima,
802: ``Static Slicing of Concurrent Object-Oriented Programs,''
803: {\it Proc. of the COMPSAC'96}, pp.312-320, IEEE Computer
804: Society Press, August 1996.
805:
806: \bibitem{Zhao97}
807: J. Zhao,
808: ``Software Architecture Slicing,''
809: {\it Proceedings of the 14th Annual Conference of Japan Society for Software
810: Science and Technology}, September 1997 (to appear).
811:
812: \end{thebibliography}
813: }
814:
815:
816: \end{document}
817:
818:
819:
820:
821:
822:
823:
824:
825:
826:
827:
828:
829:
830:
831:
832:
833:
834:
835:
836:
837:
838:
839: