1: \documentstyle[iceccs]{article}
2: \thispagestyle{empty}
3: \newtheorem{definition}{Definition}[section]
4: \renewcommand{\thefootnote}{\fnsymbol{footnote}}
5: \renewcommand{\baselinestretch}{.96}
6:
7: \newcommand{\qqquad}{\quad\qquad}
8: \newcommand{\qqqquad}{\quad\qqquad}
9: \newcommand{\qqqqquad}{\quad\qqqquad}
10: \newcommand{\qqqqqquad}{\quad\qqqqquad}
11: \newcommand{\qqqqqqquad}{\quad\qqqqqquad}
12: \newcommand{\qqqqqqqquad}{\quad\qqqqqqquad}
13: \newcommand{\qqqqqqqqquad}{\quad\qqqqqqqquad}
14: \newcommand{\qqqqqqqqqquad}{\quad\qqqqqqqqquad}
15: \newcommand{\qqqqqqqqqqquad}{\quad\qqqqqqqqqquad}
16: \newcommand{\qqqqqqqqqqqquad}{\quad\qqqqqqqqqqquad}
17: \newcommand{\qqqqqqqqqqqqquad}{\quad\qqqqqqqqqqqquad}
18:
19: \title{\Large\bf Applying Slicing Technique to Software Architectures}
20:
21: \author{\large Jianjun Zhao\\
22: Department of Computer Science and Engineering\\
23: Fukuoka Institute of Technology\\
24: 3-10-1 Wajiro-Higashi, Higashi-ku, Fukuoka 811-0214, Japan\\
25: Email: zhao@cs.fit.ac.jp}
26:
27: \date{}
28: %\setcounter{page}{85}
29: \begin{document}
30:
31: \maketitle
32:
33: \thispagestyle{empty}
34: {\normalsize
35: \abstract
36: {Software architecture is receiving increasingly attention as a
37: critical design level for software systems. As software architecture design resources (in the form of architectural specifications) are going to be
38: accumulated, the development of techniques and tools to support
39: architectural understanding, testing, reengineering, maintenance, and reuse
40: will become an important issue. This paper introduces a new form of slicing,
41: named {\it architectural slicing}, to aid architectural understanding
42: and reuse. In contrast to traditional slicing, architectural slicing is
43: designed to operate on the architectural specification of
44: a software system, rather than the source code of a program.
45: Architectural slicing provides knowledge about the high-level
46: structure of a software system, rather than the low-level
47: implementation details of a program. In order to compute an architectural slice, we present the {\it architecture
48: information flow graph} which can be used to represent
49: information flows in a software architecture. Based on the graph, we give
50: a two-phase algorithm to compute an architectural slice.}
51:
52: \vspace{3mm}
53: \section{Introduction}
54: \label{sec:intro}
55: \vspace{3mm}
56:
57: Software architecture is receiving increasingly attention as a
58: critical design level for software systems \cite{Shaw96}. The software
59: architecture of a system defines its high-level structure, exposing
60: its gross organization as a collection of interacting components.
61: A well-defined architecture allows an engineer to reason about system
62: properties at a high level of abstraction.
63: Architectural description languages (ADLs) are formal languages that
64: can be used to represent the architecture of a software system.
65: They focus on the high-level structure of the overall application
66: rather than the implementation details of any specific source module.
67: Recently, a number of architectural description languages
68: have been proposed such as W{\sc right}\cite{Allen97}, Rapide \cite{Luckham95}, UniCon \cite{Shaw95},
69: and ACME \cite{Garlan97} to support formal representation
70: and reasoning of software architectures.
71: As software architecture design resources (in the form of
72: architectural specifications) are going to be accumulated,
73: the development of techniques to support software architectural
74: understanding, testing, reengineering, maintenance and reuse
75: will become an important issue.
76:
77: One way to support software architecture development is to use
78: slicing technique. Program slicing, originally introduced by Weiser
79: \cite{Weiser79}, is a decomposition technique which extracts program elements
80: related to a particular computation. A {\it program slice} consists
81: of those parts of a program that may directly or indirectly affect the
82: values computed at some program point of interest,
83: referred to as a {\it slicing criterion}. The task to compute program
84: slices is called {\it program slicing}. To understand the basic
85: idea of program slicing, consider a simple example in Figure
86: \ref{fig:Ada} which shows: (a) a program fragment and (b) its slice with
87: respect to the slice criterion (\verb+Total+,14). The slice consists
88: of only those statements in the program that might affect the value of
89: variable \verb+Total+ at line 14. The lines represented by small rectangles
90: are statements that have been sliced away. We refer to this kind of slicing
91: as {\it traditional slicing} to distinguish it from a new form of slicing
92: introduced later.
93:
94: Traditional slicing has been studied primarily in the context of
95: conventional programming languages \cite{Tip95}. In such languages,
96: slicing is typically performed by using a control flow graph
97: or a dependence graph
98: \cite{Cheng93,Horwitz90,Ferrante87,Ottenstein84,Zhao96,Zhao97}.
99: Traditional slicing has many applications in software engineering
100: activities including program understanding \cite{DeLucia96},
101: debugging \cite{Agrawal93}, testing \cite{Bates93},
102: maintenance \cite{Gallagher91}, reuse \cite{Ning94},
103: reverse engineering \cite{Beck93}, and complexity measurement
104: \cite{Ottenstein84}.
105:
106: \begin{figure}[t]
107: \begin{center}
108: %\hspace*{1.3cm}
109: \epsfile{file=fig1.eps,scale=1}
110: \caption{\label{fig:Ada} A program fragment and its slice
111: on criterion ({\protect\verb+Total+},14).}
112: \end{center}
113: \end{figure}
114:
115: Applying slicing technique to software architectures promises benefit
116: for software architecture development at least in two aspects.
117: First, architectural understanding and maintenance
118: should benefit from slicing. When a maintainer wants to modify a
119: component in a software architecture in order to satisfy new design
120: requirements, the maintainer must first investigate which components
121: will affect the modified component and which components will be
122: affected by the modified component. This process is usually called {\it
123: impact analysis}. By slicing a software architecture, the maintainer
124: can extract the parts of a software architecture containing
125: those components that might affect, or be affected by, the modified
126: component. The slicing tool which provides such information can assist
127: the maintainer greatly.
128: Second, architectural reuse should benefit from slicing. While reuse
129: of code is important, in order to make truly large gains in
130: productivity and quality, reuse of software designs and patterns may
131: offer the greater potential for return on investment.
132: By slicing a software architecture, a system designer can extract
133: reusable architectures from it, and reuse them into new system designs
134: for which they are appropriate.
135:
136: While slicing is useful in software architecture development,
137: existing slicing techniques for conventional programming languages
138: can not be applied to architectural specifications straightforwardly
139: due to the following reasons. Generally, the traditional definition of
140: slicing is concerned with slicing programs written in conventional
141: programming languages which primarily consist of variables and statements,
142: and the slicing notions are usually defined as (1) a slicing criterion
143: is a pair (s, V) where $s$ is a statement and $V$ is a set of variables defined
144: or used at $s$, and (2) a slice consists of only statements. However,
145: in a software architecture, the basic elements are components and their
146: interconnections, but neither variables nor statements as in
147: conventional programming languages. Therefore, to perform slicing at
148: the architectural level, new slicing notions for software architectures
149: must be defined.
150:
151: In this paper, we introduce a new form of slicing,
152: named {\it architectural slicing}. In contrast to
153: traditional slicing, architectural slicing is designed to operate on
154: a formal architectural specification of a software system, rather than
155: the source code of a conventional program. Architectural slicing provides
156: knowledge about the high-level structure of a software system,
157: rather than the low-level implementation details of a conventional program.
158: Our purpose for development of architectural slicing is different
159: from that for development of traditional slicing. While
160: traditional slicing was designed originally for supporting source code
161: level understanding and debugging of conventional programs,
162: architectural slicing was primarily designed for supporting
163: architectural level understanding and reuse of large-scale software systems.
164: However, just as traditional slicing has many other
165: applications in software engineering activities, we believe that
166: architectural slicing is also useful in other software architecture
167: development activities including architectural testing, reverse engineering,
168: reengineering, and complexity measurement.
169:
170: Abstractly, our slicing algorithm takes as input a formal architectural
171: specification (written in its associated architectural description language)
172: of a software system, then it removes from the specification those components
173: and interconnections between components which are not necessary for
174: ensuring that the semantics of the specification of the software architecture
175: is maintained. This benefit allows unnecessary components and interconnections
176: between components to be removed at the architectural level of
177: the system which may lead to considerable space savings, especially
178: for large-scale software systems whose architectures consist of numerous
179: components. In order to compute an architectural slice, we present the {\it architecture
180: information flow graph} which can be used to represent
181: information flows in a software architecture. Based on the graph, we give
182: a two-phase algorithm to compute an architectural slice.
183:
184:
185: %The primary idea of this work has been presented in \cite{Zhao97a,Zhao97b},
186: %and this article can be regarded as an outgrowth of our previous work.
187:
188: The rest of the paper is organized as follows.
189: Section \ref{sec:wright} briefly introduces how to represent a software architecture using W{\sc right}: an architectural description language. Section \ref{sec:example} shows
190: a motivation example. Section \ref{sec:sslicing} defines some notions about
191: slicing software architectures. Section \ref{sec:depen} presents the
192: architecture information flow graph for software architectures .
193: Section \ref{sec:comp} gives a two-phase algorithm for computing an
194: architectural slice. Section \ref{sec:work} discusses the related work.
195: Concluding remarks are given in Section \ref{sec:final}.
196:
197: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
198: \begin{figure*}[t]
199: \renewcommand{\arraystretch}{0.85}
200: %\setlength{\tabcolsep}{1.5pt}
201: {\sf
202: \begin{center}
203: {\scriptsize
204: \begin{tabular}{l}
205: {\bf Configuration} GasStation\\
206: \qquad{\bf Component} Customer\\
207: \qqqquad {\bf Port} Pay = \underline{pay!x} $\rightarrow$ Pay\\
208: \qqqquad {\bf Port} Gas = \underline{take} $\rightarrow$ pump$?$x $\rightarrow$ Gas\\
209: \qqqquad {\bf Computation} = \underline{Pay.pay!x} $\rightarrow$ \underline{Gas.take} $\rightarrow$ Gas.pump$?$x $\rightarrow$ Computation\\
210:
211: \qquad{\bf Component} Cashier\\
212: \qqqquad {\bf Port} Customer1 = pay$?$x $\rightarrow$ Customer1\\
213: \qqqquad {\bf Port} Customer2 = pay$?$x $\rightarrow$ Customer2\\
214: \qqqquad {\bf Port} Topump = \underline{pump!x} $\rightarrow$ Topump\\
215: \qqqquad {\bf Computation} = Customer1.pay$?$x $\rightarrow$ \underline{Topump.pump!x} $\rightarrow$
216: Computation\\
217: \qqqqqquad [] Customer2.pay$?$x $\rightarrow$ \underline{Topump.pump!x} $\rightarrow$ Computation\\
218:
219: \qquad{\bf Component} Pump\\
220: \qqqquad {\bf Port} Oil1 = take $\rightarrow$ \underline{pump!x} $\rightarrow$ Oil1\\
221: \qqqquad {\bf Port} Oil2 = take $\rightarrow$ \underline{pump!x} $\rightarrow$ Oil2\\
222: \qqqquad {\bf Port} Fromcashier = pump$?$x $\rightarrow$ Fromcashier\\
223: \qqqquad {\bf Computation} = Fromcashier.pump$?$x $\rightarrow$ \\
224: \qqqqqquad (Oil1.take $\rightarrow$ \underline{Oil1.pump!x} $\rightarrow$ Computation)\\
225: \qqqqqquad [] (Oil2.take $\rightarrow$ \underline{Oil2.pump!x} $\rightarrow$ Computation)\\
226:
227: \qquad{\bf Connector} Customer\_Cashier\\
228: \qqqquad {\bf Role} Givemoney = \underline{pay!x} $\rightarrow$ Givemoney\\
229: \qqqquad {\bf Role} Getmoney = pay$?$x $\rightarrow$ Getmoney\\
230: \qqqquad {\bf Glue} = Givemoney.pay$?$x $\rightarrow$ \underline{Getmoney.pay!x} $\rightarrow$ Glue\\
231:
232: \qquad{\bf Connector} Customer\_Pump\\
233: \qqqquad {\bf Role} Getoil = \underline{take} $\rightarrow$ pump$?$x $\rightarrow$ Getoil\\
234: \qqqquad {\bf Role} Giveoil = take $\rightarrow$ \underline{pump!x} $\rightarrow$ Giveoil\\
235: \qqqquad {\bf Glue} = Getoil.take $\rightarrow$ \underline{Giveoil.take} $\rightarrow$ Giveoil.pump$?$x $\rightarrow$ \underline{Getoil.pump!x} $\rightarrow$ Glue\\
236:
237: \qquad{\bf Connector} Cashier\_Pump\\
238: \qqqquad {\bf Role} Tell = \underline{pump!x} $\rightarrow$ Tell\\
239: \qqqquad {\bf Role} Know = pump$?$x $\rightarrow$ Know\\
240: \qqqquad {\bf Glue} = Tell.pump$?$x $\rightarrow$ \underline{Know.pump!x} $\rightarrow$ Glue\\
241:
242: \qquad{\bf Instances}\\
243: \qqqquad Customer1: Customer\\
244: \qqqquad Customer2: Customer\\
245: \qqqquad cashier: Cashier\\
246: \qqqquad pump: Pump\\
247: \qqqquad Customer1\_cashier: Customer\_Cashier\\
248: \qqqquad Customer2\_cashier: Customer\_Cashier\\
249: \qqqquad Customer1\_pump: Customer\_Pump\\
250: \qqqquad Customer2\_pump: Customer\_Pump\\
251: \qqqquad cashier\_pump: Cashier\_Pump\\
252:
253: \qquad{\bf Attachments}\\
254: \qqqquad Customer1.Pay as Customer1\_cashier.Givemoney\\
255: \qqqquad Customer1.Gas as Customer1\_pump.Getoil\\
256: \qqqquad Customer2.Pay as Customer2\_cashier.Givemoney\\
257: \qqqquad Customer2.Gas as Customer2\_pump.Getoil\\
258: \qqqquad casier.Customer1 as Customer1\_cashier.Getmoney\\
259: \qqqquad casier.Customer2 as Customer2\_cashier.Getmoney\\
260: \qqqquad cashier.Topump as cashier\_pump.Tell\\
261: \qqqquad pump.Fromcashier as cashier\_pump.Know\\
262: \qqqquad pump.Oil1 as Customer1\_pump.Giveoil\\
263: \qqqquad pump.Oil2 as Customer2\_pump.Giveoil\\
264: {\bf End} GasStation.\\
265: \\
266: \end{tabular}
267: }
268: \end{center}
269: }
270: % \normalsize
271:
272: \caption{\label{fig:wright} An architectural specification in W{\sc right}.}
273:
274: \end{figure*}
275: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
276:
277: \begin{figure}[t]
278: \begin{center}
279: %\hspace*{.7cm}
280: \epsfile{file=fig2.eps,scale=0.85}
281: \caption{\label{fig:sys} The architecture of the Gas Station system.}
282: \end{center}
283: \end{figure}
284:
285: \vspace{3mm}
286: \section{Software Architectural Specification in W{\sc right}}
287: \label{sec:wright}
288: \vspace{3mm}
289:
290: We assume that readers are familiar with the basic concepts of software
291: architecture and architectural description language, and in this paper,
292: we use W{\sc right} architectural description language \cite{Allen97} as our target
293: language for formally representing software architectures. The selection of
294: W{\sc right} is based on that it supports to represent not only the
295: architectural structure but also the architectural behavior
296: of a software architecture.
297:
298: Below, we use a simple W{\sc right} architectural specification taken
299: from \cite{Naumovich97} as a sample to briefly introduce how
300: to use W{\sc right} to represent a software architecture. The
301: specification is showed in Figure \ref{fig:wright} which models
302: the system architecture of a Gas Station system \cite{Helmbold85}.
303:
304: \vspace{2mm}
305: \subsection{Representing Architectural Structure}
306: \vspace{2mm}
307:
308: %There are three design elements in W{\sc right} that can be used to represent
309: %a software architecture which include components, connectors and
310: %configurations.
311:
312: W{\sc right} uses a {\it configuration} to describe architectural structure
313: as graph of components and connectors.
314:
315: {\it Components} are computation units in the system.
316: In W{\sc right}, each component has an {\it interface}
317: defined by a set of {\it ports}. Each port identifies a point of
318: interaction between the component and its environment.
319:
320: {\it Connectors} are patterns of interaction between components.
321: In W{\sc right}, each connector has an {\it interface}
322: defined by a set of {\it roles}. Each role defines
323: a participant of the interaction represented by the connector.
324:
325: A W{\sc right} architectural specification of a system is
326: defined by a set of component and connector type definitions,
327: a set of instantiations of specific objects of these types,
328: and a set of {\it attachments}. Attachments specify which components
329: are linked to which connectors.
330:
331: For example, in Figure \ref{fig:wright} there are three component
332: type definitions, \verb+Customer+, \verb+Cashier+ and \verb+Pump+,
333: and three connector type definitions, \verb+Customer_Cashier+,
334: \verb+Customer_Pump+ and \verb+Cashier_Pump+. The configuration is composed
335: of a set of instances and a set of attachments to specify the
336: architectural structure of the system.
337:
338: \vspace{2mm}
339: \subsection{Representing Architectural Behavior}
340: \vspace{2mm}
341:
342: W{\sc right} models architectural behavior according to the significant
343: events that take place in the computation of components, and the
344: interactions between components as described by the connectors.
345: The notation for specifying event-based behavior is adapted from
346: CSP \cite{Hoare85}. Each CSP process defines an alphabet of events and the
347: permitted patterns of events that the process may exhibit. These
348: processes synchronize on common events (i.e., interact)
349: when composed in parallel. W{\sc right} uses such process descriptions
350: to describe the behavior of ports, roles, computations and glues.
351:
352: A {\it computation} specification specifies a component's behavior:
353: the way in which it accepts certain events on certain {\it ports}
354: and produces new events on those or other ports. Moreover, W{\sc right}
355: uses an overbar to distinguish initiated events from observed events
356: \footnote{In this paper, we use an underbar to represent an initiated
357: event instead of an overbar that used in the original W{\sc right}
358: language definition \cite{Allen97}.}.
359: For example, the \verb+Customer+
360: initiates \verb+Pay+ action (i.e., \underline{\verb+pay!x+})
361: while the \verb+Cashier+ observes it (i.e., \verb+pay?x+).
362:
363: A {\it port} specification specifies the local protocol with which the
364: component interacts with its environment through that port.
365:
366: A {\it role} specification specifies the protocol that must be satisfied
367: by any port that is attached to that role.
368: Generally, a port need no have the same behavior as the role that it fills,
369: but may choose to use only a subset of the connector capabilities.
370: For example, the \verb+Customer+ role \verb+Gas+ and the \verb+Customer_Pump+
371: port \verb+Getoil+ are identical.
372:
373: A {\it glue} specification specifies how the roles of a connector interact
374: with each other. For example, a \verb+Cashier_Pump+ tell (Tell.pump$?$x) must
375: be transmitted to the \verb+Cashier_Pump+ know (\underline{\verb+Know.pump!x+}).
376:
377: As a result, based on formal W{\sc right} architectural specifications,
378: we can infer which ports of a component are input ports and which are
379: output ports. Also, we can infer which roles are input roles and which are
380: output roles. Moreover, the direction in which the information transfers
381: between ports and/or roles can also be inferred based on the
382: formal specification. As we will show in Section \ref{sec:depen}, such
383: kinds of information can be used to construct the information flow graph
384: for a software architecture for computing an architectural slice
385: efficiently.
386:
387: \vspace{2mm}
388: In order to focus on the key ideas of architectural slicing, in this paper
389: we assume that a software architecture be represented by a formal
390: architectural specification which contains three basic types of design
391: entities, namely, {\it components} whose interfaces are defined by a set
392: of elements called {\it ports}, {\it connectors} whose interfaces are
393: defined by a set of elements called {\it roles} and
394: the {\it configuration} whose topology is declared by a set of elements
395: called {\it instances} and {\it attachments}. Moreover, each component has a
396: special element called {\it computation} and each connector has a special
397: element called {\it glue} as we described above.
398:
399: In the rest of the paper, we assume that an architectural specification $P$
400: be denoted by $(C_{m}, C_{n}, c_{g})$ where:
401: \begin{itemize}
402: \item $C_{m}$ is the set of components in $P$,
403: \item $C_{n}$ is the set of connectors in $P$, and
404: \item $c_{g}$ is the configuration of $P$.
405: \end{itemize}
406:
407:
408: \vspace{3mm}
409: \section{Motivation Example}
410: \label{sec:example}
411: \vspace{3mm}
412:
413: We present a simple example to explain our approach on
414: architectural slicing. The example also shows one application
415: of architectural slicing, in which it is used in the impact analysis
416: of software architectures.
417:
418: Consider the Gas Station system whose architectural representation
419: is shown in Figure \ref{fig:sys}, and W{\sc right} specification is shown in
420: Figure \ref{fig:wright}. Suppose a maintainer needs to modify the
421: component \verb+cashier+ in the architectural specification in
422: order to satisfy some new design requirements. The first thing
423: the maintainer has to do is to investigate which components
424: and connectors interact with component \verb+cashier+ through
425: its ports \verb+Customer1+, \verb+Customer2+, and \verb+Topump+.
426: A common way is to manually check
427: the source code of the specification to find such information. However,
428: it is very time-consuming and error-prone even for a small size
429: specification because there may be complex dependence relations
430: between components in the specification. If the maintainer has an architectural slicer at hand, the work may probably be simplified and automated without the
431: disadvantages mentioned above. In such a scenario, an architectural slicer
432: is invoked, which takes as input: (1) a complete architectural specification
433: of the system, and (2) a set of ports of the component \verb+cashier+,
434: i.e., \verb+Customer1+, \verb+Customer2+ and \verb+Topump+ (this is an
435: {\it architectural slicing criterion}). The slicer then computes a
436: backward
437: and forward architectural slice respectively with respect to the
438: criterion and outputs them to the maintainer.
439: A backward architectural slice is a partial specification of the original one
440: which includes those components and connectors that might affect the
441: component \verb+cashier+ through the ports in the criterion, and a forward
442: architectural slice is a partial specification of the original
443: one which includes those components and connectors that might be
444: affected by the component \verb+cashier+ through the ports in the
445: criterion. The other parts of the specification that might not affect or
446: be affected by the component \verb+cashier+ will be removed,
447: i.e., sliced away from the original specification. The maintainer can
448: thus examine only the contents included in a slice to investigate
449: the impact of modification. Using the algorithm we will present in
450: Section \ref{sec:comp}, the slice shown in Figure \ref{fig:wright.slice}
451: can be computed.
452:
453: \vspace{3mm}
454: \section{Architectural Slicing}
455: \label{sec:sslicing}
456: \vspace{3mm}
457:
458: Intuitively, an {\it architectural slice} may be viewed as a subset
459: of the behavior of a software architecture, similar to the original notion
460: of the traditional static slice. However, while a traditional slice intends
461: to isolate the behavior of a specified set of program variables,
462: an architectural slice intends to isolate the behavior of a specified set
463: of a component or connector's elements. Given an architectural
464: specification $P=(C_{m}, C_{n}, c_{g})$, our goal is to compute an
465: architectural slice $S_{p}=(C_{m}', C_{n}', c_{g}')$ which should
466: be a ``sub-architecture'' of $P$ and preserve partially the
467: semantics of $P$. To define the meanings of the word ``sub-architecture,''
468: we introduce the concepts of a reduced component, connector and
469: configuration.
470:
471: \begin{definition}\label{def:rcomp}
472: Let $P=(C_{m}, C_{n}, c_{g})$ be an architectural specification
473: and $c_{m} \in C_{m}$, $c_{n} \in C_{n}$, and $c_{g}$
474: be a component, connector, and configuration of $P$
475: respectively:
476:
477: \begin{itemize}
478: \item A {\em reduced component} of $c_{m}$ is a
479: component $c_{m}'$ that is derived from
480: $c_{m}$ by removing zero, or more elements from $c_{m}$.
481:
482: \item A {\em reduced connector} of $c_{n}$ is a
483: connector $c_{n}'$ that is derived from
484: $c_{n}$ by removing zero, or more elements from $c_{n}$.
485:
486: \item A {\em reduced configuration} of $c_{g}$ is a
487: configuration $c_{g}'$ that is derived
488: from $c_{g}$ by removing zero, or more elements
489: from $c_{g}$.
490: \end{itemize}
491: \end{definition}
492:
493: The above definition showed that a reduced component, connector,
494: or configuration of a component, connector, or configuration may equal
495: itself in the case that none of its elements has been removed,
496: or an {\it empty} component, connector, or
497: configuration in the case that all its elements have been removed.
498:
499:
500: %%%%%%%%%%%%%%%%%!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
501: For example, the followings show a component \verb+Customer+, a
502: connector \verb+Customer_Cashier+, and a configuration as well as
503: their corresponding reduced component, connector, and configuration.
504: The small rectangles represent those ports, roles, or instances
505: and attachments that have been removed from the original component,
506: connector, or configuration.\\
507:
508: (1) The component \verb+Customer+ and its reduced component (with * mark)
509: in which the port \verb+Gas+ and elements \underline{\verb+Gas.take+} and
510: \verb+Gas.pump?x+ that are related to \verb+Gas+ in the computation have
511: been removed.
512:
513: {\sf\footnotesize
514: \begin{center}
515: \begin{tabular}{l}
516: {\bf Component} Customer\\
517: \qquad {\bf Port} Pay = \underline{pay!x} $\rightarrow$ Pay\\
518: \qquad {\bf Port} Gas = \underline{take} $\rightarrow$ pump$?$x $\rightarrow$ Gas\\
519: \qquad {\bf Computation} = \underline{Pay.pay!x} $\rightarrow$ \underline{Gas.take} \\
520: \qqqqqqqqquad $\rightarrow$ Gas.pump$?$x $\rightarrow$ Computation\\
521: \\
522:
523: {\bf * Component} Customer\\
524: \qquad {\bf Port} Pay = \underline{pay!x} $\rightarrow$ Pay\\
525: \qquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
526: \qquad {\bf Computation} = \underline{Pay.pay!x} $\rightarrow$ $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$ \\
527: \qqqqqqqqquad $\rightarrow$ $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$ $\rightarrow$ Computation\\
528: \end{tabular}
529: \end{center}
530: }
531:
532: (2) The connector \verb+Customer_Cashier+ and its reduced connector
533: (with * mark) in which the role \verb+Givemoney+ and the element
534: \verb+Givemoney.pay?x+ that is related to \verb+Givemoney+ in the glue
535: have been removed.
536:
537: {\sf\footnotesize
538: \begin{center}
539: \begin{tabular}{l}
540: {\bf Connector} Customer\_Cashier\\
541: \qquad {\bf Role} Givemoney = \underline{pay!x} $\rightarrow$ Givemoney\\
542: \qquad {\bf Role} Getmoney = pay$?$x $\rightarrow$ Getmoney\\
543: \qquad {\bf Glue} = Givemoney.pay$?$x $\rightarrow$ \underline{Getmoney.pay!x} \\
544: \qqqqqquad $\rightarrow$ Glue\\
545: \\
546: {\bf * Connector} Customer\_Cashier\\
547: \qquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
548: \qquad {\bf Role} Getmoney = pay$?$x $\rightarrow$ Getmoney\\
549: \qquad {\bf Glue} = $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$ $\rightarrow$ \underline{Getmoney.pay!x}\\
550: \qqqqqquad $\rightarrow$ Glue\\
551:
552: \end{tabular}
553: \end{center}
554: }
555:
556:
557: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
558: (3) The configuration and its reduced configuration (with * mark) in which
559: some instances and attachments have been removed.
560:
561: {\renewcommand{\arraystretch}{0.9}
562: {\sf
563: \begin{center}
564: {\footnotesize
565: \begin{tabular}{l}
566: {\bf Instances}\\
567: \qquad Customer1: Customer\\
568: \qquad Customer2: Customer\\
569: \qquad cashier: Cashier\\
570: \qquad pump: Pump\\
571: \qquad Customer1\_cashier: Customer\_Cashier\\
572: \qquad Customer2\_cashier: Customer\_Cashier\\
573: \qquad Customer1\_pump: Customer\_Pump\\
574: \qquad Customer2\_pump: Customer\_Pump\\
575: \qquad cashier\_pump: Cashier\_Pump\\
576:
577: {\bf Attachments}\\
578: \qquad Customer1.Pay as Customer1\_cashier.Givemoney\\
579: \qquad Customer1.Gas as Customer1\_pump.Getoil\\
580: \qquad Customer2.Pay as Customer2\_cashier.Givemoney\\
581: \qquad Customer2.Gas as Customer2\_pump.Getoil\\
582: \qquad casier.Customer1 as Customer1\_cashier.Getmoney\\
583: \qquad casier.Customer2 as Customer2\_cashier.Getmoney\\
584: \qquad cashier.Topump as cashier\_pump.Tell\\
585: \qquad pump.Fromcashier as cashier\_pump.Know\\
586: \qquad pump.Oil1 as Customer1\_pump.Giveoil\\
587: \qquad pump.Oil2 as Customer2\_pump.Giveoil\\
588: \\
589: \end{tabular}
590: }
591: \end{center}
592: }
593:
594:
595: {\renewcommand{\arraystretch}{0.9}
596: {\sf
597: \begin{center}
598: {\footnotesize
599: \begin{tabular}{l}
600: {\bf * Instances}\\
601: \qquad Customer1: Customer\\
602: \qquad Customer2: Customer\\
603: \qquad cashier: Cashier\\
604: \qquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
605: \qquad Customer1\_cashier: Customer\_Cashier\\
606: \qquad Customer2\_cashier: Customer\_Cashier\\
607: \qquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
608: \qquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
609: \qquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
610: {\bf *Attachments}\\
611: \qquad Customer1.Pay as Customer1\_cashier.Givemoney\\
612: \qquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
613: \qquad Customer2.Pay as Customer2\_cashier.Givemoney\\
614: \qquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
615: \qquad casier.Customer1 as Customer1\_cashier.Getmoney\\
616: \qquad casier.Customer2 as Customer2\_cashier.Getmoney\\
617: \qquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
618: \qquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
619: \qquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
620: \qquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
621: \\
622:
623: \end{tabular}
624: }
625: \end{center}
626: }
627:
628: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
629:
630: Having the definitions of a reduced component, connector and
631: configuration, we can define the meaning of the word ``sub-architecture''.
632:
633: \begin{definition}\label{def:rad}
634: Let $P=(C_{m}, C_{n}, c_{g})$ and $P'=(C_{m}', C_{n}',
635: c_{g}')$ be two architectural specifications.
636: Then $P'$ is a {\em reduced architectural specification} of $P$
637: if:
638:
639: \begin{itemize}
640: \item $C_{m}'=\{c_{m_{1}}',c_{m_{2}}',\ldots,
641: c_{m_{k}}'\}$ is a ``subset'' of $C_{m}=\{c_{m_{1}},c_{m_{2}},\ldots,
642: c_{m_{k}}\}$ such that for $i=1,2,\ldots,k$, $c_{m_{i}}'$ is a
643: reduced component of $c_{m_{i}}$,
644:
645: \item $C_{n}'=\{c_{n_{1}}',c_{n_{2}}',\ldots,
646: c_{n_{k}}'\}$ is a ``subset'' of
647: $C_{n}=\{c_{n_{1}},c_{n_{2}},\ldots,c_{n_{k}}\}$ such that for
648: $i=1,2,\ldots,k$, $c_{n_{i}}'$ is a reduced connector of $c_{n_{i}}$,
649:
650: \item $c_{g}'$ is a reduced configuration of $c_{g}$,
651: \end{itemize}
652: \end{definition}
653:
654: Having the definition of a reduced architectural specification,
655: we can define some notions about slicing software architectures.
656:
657: In a W{\sc right} architectural specification, for example,
658: a component's interface is defined to be
659: a set of ports which identify the form of the component interacting with
660: its environment, and a connector's interface is defined to be a set of roles
661: which identify the form of the connector interacting with its environment.
662: To understand how a component interacts with
663: other components and connectors for making changes, a maintainer must
664: examine each port of the component of interest. Moreover, it has been
665: frequently emphasized that connectors are as important as components for
666: architectural design, and a maintainer may also want to modify a connector
667: during the maintenance. To satisfy these requirements, for example,
668: we can define a slicing criterion for a W{\sc right} architectural
669: specification as a set of ports of a component or a set of roles of a
670: connector of interest.
671:
672: \begin{definition}
673: Let $P=(C_{m}, C_{n}, c_{g})$ be an architectural specification.
674: A {\em slicing criterion} for $P$ is a pair $(c, E)$ such that:
675:
676: \begin{itemize}
677: \item[1.] $c \in C_{m}$ and $E$ is a set of elements of $c$, or
678: \item[2.] $c \in C_{n}$ and $E$ is a set of elements of $c$.
679: \end{itemize}
680: \end{definition}
681:
682: Note that the selection of a slicing criterion depends on users' interests
683: on what they want to examine. If they are interested in examining a
684: component in an architectural specification, they may use slicing criterion 1.
685: If they are interested in examining a connector, they may use slicing
686: criterion 2. Moreover, the determination of the set $E$ also depends
687: on users' interests on what they want to examine. If they want to examine a
688: component, then $E$ may be the set of ports or just a subset of ports
689: of the component. If they want to examine a connector,
690: then $E$ may be the set of roles or just a subset of roles of the connector.
691:
692: \begin{definition}\label{def:slice}
693: Let $P=(C_{m}, C_{n}, c_{g})$ be an architectural specification.
694: \begin{itemize}
695: \item A {\em backward architectural slice}
696: $S_{bp}=(C_{m}', C_{n}', C_{g}')$ of $P$ on a given slicing
697: criterion $(c, E)$ is a reduced architectural specification
698: of $P$ which contains only those reduced components, connectors,
699: and configuration that might directly or indirectly affect
700: the behavior of $c$ through elements in $E$.
701: \item {\em Backward-slicing} an architectural specification $P$ on
702: a given slicing criterion is to find the backward
703: architectural slice of $P$ with respect to the criterion.
704: \end{itemize}
705: \end{definition}
706:
707: \begin{definition}\label{def:fslice}
708: Let $P=(C_{m}, C_{n}, c_{g})$ be an architectural specification.
709: \begin{itemize}
710: \item A {\em forward architectural slice}
711: $S_{fp}=(C_{m}', C_{n}', C_{g}')$ of $P$ on a given slicing
712: criterion $(c, E)$ is a reduced architectural specification
713: of $P$ which contains only those reduced components,
714: connectors, and configuration that might be directly or
715: indirectly affected by the behavior of $c$ through elements
716: in $E$.
717: \item {\em Forward-slicing} an architectural specification $P$ on
718: a given slicing criterion is to find the forward architectural
719: slice of $P$ with respect to the criterion.
720: \end{itemize}
721: \end{definition}
722:
723: From Definitions \ref{def:slice} and \ref{def:fslice}, it is obviously
724: that there is at least one backward slice and at least one forward slice
725: of an architectural specification that is the specification itself. Moreover,
726: the architecture represented by $S_{bp}$ or $S_{fp}$ should be
727: a ``sub-architecture'' of the architecture represented by $P$.
728:
729: Defining an architectural slice as a reduced architectural specification
730: of the original one is particularly useful for supporting
731: architectural reuse. By using an architectural slicer, a system designer
732: can automatically decompose an existing architecture (in the case that
733: its architectural specification is available) into some small
734: architectures each having its own functionality which may be reused
735: in new system designs. Moreover, the view of an architectural slice
736: as a reduced architectural specification dose not reduce its usefulness
737: when applied it to architectural understanding because it also contains enough
738: information for a maintainer to facilitate the modification.
739:
740: \begin{figure*}[t]
741: \begin{center}
742: \epsfile{file=fig3.eps,scale=0.85}
743: \caption{\label{fig:graph} The information flow graph of the architectural
744: specification in Figure {\protect\ref{fig:wright}}.}
745: \end{center}
746: \end{figure*}
747:
748: \vspace{3mm}
749: \section{The Information Flow Graph for Software Architectures}
750: \label{sec:depen}
751: \vspace{3mm}
752:
753: In this section, we present the architecture information flow graph
754: for software architectures on which architectural slices can be
755: computed efficiently.
756:
757: The architecture information flow graph is an arc-classified digraph
758: whose vertices represent the ports of
759: components and the roles of the connectors in an architectural specification,
760: and arcs represent possible information flows between components and/or
761: connectors in the specification.
762:
763: \begin{definition}
764: The {\em Architecture Information Flow Graph}\ (AIFG) of an
765: architectural specification $P$ is an arc-classified digraph
766: $(V_{com}, V_{con}, Com, Con, Int)$, where:
767: \begin{itemize}
768: \item $V_{com}$ is the set of port vertices of $P$;
769: \item $V_{con}$ is the set of role vertices of $P$;
770: \item $Com$ is the set of component-connector flow arcs;
771: \item $Con$ is the set of connector-component flow arcs;
772: \item $Int$ is the set of internal flow arcs.
773: \end{itemize}
774: \end{definition}
775:
776: There are three types of information flow arcs in the AIFG, namely,
777: {\it component-connector flow arcs}, {\it connector-component flow arcs},
778: and {\it internal flow arcs}.
779:
780: Component-connector flow arcs are used to represent information flows
781: between a port of a component and a role of a connector in an architectural
782: specification. Informally, if there is an information flow from a port
783: of a component to a role of a connector in the specification, then there
784: is a component-connector flow arc in the AIFG which connects the
785: corresponding port vertex to the corresponding role vertex.
786: For example, from the W{\sc right} specification shown in Figure \ref{fig:wright},
787: we can know that there is an information flow from the
788: port \verb+Topump+ of the component \verb+cashier+ to
789: the role \verb+Tell+ of the connector \verb+cashier_pump+.
790: Therefore there is a component-connector flow arc in the AIFG in
791: Figure \ref{fig:graph} which connects the port vertex of port
792: \verb+Topump+ to the role vertex of role \verb+Tell+.
793:
794: Connector-component flow arcs are used to represent information flows
795: between a role of a connector and a port of a component in an architectural
796: specification. Informally, if there is an information flow from a role of
797: a connector to a port of a component in the specification, then there
798: is a connector-component flow arc in the AIFG which connects the
799: corresponding role vertex to the corresponding port vertex.
800: For example,
801: from the W{\sc right} specification in Figure \ref{fig:wright}, we can know that there
802: is an information flow from the role \verb+Know+ of the connector
803: \verb+cashier_pump+ to the port \verb+Fromcashier+ of the
804: component \verb+pump+. Therefore, there is a connector-component
805: flow arc in the AIFG in Figure \ref{fig:graph} which connects the role vertex
806: for role \verb+Know+ to the port vertex for port \verb+Fromcashier+.
807:
808: Internal flow arcs are used to represent internal information flows
809: within a component or connector in an architectural specification.
810: Informally, for a component in the specification, there is an internal
811: flow from an input port to an output port, and for a connector
812: in the specification, there is an internal flow from an input role
813: to an output role.
814: For example, in Figure \ref{fig:wright}, there is an internal flow
815: from the role \verb+Givemoney+ to the role \verb+Getmoney+ of
816: the connector \verb+Customer1_cashier+ and also an internal flow arc
817: from the port \verb+Fromcashier+ to the port \verb+Oil1+ of component \verb+pump+.
818:
819: As we introduced in Section \ref{sec:wright}, W{\sc right} uses CSP-based
820: model to specify the behavior of a component and a connector of a
821: software architecture. W{\sc right} allows user to infer which ports of
822: a component are input and which are output, and which roles of a
823: connector are input and which are output based on a W{\sc right}
824: architectural specification. Moreover, it also allows user to infer
825: the direction in which the information transfers between ports and/or roles.
826: As a result, by using a static analysis tool which takes an architectural
827: specification as its input, we can construct the AIFG of a
828: W{\sc right} architectural specification automatically.
829:
830: Figure \ref{fig:graph} shows the AIFG of
831: the architectural specification in Figure \ref{fig:wright}. In the figure,
832: large squares represent components in the specification, and small
833: squares represent the ports of each component. Each port vertex has
834: a name described by {\it component\_name.port\_name}. For example,
835: $pv5$ (\verb+cashier.Customer1+) is a port vertex
836: that represents the port \verb+Customer1+ of the
837: component \verb+cashier+.
838: Large circles represent connectors in the specification,
839: and small circles represent the roles of each connector. Each role
840: vertex has a name described by {\it connector\_name.role\_name}.
841: For example, $rv5$ (\verb+cashier_pump.Tell+)
842: is a role vertex that represents the role
843: \verb+Tell+ of the connector \verb+cashier_pump+. The
844: complete specification of each vertex is shown on the right side
845: of the figure.
846:
847: Solid arcs represent component-connector flow arcs that
848: connect a port of a component to a role of a connector. Dashed arcs represent
849: connector-component flow arcs that connect a role of a connector to a port
850: of a component. Dotted arcs represent internal flow arcs that connect
851: two ports within a component (from an input port to an output port),
852: or two roles
853: within a connector (from an input role to an output role).
854: For example, $(rv2,pv5)$ and $(rv6,pv8)$ are connector-component flow arcs.
855: $(pv7,rv5)$ and $(pv9,rv8)$ are component-connector flow arcs. $(rv1,rv2)$
856: and $(pv8,pv10)$ are internal flow arcs.
857:
858: \begin{figure*}[t]
859: \begin{center}
860: \epsfile{file=fig4.eps,scale=0.85}
861: \caption{\label{fig:graph.slice} A slice over the AIFG of the
862: architectural specification in Figure {\protect\ref{fig:wright}}.}
863: \end{center}
864: \end{figure*}
865:
866: \vspace{3mm}
867: \section{Computing Architectural Slices}
868: \label{sec:comp}
869: \vspace{3mm}
870:
871: The slicing notions defined in Section \ref{sec:sslicing} give us
872: only a general view
873: of an architectural slice, and do not tell us how to compute it.
874: In this section we present a two-phase algorithm to compute a slice of an
875: architectural specification based on its information flow graph.
876: %Similar to those for traditional slicing
877: %\cite{Horwitz90,Ottenstein84},
878: Our algorithm contains two phases: (1) Computing a slice $S_{g}$ over the
879: information flow graph of an architectural specification,
880: and (2) Constructing an architectural slice $S_{p}$ from $S_{g}$.
881:
882: \vspace{2mm}
883: \subsection{Computing a Slice over the AIFG}
884: \vspace{2mm}
885:
886: Let $P=(C_{m}, C_{n}, c_{g})$ be an architectural specification
887: and $G=(V_{com},V_{con}, Com, Con, Int)$ be the AIFG of $P$.
888: To compute a slice
889: over the $G$, we refine the slicing notions defined in
890: Section \ref{sec:sslicing} as follows:
891:
892: {\it
893: \begin{itemize}
894: \item A {\em slicing criterion} for $G$ is a pair $(c,V_{c})$
895: such that: (1) $c \in C_{m}$ and $V_{c}$ is a set of port
896: vertices corresponding to the ports of $c$, or (2) $c
897: \in C_{n}$ and $V_{c}$ is a set of role vertices
898: corresponding to roles of $c$.
899:
900: \item The {\em backward slice} $S_{bg}(c,V_{c})$ of $G$ on a given
901: slicing
902: criterion $(c,V_{c})$ is a subset of vertices of $G$ such
903: that for any vertex $v$ of $G$, $v \in S_{bg}(c,V_{c})$ iff
904: there exists a path from $v$ to $v' \in V_{c}$ in the AIFG.
905:
906: \item The {\em forward slice} $S_{fg}(c,V_{c})$ of $G$ on a
907: given slicing criterion $(c,V_{c})$ is a subset of
908: vertices of $G$ such that for any vertex $v$ of $G$, $v
909: \in S_{fg}(c,V_{c})$ iff there exists a path from
910: $v' \in V_{c}$ to $v$ in the AIFG.
911: \end{itemize}
912: }
913:
914: According to the above descriptions, the computation of a backward slice
915: or forward slice over the AIFG can be solved by using an usual
916: depth-first or breath-first graph traversal algorithm to traverse the
917: graph by taking some port or role vertices of interest as the start
918: point of interest.
919:
920: Figure \ref{fig:graph.slice} shows a backward slice over the AIFG with respect
921: to the slicing criterion $(\verb+cashier+, V_{c})$ such that
922: $V_{c}=\{pv5, pv6, pv7\}$.
923:
924: \vspace{2mm}
925: \subsection{Computing an Architectural Slice}
926: \vspace{2mm}
927:
928: The slice $S_{g}$ computed above is only a slice
929: over the AIFG of an architectural specification, which is a set of
930: vertices of the AIFG. Therefore we should map each element in
931: $S_{g}$ to the source code of the specification.
932: Let $P=(C_{m}, C_{n}, c_{g})$ be an architectural specification and
933: $G=(V_{com}, V_{con}, Com, Con, Int)$ be the AIFG of $P$.
934: By using the concepts of a reduced component, connector, and configuration
935: introduced in Section \ref{sec:sslicing}, a slice
936: $S_{p} = (C_{m}', C_{n}', c_{g}')$ of an architectural specification
937: $P$ can be constructed in the following steps:
938:
939: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
940: \begin{figure*}[t]
941: \renewcommand{\arraystretch}{0.85}
942: %\setlength{\tabcolsep}{1.5pt}
943: {\sf
944: \begin{center}
945: {\scriptsize
946: \begin{tabular}{l}
947: {\bf Configuration} GasStation\\
948: \qquad{\bf Component} Customer\\
949: \qqqquad {\bf Port} Pay = \underline{pay!x} $\rightarrow$ Pay\\
950: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
951: \qqqquad {\bf Computation} = \underline{Pay.pay!x} $\rightarrow$ \underline{Gas.take} $\rightarrow$ Gas.pump$?$x $\rightarrow$ Computation\\
952:
953: \qquad{\bf Component} Cashier\\
954: \qqqquad {\bf Port} Customer1 = pay$?$x $\rightarrow$ Customer1\\
955: \qqqquad {\bf Port} Customer2 = pay$?$x $\rightarrow$ Customer2\\
956: \qqqquad {\bf Port} Topump = \underline{pump!x} $\rightarrow$ Topump\\
957: \qqqquad {\bf Computation} = Customer1.pay$?$x $\rightarrow$ \underline{Topump.pump!x} $\rightarrow$
958: Computation\\
959: \qqqqqquad [] Customer2.pay$?$x $\rightarrow$ \underline{Topump.pump!x} $\rightarrow$ Computation\\
960:
961: \qquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
962: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
963: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
964: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
965: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
966: \qqqqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
967: \qqqqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
968: \qquad{\bf Connector} Customer\_Cashier\\
969: \qqqquad {\bf Role} Givemoney = \underline{pay!x} $\rightarrow$ Givemoney\\
970: \qqqquad {\bf Role} Getmoney = pay$?$x $\rightarrow$ Getmoney\\
971: \qqqquad {\bf Glue} = Givemoney.pay$?$x $\rightarrow$ \underline{Getmoney.pay!x} $\rightarrow$ Glue\\
972: \qquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
973: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
974: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
975: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
976: \qquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
977: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
978: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
979: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
980: \qquad{\bf Instances}\\
981: \qqqquad Customer1: Customer\\
982: \qqqquad Customer2: Customer\\
983: \qqqquad cashier: Cashier\\
984: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
985: \qqqquad Customer1\_cashier: Customer\_Cashier\\
986: \qqqquad Customer2\_cashier: Customer\_Cashier\\
987: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
988: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
989: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
990: \qquad{\bf Attachments}\\
991: \qqqquad Customer1.Pay as Customer1\_cashier.Givemoney\\
992: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
993: \qqqquad Customer2.Pay as Customer2\_cashier.Givemoney\\
994: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
995: \qqqquad casier.Customer1 as Customer1\_cashier.Getmoney\\
996: \qqqquad casier.Customer2 as Customer2\_cashier.Getmoney\\
997: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
998: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
999: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
1000: \qqqquad $\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$$\Box$\\
1001: \qquad{\bf End} GasStation.\\
1002: \\
1003: \end{tabular}
1004: }
1005: \end{center}
1006: }
1007:
1008: \caption{\label{fig:wright.slice} A backward slice of the architectural
1009: specification in Figure {\protect\ref{fig:wright}}.}
1010:
1011: \end{figure*}
1012: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1013:
1014: \begin{itemize}
1015:
1016: \item[1.] Constructing a reduced component $c_{m}'$ from a component
1017: $c_{m}$ by removing all ports such that their corresponding
1018: port vertices in $G$ have not been included in $S_{g}$ and
1019: unnecessary elements in the computation from $c_{m}$.
1020: The reduced components $C_{m}'$ in $S_{p}$ have the same
1021: relative order as the components $C_{m}$ in $P$.
1022:
1023: \item[2.] Constructing a reduced connector $c_{n}'$ from a connector
1024: $c_{n}$ by removing all roles such that their corresponding
1025: role vertices in $G$ have not been included in $S_{g}$ and
1026: unnecessary elements in the glue from $c_{n}$.
1027: The reduced connectors $C_{n}'$ in $S_{p}$ have the same
1028: relative order as their corresponding connectors in $P$.
1029:
1030:
1031: \item[3.] Constructing the reduced configuration $c_{g}'$ from the
1032: configuration $c_{g}$ by the following steps:
1033:
1034: \begin{itemize}
1035: \item Removing all component and connector instances from $c_{g}$
1036: that are not included in $C_{m}'$ and $C_{n}'$.
1037:
1038: \item Removing all attachments from $c_{g}$ such that there exists
1039: no two vertices $v_{1}$ and $v_{2}$ where
1040: $v_{1}, v_{2} \in S_{g}$ and \verb+v1 as v2+ represents
1041: an attachment.
1042:
1043: \item The instances and attachments in the reduced configuration
1044: in $S_{p}$ have the same relative order as their corresponding
1045: instances and attachments in $P$.
1046: \end{itemize}
1047:
1048: \end{itemize}
1049:
1050: Figure \ref{fig:wright.slice} shows a backward slice of the
1051: W{\sc right} specification in Figure \ref{fig:wright} with respect to
1052: the slicing criterion (\verb+cashier+, E) such that
1053: E=\{\verb+Customer1+, \verb+Customer2+, \verb+Topump+\}
1054: is a set of ports of component \verb+cashier+.
1055: The small rectangles represent the parts of specification that have been
1056: removed, i.e., sliced away from the original specification.
1057: The slice is obtained from a slice over the AIFG in Figure
1058: \ref{fig:graph.slice} according to the mapping process described above.
1059: Figure \ref{fig:sys-slice} shows the architectural representation of
1060: the slice in Figure \ref{fig:wright.slice}.
1061:
1062: \begin{figure}[t]
1063: \begin{center}
1064: \epsfile{file=fig5.eps,scale=0.85}
1065: \caption{\label{fig:sys-slice} The architectural representation of
1066: the slice in Figure {\protect\ref{fig:wright.slice}}.}
1067: \end{center}
1068: \end{figure}
1069:
1070: \vspace{3mm}
1071: \section{Related Work}
1072: \label{sec:work}
1073: \vspace{3mm}
1074:
1075: \vspace{2mm}
1076: \subsection{Software Architecture Dependence Analysis}
1077: \vspace{2mm}
1078:
1079: Perhaps, the most similar work with ours is that
1080: presented by Stafford, Richardson and Wolf \cite{Stafford97}, who
1081: introduced a software architecture dependence analysis technique,
1082: called {\it chaining} to support software architecture development such
1083: as debugging and testing. In chaining, links represent the dependence
1084: relationships that exist in an architectural specification. Links connect
1085: elements of the specification that are directly related, producing a chain of
1086: dependences similar to a slice in traditional slicing that can be followed
1087: during analysis. Although their consideration is similar to ours, there
1088: are still some differences between their work and ours. First,
1089: the slicing criterions are different. While Stafford, Richardson,
1090: and Wolf define a slicing criterion of an architectural specification
1091: as a set of ports of a component, we defined a slicing criterion as either
1092: a set of ports of a component or a set of roles of a connector of an
1093: architectural specification. This is because that in addition to modifying
1094: a component, in some cases, a maintainer may also want to modify a connector.
1095: Second, the types of architectural slices are different.
1096: Stafford, Richardson, and Wolf compute an architectural slice that
1097: includes only a set of components of an architectural specification, and
1098: therefore, it seems that their slices fail to capture the information
1099: concerning interactions between these components. In contrast, we compute
1100: an architectural slice that includes not only a set of components but also
1101: connectors (interactions between these components). Moreover, since
1102: our architectural slice is a reduced architectural specification
1103: of the original one and can also preserve the partial semantics of the
1104: original architectural specification, our slice is particularly useful
1105: in software architecture reuse.
1106:
1107: \vspace{2mm}
1108: \subsection{Class Slicing for C++}
1109: \vspace{2mm}
1110:
1111: Tip {\it et.al} \cite{Tip96} introduced an algorithm for slicing
1112: class hierarchies in C++ programs. Given a C++ class hierarchy
1113: (a collection of C++ class and inheritance relations among them)
1114: and a program that uses the hierarchy, the algorithm eliminates
1115: from the hierarchy those data members, member of
1116: functions, classes, and inheritance relations that are unnecessary for
1117: ensuring that the semantics of the program is maintained.
1118: The class slicing has the benefit of allowing unused components of
1119: classes to be eliminated in applications that do not use those
1120: components. In this aspect, our work is strongly inspired by their work in
1121: the sense that we also want to use architectural slicing to remove
1122: unused components at the architectural level of software systems
1123: to narrow the domain on which reasoning about bugs is performed
1124: during the debugging at the architectural level.
1125:
1126: \vspace{2mm}
1127: \subsection{Generalized Slicing}
1128: \vspace{2mm}
1129:
1130: Another work beyond traditional slicing is presented by Sloane
1131: and Holdsworth \cite{Sloane96}. They observed that two assumptions
1132: implicit in the definition of a traditional slice for programs written
1133: in imperative programming languages: (1) that variables
1134: and statements are concepts of the programming language in which
1135: program is written, and (2) that slices consist only of statements. For
1136: a language that does not have variables and statements, for example, a
1137: compiler specification language, traditional slicing does not make
1138: sense. To solve this problem, they introduced the generalized slicing
1139: as an extension of the traditional slicing by replacing variables
1140: with arbitrary named program entities and statements with arbitrary
1141: program constructs. This allows them to perform the slicing of
1142: non-imperative programs. Our work has a similar goal with theirs, but
1143: focuses specially on software architectures.
1144:
1145: \vspace{3mm}
1146: \section{Concluding Remarks}
1147: \label{sec:final}
1148: \vspace{3mm}
1149:
1150: \noindent
1151: We introduced a new form of slicing, named
1152: {\it architectural slicing} to aid architectural understanding and reuse.
1153: In contrast to the traditional
1154: slicing, architectural slicing is designed to operate on the architectural
1155: specification of a software system, rather than the source code of a
1156: program. Architectural slicing provides knowledge about the high-level
1157: structure of a software system, rather than the low-level
1158: implementation details of a program. In order to compute an
1159: architectural slice, we presented the {\it architecture information
1160: flow graph} to explicitly represent information flows in a formal
1161: architectural specification. Based on the graph, we gave a
1162: two-phase algorithm to compute an architectural slice.
1163:
1164: While our initial exploration used W{\sc right} as the architecture
1165: description language, the concept and approach of architectural slicing
1166: are language-independent. However, the implementation of
1167: an architectural slicing tool may differ from one architecture description
1168: language to another because each language has its own structure and
1169: syntax which must be handled carefully.
1170:
1171: In architectural description languages, in addition to provide both
1172: a conceptual framework and a concrete syntax for characterizing
1173: software architectures, they also provide tools for parsing,
1174: displaying, compiling, analyzing, or simulating architectural
1175: specifications written in their associated language. However,
1176: existing language environments provide no tools to support
1177: architectural understanding, maintenance, testing, and reuse
1178: from an engineering viewpoint. We believe that some static analysis
1179: tools such as an architectural slicing tool introduced in this paper and an
1180: architectural dependence analysis tool \cite{Stafford97,Zhao97a} should be
1181: provided by any ADL as an essential means to support these development
1182: activities.
1183:
1184: As future work, we would like to extend our approach presented here
1185: to handle other constructs in W{\sc right} language such as {\it styles}
1186: which were not considered here, and
1187: also to extend our approach to handle the slicing problem for
1188: other architecture description languages such as Rapide, ACME, and UniCon.
1189: %Moreover, we are also considering to apply the coordination theory
1190: %\cite{Malone94} to software architecture dependence analysis to identify all
1191: %primary dependence relationships between components.
1192: %Finally,
1193: To demonstrate the usefulness of our slicing approach,
1194: we are implementing a slicer for W{\sc right} architectural descriptions to
1195: support architectural level understanding and reuse.
1196: The next step for us is to perform some experiments to evaluate the
1197: usefulness of architectural slicing in practical development of
1198: software architectures.
1199: }
1200:
1201: \vspace{3mm}
1202: \noindent
1203: {\large\bf Acknowledgements}
1204: \vspace{3mm}
1205:
1206: The author would like to thank the anonymous referees for their valuable
1207: suggestions and comments on earlier drafts of the paper.
1208:
1209: \vspace{3mm}
1210:
1211: %{\small
1212: \renewcommand{\baselinestretch}{.9}
1213:
1214: \begin{thebibliography}{99}
1215:
1216: \bibitem{Agrawal93}
1217: H. Agrawal, R. Demillo, and E. Spafford,
1218: ``Debugging with Dynamic Slicing and Backtracking,''
1219: {\it Software-Practice and Experience}, Vol.23, No.6, pp.589-616, 1993.
1220:
1221: \bibitem{Allen97}
1222: R. Allen,
1223: ``A Formal Approach to Software Architecture,''
1224: PhD thesis, Department of Computer Science, Carnegie Mellon University, 1997.
1225:
1226: \bibitem{Bates93}
1227: S. Bates and S. Horwitz, ``Incremental Program Testing Using Program
1228: Dependence Graphs,'' {\it Conference Record of the 20th Annual ACM
1229: SIGPLAN-SIGACT Symposium of Principles of Programming Languages},
1230: pp.384-396, Charleston, South California, ACM Press, 1993.
1231:
1232: \bibitem{Beck93}
1233: J. Beck and D. Eichmann,
1234: ``Program and Interface Slicing for Reverse Engineering,''
1235: {\it Proceeding of the 15th International Conference on Software
1236: Engineering}, pp.509-518, Baltimore, Maryland, IEEE Computer Society Press, 1993.
1237:
1238: \bibitem{Cheng93}
1239: J. Cheng, ``Slicing Concurrent Programs -- A Graph-Theoretical
1240: Approach,'' {\em Lecture Notes in Computer Science}, Vol.749, pp.223-240,
1241: Springer-Verlag, 1993.
1242:
1243: \bibitem{DeLucia96}
1244: A. De Lucia, A. R. Fasolino, and M. Munro,
1245: ``Understanding function behaviors through program slicing,''
1246: {\it Proceedings of the Fourth Workshop on Program Comprehension},
1247: Berlin, Germany, March 1996.
1248:
1249: \bibitem{Ferrante87}
1250: J.Ferrante, K.J.Ottenstein, and J.D.Warren, ``The Program Dependence
1251: Graph and Its Use in Optimization,'' {\it ACM Transaction on
1252: Programming Language and System}, Vol.9, No.3, pp.319-349, 1987.
1253:
1254: \bibitem{Gallagher91}
1255: K. B. Gallagher and J. R. Lyle, ``Using Program Slicing in Software Maintenance,''
1256: {\it IEEE Transaction on Software Engineering}, Vol.17, No.8, pp.751-761, 1991.
1257:
1258: \bibitem{Garlan97}
1259: D. Garlan, R. Monroe, and D. Wile, ``ACME: An Architecture Description
1260: Interchange Language,'' {\it Proceedings of CASCON'97}, November 1997.
1261:
1262: \bibitem{Hoare85}
1263: C.A.R. Hoare,
1264: ``Communicating Sequential Processes,''
1265: Prentice Hall, 1985.
1266:
1267: \bibitem{Helmbold85}
1268: D. Helmbold and D. Luckham,
1269: ``Debugging Ada Tasking Programs,''
1270: {\it IEEE Software}, Vol.2, No.2, pp.47-57, 1985.
1271:
1272: \bibitem{Horwitz90}
1273: S. Horwitz, T. Reps, and D. Binkley,
1274: ``Interprocedural Slicing Using Dependence Graphs,''
1275: {\it ACM Transaction on Programming Language and System}, Vol.12,
1276: No.1, pp.26-60, 1990.
1277:
1278: \bibitem{Luckham95}
1279: D. C. Luckham, L. M. Augustin, J. J. Kenney, J. Veera, D. Bryan, and
1280: W. Mann,
1281: ``Specification Analysis of System Architecture Using Rapide,''
1282: {\it IEEE Transaction on Software Engineering}, Vol.21, No.4,
1283: pp.336-355, April 1995.
1284:
1285: \bibitem{Naumovich97}
1286: G. Naumovich, G.S. Avrunin, L.A. Clarke, and L.J.Osterweil,
1287: ``Applying Static Analysis to Software Architectures,''
1288: {\it Proceedings of the Sixth European Software Engineering Conference},
1289: LNCS, Vol.1301, pp.77-93,
1290: Springer-Verlag, 1997.
1291: v
1292: %\bibitem{ACME}
1293: %``ACME Version 3.0,''
1294: %The ABLE Project, Department of Computer Science, Carnegie Mellon University \\
1295: %\verb+http://www.cs.cmu.edu/~acme/+.
1296:
1297: \bibitem{Ning94}
1298: J. Q. Ning, A. Engberts, and W. Kozaczynski,
1299: ``Automated Support for Legacy Code Understanding,''
1300: {\it Communications of ACM}, Vol.37, No.5, pp.50-57, May 1994.
1301:
1302: \bibitem{Ottenstein84}
1303: K. J. Ottenstein and L. M. Ottenstein,
1304: ``The Program Dependence Graph in a software Development
1305: Environment,''
1306: {\it ACM Software Engineering Notes}, Vol.9, No.3, pp.177-184, 1984.
1307:
1308: \bibitem{Shaw95}
1309: M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. Young, and G.
1310: Zelesnik,
1311: ``Abstractions for Software Architecture and Tools to Support Them,''
1312: {\it IEEE Transaction on Software Engineering}, Vol.21, No.4,
1313: pp.314-335, April 1995.
1314:
1315: \bibitem{Shaw96}
1316: M. Shaw and D. Garlan,
1317: ``Software Architecture: Perspective on an Emerging Discipline,''
1318: Prentice Hall, 1996.
1319:
1320: \bibitem{Stafford97}
1321: J. A. Stafford, D. J. Richardson, and A. L. Wolf,
1322: ``Chaining: A Software Architecture Dependence Analysis Technique,''
1323: Technical Report CU-CS-845-97, Department of Computer Science, University
1324: of Colorado, September 1997.
1325:
1326: \bibitem{Sloane96}
1327: A. M. Sloane, J. Holdsworth,
1328: ``Beyond Traditional Program Slicing,''
1329: {\it Proceedings of the 1996 International Symposium on Software
1330: Testing and Analysis}, pp.180-186, January 1996.
1331:
1332: \bibitem{Tip95}
1333: F. Tip, ``A Survey of Program Slicing Techniques,''
1334: {\it Journal of Programming Languages}, Vol.3, No.3, pp.121-189, September, 1995.
1335:
1336: \bibitem{Tip96}
1337: F. Tip, J. D. Choi, J. Field, and G. Ramalingam
1338: ``Slicing Class Hierarchies in C++,''
1339: {\it Proceedings of the 11th Annual Conference on Object-Oriented
1340: Programming, Systems, Languages, and Applications}, pp.179-197, October, 1996.
1341:
1342: \bibitem{Weiser79}
1343: M. Weiser,
1344: ``Program Slices: Formal, Psychological, and Practical Investigations
1345: of an Automatic Program Abstraction Method,'' PhD thesis, University
1346: of Michigan, Ann Arbor, 1979.
1347:
1348: \bibitem{Zhao96}
1349: J. Zhao, J. Cheng and K. Ushijima,
1350: ``Static Slicing of Concurrent Object-Oriented Programs,''
1351: {\it Proc. of the COMPSAC'96}, pp.312-320, IEEE Computer
1352: Society Press, August 1996.
1353:
1354: \bibitem{Zhao97}
1355: J. Zhao, J. Cheng, and K. Ushijima,
1356: ``Slicing Concurrent Logic Programs,'' in T. Ida, A. Ohori and
1357: M. Takeichi (Eds.), {\it Second Fuji International Workshop on Functional
1358: and Logic Programming}, pp.143-162, World Scientific, 1997.
1359:
1360: \bibitem{Zhao97a}
1361: J. Zhao,
1362: ``Using Dependence Analysis to Support Software Architecture Understanding,''
1363: in M. Li (Ed.), {\it New Technologies on Computer Software},
1364: pp.135-142, International Academic Publishers, September 1997.
1365:
1366: \end{thebibliography}
1367: %}
1368:
1369:
1370:
1371: \end{document}
1372:
1373:
1374:
1375:
1376:
1377:
1378:
1379:
1380:
1381:
1382: