The paper presents a framwork for verifying concurrent message-passing C programs in an automated manner. The methodology relies on several key ideas.

 

First, programs are modeled as finite state machines whose states are labeled with data and whose transitions are labeled with events. We refer to such state machines as labeled Kripke structures(LKSs). Our state/event-based approach enables us to succinctly express and efficiently verify properties which involve simultaneously both the static (data-based) and the dynamic (reactive or event-based) aspects of any software systems.

 

Second, the framework supports a wide range of specification mechanisms and notions of conformance. For instance, complete system specifications can be expressed as LKSs and simulation conformance verified between such specifications and any C implementation. For partial specifications, the framework supports (in addition to LKSs) a state/event-based linear temporal logic capable of expressing complex safety as well as liveness properties. Finally, the framework enables us to check for deadlocks in concurrent message-passing programs.

 

Third, for each notion of conformance, we present a completely automated and compositional verification procedure based on the couterexample guided abstraction refinement (CEGAR) paradigm. Like other CEGAR-based approaches, these verification procedures consist of an iterative application of model construction, model checking, counterexample validation and model refinement steps. However, they are uniquely distinguished by their compositionalily. More precisely, in each of our conformance checking procedures, the algorithms for model construction, counterexample validation and model refinement are applied component-wise. The state space size of the models are controlled via a two-pronged strategy: (i)using two complementary abstraction techniques based on the static (predicate abstraction) and dynamic (action-guided abstraction) aspects of the program, and (ii)minimizing the number of predicates required  for predicate abstraction.

 

The proposed framework has been implemented in the MAGIC tool. We present experimental evaluation in support of the effectiveness of our framework in verifying non-trivial concurrent C programs against a rich class of specifications in an automated manner.

姚期智：清华一年间


2005年，计算机科学领域的大师Avi Wigderson教授（Rolf Nevanlinna Prize 1994
年得主）和Leslie G. Valiant教授(Nevanlinna Prize 和Knuth Prize得主)先后在
清华演讲，引起了极大反响。

2005年4月，清华大学高等研究中心引进了世界著名的密码学学者王小云教授和微软
亚洲研究院团队来清华紧密合作。

2005年8月初，三位来自MIT和加州大学伯克利分校的美国学生开始了他们在清华为期
半年的研究与学习。这学期，我校三名同学分别到美国耶鲁大学和美国密歇根大学进
行短期交流访问。

……

在这每一次交流与合作的背后，都有一个共同的名字——姚期智。

姚期智教授现年59岁，出生于上海，毕业于台湾大学，分别获哈佛大学物理学博士及
伊里诺斯大学计算机博士，是美国国家科学院院士和美国人文及科学院院士，曾先后
获得SIAM George Polya奖和ACM SIGACT-IEEE TCMFCS Donald E. Knuth奖，2000年
获得计算机科学的最高奖“图灵奖”(被认为“信息领域的诺贝尔奖”)，成为首位也
是唯一获此殊荣的亚裔科学家。2003年10月受聘担任清华大学讲席教授，成为清华大
学计算机系讲席教授组首席科学家。2004年6月，当选中国科学院外籍院士。2004年
9月，姚期智教授于正式受聘为清华大学教授，担任清华大学高等研究中心全职教授
工作，并定居清华园。

回国定居一年间，姚先生在推动清华大学计算机学科向世界一流水平迈进的过程中，
发挥了积极的作用。

温总理的嘱托

2004年9月5日，温家宝总理专程在教师节前来看望姚期智教授。在交谈中，温总理说
，国家对人才的需求如饥似渴，高层次的人才是国家最稀缺、最宝贵的资源；我们在
抓好基础教育的同时，也要下大力气抓好高等教育，为国家广泛培养高层次优秀人才
；在重点科研机构和重要科研领域，要实行杰出人才的全球招聘制度；要为杰出人才
的脱颖而出和充分发挥作用创造良好的条件。

作为在国际一流大学长期任教的教授以及在计算机理论领域享有世界声誉的学者，姚
期智教授出任清华大学信息科学与技术国家实验室（筹）学术委员会主任和首席科学
家，立即承担起建设世界一流的清华大学信息科学的重任，组织筹建国家实验室。2004

年10月22日，教育部部长周济、副部长吴启迪等领导来到清华大学考察信息科学与技
术国家实验室的筹建工作，专门与姚期智教授会面并听取了他的汇报和建议。

“5年争取新突破！”


在清华的一年间，姚先生全面延续了他的国外的高水平学术研究，在演算法和量子计
算学两个领域发表了4篇国际会议论文，在通信复杂性上也取得了一些新的研究结果
。

在清华的一年间，姚先生获得了伊利诺大学工学院杰出校友奖、香港科技大学荣誉工
学博士等学术荣誉。今年9月，荣获“友谊奖”这一我国授予外国专家的最高荣誉。


在清华的一年间，姚先生带领清华大学计算机系讲席教授组在理论计算机领域勤奋工
作。理论计算机科学是他的主要研究方向，该学科在国际计算机科学与技术研究中起
着重要的作用，我国在这一领域的研究工作却比较薄弱，严重影响了国内计算机学科
的发展。2003年，姚先生亲自精心挑选了7名国际一流大学的知名教授组建了讲席教
授组。一方面，讲席教授组成员全力以赴做好在清华的理论计算机科学人才的培养工
作；另一方面，身在世界各地的教授组成员以姚先生为中心，经常通过各种通讯手段
电子邮件相互联系与交流，及时互通理论计算机学科的最新动态。

“做世界一流的工作，用5年左右时间在计算机理论领域有一个新的突破。”这是姚
先生给自己定的目标。在清华大学，姚先生计划重点发展计算机密码学和计算机图形
学两个方向。在他的积极争取下，这两个方向在过去一年里分别引进了世界著名的密
码学学者王小云教授和吸引了微软亚洲研究院团队来清华紧密合作。

王小云教授的主要研究领域是计算机密码学和信息安全学。她先后于2004年8月和2005
年2月破解了目前国际通用多年的、属于电子通讯中关键技术的MD5和SHA-1密码算法
，在国际上产生了强烈影响。姚先生得知王小云教授所做的工作后，主动联系王小云
教授到清华讲学，并提出引进她到清华大学担任高等研究中心“杨振宁讲席教授”的
职位。王小云教授欣然接受，于2005年4月正式受聘为清华大学高等研究中心教授，
她与姚先生在密码学方面的合作研究也随之展开。

姚先生还联系了微软亚洲研究院院长兼首席科学家沈向洋博士为首的4位图形学领域
的著名专家，来清华参与计算机图形学的研究工作和博士研究生的培养工作。2005年
春季学期开始，这四位计算机专家已在清华大学开设《高级计算机图形学》的研究课
程，并开放给学生选修，受到我校学生的热烈欢迎。

青青子衿，悠悠我心

在清华大学信息学院开学典礼上，姚先生对学生们说，“大家在求学期间不要把将来
求得温饱这件事情当作自己生活的唯一目标，各位都是在中国最顶尖的人才，我希望
大家把理想放得高一些，要做一个有用的人，要做大事业，成为一个顶天立地的人！
”当时，会场的掌声经久不息。

为了培养出更多“顶天立地的人”，姚先生在学生们身上倾注了大量的心血。

两年前，他领导的讲席教授组将培养我国理论计算机科学人才作为首要任务。当时，
学校从计算机系、数学系和基础科学班中先后挑选了13名成绩优秀、又有志向投身于
计算机理论科学研究的本科生和研究生，组成了学习小组，师从国际一流大学的知名
教授组成的讲席教授组进行学习。

在他的亲自规划下，讲席教授组有着严密的教学计划和严格的分工，尽管每位教授在
京授课的时间只有短短的一个月时间，但每位成员在完成教学任务之后，都及时向全
组通报完成的情况及存在的问题，并在最短的时间内加以解决，使各成员间的工作能
互相衔接。姚期智教授亲自指导学生们的研究和学习，学生们的多篇论文在国际著名
杂志Algorithmica和国际理论计算机重要会议Computational Complexity上得以发表
。

在给同学们配备一流的师资的同时，姚先生还努力为同学们创造与国外著名大学的优
秀学生交流的机会，加速与国际专业水平的接轨。一方面他从2005年初开始就向美国
多所著名大学的计算机系博士生发出邀请，邀请他们来清华参与讲席教授组内的学术
活动，并和国内的学生共同学习、相互切磋。另一方面，他也尽可能地介绍组内的同
学到国外参与知名学府的科研项目。同学们通过这种经常与不同的国际一流学者交流
与学习的方式，大大地开阔了视野，活跃了思维，提升了学术水平。

2004年11月27日，姚先生在清华大学主楼后厅举办了一场面向全校本科生的别开生面
的“现代密码学探秘”讲座。他在报告中并没有引述大段的专业定义和概念，而是带
给同学们很多趣事：拍卖场上的斗智斗勇，两个有钱人的比富，如何能够用复杂的参
数对付狡猾的奸细……不少同学是坐在台阶上或者是站着听完这场报告的。报告之后
，“学术追星”族们把姚先生围了个结结实实。

我有嘉宾，鼓瑟吹笙

姚先生回国定居后，主动和国内同行联系，并亲自走访国内高校开展学术交流。同时
，姚先生积极吸引世界最优秀的科学家来做访问，他说，“让年轻学者和学生接触到
这些专家，了解他们是怎么做出一流水平的研究。”

2004年9月以来，姚先生定期联系、邀请国内外知名大学教授来清华为学生做学术报
告。不仅为学生提供了与国际一流学者交流的宝贵机会，还大大提升了学术讲座的水
平、丰富了学院的学术气氛，至今已经组织过10场高水平的讲座。开篇所说的两位计
算机科学领域的大师正是姚先生2005年邀请来华的。讲座举办当天，许多慕名而来的
学生把整个讲堂挤得水泄不通，两位大师深入浅出的精彩讲演让清华学子们真正领略
到了名家风采。

为了使学生们能够与这些世界级大师有更频繁更深入的交流，姚先生计划于下半年继
续邀请更多在计算机科学领域有突出贡献的知名学者到清华访问，并以“名家系列讲
座”的形式固定下来，作为讲席教授组教学的一种重要辅助手段，长期地办下去。

2005年3月16日，在北京市政府举行的颁发仪式上，姚期智先生从北京市公安局局长
马振川手中接过了标志着北京永久居留权的“绿卡”。

---

Professor Ric Holt, holt@uwaterloo.ca, School of Computer Science, University of Waterloo

---

This is a bibliography of references for the study of software architecture. Many of its entries have been annotated. This bibliography has been the basis of a graduate seminar on software architecture taught years at the University of Waterloo and previously at the Univerity of Toronto.

---

For University of Waterloo students, to have access to IEEE and ACM libraries of articles, please first log into: http://login.lib.uwaterloo.ca/

---

• Andersson, Jonas and Johnson, Pontus, Architectual Integration Styles for Large-Scale Enterprise Software Systems, Proceedings of Fifth IEEE International Enterprise Distributed Object Computing Conference, 2001, Page 224-236.
• Felix Bachmann, Len Bass, Gary Chastek, Pat Donohoe, and Fabio Peruzzi, Architecture Based Design Method, Technical Report, CMU/SEI-2000-TR-001, January 2000. The report presents a systematic and comprehensive method to construct a conceptual architecture of a product line or large-scale software system. The method is based on iterative model. The first iteration is a nine steps process. The input of the method is a list of requirements and constraints; the output of the method is a list of architecture decisions including views, design elements and design templates. There is another related report that helps to understand how to apply this method in a real life project. [Morgan Yingfu Lu] (See also Morgan's slides on this paper.)
• T. Ball, S.G. Eick; Software visualization in the large; Computer, Volume 29, Issue 4, April 1996
• D. Batory; Product-Line Architectures; International Conference on Software Engineering, 1998
• Andreas Bauer, Markus Pizka, Contribution of Free Software to Software Evolution, Institut fur Informatik, Technische Universit at Munchen, Boltzmannstr. 3, Germany 85748 Garching, Page 170, Sixth International Workshop on Principles of Software Evolution (IWPSE'03) September 01 - 02, 2003, Helsinki, Finland. Paper discusses how free software is developed and what kind of role the architecture plays. Notably, it discusses architectural issues of Mozilla.
• Berghammer, R. et al, The RELVIEW System, from Department of Computer Science and Applied Mathematics of Christian-Albrechts-University of Kiel. The Relview system is a tool designed to support the manipulation, analysis and visualization of data represented as binary relations. It is currently an active research project of the Department of Computer Science and Applied Mathematics of Christian-Albrechts-University of Kiel.  More information can be found at the Relview WWW Page .  The system provides the ability to view and edit relations from two views, a binary boolean matrix and a directed graph.   The system also provides many ways for manipulating relations.  These are provided through the user interface and also a fairly extensive programming language. There is a potential for using this system to manipulate the facts about a software system in order to obtain architectural views, although the Relview project has not considered this possibility so far. [James Keast] (See also Keast's notes and slides on this work.)
• Ivan T. Bowman, Richard C. Holt and Neil V. Brewster, Linux as a Case Study: Its Extracted Software Architecture, ICSE 99, Los Angeles, May 99. This paper describes an approach to extracting the conceptual and concrete architectures from a large software system where no such documentation previously existed Using a recent version of Linux as a software guinea pig, the authors used a combination of automated tools and manual effort to build a visual representation of the overall structure of the operating system's kernel. In particular, the process of extracting the file subsystem architecture is described in detail. In an iterative process, the results generated from the automated tools were manipulated based on knowledge of a conceptual model. The final result was a graphical representation of the file subsystem structure that can aid in understanding the system from a high level. Finally, the differences between the abstract and concrete architectures are presented along with possible explanations for those differences. [Richard Gregory] (See also Gregory's slides on this work.)
• Grady Booch, The architecture of Web applications
• Grady Booch, When Worlds Collide
• * Buhr, R.J.A. and Casselman, R.S., Architectures with Pictures, OOPSLA '92, pp 466-483. This paper advocates the use of wired and wireless architectural diagrams to illustrate high level architecutral style. Wired architectures have static connections between components while wireless components have dynamic "soft links" between components. They use a very basic notation for their links between components. Large lines are used to indicate communication between components (no direction is used). The authors introduce the idea of a time thread which passes through various components of an architecture. Designs can be made in terms of timethreads in two ways: Time threads can be defined first, then components can be defined to complete the task. Components with similar roles can then be merged. Alternatively, components can be defined first and then timethreads are strung between components. The use of animated diagrams illustrating component collaboration over time was advocated to illustrate the dynamic behavior of an architecture. They also discuss contracts between components and discuss component-component interactions in terms of contracts between components. [Chris Pal] (See also Chris Pal's notes and slides on this paper.)
• *+ Buxton, John and McDermid, John, Architectual Design (Chapter 17), pp. 17/1 - 17/33, in Software Engineer's Reference Book, CRC Press, 2000 Corporate Blvd NW, Boca Raton, Florida, 33431, 1993. This paper discusses 'architectural design', which is described as the high-level design which follows requirements analysis, but precedes any detailed design. This paper (being a chapter from a book) is quite long, and covers a number of ideas relating to architectural design. The paper first presents design principles and notations for the ideal design process. Acknowledging that the ideal design process is essentially impossible, pragmatic guidelines/heuristics for architectural design are suggested. Next, the importance of analysis and review of architecture designs is explained. Finally, the paper presents some existing methods (e.g. HOOD, SSADM) which could be used for architectural design. [Jason Chase] (See also McDermid's group web page with its bibliography.)
• Carmichael, I., Tzerpos, T and Holt, R.C., Design Maintenance: Unexpected Architectural Interactions, IEEE Proceedings of the International Conference on Software Maintenance, Nice, France, October 1995, pp. 134-137.
• +Consens, M, Mendelzon, A., and Ryman, Arthur, Visualizing and Querying Software Structures, IBM Labs Canada Tech Report 74.053, Sept 1991.
• Jeromy Carriere, Rick Kazman, Assessing Design Quality From a Software Architectural Perspective, Technical Report, CMU/SEI. This report draws on the authors' experiences with Software Architectures and Object Oriented Systems in order to relate how a good object oriented design and a well designed architecture are related. Some ideas are presented on what the definition of good design might be, and how how that good design can be achieved.[M. Kaastra] (See also Mike Kaastra's slides on this paper.)
• Paul C. Clements; A Survey of Architecture Description Languages; International Workshop on Software Specification and Design, 1996
• +Dart, S.A., The Past, Present, and the Future of Configuration Management, Tech Report CMU/SEI-92-TR-8, Carnegie-Mellon University, Software Engineering Institute, July 1992.
• +Dean, T.R. and Cordy, J.R., A Syntactic Theory of Software Architecture, Special Issue on Software Architecture, IEEE Transactions on Software Engineering 21,4 (April 1995), pp. 302-313.
• * +Deremer, F., Kron, H.H. Programming-in-the-large versus Programming-in-the-Small, IEEE Transactions on Software Engineering, Vol SE-2, No 2, June 1976. This 'classical' paper argues for the need to distinguish between programming-in-the-large and programming-in-the-small. It is argued that "...structuring a large collection of modules to form a 'system' is an essentially distinct and different intellectual activity from that of constructing the individual modules". To this end, a separate language is needed to allow programmers to express their intent regarding the system structure: a Module Interconnection Language (MIL). The motivation and goals for an MIL are explicated, and a sample MIL, (MIL75), is presented. This paper is an early attempt to resolve issues pertaining to the construction of large scaled software systems which are still prevalent today. [Siddiqi]
• * Eades, Peter, A Heuristic for Graph Drawing, Congressus Numerantium, Vol 42 (1984), pp 149-160. This paper presents a heuristic for laying out graphs that works well for graphs of order less than 30. The algorithm views the graph as a physical system, having nodes which are adjacent being attracted to each other while non-adjacent nodes repel each other. The algorithm provides a good initial layout of a graph. [Dan Frank]
• Eick, Stephen G., Todd L. Graves, Alan F. Karr, J.S. Marron, Audris Mockus, Does Code Decay? Assessing the Evidence from Change Management Data, IEEE Trans on Software Engineering, Vol. 27, No 1, pp 1-12, 1990.
• A. Mockus, R.T. Fielding and J. Herbsleb, Two Case Studies of Open Source Software Development: Apache and Mozilla, ACM Transactions on Software Engineering and Methodology, 11(3), 1-38, July 2002.
• Feijs, L, Krikhaar, R., and VanOmmering, R., A Relational Approach to Support Software Architecture Analysis, [URL accessible from U Waterloo] Software Practice and Experience, Vol 28(4), pp 371-400, April 1998.
• Fowler, Martin, Who Needs an Architect? IEEE Software
• A. Frick, A. Ludwig and H. Mehldau, A fast adaptive layout algorithm for undirected graphs, Proceedings of Graph Drawing'94, LNCS 894, Springer Verlag 1995. (See also .)
• +Gamma, E, Helm, R., Vlissides, J. Design Patterns: Abstraction and Reuse of Object-Oriented Design, ECOOP 93, Germany, 1993.
• Gangopadhyay, D., ObjChart: Tangible Specification of Reactive Object Behavior, Tech Report RC-18627, IBM Thomas J. Watson Research Center, Jan 1993.
• * + Garlan, David and Shaw, Mary, An Introduction to Software Architecture, Advances in Software Engineering and Knowledge Engineering, Volume 1, World Scientific Publishing Co., 1993. In this paper, the authors provide an introduction to the field of Software Architecture. Their purpose is to illustrate the current state of the discipline and examine the ways in which architectural design can impact software design. The authors outline a number of common architectural styles based on practical experience: pipes and filters, data abstraction, implicit invocation, layered systems, repositories, and table driven interpreters. While it is important to understand the individual nature of each of these styles, most systems typically involve some combination of several styles. The authors show how heterogeneous styles can be combined in a single design. Next, the authors use six case studies to illustrate how architectural representations of a software system can improve the understanding of complex systems. Finally, the authors survey some of the outstanding problems in the field of Software Architecture, and consider a few of the possible future directions for research. The abstract from the paper is as follows: As the size of software systems increases, the algorithms and data structures of the computation no longer constitute the major design problems. When systems are constructed from many components, the organisation of the overall system -- the software architecture -- presents a new set of design problems. This level of design has been addressed in a number of ways including informal diagrams and descriptive terms, module interconnection languages, templates and frameworks for systems that serve the needs of specific domains, and formal models of component integration mechanisms. In this paper we provide an introduction to the emerging field of software architecture. We begin by considering a number of common architectural styles upon which many systems are currently based and show how different styles can be combined in a single design. Then we present six case studies to illustrate how architectural representations can improve our understanding of complex software systems. Finally, we survey some of the outstanding problems in the field, and consider a few of the promising research directions. [Ladan Tahvildari] (See also Ladan's notes on this paper and Bowman's notes on this paper.)
• * Garlan, David and Allen, R., and Ockerbloom, J., Architectural Mismatch or, Why Reuse is So Hard, IEEE Software, November 1995. This paper attempts to develop and new techniques to cope with mismatches between assembled software components. The paper argues that there exist fundamental differences between compositional problems that occur due to low-level issues of interoperability such as differing programming languages or database designs and problems of architectural mismatch. They argue that problems of architectural mismatch are a more pervasive class of problem. They illustrate the types of mismatch that they experienced building software development environments from existing parts. They argue that key mismatch issues centre around the assumptions the reusable parts make about the structure of the application in which the developers expect the part to appear, yet do not necessarily make explicitly clear. Based on this experience they show how an architectural view can help expose and highlight some of these compositional problems. [Chris Pal] (See also Pal's notes and slides and Hassan's slides on this paper.)
• David Garlan, Software Architecture: a Roadmap, ICSE 2000, 22nd International Conference on Software Engineering, Future of Software Engineering Track, June 4-11, 2000, Limerick Ireland, ACM, 2000. The paper examines some of the important trends of software architecture. It describes the roles of architecture in software systems development and summarizes the past and current state of research and practice. It also considers some of the forces that are changing the world of software systems themselves, and speculates on emerging trends, challenges, and aspirations. [Maher Shinouda]
• Gerald Gannod and Shilpa Murthy, Verification of Recovered Software Architectures, IWPC 2003: Proceedings of 2003 International Workshop on Program Comprehension, May 2003
• +Harel, David On Visual Formalisms, CACM, 31,5, May 88.
• + Harel, D., Statecharts: A Visual Formalism for Complex Systems, Science of Computer Programming 8 (1987) 231-274, Elsevier, North Holland.
• * Harel, David and Eran, Gery, Executable Object Modeling with Statecharts, ICSE 96, Mar 1996, Berlin, pp 246-257. The paper describes an object-oriented modeling technique based on visual formalisms. The modeling technique consists of two modeling languages (O-Charts and Statecharts) which respectively describe the structure and behavior of a system. The paper informally describes the formal syntax and semantics of these two languages and uses a rail-car system as an example. The topic of behavioral inheritance is introduced and cited as an area of future research. The languages are supported in the form of a tool called O-MATE which generates executable code given O-Charts and Statecharts. [Moataz Kamel] (See also Kamel's slides on this paper.)
• David R. Harris and Howard B. Reubenstein and Alexander S. Yeh, Reverse Engineering to the Architectural Level, International Conference on Software Engineering (ICSE), pp 186-195, April 1995 This paper presents an architecture recovery framework that integrates reverse engineering technology and architectural style representations. The authors claim that by using this framework, an analyst can recover custom, dynamic documentation to fit a variety of software analysis requirements. This framework is made of 3 components: architectural representation, a source code recognition engine and a library of recognition queries, and a "Bird's Eyes" program overview capability. The architecture style and the query library of this framework are discussed in details with examples. Then, this paper addresses some questions about bridging the gaps to system understanding. Also, the framework attempts to inform the analyst about the percentage of the code that implements architectural commitments by using a preliminary code coverage metric. As many papers in software architecture, this paper provides an example of using this architecture recovery framework. Finally, the authors describe the several areas in which they intend to extend to their architecture recovery framework. [Eric Lee] (See also Lee's slides on this paper.)
• Ahmed E. Hassan and Richard C. Holt, Reference Architecture for Web Servers, WCRE 2000: Working Conference on Reverse Engineering, Brisbane, Australia, Nov 6, 2000.
• Holt, R.C., Permission Theory for Software Architecture Plus Phantom Architectures , School of Computer Science, University of Waterloo, September 2005. See slides.
• + Holt, R.C., Penny, D.A., and Mancoridis, S. Multicolour Programming and Metamorphic Programming: Object-Oriented Programming-in-the-Large, CASCON 92, IBM Canada Ltd Lab Centre for Advanced Studies, Toronto, Ont, Nov 92.
• *+ Holt, R.C., Binary Relational Algebra Applied to Software Architecture, CSRI Tech Report 345, University of Toronto, March 1996.
• Holt, R.C., An Introduction to the Grok Programming Language, technical Report, University of Waterloo, May 2002.
• Holt, R.C., An Introduction to TA: the Tuple-Attribute Language, technical Report, University of Waterloo, 1997.
• Holt, R.C., Software Architecture as a Shared Mental Model, International Workshop on Program Comprehension, Paris, June, 2002.
• Richard C. Holt, Andreas Winter, Andy Schurr, GXL: Toward A Standard Exchange Format, local copy, WCRE 2000: Working Conference on Reverse Engineering, Brisbane, Australia, Nov 6, 2000. GXL is an XML sublanguage used for representing typed, attributed, directed graphs. Its main purpose was to promote interoperability between reverse engineering tools that use these types of graphs to represent software programs. It was derived from other similar languages such as TA, RSF, and Grax which were used in other reverse engineering tools/toolkits. Besides defining what GXL is and what it was derived from, this paper attempts to give us an idea of the history of these langauges and the tools that have used them. By doing this they have also shown that GXL is capable of the same work (using the premise that anything they could do, GXL could do as well since it was derived from their features). They then attempt to validate the language by proving that GXL meets a certain list of criteria for "Software Exchage Languages" derived from three other papers. These criteria include scalability, extensibility, and coverage of a number of different languages. [Andrew Trevors] See Andrew Trevor's slides on GXL.
• Jerding, Dean and Rugaber, Spencer, Using Visualization for Architecturual Localization and Extraction, Proceedings of the Working Conference on Reverse Engineering, WCRE97, pp. 56-65, October 1997, Amsterdam, Netherlands. This paper discusses the use of static and dynamic extraction in obtaining software system architecture. For practical purposes, this information is then used to localize the addition of components into the system by examining the extracted architecture and determining the best place for inclusion of that new component. To accomplish this, the authors describe a tool called ISVis that they have developed; this tool implements the static and dynamic extraction methods described. [Ryan Bannon] (See also Ryan Bannon's slides on this paper.)
• * Kazman, R., Bass, L., Abowd, G. and Clements, P., An Architectural Analysis Case Study: Internet Information Systems A methodology for comparing candidate architectures is presented. Specific emphasis is placed on "task scenarios" which are hypothetical situations posed for the purpose of assisting in the evaluation of qualities which would otherwise be considered difficult to measure. Examples of the methodology are shown in reference to Internet Information Systems. [Christopher Trudeau] (See also Trudeau's notes)
• Kazman, R. and Carriere, S.J., View Extraction and View Fusion in Architectural Understanding, submitted to 5th Int'l Conf on Software Reuse, 1998.
• * Kazman, R., Mark Klein and Paul Clements, Abowd, G. and Clements, P., ATAM: Method for Architecture Evaluation, Aug 2000, Tech Report CMU/SEI-2000-TR-004.
• Kreger, Heather, Web Services Conceptual Architecture (WCSA 1.0), IBM, May 2001
• Rene L. Krikhaar, Software Architecture Reconstruction, Doctoral thesis, University of Amsterdam, 1999
• * Kruchten, P.B., The 4+1 Views Model of Architecture, IEEE Software, Nov 95, pp 42-50. This paper aims to remedy the problem of presenting many concerns on one software architecture diagram. The 4+1 View Model was developed using Phillipe Kruchten's experiences as a software architect of Rational Software Inc. The five concurrent views are: Logical View, Process View, Development View, Physical View and Scenarios. Each view shows a specific aspect of the system that is modeled. This makes it possible for each group of stakeholders to focus on the views that they are concerned with. Most of the views used the Booch notation. The process is mainly driven by the logical view which can be described by Class Diagrams and State Transition Diagrams. Software developers using an Object Oriented Analysis and Design Methodology will find this paper useful to organize their views of the system. (See also Tanuan's slides and Hassan's slides on this paper.)
• Lampson, Butler L., Hints for Computer System Design , ACM Operating Systems Rev. 15, 5 (Oct. 1983), pp 33-48. Reprinted in IEEE Software 1, 1 (Jan. 1984), pp 11-28.
• M. Lanza, S. Ducass; Polymetric views - a lightweight visual approach to reverse engineering; IEEE Transactions onSoftware Engineering, Volume 29, Issue 9, Sept. 2003
• Levin, R. and McJones, P., The Vesta Approach to Precise Configuration of Large Software Systems, SRC Research Report 105, Digitial Equipment Corporation, June 1993.
• * Lindig, Christian and Snelting, Gregor, Assessing Modular Structure of Legacy Code Based on Mathematical Concept Analysis, ICSE 97, Boston MA, pp 349-359. The focus of this research is to attempt to automate modularization of legacy code. To this end, the technique of mathematical concept analysis based on set theory is applied to software systems. The paper explains how module structures show up in a concept lattice. Cohesion and coupling are defined and methods for resolving interferences between modules are presented. The method is applied to several examples written in Modula-2, Fortran, and Cobol with limited success. They conclude that the language used affects the modularization potential. Also, automatic modularization is possible only if there is still some hidden structure, but fails on software which is near entropy death. From the abstract: We apply mathematical concept analysis in order to modularize legacy code. By analysing the relation between procedures and global variables, a so-called concept lattice is constructed. The paper explains how module structures show up in the lattice, and how the lattice can be used to assess cohesion and coupling between module candidates. Certain algebraic decompositions of the lattice can lead to automatic generation of modularization proposals. The method is applied to several examples written in Modula-2, Fortran, and Cobol; among them a > 100kloc aerodynamics program. [Moataz Kamel] (See also Kamel's slides on this paper.)
• C.-H. Lung and K. Kalaichelvan, A Quantitative Approach to Software Architecture Sensitivity Analysis, Proc. of the Int'l Conf. on Software Eng and Knowledge Eng, June 1998, pp. 185-192.
• Chung-Horng Lung, Sonia Bot, Kalai Kalaichelvan, and Rick Kazman, An Approach to Software Architecture Analysis for Evolution and Reusability, Proceedings of CASCON '97, November 1997.
• J.I. Maletic, A. Marcus, L. Feng; Source Viewer 3D (sv3D) - a framework for software visualization; International Conference on Software Engineering, 2003
• * S. Mancoridis, ISF: A Visual Formalism for Specifying Interconnection Styles for Software Design, International Journal of Software Engineering and Knowledge Engineering (to appear, 1998). See also shorter version "Customizable Notations for Software Design" by Mancoridis. The motivation for ISF (Interconnection Style Formalism) is to understand the structure of a software system. An understanding of the relationships between components and dependencies leads to the success during the implemention, testing, and maintenance stages of the system. Unlike most software design notations, ISF is customizable while still remaining formal. The visual aspect of ISF consist of labelled boxes and directed edges. The arrangements of the boxes (components/entities) and edges (edge relations) must obey ISF rules, ergo the formal side of ISF. There are two ISF rules: permission rules which indicate what is permissable under the current configurations of the components and dependencies; and definition rules which allows new relations to be defined. Different interconnection styles have different sets of permission rules and definition rules. Mancoridis gave an ISF specification for the export style and the tube style. [John Tran]
• S. Mancoridis, Customizable Notations for Software Design, In the ACM/IEEE Proceedings of the 1997 International Conference on Software Engineering and Knowledge Engineering , Madrid, Spain, June, 1997.
• Spiros Mancoridis, Toward a generic framework for computing subsystem interfaces, Joint proceedings of the second international software architecture workshop (ISAW-2) and international workshop on multiple perspectives in software development (Viewpoints '96) on SIGSOFT '96 workshops, 1996, pages 106-110, San Francisco, California, United States
• S. Mancoridis, B. S. Mitchell, C. Rorres, Y. Chen, E. R. Gansner, Using Automatic Clustering to Produce High-level System Organizations of Source Code, IEEE Proceedings of 6th International Workshop on Program Understanding, Ischia, Italy, June, 1998. This paper presents a fully automatic technique that creates a hierarchical view of the system organization based on the components and relationships that exist in the source code. The first step in this technique is to represent the system modules and module-level relationships as a module dependency graph (MDG). Then, a collection of algorithms is applied to partition the graph in a way that derives the high-level subsystem structure from the component-level relationships that are extracted from the source code. The goal of this software modularization process is to automatically partition the components of a system into clusters (subsystems) so that the resultant organization concurrently minimizes inter-connectivity (connections between the components of two distinct clusters) while maximizing intra-connectivity (connections between the components of the same cluster). Bunch is the clustering tool that applies the clustering algorithms to the module dependency graph. This paper also presents a case study that illustrates the automatic software modularization technique. This paper concludes by outlining the research benefits and limitations of the work along with discussion of the future plans to improve the technique. [Ladan Tahvildari] (See also Ladan's notes on this paper.)
• Nenad Medvidovic, Alexander Egyed, and Paul Gruenbacher, Stemming Architectural Erosion by Coupling Architecture Discovery and Recovery, Proceedings of the 2nd International Workshop from Software Requirements to Architectures (STRAW), 2003. Paper discusses how to prevent arch erosion by studying and synthesizing requirements and implementation.
• * Mendonca, N.C. and Kramer, J., Requirements for an Effective Architecture Recovery Framework, Proc 2nd International Software Architecture Workshop (ISAW-2), pp 101-105, 1996. This paper discusses two topics. First, the current frameworks for reverse engineering for architectural analysis are presented. Second, the authors propose a new framework for architectural recovery and analysis. The five existing frameworks discussed are: filtering and clustering, compliance checking, analyzers generators, program understanding, and architecture recognition. Their proposed framework is based on a combination of these ideas including an additional extraction step to recognize architectural elements. [Matt Armstrong] (See also Armstrong's slides on this paper.)
• Minsky, N.H. and Rozenshtein, C. Configuration Management by Consensus: An Application of Law-Governed Systems, ITIRC March 1992.
• Minsky, N.H., Law-Governed Systems, IEEE Transactions on Software Engineering, Sept 1991.
• +Minsky, N.H., Law-Governed Regularities in Object Systems; Part I: Principles, Theory and Practice in Object Systems (TAPOS) 1996. http://www.cs.rutgers.edu/~minsky/index.html
• * Robert T. Monroe, Andrew Kompanek, Ralph Melton, and David Garlan, Architectural Styles, Design Patterns, and Objects, IEEE Software, Jan 97, pp 43-52. This paper describes the relationship between software architecture and object-oriented design (OOD), as well as the relationship between architectural styles and design patterns. First of all, the authors present what architectural designs and styles are, along with their purposes and benefits. Then, the authors describe applying object-oriented design to software architecture and the differences between architectural design and OOD. Finally, the authors compare/contrast architectural styles and design patterns. This paper concludes that architectures, architectural styles, objects and design patterns are complementary aspects of design and none of them completely subsumes the other. [Eric Lee] (See also Lee's slices on this paper.)
• *+ Müller, Hausi A., Mehmet, O.A., Tilley, S.R., and Uhl, J.S., A Reverse Engineering Approach to Subsystem Identification, Software Maintenance and Practice, Vol 5, 181-204, 1993. This paper presents a reverse-engineering methodology that utilizes the Rigi system. This paper describes an approach to creating higher-level abstract representation of a system, which involves the identification of related components and dependencies, the construction of layered subsystem structures, and the computation of exact interfaces among subsystems. This paper concludes with a detailed, step-by-step analysis of a 30-module image rendering program by applying their subsystem composition methodology. [Ladan Tahvildari] (See also Ladan's notes on this paper.)
• *+ Murphy, G.C, Notkin, D., and Sullivan, K., Software Reflexion Models: Bridging the Gap between Source and High-Level Models, Proceedings of the Third ACM Symposium on the Foundations of Software Engineering (FSE '95) This paper presents a way to map a source-code model into a developer's high-level software model. This is acheived by using a mapping from files to high-level modules. Using the given mapping, software reflexion tools can map a source-code model (which is a relation on files) into a high-level model (which is a relation on modules). After the mapping is done, software reflexion tools can identify the differences between the high-level model and the source-code model. The user of these is tools is able to have a better understanding of a software system by noting divergences and absences between the source-code model and the high-level model. [Itai Danan]
• Ciaran O'Reilly, Philip Morrow, and David Bustard, School of Computing and Information Engineering, University of Ulster, Coleraine, BT52 1SA, Northern Ireland, {c.oreilly, pj.morrow, dw.bustard}@ulster.ac.uk, Lightweight Prevention of Architecture Erosion, Sixth International Workshop on Principles of Software Evolution (IWPSE'03), Page 59, September 01 - 02, 2003, Helsinki, Finland. A straightforward and easy-to-read paper. It shows an easy to apply approach to preventing architecture approach. It is close to Khrikkar's work and to work at the University of Waterloo.
• Ossher, Harold, A Mechanism for Specifying the Structure of Large, Layered Programs, RC12300, Nov 86, 27 pages.
• Pal, Chris, A Technique for Illustrating Dynamic Component Level Interactions Within a Software Architecture
• Parker, Greg, Franck, Glenn, and Ware, Colin, Visualization of Large Nested Graphs in 3D, Special issue of the Journal of Visual Languages and Computing. 9, 299-317.
• Parnas, D.L., Software Aging , Proceedings of the 16th International Conference on Software engineering, Sorrento, Italy, Pps 279 - 287, 1994
• +Parnas, D.L., On Criteria to be used in Decomposing Systems into Modules, CACM, 14,1, pp 221-227, April 72
• Parnas, D.L., On the Design and Development of Program Families, IEEE TSE (special issue), SE-2, Dec 76
• Parnas, D.L., and Clements, P.C., Rational Design Process: How and Why to Fake It, IEEE TSE, SE12,2, pp. 251-257, Feb 86.
• * + Perry, Dewayne E. and Wolf, Alexander L., Foundations for the Study of Software Architecture, alternate source, ACM SIGSOFT Software Engineering Notes, 17:4, October 1992 pp 40-52. This paper aims to build the foundation for software architecture. The authors presented a model of software architecture that consists of three components: elements, form, and rationale. Components of the model in the context of both architecture and architectural styles were discussed. They conclude by presenting some of the benefits of their approach to software architecture, summarizing their contributions, and relating their approach to Schwanke et al., Zachman, and Shaw. The abstract from the paper is as follows: The purpose of this paper is to build the foundation for software architecture. We first develop an intuition for software architecture by appealing to several well-established architectural disciplines. On the basis of this intuition, we present a model of software architecture that consists of three components: elements, form, and rationale. Elements are either processing, data, or connecting elements. Form is defined in terms of the properties of, and the relationships among, the elements---that is, the constraints on the elements. The rationale provides the underlying basis for the architecture in terms of the system constraints, which most often derive from the system requirements. We discuss the components of the model in the context of both architectures and architectural styles and present an extended example to illustrate some important architecture and style considerations. We conclude by presenting some of the benefits of our approach to software architecture, summarizing our contributions, and relating our approach to other current work. [Meyer Tanuan]
• Perry, Dewayne E., A Product Line Architecture for a Network Product, manuscript was reviewed, paper since revised, 1998. The paper describes how a generic architecture that supports dynamical reconfigurability can be defined for a (network) product line (a range of products with similar characteristics). The generic characteristics (independence of the exact components in a given system in the line) of the architecture are achieved by addressing distribution (where are the components) at design and implementation layers. The system should have a model of itself, a command broker providing location transparency, a reconfiguration manager and reconfigurable components. The architecture is split into reconfiguration and domain-specific components. One of the points the paper makes is that identifying the abstractions (the connection in the case network product line) can help organize the system around them. It also shows that for a viable architectural solution relevant aspects (at architectural level) should be taken from both system objects and system functionality (i.e. a hybrid approach).[Andrei Dragoi] (See also Dragoi's notes on this paper.)
• Raymond, Eric S., The Cathedral and the Bazaar, Firstmonday, 1998.
• Reinder Bril, Rene, Krikhaar, and Andre, Postma, Embedding architectural support in industry, Proceedings International Conference on Software, Maintenance, p348-357, IEEE Computer Society, 2003.
• Rotschke, Tobias and Krikhaar, Rene, Architecture Analysis Tools to Support Evolution of Large Industrial Systems, ICSM 02, International Conference on Software Maintenance.
• +Ryman, Arthur, The Theory-Model Paradigm in Software Design, Tr 74.048, 11 Oct 89, IBM Canada Lab Tech Report
• +Schwanke, R. W., Altucher, R.Z., Platoff, M.A., Discovering, Visualizing, and Controlling Software Structure, Siemens Corp. Research, Inc., 755 College Rd East, Princeton, NJ 08540
• Schwanke,R.W., Platoff, M.A., Cross References are Features, 2nd International Workshop on Software Configuration Management, p 86-96, 1989. In the context of this paper a cross reference is any relation between two entities (e.g. module A calls module B, A uses variable V, procedure P calls procedure Q). The authors consider that if A calls B than this can be seen as A having the feature (i.e. property) of calling B, and B has the feature of being called. Based on this observation a new clustering measure can be defined, based on shared neighbors (e.g. if A calls B and A calls C then C and be have the common feature of being called by A - i.e. share the neighbor A). This measure can be used as an alternative to the cohesion strength for summarizing call graphs. It can also be used in splitting large include files and in improving the modularity of a system, by finding the misplaced files (according to the measure). The authors have prototyped a system (ARCH) that uses the measure for the previous tasks. ARCH should is used in an iterative process which involve feedback from a human architect. The paper points out that the described measure should be use as a complement, not a replacement of the various cohesion based measures. [Andrei Dragoi] (See also Dragoi's notes on this paper.)
• * Schwanke, Robert W., An Intelligent Tool for Re-engineering Software Modularity, Proc ICSE 91, Austin TX, May, 1991, pp 81-92. This paper describes a program which attempts to reverse engineer software in order to better provide software modularity. By looking at which procedures reference data structures of the same name, the program will group them together assuming this implies a modular relationship. In practice, this was a useful tool but required hand tuning of various constants in order to provide meaningful groupings. [Dan Frank]
• * Shaw, M. and Clements, P., A Field Guide to Boxology: Preliminary Classification of Architectural Styles for Software Systems, C.S. Dept and Software Engineering Institute, Carnegie Mellon Univ, Pittsburgh, PA 15213. This paper extends the previous work of Garlan and Shaw, by further defining software architecture styles. Characteristics of various styles are examined in order to distinguish between styles. Control and data flow are analyzed with respect to topology, synchronicity, continuity, and binding time. A table is given with twenty-five common architectures, each analyzed with respect to the above criteria. In-depth analysis is done on a small selection of these architectures showing variations on each. [Jen Campbell]
• S.E. Sim, C.L.A. Clarke, R.C. Holt, A.M. Cox; Browsing and Searching Software Architectures; International Conference on Software Maintenance, 1999
• * Soni, D., Nord, R., and Hofmeister, C., Software Architecture in Industrial Applications, IEEE ICSE 95. From the abstract: To help us identify and focus on pragmatic and concrete issues related to the role of the software architecture in large systems, we conducted a survey of a variety of software systems used in industrial applications. Our premise, which guided the examination of these systems, was that software architecture is concerned with capturing the structures of a system and the relationships among the elements both within and between structures. The structures we found fell into several broad categories: conceptual architecture, module interconnection architecture, code architecture and execution architecture. These categories address different engineering concerns. combined with specialized implementation techniques decreased the complexity of implementation and improved reuse and reconfiguration. [James Keast] (See also Keast's slides on this paper.)
• Sowa, J.F. and Zachman, J.A., Extending and Formalizing the Framework of Information Systems Architecture, IBM Systems Journal, Vol 31, No 3, 1992.
• C. Stoermer, L. O'Brien, C. Verhoef, Practice Patterns for Architecture Reconstruction , (abstract), Ninth Working Conference on Reverse Engineering (WCRE'02), October 29 - November 01, 2002, Richmond, Virginia
• M.D. Storey, H.A. Mller, K. Wong; Manipulating And Documenting Software Structures; International Conference on Software Maintenance, 1995
• * Sugiyama, Kozo, Shojiro, Tagawa, and Toda, Mitsuhiko, Models for Visual Understanding of Hierarchical System Structures, IEEE Trans on Systems, Man and Cybernetics, Vol SMC-11, No 2, Feb 1981, pp 109-125. The Sugiyama graph layout algorithm uses a heuristic to quickly display hierarchical graphs in a visually understandable way. This layout is effective for many graphs, and the techniques described are useful to authors of software-architecture tools. Bowman's notes summarize the algorithm discussed in the paper, and provide an example implementation. Several improvements to the algorithm have been made; for a summary of recent graph drawing research, see Cruz and Tamassia's tutorial on graph drawing. [Ivan Bowman]
• Torvalds, Linus, Comments on Designing Linux , Nov 2001.
• Tran, John B., and Holt, Richard C., Forward and Reverse Repair of Software Architecture, CASCON '99, Toronto, November 1999.
• Tzerpos, V. and Holt, R.C., and Farmaner, G., Web-Based Presentation of Hierarchic Software Architecture, Workshop on Software Engineering (on) the World Wide Web, International Conference on Software Engineering 1997, Boston, May 19, 1997.
• * Tzerpos, V. and Holt, R.C., The Orphan Adoption Problem in Architecture Maintenance, Proceedings of the Working Conference on Reverse Engineering 1997, Amsterdam, October 1997. The reverse engineering of a legacy application without aid from the original developers or design documentation is a difficult task. Subsystem structure is usually not inherently visible from the source code, and is changed over the course of the evolution of the software system. This paper focuses on the effects of software evolution on the structure of the software system. Two problems are identified as being particularly important, namely the orphan adoption problem and the kidnappee adoption problem. The orphan adoption problem is that of incremental clustering. That is, finding the appropriate subsystem to place a newly introduced resource. The kidnappee adoption problem is that of corrective clustering, or the movement of resources from one subsystem to another as structural change is introduced. An algorithm is presented which attempts to address these problems using resource names, resource dependencies, and classification of resources as being either functional or utility resources. Case studies are provided which study the efficacy of the presented algorithm in addressing the orphan adoption problem. [Saheem Siddiqi] (See also Hassan's slides on this paper.)
• Vassilios Tzerpos, R. C. Holt, ACDC: An Algorithm for Comprehension-Driven Clustering, WCRE 2000: Working Conference on Reverse Engineering, Brisbane, Australia, Nov 6, 2000.
• +Ware, C., Hui, D. and Franck, G., Visualizing Object-Oriented Software in Three Dimensions, CASCON 93.
• Wiggerts, Theo A., Using Clustering Algorithms in Legacy Systems Remodularization, pp 33-43, WCRE, Oct 1997. Like so many other papers on clustering and software reengineering, this one begins by describing how large systems become structurally decayed over long periods. The study of clustering began in the field of biology over twenty-five years ago and has spread to many other disciplines, including software engineering, which has an interest in grouping related entities together. The paper argues that in system remodularization, many people have either been reinventing clustering technology or could be aided by it, thus the goal of this paper is to provide an overview of clustering. The paper continues by describing what clustering is and discusses how one might determine the degree of similarity between nodes and between newly formed clusters. Various clustering algorithms using different measures of similarity are also presented. Finally, approaches that researchers have taken to apply clustering techniques to existing systems are listed. [Richard Gregory] (See also Gregory's slides on this work.)

This is the bibliography on software architecture analysis, with special emphasis on architectural-level understanding, testing, debugging, reverse engineering, re-engineering, maintenance, and complexity measurement.

---

1. R. Balzer, "Instrumenting, Monitoring and Debugging Software Architectures."

2. P. Bengtsson and J. Bosch, "Scenario-Based Software Architecture Reengineering," Proc. 5th International Conference on Software Reuse (ICSR5), pp.308-317, IEEE Computer Society Press, Victoria, B.C, Canada, June 1998.

3. P. Bengtsson, "Towards Maintainability Metrics on Software Architecture: An Adaptation of Object-Oriented Metrics," Firsrt Nordic Workshop on Software Architecture (NOSA'98), Ronneby, August 1998.

4. P. Bengtsson and J. Bosch, "Architecture Level Prediction of Software Maintenance," Proc. 3rd European Conference on Maintenance and Reengineering (CSMR99) , Amsterdam, The Netherlands, March 1999.

5. K. S. Barber and A. Lakshmanan, "Analysis of Software Architectures to Generate Test Sequences," Proc. 14th International Conference on Software & Systems Engineering and their Applications (ICSSEA 2001), Paris, France, December 2001.

6. L. Bass, P. Clements, and R. Kazman, "Software Architecture in Practice," Published by Addison-Wesley in the SEI Series, 1998.

7. A. Bertolino, P. Inverardi, H. Muccini, and A. Rosetti, "An Approach to Integration Testing Based on Architectural Descriptions," Proc. Third IEEE International Conference on Engineering of Complex Computer Systems (ICECCS97), pp.77-84, Como, Italy, September 1997.

8. A. Bertolino, F. Corradini, P. Inverardi, and H. Muccini, "Deriving Test Plans from Architectural Descriptions," Proc. 22nd International Conference on Software Engineering (ICSE'2000) , pp.220-229, Limerick, Ireland, June 2000.

9. G. Canfora, A. De Lucia, G. di Lucca, and A. Fasolino, "Recovering the Architectural Design for Software Comprehension," Proc. IEEE Third Workshop on Program Comprehension, Washington, DC, November 1994.

10. S. J. Carriere and R. Kazman, "The Perils of Reconstructing Architectures," Proc. 3rd International Software Architecture Workshop (ISAW3), pp.13-16, ACM SIGSOFT, Orlando, Florida, USA, November 1998.

11. S. J. Carriere, R. Kazman, and S. Woods, "Assessing and Maintaining Architectural Quality," Proc. 3rd European Conference on Maintenance and Reengineering (CSMR99) , Amsterdam, The Netherlands, March 1999.

12. P. Clements, R. Krut, E. Morris, and K. Wallnau, "The Gadfly: An Approach to Architectural-Level System Comprehension," Proc. 4th International Workshop on Program Comprehension (IWPC96), IEEE Computer Society Press, pp.178-186, 1996.

13. M. Dias, M. Vieira, and D. J. Richardson, "Software Architecture Analysis based on Statechart Semantics," Proc. 10th International Workshop on Software Specification and Design (IWSSD-10), San Diego, CA, November 2000.

14. D. Garlan, "Software Architecture: a Roadmap," The Future of Software Engineering, ACM Press, pp.91-101, 2000.

15. J. F. Girard and R. Koschke, "Finding Components in a Hierarchy of Modules: A Step towards Architectural Understanding," Proc. International Conference on Software Maintenance (ICSM97), IEEE Computer Society Press, pp.58-65, Bari, Italy, October 1997.

16. G. Y. Guo, J. M. Atlee, and R. Kazman, "A Software Architecture Reconstruction Method," Proc. First Working IFIP Conference on Software Architecture (WICSA1), San Antonio, TX, USA, February 1999.

17. D. Harris, H. Reubenstein, and A. S. Yeh, "Reverse Engineering to the Architectural Level," Proc. International Conference on Software Engineering (ICSE95), pp.186-195, IEEE Computer Society Press, July 1995.

18. S. Henry and D. Kafura, "Software Structure Metrics Based on Information Flow," IEEE Transactions on Software Engineering, 7(5), September 1981.

19. P. Inverardi and A. L. Wolf, "Formal Specification and Analysis of Software Architectures using the Chemical Abstract Machine Model," IEEE Transactions on Software Engineering, 21(4):373--386, April 1995.

20. Z. Jin, A. J. Offutt, A. Abdurazik, and E. L. White, "Analyzing Software Architecture Descriptions to Generate System-level Tests," Workshop on Evaluating Software Architectural Solutions 2000 (WESAS), Irvine, CA, May 2000.

21. R. Kazman, "Tool Support for Architectural Analysis and Design," Proc. 2nd Software Architecture Workshop (ISAW2), pp.94-97, San Francisco, CA, October 1996.

22. R. Kazman, G. Abowd, L. Bass, and P. Clements, "Scenario-Based Analysis of Software Architecture," IEEE Software, pp.47-55, November 1996.

23. R. Kazman and M. Burth, "Assessing Architectural Complexity," Proc. 2nd Euromicro Working Conference on Software Maintenance and Reengineering (CSMR98), pp.104-112, IEEE Computer Society Press, Florence, Italy, March 1998.

24. R. Kazman and S. J. Carriere, "View Extraction and View Fusion in Architectural Understanding," Proc. 5th International Conference on Software Reuse (ICSR5), pp.290-299, IEEE Computer Society Press, Victoria, B.C, Canada, June 1998.

25. R. Kazman, M. Klein, M. Barbacci, H. Lipson, T. Longstaff, and S. J. Carriere, "The Architecture Tradeoff Analysis Method," Proc. Fourth IEEE International Conference on Engineering of Complex Computer Systems (ICECCS98), pp.68-78, Montery, USA, August 1998.

26. R. Kazman, S. Woods, and S. J. Carriere, "Requirements for Integrating Software Architecture and Reengineering Models: CORUM II", Proc. 5th Working Conference on Reverse Engineering (WCRE98), pp.154-163, Honolulu, HI, October 1998.

27. R. Kazman and S. J. Carriere, Playing Detective: Reconstructing Software Architecture from Available Evidence", Journal of Automated Software Engineering, April 1999. (to appear)

28. T. H. Kim, Y. T. Song, L. Chung, and D. Huynh, "Software Architecture Analysis Using Dynamic Slicing", Proc. AoM/IAoM CS'99, Auguest 1999.

29. T. H. Kim, Y. T. Song, L. Chung, and D. Huynh, "Dynamic Software Architecture Slicing", Proc. 23th IEEE Annual International Computer Software and Applications Conference (COMPSAC99), October 1999. (to appear)

30. J. Kramer and J. Magee, "Analysing Dynamic Change in Software Architectures: A Case Study", Proc. IEEE 4th International Conference on Configurable Distributed Systems (CDS 98), pp.91-100, Annapolis, May 1998.

31. R.L. Krikhaar, R.P. de Jong, J.P. Medema, and L.M.G. Feijs, "Architecture Comprehension Tools for a PBX System", Proc. 3rd European Conference on Maintenance and Reengineering (CSMR99) , Amsterdam, The Netherlands, March 1999.

32. Nico Lassing, D. Rijsenbrij, and H. Vliet, "Towards a broader view on software architecture analysis of flexibility," Proc. the Asian-Pacific Software Engineering Conference (APSEC'99),1999.

33. Nico Lassing, D. Rijsenbrij, and H. Vliet, "On software architecture analysis of flexibility, Complexity of changes: Size isn't everything," Proc. the second Nordic Software Architecture Workshop (NOSA'99),1999.

34. D.C. Luckham, J.J. Kenney, L.M. Augustin, J. Vera, D. Bryan, and W. Mann, "Specification and Analysis of System Architecture Using Rapide," IEEE Transactions on Software Engineering, Vol.21, No.4, pp.336-355, April 1995.

35. C. H. Lung, S. Bot, K. Kalaichelvan, and R. Kazman, "An Approach to Software Architecture Analysis for Evolution and Reusability," Proc. of CASCON '97, November 1997.

36. C. H. Lung and K. Kalaichelvan, "A Quantitative Approach to Software Architecture Sensitivity Analysis", Proc. of the 10th Internationall Conference on Software Engineering and Knowledge Engineering, pp. 185-192, June 1998.

37. C. H. Lung, "Software Architecture Recovery and Restructuring through Clustering Techniques," Proc. 3rd International Software Architecture Workshop (ISAW3), pp.101-104, ACM SIGSOFT, Orlando, Florida, USA, November 1998.

38. J. Magee, J. Kramer, and D. Giannakopoulou, "Analysing the Behaviour of Distributed Software Architectures: a Case Study", Proc. 5th IEEE Workshop on Future Trends in Distributed Computing Systems (FTDCS97), pp.240-247, Tunisia, October 1997.

39. J. Magee, J. Kramer, and D. Giannakopoulou, "Software Architecture Directed Behavior Analysis," Proc. Ninth International Workshop on Software Specification and Design (IWSSD9), pp.144-146, IEEE Computer Society Press, Ise-Shima, Japan, April 1998.

40. J. Magee, J. Kramer and D. Giannakopoulou, "Behaviour Analysis of Software Architectures" Proc. First Working IFIP Conference on Software Architecture (WICSA1), San Antonio, Texas, February 1999.

41. T. J. McCabe and C. W. Butler, "Design Complexity Measurement and Testing," Communications of ACM, Vol.32, No.12, pp.1415-1425, 1989.

42. G. Naumovich, G.S. Avrunin, L.A. Clarke, and L.J. Osterweil, "Applying Static Analysis to Software Architectures," Proc. the Sixth European Software Engineering Conference Held Jointly with the 5th ACM SIGSOFT Symposium on Foundations of Software Engineering, pp.77-93, Lecture Notes in Computer Science, Vol.1301, Springer-Verlag, 1997.

43. D. E. Perry and A. L. Wolf, ``Foundations for the Study of Software Architecture'', ACM SIGSOFT Software Engineering Notes, pp.40-52, Vol.17, No.4, October 1992.

44. J. Peterson and M. Sulzmann, "Analysis of Architectures using Constraint-Based Types," Proc. First Working IFIP Conference on Software Architecture (WICSA1), San Antonio, TX, USA, February 1999.

45. M. D. Rice and S. B. Seidman, "An Approach to Architectural Analysis and Testing," Proc. 3rd International Software Architecture Workshop (ISAW3), pp.121-123, ACM SIGSOFT, Orlando, Florida, USA, November 1998.

46. D.J. Richardson and A. L. Wolf, "Software Testing at the Architectural Level," Proc. 2nd International Software Architecture Workshop (ISAW2), pp.68-71, San Francisco, California, October 1996.

47. M. Shaw and D. Garlan, "Software Architecture: Perspectives on an Emerging Discipline," Prentice Hall, 1996.

48. Mark Shereshevsky, Habib Ammari, Nicholay Gradetsky, Ali Mili, and Hany H. Ammar, "Information Theoretic Metrics for Software Architectures," Proc. 25th Annual International Computer Software and Applications Conference (COMPSAC'01), pp.151-157, Chicago, USA, October 2001.

49. J.A. Stafford, D.J. Richardson, and A. L. Wolf, "Chaining: A Software Architecture Dependence Analysis Technique," Technical Report CU-CS-845-97, University of Colorado, September 1997.

50. J.A. Stafford, D.J. Richardson, and A. L. Wolf, "Aladdin: A Tool for Architecture-level Dependence Analysis of Software Systems," University of Colorado Technical Report, CU-CS-858-98, 1998.

51. J.A. Stafford and A. L. Wolf, "Architectural-level Dependence Analysis in Support of Software Maintenance," Proc. 3rd International Software Architecture Workshop (ISAW3), pp.129-132, ACM SIGSOFT, Orlando, Florida, USA, November 1998.

52. J.A. Stafford and A. L. Wolf, "Architecture-Level Dependence Analysis for Software Systems," International Journal of Software Engineering and Knowledge Engineering, Vol.11, No.4, pp.431-453, August 2001.

53. W. Tracz, "Testing and Analysis of Software Architectures," Proc. ACM International Symposium on Software Testing and Analysis (ISSTA96), S.Diego, USA, January 1996.

54. V. Tzerpos and R.C. Holt, "The Orphan Adoption problem in Architecture Maintenance," Proc. Working Conference on Reverse Engineering (WCRE97), Amsterdam, The Netherlands, October 1997.

55. C. Williams, "Software Architecture: Implications for Computer Science Research," Proc. First Working IFIP Conference on Software Architecture (WICSA1), San Antonio, TX, USA, February 1999.

56. J. Zhao, "Software Architecture Slicing," Proc. 14th Conference of Japan Society for Software Science and Technology (JSSST'97), pp.49-52, Ishikawa, Japan, September 1997.

57. J. Zhao, "Using Dependence Analysis to Support Software Architecture Understanding," in M. Li (Ed.), "New Technologies on Computer Software," pp.135-142, International Academic Publishers, September 1997.

58. J. Zhao, "Slicing Software Architectures," Technical-Report SE-97-117, pp.85-92, Information Processing Society of Japan, November 1997.

59. J. Zhao, "Applying Slicing Technique to Software Architectures," Proc. Fourth IEEE International Conference on Engineering of Complex Computer Systems (ICECCS98), pp.87-98, August 1998.

60. J. Zhao, "On Assessing the Complexity of Software Architectures," Proc. 3rd International Software Architecture Workshop (ISAW3), pp.163-166, ACM SIGSOFT, Orlando, Florida, USA, November 1998.

61. J. Zhao, "A Slicing-Based Approach to Extracting Reusable Software Architectures," Proc. 4th European Conference on Software Maintenance and Reengineering, pp.215-223, IEEE Computer Society Press, Zurich, Switzerland, February 2000.

---

 

the lecture will be given  

 

2005年6月30日下午, YOCSEF长沙在长沙国防科技大学计算机学院学术报告厅举行主题为“软件可靠性与测试”的报告会，这是YOCSEF长沙2005年举行的第一次活动。长沙地区的委员以及对该主题感兴趣的老师和同学济济一堂，整个学术报告厅爆满。会议邀请了美国University of Texas at Dallas副教授Eric Wong 博士、北京航空航天大学长江特聘教授蔡开元博士和国防科技大学长江特聘教授朱鸿博士进行特邀演讲，国防科技大学教授、CCF软件工程专委会副主任、YOCSEF长沙学术委员会委员王戟博士和国防科技大学教授、YOCSEF长沙学术委员会主席王意洁博士担任会议的主持。

 

王戟博士首先向大家介绍Eric Wong 博士，随后Eric Wong 博士做了题为“软件设计规约的测试与诊断”（Testing and Diagnosis of Software Design Specifications）的报告，报告重点介绍了其近几年的主要研究方向，并且探讨了相关领域的一些细节问题，主要内容是：统计数据表明：在软件开发过程早期发现故障，能够显著减少费用。另外，为了改进从体系结构设计规格说明出发自动生成代码这一技术，更需要从一开始就具备一个高度可靠的系统设计。为此，必须尽早预测并改善系统质量。本次报告着重于如何将基于源代码的技术扩展到软件设计规格说明层，以达到更加有效的规格说明验证和维护。另外还将讨论一种新方法，用于从设计模型中构建一个小的有效测试序列集，以满足某些结构覆盖要求。这些方法不仅可以用于强调规格说明和实现之间一致性的测试，还可用于验证设计规格说明本身。

 

蔡开元博士做了题为“软件可靠性实验研究”的报告，报告介绍了他最近三年的主要研究工作以及研究工作中面临的问题和困惑，蔡博士严谨的工作作风和科学的研究精神得到了与会者的掌声。蔡博士最后针对自己面临的困惑，结合亲身经历发出了“现有科学方法适用于软件吗？”、“软件规律蕴涵于大量的软件观测数据吗？”、“如何证明软件行为的随机性？”以及“软件可靠性研究是个正确的发展方向吗？”等问题。国防科技大学的文职将军齐治昌教授以及与会的学生与其进行了科学实验的随机性和传统科学研究方法普适性方面的讨论。

 

最后，朱鸿博士作了题为“构件化软件集成测试”的报告，在报告之后的自由提问期间，有一位与会代表提出的关于“公理测试的套路”和“测试效率”方面的问题被朱鸿博士评价为“very good questions”，朱鸿博士给出了极为细致和谦虚的解答。总之各位专家不仅在其专业领域的研究工作和进展给大家很大的启发，他们严谨的科学研究态度同样令人折服。

会议结束后，YOCSEF长沙的主席王意洁博士代表YOCSEF向特邀报告专家赠送了纪念品。

 

（周婧供稿2005.7.1）

歌手：陈慧琳 专辑：我是阳光的

看天空飘的云还有梦   看生命回家路路长漫漫   看阴天的岁月越走越远   远方的回忆的你的微笑   天黑路茫茫心中的彷徨   没犹豫的方向   希望的翅膀一天终张开   飞翔天上   看天空飞的鸟还有梦   看清风像带路吹散淡雾   看冬天悲的雪越来越远   昨天的曾经的我的微笑   分开的感伤想飞的彷徨   有天跑出想像   心中一个梦想雨后彩虹   画在天空     歌曲：希望 歌手：陈慧琳 专辑：《grace & charm》   看风筝飞多远未断线 看一生万里路路遥漫漫 看牺牲的脚步尽化温暖 暖的心爱追忆你的微笑 滔滔风雨浪心声相踫撞信将爱能力创 心中的冀望终于都靠岸未曾绝望 看风筝飞高了未断线 看天空雾散聚是谁定下 看艰辛不却步步向温暖 暖的心爱珍惜我的微笑 滔滔风雨浪心声相踫撞信将爱能力创 心中的冀望终于都靠岸未曾绝望 分开的眼泪伤心相挂累 盼将重逢遇上心中只有梦 一天终再聚未来在望

就在昨晚，老板授意要把我待发表的论文上添加几位本科生作者。老板糊涂，为了几个本科生需要论文保研，居然行此下策。

 

老板知道我不会听他的，所以很晚了还打电话逼我就犯。

 

记得当年我考研，在那所国内著名大学复试的时候或多或少受到过一些不公平不公正的待遇，最终很委屈的来到目前的这所大学。我讨厌招生的黑手，讨厌所谓的操作。

 

凡是老板看上的学生，就如同被立了太子一样，大家都要围绕他转。电话里面什么美其名曰“你走了以后这里不能跨掉，必须加强学术梯队的建设”。多好的借口，多好的幌子。学术梯队是这样建设的？老板就不能给那些能力一般的学生一点点机会，就算很普通的学生就不能通过后来的努力迎头赶上？既然要保研，那么就更应该靠自己的实力发表论文。

 

如果系里的每个教授（研究生导师）都有看好的学生，都这样操作，那其他学生还活不活啊。就算他们再努力再刻苦也是白搭啊。想起来就恶心。

 

我也知道社会上这种现象有很多很多，但在象牙塔里我觉得应该保持一片净土。如果为这个事情，老板对我有很大意见，我也认了，至少我可以再清楚的认识他，那个我的老板。

 

附上：

IEEE Policies

6.4 PUBLICATIONS STANDARDS POLICY AND PRINCIPLES FOR AUTHORS, REFEREES, AND EDITORS  

IEEE Publications Standards Policy

The IEEE supports the highest standards of intellectual discourse in its publications.  All members of the publication process -- authors, editors and reviewers -- should be treated with fairness and balance, and adhere to the principles in Section 6.4.1.  The principles in this document represent a minimum set of requirements. Individual publications may have additional requirements.  A publication with additional requirements shall have a publicly available statement of publication policies and procedures that has been endorsed by PSPB.

6.4.1 PUBLICATION PRINCIPLES

A.  Authorship

Authorship credit should be based on a substantial intellectual contribution.  It is assumed that all authors have had a significant role in the creation of a manuscript that bears their names.  Therefore, the list of authors on an article serves multiple purposes; it indicates who is responsible for the work and to whom questions regarding the work should be addressed.  Moreover, the credit implied by authorship is often used as a measure of the contributors’ productivity when they are evaluated for employment, promotions, grants, and prizes.

a)     The IEEE affirms that authorship credit must be reserved for individuals who have met each of the following conditions: 1) made a significant intellectual contribution to the theoretical development, system or experimental design, prototype development, and/or the analysis and interpretation of data associated with the work contained in the manuscript, 2) contributed to drafting the article or reviewing and/or revising it for intellectual content, and 3) approved the final version of the manuscript., including references. (Deceased persons deemed appropriate as authors should be so included with a footnote reporting their death.)

b)     In papers with multiple authorship, the order of the authors shall be at the discretion of the authors.

c)     Once the list and order of authors has been established, the list and order of authors should not be altered without permission of all living authors.

d)     Any part of an article essential to its main conclusions must be the responsibility of at least one author.

e)     In the case of papers with multiple authors, a “corresponding” author must be designated as having responsibility for overseeing the publication process and ensuring the integrity of the final document.  The corresponding author accepts the responsibility for:  1) including as co-authors all persons appropriate and none inappropriate; 2) obtaining from all co-authors their assent to be designated as such, as well as their approval of the final version of the manuscript; and 3) keeping all co-authors apprised of the current status of a manuscript submitted for publication, including furnishing all co-authors with copies of the reviewers’ comments and a copy of the published version, as appropriate.

f)     Co-authors have responsibility for work submitted under their names. They should remain knowledgeable in so far as possible regarding the status of the manuscript, including the nature of any revisions.

g)     If a manuscript is revised and resubmitted to the same journal, co-authors should be asked by the corresponding author to reaffirm their assent to be listed as co-authors and to approve the revised version.  In addition, if the manuscript is rejected or withdrawn from a journal and then submitted to a different IEEE journal, the co-authors should be asked again by the corresponding author to affirm their assent to authorship even if no substantive changes have been made.

h)     Co-authors have the right to withdraw their names from a manuscript at any time before acceptance of the manuscript by the editor.  However, an author’s or co-author’s name should not be removed from a manuscript without his or her permission.  The responsible editor shall be notified of any change in authorship.

B. Responsibilities of Manuscript Authors

a)     Peer review is essential to scientific and technical discourse.  Authors are encouraged to have the first formal publication of their results be a peer-reviewed paper.

b)     Financial support of the work being reported and of the authors should be clearly acknowledged, as should any potential conflict of interest.

c)     Methods and materials should be described in sufficient detail to permit evaluation and replication.

d)     All data should be presented upon request by the editor, to facilitate the review process.

e)     Authors have an obligation to correct errors promptly.

f)     IEEE defines plagiarism as the use of someone else’s prior ideas, processes, results, or words without explicitly acknowledging the original author and source. Plagiarism in any form is unacceptable and is considered a serious breach of professional conduct, with potentially severe ethical and legal consequences. The PSPB Operations Manual provides detailed guidelines for 1) handling allegations of plagiarism, 2) applying appropriate corrective actions when findings of plagiarism have been reached, and 3) referencing previously published material.

g)     Fabrication and falsification are unacceptable.

h)     Except as indicated in Section 6.3.4 (Multiple Publication of Original Technical Material in IEEE Periodicals), authors should only submit original work that has neither appeared elsewhere for publication, nor which is under review for another refereed publication. If authors have used their own previously published work(s) as a basis for a new submission, they are required to cite the previous work(s) and very briefly indicate how the new submission offers substantively novel contributions beyond those of the previously published work(s).

i)      Authors should not discuss any aspect of a manuscript under evaluation with reviewers of the submitted manuscript. 

j)      Only those articles of a researcher’s publication record that are directly relevant to the subject matter of the paper under consideration should be included in the bibliography. Furthermore, an article should be appropriately labeled as "submitted" when still in the review process or "in press" when it has been accepted for publication but has not yet appeared in print.

k)     The IEEE assumes that the material submitted to its publications is properly available for general dissemination to the readership of those publications.  It is the responsibility of the authors, not the IEEE, to determine whether disclosure of their material requires the prior consent of other parties and, if so, to obtain it.  If authors make use of charts, photographs, or other graphical or textual material from previously published material, the authors are responsible for obtaining written permission to use the material in the manuscript.

C.     Referees of Manuscripts

a)     Referees should be chosen for their high qualifications and objectivity regarding a particular manuscript.

b)     Reviews should be prompt and thorough.

c)     Anonymity of referees should be preserved to the extent possible, unless the referee and editor agree to disclosure.

d)      Information contained in a manuscript under review is confidential and must not be shared with others, nor should referees use non-public information contained in a manuscript to advance their own research or financial interests.

D.     Editors of Scientific and Technical Journals

a)     The sole responsibility for acceptance or rejection of a manuscript rests with the editor.

b)     Editors should generally grant the request of an author who asks that particular individual(s) be excluded from the review of a particular manuscript.

c)     Editors should establish a review process that minimizes bias.

d)     Editors should subject all manuscripts of a given type to equivalent and unprejudiced reviews. Decisions about acceptance for publication should occur in a reasonable time frame, and (except for issues devoted to special topics) manuscripts should, to the editor’s best ability, be published in the chronological order of acceptance.

e)     Editors should provide to the authors a written rationale for editorial decisions regarding a manuscript submitted for publication. This is especially important if the manuscript is being rejected.

f)      Unpublished manuscripts must be treated as confidential documents by all individuals involved in the editorial process.

g)     Editors should correct errors in a manuscript if the errors are detected or reported before publication, or publish corrections if they are detected afterward.

h)     Editors should handle cases of alleged misconduct at the lowest possible organizational level, and should usually involve the institutions at which the research in question was performed (see below).

i)      Papers submitted by an editor or associate editor should be handled by another member of the editorial board.

The IEEE is grateful to the Society for Neuroscience for permission to adopt portions of its publication, “Guidelines: Responsible Conduct Regarding Scientific Communication”, to use in the preparation of the IEEE Publications Policy.

1996年度“中创软件基金”获奖人员简介

　　王怀民
　　863专家、国防科技大学计算机学院·博士。 王怀民博士在人工智能及分布式计算技术领域做出了多项创造性成果，在国内计算机界具有较大影响。特别是他系统地提出了以中间件为核心的“分布式Client/Server计算机系统”的设计方案，成功地开发了基于分布对象技术的新一代系统集成中间件StarBus，对Client/Server结构的开放系统具有重要的理论和实践价值。

　　朱鸿
　　南京大学软件研究所·博士。朱鸿博士一直致力于计算机软件理论、方法和技术研究，取得了一系列具有重要理论意义和应用价值的成果。他提出的函数式程序的综合方法被牛津大学出版的研究生教科书专章介绍，并被用于英国King’s College的研究生教学；在软件测试和软件安全性方面，他也做出了创新性的成果，著有《软件质量保障与测试》等专著。朱鸿博士曾多次为技术骨干参与了“八五”攻关、“863”高技术等重大科研项目。

　　张松懋
　　中科院数学所·博士。张松懋博士创造性地运用高维上下文有关文法为自然语言理解这一国际性课题开辟了一条新的途径，在国内外都得到了较高的评价。她作为第二负责人参与主持了中科院院长基金课题“全过程计算机辅助动画制作”，研制的“神笔马良”软件系统在国际上首次实现了真正的计算机动画自动制作，达到国际领先水平。张松懋博士曾多次参与或主持863项目、院长基金课题和国家自然科学基金项目。

 

1997年度“中创软件基金”获奖人员简介

　　王戟
　　国防科技大学计算机学院·博士。王戟博士在软件方法学，特别是形式化方法和混成实时计算方面做出了诸多创新性成果。他提出了基于模型检验的实时系统形式化验证与分析方法；提出了混合实时系统层次化抽象模型；提出了基于对象间和对象内二级并发的实时系统形式模型；提出了基于CSP的混合系统设计语言HCSP及其时段语义；提出了基于时段演算的混合系统的归约推理和自动机综合设计框架。王戟博士多次参加了863、国防预研项目的研究工作。

　　金芝
　　中科院数学所·博士。金芝博士对逻辑程序和面向对象程序风范的结合、对非单调推理和逻辑程序的结合等方面有深入研究；并在知识工程和专家系统、软件工程和应用软件开发、自然语言理解和人机接口开发等方面做出了出色工作；曾在多项国家攻关科技项目中担任重要工作。

　　金凌紫
　　南京大学软件所·博士。金凌紫博士在软件自动化、软件复用、需求工程和软件质量保障与测试技术方面取得突出成果，并参加了《软件质量保障与测试》、《Software Without Frontiers》等专著的编写。她提出了一种基于知识的由输入/输出实例自动综合程序的方法与系统，已被英国伦敦大学用于研究生教学，并被英国学者Hutchinson编入其专著《Algorithmic Learning》；多次参加国家科技攻关和863科技项目开发，并主持一项国家自然科学基金及国家教委留学回国人员基金项目。

　　梅宏
　　北京大学计算机系·博士。梅宏博士的研究工作涉及到新型程序设计语言、软件工程和软件开环境、软件复用、面向对象技术方面，其工作具有基础性、系统性和创新性，受到学术界的重视，并在同行中产生了较大的影响。他设计实现了多种新型程序设计语言(合成型语言FOPL、BDOL)；参与国家重点科技攻关项目北大“青鸟系统”开发，负责JB2环境的集成工作，创造性地解决了若干技术问题。

贲可荣，男，1986年8月入伍，现专业技术7级，文职4级。1983年7月毕业于苏州大学数学系，获理学学士学位，1986年7月毕业于南京大学数学系基础数学专业，获理学硕士学位，1994年6月毕业于国防科技大学计算机系计算机软件专业，获工学博士学位。学校首批培养的33名学科带头人之一。2001年2月，经教育部批准，被确定为海军首批十名骨干教师之一。2000年5月，经教育部批准，被武汉大学软件工程国家重点实验室聘为访问学者。学校学位评定委员会委员、科学技术委员会委员。中国计算机学会计算机理论专业委员会委员、中国造船工程学会电子技术委员会委员、武汉软件工程学会副理事长。海军工程大学学术研究中心研究员。《海军工程大学学报》、《舰船电子工程》编委。

    承担博士生的《人工神经网络》、硕士生的《软件测试技术》、《软件可靠性》、《算法设计与分析》、《人工智能》和本科生的《人工智能导论》、《软件工程导论》、《离散数学》、《软件能力成熟度模型》等课程的主讲任务。在软件可靠性、软件测试技术、软件质量保证技术、信息安全、程序理论及计算机应用等方面有较强的研究能力。承担了包括国家自然科学基金、国家863项目、高等学校骨干教师资助计划项目、国家重点实验室开放基金、国家重点实验室访问学者项目和海军装备部课题等国家级科研项目7项。在“中国科学”、“数学年刊”等刊物发表论文40余篇。 

 

     “把微笑留给伤害你最深的人。”这是我无意中看到的一句话，读后就深深的记住了。这是多么坚强而洒脱的人生，这其中要经历多少爱与恨的交织。

 

      男女之间从见面心跳到两情相悦，再到彼此间出神入化的心灵呼唤，也许要走很长的一段路程，而从一切不设防，连心带身都纯真地呈现给对方，再到万般柔情都化为一声震撼心灵的叹息，也只需短暂的一瞬。

 

      当昔日的真爱已不存在，当感情的繁花已被秋雨打得残红飘零时，人们总是习惯于久久地停息在爱情的树枝上低吟浅唱，不是心里仍眷恋那份早已随风而逝的柔情，企求伤害自己的人回心转意，就是下定决心以同样的方式实行报复，但这都是不明智,不潇洒，不可爱的。

 

      最恰当的方法就是微笑着向他道珍重。

 

      把微笑留给负于我们的人，把泪水留给自己；把祝福给有负于我们的人，把痛苦留给自己。没有较高的文化修养，没有对感情细微的洞察，没有对所爱的人发自内心的挚爱，谁能做到微笑告别？

   

      把微笑留给一般朋友已不易，给有负我们的人更是难上加难。因为最伤害我们的人往往就是我们最深爱的人，付出的越多，被伤害时心里越疼。然而我们不得不微笑，感情本身是个很玄很复杂的事。我们不能勉强他人，相爱的理由有千百条，不爱的千百条理由可能一条也站不住脚，这其中的奥秘又有谁能说得清？

 

     爱情无解，爱情无常。我们可以牺牲爱情，却不能牺牲人格和自尊，那是人活着的首要意义。

 

      以伤害来对付伤害固然是一种解恨的办法，但伤害的结果只能更加坚定你爱的人离去的决心。爱情是把双刃剑，一头对着对方，另一头直指自己。一时的宣泄虽淋漓，一世的悲怆更难耐。

 

      暂时的内心平衡只能加重自身的遍体鳞伤，何苦扰了别人，又伤了自己呢？

 

      还是把那微笑留给伤害你最深的人吧！ 把微笑留给伤害你最深的人。

一般文科的，除了很少部分人工作不错外，大多数工作相对来说都比较难找，包括硕士和博士。当然有关系的就不用我们操心了。理科的学生，要么出国，要么读博士留校。不过能达到愿望的也只是一少部分人。其他大部分人是走入社会，到公司、企业或其他单位。

 

还有相当一部分人是选择转行。目前很多的大学毕业的从事的职业都于自己的专业无关。在这个扩招的年代，其实学工科的也同样面临这些问题，出国、留校、工作、转行的都有，只是现实条件下相对来说选择面宽点。很多工科学习内容比理科更多，理论加实践。

 

没有选择是悲惨的，但有选择却又是痛苦的。

 

其实有一点可以解决所有问题，如果你志愿为你选择的专业奉献一生的话，那什么都难不倒你，其他一切因素都不重要，你只需要专注于你的兴趣再选择专业，无论是文理工。各个领域都能出大家，而到了那个阶段就不会出现互相贬低的问题，因为一切事物都是相通互的。PHD就是哲学，关乎人生、自然、宇宙、芸芸众生等等。而不是互相攀比和排斥，也不是名利之争。不过现在很多PHD似乎都......真不想说了。

 

现实和理想是有差距的，对于很多人来说，这种差距是一条很难逾越的鸿沟。

 

每个人适合的道路是不同的，大家需要的是找到合适自己的人生规划。别人的意见可以听，但是别被纷扰的言论迷惑了你的心，毕竟没有人比你自己更了解你。只有你自己才能对你自己的生活负责，其他人都代替不了。文理工，没有高低好坏之分，区别只在于你的选择。就如同选择空气还是选择水，那是你 自己的决策。

 

现在很多人争来争去的学校排名也是很虚的东西。也许会暂时增加一点虚无的满足感或虚荣心，但真要把这当回事将来只会给自己增加失落感，因为那玩艺儿对于你的人生和理想基本没有太大帮助，并且也不能反映出真实的情况。尤其是在中国现在的历史条件下。

 

真正能够做到不已物喜，不已己悲的人又有多少呢。我自己试图做到，但是，觉得光有理想并为之不懈的努力远远不够，其实生存的压力好大，影响我前进的因素太多。