1: \documentstyle[pubform]{article}
2:
3: \newtheorem{definition}{Definition}[section]
4:
5: \renewcommand{\baselinestretch}{.75}
6:
7: \title{\LARGE\bf On Assessing the Complexity of Software Architectures}
8: \author{{\bf Jianjun Zhao}\\
9: \large Department of Computer Science and Engineering\\
10: \large Fukuoka Institute of Technology\\
11: \large 3-10-1 Wajiro-Higashi, Higashi-ku, Fukuoka 811-0214, Japan\\
12: \large zhao@cs.fit.ac.jp}
13:
14: \date{}
15:
16: \begin{document}
17: \maketitle
18:
19: \abstract{
20: This paper proposes some new architectural metrics which are
21: appropriate for evaluating the architectural attributes of a software
22: system. The main feature of our approach is to assess the
23: complexity of a software architecture by analyzing
24: various types of architectural dependences in the architecture.}
25:
26: \medskip
27: \noindent
28: {\bf keywords:} Architectural description lanaguage, Architectural metric,
29: Dependence analysis, Software architecture
30:
31:
32: \section{Introduction}
33: \label{sec:intro}
34:
35: Software metrics have many applications in software engineering
36: activities including software analysis, testing, debugging,
37: maintenance, and project management.
38: In the past two decades numerous software metrics
39: have been proposed for measuring the complexity of software
40: \cite{Fenton97,Zuse90}. These metrics can be divided into two
41: categories according to the design levels of software\footnote{There are usually two levels of design for software, {\it architectural level design}
42: where involves overall association of system capability with components,
43: and {\it code level design} where involves algorithms
44: and data structures \cite{Rombach90}.}: {\it code metrics} which aim at
45: measuring the complexity of a single program module at
46: code design level \cite{Cheng93,Halstead77,Harrison87,Mccabe76},
47: and {\it architectural metrics}
48: which aim at measuring the complexity of components and their
49: interconnections in software systems at architectural design level
50: \cite{Henry81,Kazman98,Mccabe89,Yin78}.
51:
52: Most work on software metrics focused on code metrics
53: which are derived solely from source code of a program, and
54: the study of architectural metrics has received little attention.
55: However, architectural measurement can be regarded as a desirable
56: addition to code metrics because it allows you to capture important
57: aspects of a system's architecture earlier in the system life cycle so
58: you can take corrective actions earlier \cite{Rombach90}. This may
59: offer greater potential for return on investment in order to make
60: large gains in productivity and quality since error detection and
61: repair is more costly if we can not catch errors in the early stage
62: of system design.
63:
64: But, why the study of architectural metrics has received little
65: attention in comparison with code metrics ?
66: One important reason is while the code level for software
67: systems is now well understood, the architectural level is currently
68: understood mostly at the level of intuition, anecdote, and
69: folklore \cite{Shaw96}.
70: Existing representations that a system architect uses to represent the
71: architecture of a software system are usually informal and {\it ad hoc},
72: and therefore can not capture enough useful information of the
73: system's architecture. Moreover, with such an informal and {\it ad hoc} manner, it is
74: difficult to develop analysis tools to automatically support the
75: evaluation and comparison of existing architectural metrics. As a
76: result, in order to make
77: architectural metrics more widely accepted and used in software
78: system design, formal representation of system architectures is
79: strongly needed.
80:
81: Recently, as the size and complexity of software systems increases, the design
82: and specification of the overall software architecture of a system is
83: receiving increasingly attention. The software architecture of a
84: system defines its high-level structure, exposing
85: its gross organization as a collection of interacting components.
86: A well-defined architecture allows an engineer to reason about system
87: properties at a high level of abstraction \cite{Shaw96}.
88: Architecture description languages (ADLs) are formal languages that
89: can be used to represent the architecture of a software system.
90: They focus on the high-level structure of the overall application
91: rather than the implementation details of any specific source module.
92: In order to support formal representation and reasoning of software
93: architecture, a number of ADLs such as W{\sc right} \cite{Allen97},
94: Rapide \cite {Luckham95}, and UniCon
95: \cite{Shaw95} have been proposed. By using an ADL, a system architect
96: can formally represent various general attributes of a software system's
97: architecture. This provides researchers with a promising solution to
98: solve the problems existing in recent architectural metrics. First,
99: a sound basis for software architecture promises one to define new
100: architectural metrics, or refine existing architectural metrics in a more
101: formal way in comparing with existing informal structure charts based
102: architectural metrics. Second, formal language support for software
103: architecture provides a useful platform on which automated support tools
104: for architectural metrics can be developed and formal
105: evaluation and comparison of existing architectural metrics can be
106: done.
107:
108: In this paper, we propose some new architectural metrics for
109: software architecture. Our metrics are appropriate for
110: evaluating the architectural attributes of a software system. The main
111: feature of our approach is to assess the complexity of a
112: software architecture by analyzing various types of architectural dependences
113: in a software architecture. To formally define these metrics, we present a
114: dependence-based representation named {\em Architectural Dependence
115: Graph} (ADG) to explicitly represent various architectural dependences in
116: a software architecture.
117: %The SADG is an
118: %arc-classified digraph whose vertices represent ports and roles of
119: %components and connectors of an architectural specification,
120: %and arcs represent possible dependence relationships between them.
121:
122: The rest of the paper is organized as follows.
123: %Section \ref{sec:wright} briefly introduces software architecture
124: %and architecture description languages.
125: Section \ref{sec:depen} presents three types of architectural
126: dependences in a software
127: architecture and the architectural dependence graph. Section
128: \ref{sec:measure} defines some dependence-based metrics for software
129: architecture. Section \ref{sec:work} discusses some related work.
130: Concluding remarks are given in Section \ref{sec:final}.
131:
132: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
133:
134: %\section{Software Architecture and Architecture Description Languages}
135: %\label{sec:wright}
136:
137: %Software architecture is receiving increasingly attention as a
138: %critical design level for software systems \cite{Shaw96}. The software
139: %architecture of a system defines its high-level structure, exposing
140: %its gross organization as a collection of interacting components.
141: %A well-defined architecture allows an engineer to reason about system
142: %properties at a high level of abstraction.
143: %Architectural description languages (ADLs) are formal languages that
144: %can be used to represent the architecture of a software system.
145: %They focus on the high-level structure of the overall application
146: %rather than the implementation details of any specific source module.
147: %Recently, a number of architectural description languages
148: %have been proposed such as W{\sc right}\cite{Allen97}, Rapide
149: %\cite{Luckham95}, and UniCon \cite{Shaw95} to support formal representation
150: %and reasoning of software architectures.
151: %As software architecture design resources (in the form of
152: %architectural specifications) are going to be accumulated,
153: %the development of techniques to support software architectural
154: %understanding, testing, reengineering, maintenance and reuse
155: %will become an important issue.
156:
157: %As a result, based on formal W{\sc right} architectural specifications,
158: %we can infer which ports of a component are input ports and which are
159: %output ports. Also, we can infer which roles are input roles and which are
160: %output roles. Moreover, the direction in which the information transfers
161: %between ports and/or roles can also be inferred based on the
162: %formal specification. As we will show in Section \ref{sec:depen}, such
163: %kinds of information can be used to construct the software
164: %architectural dependence graph for a software architecture for
165: %defining architectural metrics.
166:
167: %\begin{figure}[t]
168: % \begin{center}
169: % \epsfile{file=/home/zhao/paper/sa/slicing/iceccs98w.sys.eps,scale=0.85}
170: % \caption{\label{fig:sys} The architecture of the Gas Station system.}
171: % \end{center}
172: %\end{figure}
173:
174: \section{A Dependence Model for Software Architecture}
175: \label{sec:depen}
176:
177: When we intend to measure some attributes of an entity, we must build
178: some model for the entity such that the attributes can
179: be explicitly described in the model. In this section, we present
180: a dependence model for software architecture to capture attributes
181: concerning about information flow in a software architecture.
182:
183: \subsection{Program Dependences}
184:
185: Program dependences are dependence relationships holding between
186: program statements (variables) in a program that are implicitly
187: determined by control flow and data flow in the program. Usually,
188: there are two types of program dependences in a program, that is,
189: {\it control dependences} representing the control conditions on which
190: the execution of a statement or expression depends and {\it data
191: dependences} representing the flow of data between statements or
192: expressions. The task to determine a program's dependences is
193: called {\it program dependence analysis}.
194:
195: Program dependence analysis has been primarily studied
196: in the context of conventional programming languages.
197: In such languages, it is typically performed
198: using a {\it program dependence graph} \cite{Cheng93,Horwitz90,Ottenstein84}.
199: Program dependence analysis, though originally proposed for complier
200: optimization, has also many applications in software engineering
201: activities such as program slicing, understanding, debugging, testing,
202: maintenance and complexity measurement
203: \cite{Horwitz90,Ottenstein84,Podgurski90}. As a result,
204: it seems reasonable to apply program dependence analysis technique
205: to software architectures to support software architecture development
206: activities \cite{Stafford98,Zhao97}.
207:
208: %While dependence analysis is useful in software architecture
209: %development, existing dependence analysis techniques for conventional
210: %programming languages can not be applied to software architectures
211: %straightforwardly due to the following reasons. The traditional
212: %definition of dependences only concerned with programs written in
213: %conventional programming languages which primarily consist of
214: %variables and statements as their basic language elements,
215: %and dependences are usually defined as dependence relationships
216: %between statements or variables. However, in a software architecture,
217: %the basic elements are primarily components, but neither variables
218: %nor statements as in a conventional program. Moreover, in addition to
219: %definition/use binding relationships, a software architecture
220: %topically support more broad and complex dependence relationships
221: %between components.
222:
223: \subsection{Architectural Dependences}
224:
225: Roughly speaking, architectural dependences are dependence
226: relationships holding between components (ports) in a software architecture,
227: and are implicitly determined by information flow in the architecture.
228: Unlike program dependences, which are defined as dependence
229: relationships between statements (variables) in a program,
230: architectural dependences are defined as
231: dependence relationships between components (ports) in a software
232: architecture. To perform dependence analysis on software
233: architectures, it is important to identify all primary architectural
234: dependence relationships between components (ports) in the architectures.
235: However, such a work is quite difficult because comparing with
236: program dependence analysis, the dependence relationships between
237: components (ports) in a software architecture can be more complex
238: and broad. In this section we introduce three types of primary
239: architectural dependences between components (ports) in a software
240: architecture. The classification of architectural dependence types
241: based on the results of {\it coordination theory} \cite{Malone94}
242: \footnote{In \cite{Malone94},
243: Malone and Crowston defines {\it coordination} as the process of
244: {\it managing dependences} among activities.}.
245: %This is a primary result after we studied many software systems.
246: The types of primary architectural dependences are not limited to
247: these three ones, rather, new types of primary architectural
248: dependences must be further exploited in order to identify all types
249: of primary architectural dependences in a software architecture.
250:
251: \vspace{2mm}
252: \noindent
253: {\it Shared Dependences}
254:
255: \vspace{2mm}
256: %The second type of primary architectural dependence in a software
257: %architecture is named {\it common dependence}.
258: \noindent
259: Sharing dependences represent dependence relationships \\among
260: consumers who use the same resource or producers who produce for
261: the same consumers. For example, for two components $u$ and $v$,
262: if $u$ and $v$ refer to the same global data, then there exists a
263: shared dependence relationship between $u$ and $v$.
264:
265: \vspace{2mm}
266: \noindent
267: {\it Flow Dependences}
268:
269: \vspace{2mm}
270: %The first type of primary architectural dependence in a software
271: %architecture is named {\it information-flow dependence}.
272: \noindent
273: Flow dependences represent dependence relationships
274: between producers and consumers of resources. For example, for two
275: components $u$ and $v$, if $u$ must complete before control flows into
276: $v$ (prerequisite), or if $u$ communicate $v$ by parameters,
277: then there exists a flow dependence relationship
278: between $u$ and $v$.
279:
280: \vspace{2mm}
281: \noindent
282: {\it Constrained Dependences}
283:
284: \vspace{2mm}
285: %The third type of primary architectural dependence in a software
286: %architecture is named {\it constrained dependence}.
287: \noindent
288: Constrained dependences represent constraints on the relative
289: flow of control among a set of activities. For example, for two
290: components $u$ and $v$, $u$ and $v$ can not execute at the same time
291: (mutual exclusion), then there exists a constrained dependence
292: relationship between $u$ and $v$.
293:
294: \subsection{Architectural Dependence Graph}
295: \label{sec:adg}
296:
297: We present an arc-classified digraph named
298: {\it Architectural Dependence Graph} (ADG) for explicitly representing the
299: three types of primary architectural dependences in a software
300: architecture. Here we assume that the interface of
301: each component in a software architecture is defined by a set of
302: {\it ports}. The ADG of a software architecture consists of vertices
303: and arcs to connect these vertices.
304: There is a {\it component vertex} for each component in the
305: architecture, and each component vertex consists of a set of
306: {\it port vertices} each representing a port of the component.
307: There is an architectural dependence arc between two port vertices
308: of components if there exists a shared, flow, or constrained
309: dependence relationship between the ports.
310: %Architectural dependence arcs are connected by the corresponding port
311: %vertices of the components.
312:
313: Architectural dependence information can be inferred
314: based on formal architectural specifications of a software
315: architecture. For example, based on a W{\sc right} architectural
316: specification we can infer which ports of a component are input ports
317: and which are output ports in the specification.
318: Moreover, the direction in which the information transfers between
319: ports can also be inferred based on the formal specification. Such
320: kinds of information can be used to construct the architectural
321: dependence graph for a software architecture to formally define
322: dependence-based architectural metrics.
323:
324: %\begin{figure*}[bt]
325: % \begin{center}
326: % \epsfile{file=semi.sadg.eps,scale=0.7}
327: % \caption{\label{fig:graph} The architecture dependence graph of
328: %a W{\sc right} architectural specification.}
329: % \end{center}
330: %\end{figure*}
331:
332: %As we introduced in Section \ref{sec:wright}, W{\sc right} uses CSP-based
333: %model to specify the behavior of a component and a connector of a
334: %software architecture. W{\sc right} allows user to infer which ports of
335: %a component are input and which are output, and which roles of a
336: %connector are input and which are output based on a W{\sc right}
337: %architectural specification. Moreover, it also allows user to infer
338: %the direction in which the information transfers between ports and/or roles.
339: %As a result, by using a static analysis tool which takes an architectural
340: %specification as its input, we can construct the SADG of a W{\sc
341: %right} architectural specification automatically.
342:
343:
344: %Program dependence analysis has been traditionally studied in the
345: %context of conventional programming languages. In such languages,
346: %dependences are usually defined between statements or variables.
347: %However, in an architectural description language, the basic language
348: %elements are components and ports (components'interfaces), but neither
349: %statements nor variables. As a result, new definition of dependences
350: %between components must be studied for architectural specifications.
351: %Roughly speaking, architectural
352: %dependences are dependence relationships holding between components
353: %in an architectural specification of a software system, and
354: %can be determined by analyzing information flows in the specification.
355: %In this paper, we present three types of architectural dependences
356: %between components and/or connectors in an architectural specification,
357: %namely, {\it component-connector dependences}, {\it
358: %connector-component dependences}, and {\it internal dependences}.
359:
360: \section{Architectural Metrics}
361: \label{sec:measure}
362:
363: As we mentioned in Section \ref{sec:depen},
364: architectural dependences are dependence relationships holding between
365: components in a software architecture that are implicitly determined
366: by information flow in the architecture. Therefore, architectural
367: dependences can be regarded as one of intrinsic attributes of a
368: software architecture and it is reasonable to regard architectural
369: dependences as one of objects for measuring the architectural
370: complexity of a software architecture.
371:
372: In this section, we define a set of new architectural metrics
373: in terms of architectural dependences to assess the complexity
374: of a software architecture from various different viewpoints.
375: Once the ADG of a software architecture is constructed,
376: the metrics can be computed easily based on the graph. The following
377: notations are used for defining these metrics:
378:
379: \begin{itemize}
380: \item[] $|A|$: the cardinality of set $A$.
381: \item[] $R^+$: the transitive closure of binary relation $R$.
382: \item[] ${\sigma}_{[1]=v}(R)$: the selection of binary relation
383: $R$ such that ${\sigma}_{[1]=v}(R)=\{(v1,v2)| (v1,v2)\in R\ and\ v1=v\}$.
384: \end{itemize}
385:
386: When we constructed the ADG for a software architecture, the most
387: general metric can be defined in terms
388: of ADG. The following metric is defined for measuring the total
389: complexity of a software architecture:
390:
391: \begin{itemize}
392: \item Let $D_{t}$ be the set of all dependences arcs in the ADG of a
393: software architecture, then the total complexity $M_{T}$ of the
394: architecture can be measured by $M_{T}= |D_{t}|.$
395: \end{itemize}
396:
397: Note that the above metric was defined under the situation that we
398: treat a component as an unit to construct the ADG of a software
399: architecture. However, in fact, each component in the architecture
400: may generally correspond to a single application module which can be
401: measured by usual code metrics at code level. So there is a need to
402: combine the total complexity at architectural design level with
403: internal component complexity at code design level to obtain an
404: overall complexity metric.
405:
406: \begin{itemize}
407: \item Let $M_{T}$ be the total complexity and $M_{1}, ..., M_{k}$ be
408: the individual component complexities. Then the global complexity
409: $M_{G}$ of a software architecture can be measured by:
410: $M_{G}= M_{T} + \sum_{i=1}^{k}M_{i}$.
411: \end{itemize}
412:
413: The above metrics only concerned with the direct architectural
414: dependences in a software architecture, but did not take indirect
415: architectural dependences into account.
416: As a result, they only capture the sum of some local complexity, rather
417: than the total complexity of the architecture. In fact, a component
418: in a software architecture may indirectly depend on other components
419: in the architecture. Therefore, to assess the total complexity of a
420: software architecture, we should define a metric by taking either direct or
421: indirect architectural dependences into account. This can be obtained
422: by calculating the transitive closure $|D_{t}^+|$ of the $|D_{t}|$,
423: we have: $M'_{T}= |D_{t}^+|.$ Similarly, if we also consider the
424: indirect dependences at
425: architectural level and each of application modules at
426: code level, we can obtain more detailed global complexity
427: $M'_{G}$ of the system: $M'_{G}= M'_{T} + \sum_{i=1}^{k}M'_{i}.$
428:
429:
430: In maintenance phases, when we have to modify some component in a
431: software architecture, usually, we intend to know information about
432: how the modified component intersect
433: with other components. This kind of information is very useful because
434: it can tell us if the modified component is a special point that
435: connects with its environment more closely than other components.
436: If so, that means it is difficult to make changes to the component
437: due to a large number of potential effects on other components.
438: We call such a component the ``most easily affected component of the
439: architecture.'' To capture such attribute, we can define following metrics.
440:
441: \begin{itemize}
442: \item Let $D_{t}$ be the set of all dependences arcs in the ADG of a
443: software architecture, and ${\sigma}_{[1]=v}(D_{t})$
444: be the number of ports of components on which a port $v$ of a
445: component is directly dependent. The complexity $M_{S}$ of the most
446: easily affected component in the architecture can be measured by
447: $M_{S}=max \{|{\sigma}_{[1]=v}({D}_{t})|\ | $ {\it v is a vertex of the ADG} \}.
448: \end{itemize}
449:
450: Similarly, if we also considered indirect architectural dependences
451: in a software architecture, we can obtain a more detailed
452: metric: $M'_{S}=max \{|{\sigma}_{[1]=v}({D}_{t}^+)|\ | $ {\it v is a vertex of the ADG} \}.
453:
454: As we observed, all the architectural metrics defined above are
455: absolute metrics. In general, the larger is a architectural metric of
456: a software architecture, the more complex is the software
457: architecture. Moreover, some relative architectural metrics should
458: also by considered since they can assess the complexity of a software
459: architecture from some different viewpoints.
460:
461: \section{Related Work}
462: \label{sec:work}
463:
464: Although much work has been studied for code metrics at implementation
465: code level, the study of architectural metrics has not received as
466: much as attention in comparing with code metrics.
467: Among existing architectural metrics, there are two famous
468: architectural metrics that have been proposed by Yin and Winchester which is
469: derived from a system's structured design chart, and by Henry and
470: Kafura which is derived from a system's information flow. We compare
471: their approaches with ours here.
472:
473: Yin and Winchester have defined some architectural metrics based on analysis
474: of a system's design structure chart \cite{Yin78}. They focused on the
475: interface between the major levels in a large, hierarchically
476: structure. However, the fundamental problem for Yin and Winchester's
477: work is that their metrics were defined based on informal system's
478: design structure charts which can only capture the flow of information
479: across level boundaries. In contrast, our metrics are defined based
480: on various types of architectural dependences in a software
481: architecture that can be represented by formal
482: architectural specification of a system, and therefore, can measure the
483: architectural complexity of the system more well.
484:
485: Henry and Kafura proposed some architectural metrics based on information
486: flow of a system. Their metrics are probably the most cited
487: architectural metrics that have been developed. The idea behind
488: these metrics is that complexity is measured in terms of information
489: flow, and that more complex modules in a system are those through
490: which large amounts of information flow. Their approach is much more
491: detailed compared with Yin and Winchester's work because it observes
492: all information flow rather than just flow across level boundaries.
493: However, there are two fundamental problems in
494: information flow metrics. First, although Henry and Kafura stated
495: that their approach can be completely automated, this is not often the
496: case. Recent evaluations showed that due to the ambiguous definitions of
497: some of the metrics, it is difficult to give an evaluation of the
498: metrics. This makes it difficulty to develop automated support tools
499: for the approach \cite{Kitchenham90,Shepperd90}. Second, information flow
500: metrics were also defined based on some informal structure charts
501: which usually poorly capture the attributes of a system's architecture.
502: In contrast, our metrics which are defined in terms of various types
503: of architectural dependences in a software architecture
504: that can be represented by formal architectural specification of
505: a system, and therefore can capture more intrinsic and deeper
506: attributes of a system's architecture. Moreover, due to the synthetic
507: nature of some information flow metrics (i.e. the fact that they are
508: obtained by combining the values of a number of other counts), recent studies
509: showed that this may conceal underlying effects and lead to incorrect
510: diagnoses of the status of either the system as a whole or of
511: individual components \cite{Kitchenham90}. Our metrics, in contrast,
512: are defined based on primitive counts (of dependence arcs in the ADG),
513: rather than synthetics, and therefore no such a problem occurred.
514:
515: \section{Concluding Remarks}
516: \label{sec:final}
517:
518: We proposed some new architectural metrics which are appropriate
519: for evaluating the architectural attributes of a software system. The main
520: feature of our approach is to measure the complexity of a software
521: architecture by analyzing various types of architectural dependences
522: in the architecture. In order to formally
523: define these metrics, we presented a dependence-based representation
524: named {\it Architectural Dependence Graph} (ADG) to explicitly
525: represent these architectural dependences in the architecture.
526:
527: The work presented here is primary, and there is still a lot of work
528: that remains to be done. For example, in addition to defining metrics based
529: on architectural dependences, similar to \cite{Bieman94} which they
530: defined some metrics based on program slices to evaluate functional
531: cohesion of a program, we can also define metrics to evaluate the
532: functional cohesion of a software architecture based on architectural
533: slices that can be computed by a new slicing technique called {\it
534: architectural slicing} \cite{Stafford98,Zhao97,Zhao98}. Moreover,
535: we can also define some architectural metrics by simply counting the
536: number of elements
537: in a formal architectural specification. For example, we can define
538: metrics by counting the number of components, connections between
539: components, and even the number of lines in a formal architectural
540: specification.
541: On the other hand, it is important to develop static analysis tools to
542: automatically support the collection and evaluation of the
543: architectural metrics proposed in this paper. Now we are implementing
544: an architectural dependence analysis tool for W{\sc right} architectural
545: specifications and an architectural metric collector based on it. The
546: next step for us is to perform some experiments and collect data for
547: evaluation. We hope a primary evaluation of these metrics will be
548: available soon.
549:
550:
551: {\small
552: \renewcommand{\baselinestretch}{0.7}
553:
554: \begin{thebibliography}{99}
555:
556: \bibitem{Allen97}
557: R. Allen,
558: ``A Formal Approach to Software Architecture,''
559: PhD thesis, Department of Computer Science, Carnegie Mellon University, 1997.
560:
561: \bibitem{Bieman94}
562: J. M. Bieman and L. M. Ott,
563: ``Measuring Functional Cohesion,''
564: {\it IEEE Transaction on Software Engineering}, Vol.20, No.8, pp.644-657, 1994.
565:
566: \bibitem{Cheng93}
567: J. Cheng,
568: ``Process Dependence Net of Distributed Programs and Its Applications
569: in Development of Distributed Systems,''
570: {\it Proc. of the COMPSAC'93}, pp.231-240, 1993.
571:
572: \bibitem{Fenton97}
573: N.E.Fenton and S. L. Pfleeger, ``Software Metrics: A Rigorous and
574: Practical Approach,'' Second Edition, International Thomson Computer Press, 1997.
575:
576: %\bibitem{Ferrante87}
577: %J.Ferrante, K.J.Ottenstein, and J.D.Warren,
578: %``The Program Dependence Graph and Its Use in Optimization,''
579: %{\it ACM Transaction on Programming Language and System}, Vol.9, No.3,
580: %pp.319-349, 1987.
581:
582: %\bibitem{Garlan97}
583: %D. Garlan, R. Monroe, and D. Wile, ``ACME: An Architecture Description
584: %Interchange Language,'' {\it Submitted for publication}, January 1997.
585:
586: \bibitem{Halstead77}
587: M. Halstead,
588: ``Elements of Software Science,''
589: Elsevier, North Holland, 1977.
590:
591: \bibitem{Harrison87}
592: W. Harrison and C. Cook, ``A Micro/Macro Measure of Software Complexity,''
593: {\em Journal of System and Software}, Vol.7, No.2, pp.213-219, 1987.
594:
595: \bibitem{Henry81}
596: S. Henry and D. Kafura, ``Software Structure Measures Based on
597: Information Flow,'' {\em IEEE Transactions on
598: Software Engineering}, Vol.7, No.5, pp.510-518, 1981.
599:
600: \bibitem{Horwitz90}
601: S. Horwitz, T. Reps, and D. Binkley,
602: ``Interprocedural Slicing Using Dependence Graphs,''
603: {\it ACM Transaction on Programming Language and System}, Vol.12,
604: No.1, pp.26-60, 1990.
605:
606: \bibitem{Luckham95}
607: D. C. Luckham, L. M. Augustin, J. J. Kenney, J. Veera, D. Bryan, and
608: W. Mann,
609: ``Specification Analysis of System Architecture Using Rapide,''
610: {\it IEEE Transaction on Software Engineering}, Vol.21, No.4,
611: pp.336-355, April 1995.
612:
613: \bibitem{Kazman98}
614: R. Kazman and M. Burth,
615: ``Assessing Architectural Complexity,''
616: {\it Proceedings of the 2nd Euromicro Conference on Software Maintenance and
617: Reengineering}, pp.104-112, Florence, Italy, March 1998.
618:
619: \bibitem{Kitchenham90}
620: B. A. Kitchenham, L. M. Pickard, and S. J. Linkman,
621: ``An Evaluation of Some Design Measures,''
622: {\it Software Engineering Journal}, pp.50-58, January 1990.
623:
624: \bibitem{Malone94}
625: T. W. Malone and K. Crowston,
626: ``The Interdisciplinary Study of Coordination,''
627: {\it ACM Computing Surveys}, Vol.26, No.1, pp.87-119, 1994.
628:
629: \bibitem{Mccabe76}
630: T. J. McCabe,
631: ``A Software Complexity Measure,''
632: {\it IEEE Transaction on Software Engineering}, Vol.2, No.4,
633: pp.308-320, 1976.
634:
635: \bibitem{Mccabe89}
636: T. J. McCabe and C. W. Butler,
637: ``Design Complexity Measurement and Testing,''
638: {\it Communications of the ACM}, Vol.32, No.12, pp.1415-1425, 1989.
639:
640: \bibitem{Ottenstein84}
641: K. J. Ottenstein and L. M. Ottenstein,
642: ``The Program Dependence Graph in a software Development
643: Environment,''
644: {\it ACM Software Engineering Notes}, Vol.9, No.3, pp.177-184, 1984.
645:
646: \bibitem{Rombach90}
647: H. D. Rombach,
648: ``Design Measurement: Some Lessons Learned,''
649: {\it IEEE Software}, pp.17-25, March 1990.
650:
651: \bibitem{Podgurski90}
652: A. Podgurski and L. A. Clarke,
653: ``A Formal Model of Program Dependences and its Implications for
654: Software
655: Testing, Debugging, and Maintenance,''
656: {\it IEEE Transaction on Software Engineering}, Vol.16, No.9,
657: pp.965-979, September 1990.
658:
659: \bibitem{Shaw95}
660: M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. Young, and G.
661: Zelesnik,
662: ``Abstractions for Software Architecture and Tools to Support Them,''
663: {\it IEEE Transaction on Software Engineering}, Vol.21, No.4,
664: pp.314-335, April 1995.
665:
666: \bibitem{Shaw96}
667: M. Shaw and D. Garlan,
668: ``Software Architecture: Perspective on an Emerging Discipline,''
669: Prentice Hall, 1996.
670:
671: \bibitem{Shepperd90}
672: M. Shepperd,
673: ``Design Metrics: An Empirical Analysis,''
674: {\it Software Engineering Journal}, pp.3-10, January 1990.
675:
676: \bibitem{Stafford98}
677: J. A. Stafford, D. J. Richardson, and A. L. Wolf,
678: ``Aladdin: A Tool for Architecture-level Dependence Analysis of
679: Software Systems,''
680: Technical Report CU-CS-858-98, Department of Computer Science,
681: University of Colorado, April 1998.
682:
683: \bibitem{Yin78}
684: B. H. Yin and J. W. Winchester,
685: ``The Establishment and Use of Measures to Evaluate the Quality of
686: Software Designs,''
687: {\it Proceedings of the Software Quality and Assurance Workshop},
688: pp.45-52, 1978.
689:
690: \bibitem{Zhao97}
691: J. Zhao,
692: ``Using Dependence Analysis to Support Software Architecture
693: Understanding,'' in M. Li (Ed.), {\it New Technologies on Computer
694: Software}, pp.135-142, International Academic Publishers, September 1997.
695:
696: \bibitem{Zhao98}
697: J. Zhao,
698: `` Applying Slicing Technique to Software Architectures,''
699: {\it Proceedings of the Fourth IEEE International Conference on Engineering of
700: Complex Computer Systems}, pp.87-98, Monterey, USA, August 1998.
701:
702: \bibitem{Zuse90}
703: H.Zuse, ``{\em Software Complexity: Measures and Methods},'' Walter de
704: Gruyter, 1990.
705: \end{thebibliography}
706: }
707:
708: \end{document}
709:
710:
711:
712:
713:
714:
715:
716:
717:
718:
719:
720:
721:
722:
723:
724:
725:
726:
727:
728:
729:
730:
731:
732:
733:
734:
735:
736:
737:
738:
739:
740:
741:
742:
743:
744:
745:
746:
747:
748:
749:
750:
751:
752:
753:
754:
755:
756:
757:
758:
759:
760:
761:
762:
763:
764:
765:
766:
767:
768:
769:
770:
771:
772:
773:
774:
775:
776:
777:
778:
779:
780:
781:
782:
783:
784:
785:
786:
787:
788:
789:
790:
791:
792:
793:
794:
795:
796:
797:
798:
799:
800:
801:
802:
803:
804:
805:
806:
807:
808:
809:
810:
811:
812:
813:
814:
815:
816:
817:
818:
819:
820:
821:
822:
823:
824:
825:
826:
827:
828:
829:
830:
831:
832:
833:
834:
835:
836:
837:
838:
839:
840:
841:
842:
843:
844:
845:
846:
847:
848:
849:
850:
851:
852:
853:
854:
855:
856:
857:
858:
859: